Xterm.js: ¿Soporte de ZModem?

¿Podrías entrar en más detalles sobre cómo funcionaría esto en xterm.js?

Uso xterm.js para conectarme a un bash (un bash con todas las funciones) y dejar que el usuario interactúe con el bash. Me gustaría que el usuario de soporte cargue / descargue archivos a través de la terminal web usando rz / sz.

Si me conecto al shell de una máquina con SecureCRT / Xshell, puedo cargar / descargar archivos con el comando rz / sz . Me gustaría usar zterm.js para conectarme al shell de una máquina y cargar / descargar archivos con el comando rz / sz

Zmodem es una característica de protocolo de la abstracción de línea serial subyacente del sistema PTY. Esto ya se puede utilizar con herramientas como zssh en xterm.js. xterm.js en sí solo está reenviando el IO maestro del PTY al navegador. En realidad, está operando en el sistema donde está alojada la parte del servidor xterm.js.

Esto es bastante diferente a un emulador de terminal que opera en la misma máquina como lo hace SecureCRT.

Entonces, la pregunta es: ¿De qué máquina a qué máquina desea mover archivos a través de la terminal? (Recuerde que su máquina local no tiene un canal de terminal a la parte del servidor de xterm.js).

|       local machine               |
|   +----------------------------+  |
|   |       browser              |  |
|   |   +-------------------+    |  |               +---------------------------+          +------------------------+
|   |   |                   |    |  |               |   proxy                   |          |                        |
|   |   |   web terminal    >----------------------->   server part of xterm.js >----------| romote machine terminal|
|   |   |                   |    |  |               +---------------------------+          +------------------------+
|   |   |                   |    |  |
|   |   +-------------------+    |  |
|   +----------------------------+  |
+-----------------------------------+

Me gustaría mover archivos de la máquina local a la máquina remota. La máquina local no puede acceder directamente a la máquina remota, ya que no tiene ip externa.

Recuerde que su máquina local no tiene un canal de terminal a la parte del servidor de xterm.js

¿Existe alguna solución para esto?

Bueno, puedes usar zssh (con soporte zmodem), sftp o scp desde el proxy.

A menos que alguien lo implemente, no hay forma de subir / descargar archivos directamente desde el terminal web en su navegador a la máquina remota. Uno de los protocolos de módem podría usarse de esa manera (hay una implementación XModem JS), pero como el navegador tiene un acceso muy limitado al sistema de archivos, dudo de su utilidad. La parte difícil sería proporcionar una interacción de descarga con el navegador para archivos grandes (dado que los datos aterrizan directamente en el navegador a través del websocket, JS tendría que retener todos los datos hasta que se puedan guardar).

Otro enfoque sería mejorar la parte del servidor con la funcionalidad rz / sz y mapear eso de forma transparente al navegador. Esto eludiría las limitaciones de FS del navegador, pero necesitaría conectar otro analizador al flujo del terminal para captar la inicialización 'rz \ r' de los protocolos del módem.

He estado trabajando en una implementación de ZMODEM en JavaScript y lo tengo transfiriendo archivos en ambas direcciones a través de xterm.js.

De hecho, el navegador tiene que almacenar en búfer todo el archivo cuando lo recibe. :( Sin embargo, ese es realmente el único inconveniente, y no está mal a menos que esté enviando archivos muy grandes. Las cargas se pueden realizar a través de FileReader, y las descargas se realizan a través del atributo "download" de los elementos <a> .

Todavía lo estoy probando y documentándolo, pero ¿es la integración de ZMODEM una característica que interesaría a xterm.js?

@FGasper Nice :) Suena prometedor, si lo implementó con la API de flujo de nodo, también podría ser útil para archivos grandes como una extensión del lado del servidor, que envía esos archivos al punto final del navegador a través del enlace de descarga.

La biblioteca en sí es independiente de la plataforma, por lo que debería funcionar en cualquier lugar. (Toco madera.)

@FGasper suena genial 😄!

Definitivamente podemos considerar un complemento zmodem, si funciona en el navegador.

¿Cuáles son generalmente los casos de uso para usar zmodem?

Lo uso para realizar transferencias de archivos dentro de una sesión de terminal hacia / desde mi estación de trabajo. Le permite no tener que usar scp / sftp o lo que sea.

Similar a esto para iTerm2:
https://github.com/mmastrac/iterm2-zmodem

@parisk Los rz / sz para lograr esto.

Bueno, para xterm.js es un complemento perfecto, aumentará la utilidad de xterm.js para administradores de servidores en entornos restringidos. : +1:

NB: XMODEM e YMODEM tienen el inconveniente de no "preguntar" al otro lado que hay una transferencia de archivos lista. (¡Es una pena porque son mucho más simples!)

ZMODEM envía lo que es esencialmente una "cadena mágica" que se puede observar; luego le pregunta al usuario, “ZMODEM detectó; continuar con la transferencia de archivos? " En ese punto, la implementación proporciona los medios para proporcionar archivos para transferir o para aceptar / omitir archivos a medida que el remitente los ofrece.

Para xterm.js, sería bueno simplemente arrastrar y soltar archivos en el terminal; digamos que un archivo se guarda en la ruta actual del shell del terminal. Pero eso es muy complicado de lograr a menos que xterm.js pueda controlar el propio shell remoto o al menos tomar el directorio de trabajo actual en cualquier momento. Lo mismo ocurre al revés: si una lista ls pudiera identificarse como una referencia a archivos remotos, arrastrar y soltar fuera de la terminal estaría bien. Bueno, solo soñando: guiño:

No veo por qué arrastrar / soltar rz no sería factible una vez iniciada la sesión de Zmodem. Podría implementarse de varias formas, pero tal vez:

1) Escriba rz en su consola.
2) Arrastra y suelta archivos en formato.
3) Inicie la transferencia.

Pregunta: ¿Qué tan configurado está xterm.js todavía en el soporte de IE?

No más soporte de IE en v3 debido a https://github.com/sourcelair/xterm.js/pull/938 , los desarrolladores deberían dejar de usarlo de todos modos.

Me gustaría mostrarles una demostración.

He estado probando contra mi propio servidor de terminal, pero me gustaría usar lo que tengan por defecto.

^^ ¿Me estoy perdiendo algo aquí? npm install errores para mí ...

felipe@Macintosh-4 18:00:56 ~/code/p5-Net-WebSocket/demo
> sudo npm install
npm ERR! install Couldn't read dependencies
npm ERR! Darwin 16.7.0
npm ERR! argv "/opt/local/bin/node" "/opt/local/bin/npm" "install"
npm ERR! node v8.3.0
npm ERR! npm  v2.15.12
npm ERR! path /Users/felipe/package.json
npm ERR! code ENOPACKAGEJSON
npm ERR! errno -2
npm ERR! syscall open

npm ERR! package.json ENOENT: no such file or directory, open '/Users/felipe/package.json'
npm ERR! package.json This is most likely not a problem with npm itself.
npm ERR! package.json npm can't find a package.json file in your current directory.

npm ERR! Please include the following file with any support request:
npm ERR!     /Users/felipe/code/p5-Net-WebSocket/demo/npm-debug.log

¿Quizás te olvidaste de git clone ... ? ¿Y por qué con sudo ?

@FGasper

npm ERR! package.json ENOENT: no such file or directory, open '/Users/felipe/package.json'

Está ejecutando npm install en su directorio de inicio, no en el directorio de repositorio.

¿Hay alguna manera de hacer que node-pty genere binarios en lugar de cadenas? ZMODEM es un protocolo binario, pero la demostración parece pensar que todo es UTF-8. En particular, algo parece convertir 0x8a a UTF-8 \ ufffd

Esto podría ser un poco más complicado: para una solución rápida, puede intentar deshabilitar los codificadores de node-pty o establecer el tipo de cadena en 'binario', pero esto podría tener impactos no deseados en la transferencia de websocket a xterm.js. Por lo que puedo decir, toda la cadena node-pty <---> websocket <---> xterm.js basa en bytes UTF-8 que se decodifican en cadenas JS sobre la marcha. Es posible que necesite un parche mayor para que los datos binarios fluyan.

¿Dónde está esa configuración de tipo de cadena binary ? (¿No veo eso en node-pty?)

Lo mejor que puedo decir es que los datos ya están dañados cuando llegan a app.js , por lo que el cambio de comportamiento tendría que estar en node-pty.

ZMODEM deletrea una codificación que escapa a todos los caracteres de bits altos hasta 7 bits, pero aparentemente nunca se implementó realmente ... Forsberg probablemente pensó que nunca sería necesario ya que todas las líneas se volvieron seguras para 8 bits, je. :)

Puede probar con {encoding: 'binary'} en las opciones de ctor o .setEncoding('binary') sobre la marcha.

Parece que el node-pty más reciente permite configurar o no configurar el modo UTF8 ...

  if (info[8]->ToBoolean()->Value()) {
#if defined(IUTF8)
    term->c_iflag |= IUTF8;
#endif
}

https://github.com/Tyriar/node-pty/blob/master/src/unix/pty.cc

Hm ... el node-pty que extrae xterm.js (0.4.1) es bastante antiguo ... tal vez la versión más reciente incluiría ese indicador.

Llamar a .setEncoding('binary') no funciona… y tampoco pasar encoding:"binary" a pty.spawn ().

IUTF8 de termios hace algo diferente: permite el manejo correcto de caracteres UTF8 de múltiples bytes en el dispositivo pty (para ancho de línea y borrado).
Hmm, tal vez de la manera más difícil, intente quitar el codificador:

delete ptyObj._socket._readableState.decoder;
delete ptyObj._socket._readableState.encoding;

Esto debería proporcionarle objetos de búfer en lugar de cadenas (lo más probable es que se rompa hacia xterm.js).

De acuerdo, lo obtuve actualizando a node-pty 0.6.4 y configurando la codificación en null . (No necesitaba las cosas _readableState .) Aún envía la primera línea de la sesión de shell como texto, pero todo lo que sigue es binario, muy bueno.

Todavía envía la primera línea de la sesión de shell como texto ...

Incluso si lo aplica al constructor como {encoding: null} ?

Sí, incluso con {encoding: null} la primera línea se envía como un marco de texto.

Tengo esto en lo que creo que es un estado razonable para probarlo.

1) Configure https://github.com/FGasper/xterm.js.git como control remoto.
2) Echa un vistazo a la rama zmodem ese repositorio.
3) git submodule init; git submodule update
4) npm install (Ver más abajo).
5) npm start , luego cargue localhost:3000 en el navegador. (Chrome es lo que he probado).
6) ssh a una máquina que tiene lrzsz instalado.
7) Escriba rz y envíe uno o más archivos desde su estación de trabajo al control remoto.
8) sz <filename1> <filename2> … enviará archivos en un lote a su estación de trabajo.

(La interfaz de usuario es mínima por diseño; se supone que una implementación "real" la puliría más).

Con respecto al paso 4: cuando probé hace un momento en mi estación de trabajo, tuve que solucionar un problema de permisos con el paquete node-gyp .

Bien, funciona a las mil maravillas (probado con archivos de texto en Firefox).

Solo unas pocas observaciones:

• ¿Es posible activar la secuencia de inicio por accidente (por ejemplo, salida de datos aleatorios)? Si es así, la terminal en mi humilde opinión necesitaría una configuración de "ingresar transferencia de archivos" para hacer esto explícito.
• El "Iniciar sesión ZMODEM" debe ser interrumpible, seleccionar "No" no cancela rz en el otro extremo del cajero automático.
• ¿Es posible dibujar alguna barra / indicador de progreso en el widget del terminal mientras la transferencia está en curso? O algunas otras cosas más sofisticadas, atm rz/sz imprime algunos números de estado extraños en la terminal.

@jerch

1) Sí, es posible activar la secuencia de inicio por accidente. Para eso es el mensaje "Iniciar sesión ZMODEM": el usuario aún puede retroceder si es necesario.

2) Debería arreglarse ahora.

3) La aplicación recibe eventos progress en sincronización con la API FileReader del navegador. Chrome parece ofrecer contenido con progress ; sin embargo, Firefox en realidad no proporciona el contenido del archivo en esos eventos. Si se envía a sí mismo un archivo suficientemente grande en Chrome, verá algo como:

4) Los caracteres extraños al comienzo de una sesión son las partes imprimibles de la secuencia de inicio de recepción de ZMODEM: ** + ASCII CAN + B01 + 10 caracteres hexadecimales + CR + 0x8a + XON. Estoy de acuerdo en que es feo que vayan a la pantalla; sin embargo, es bastante estándar en los terminales con conocimientos de ZMODEM que he usado. Supongo que podría enviar suficientes caracteres BS al terminal para eliminar esos caracteres.

También es necesario agregar un control para cancelar una transferencia en curso. Todavía estoy buscando la mejor manera de manejar eso.

También es necesario agregar un control para cancelar una transferencia en curso. Todavía estoy buscando la mejor manera de manejar eso.

¿Quizás esto de las especificaciones ayude?

A ZFIN, ZABORT, or TIMEOUT terminates the session; a ZSKIP terminates the processing of
this file.

Potencialmente. La especificación no siempre es lo más útil; por ejemplo, menciona una secuencia Attn que se envía después de un ZSINIT. La especificación parece sugerir que así es como hacer que un remitente pause un envío de datos, pero aparentemente nada usa Attn. Lo mismo ocurre con la opción ESC8: en realidad no está implementado en lrzsz , y dado que esa es la implementación de referencia de facto, ESC8 no se puede usar, lo cual es una pena porque solucionaría muy bien ese problema con el indicador termios IEXTEN.

Estoy en un poco de tiempo en otros proyectos en este momento, pero espero volver a esto la semana que viene.

Si puedo agregar mis dos centavos con respecto a la forma de esto para convertirlo en un complemento xterm: propondría no agregar una interfaz de usuario en absoluto, sino enviar cosas a través de un evento, similar a los flujos de nodos. Algo como

term.on('transfer', (transfer) => {

  // accept or reject the transfer
  transfer.accept();

  // listen for progress
  transfer.on('progress', ...);

  // data chunks arrive
  transfer.on('data', ...);

  // transfer has finished
  transfer.once('end', ...);

  // cancel transfer
  transfer.abort();

});

De esta manera, un consumidor puede crear su propia interfaz de usuario sobre el complemento.

@mofux Así es como me gustaría que esto también funcionara. Los componentes de la interfaz de usuario que he incluido en la demostración están pensados ​​solo para demostrar los controles.

@FGasper Buen trabajo 👍

Voy a agregar soporte de ZModem para ttyd cuando su api esté lista para usar (https://github.com/tsl0922/ttyd/issues/37), gracias por su trabajo.

https://www.npmjs.com/package/zmodem.js

Hice una versión ALPHA de zmodem.js. Desde aquí, miraré la interfaz del complemento para xterm.js, pero cualquiera que quiera ver zmodem.js, no dude en hacerlo y déjeme saber cómo funciona para usted.

El complemento ZMODEM ahora está combinado, FYI.

sistema win7

$ npm run start-zmodem

> [email protected] start-zmodem E:\test\xterm\xterm.js
> node demo/zmodem/app

App listening to http://127.0.0.1:3100

¿Por qué no puedo abrir el Explorador de archivos?