Xterm.js: Prise en charge de ZModem ?

Pourriez-vous s'il vous plaît entrer dans plus de détails sur la façon dont cela fonctionnerait sur xterm.js ?

J'utilise xterm.js pour me connecter à un bash (un bash complet) et laisser l'utilisateur interagir avec le bash. J'aimerais aider l'utilisateur à télécharger/télécharger un fichier via un terminal Web en utilisant rz/sz.

Si je me connecte au shell d'une machine avec SecureCRT/Xshell, je peux charger/télécharger des fichiers avec la commande rz / sz . J'aimerais utiliser zterm.js pour me connecter au shell d'une machine et charger/télécharger des fichiers avec la commande rz / sz

Zmodem est une fonctionnalité de protocole de l'abstraction de ligne série sous-jacente du système PTY. C'est déjà utilisable avec des outils comme zssh dans xterm.js. xterm.js lui-même ne fait que transmettre l'E/S maître du PTY au navigateur. En réalité, vous opérez sur le système sur lequel la partie serveur xterm.js est hébergée.

C'est assez différent d'un émulateur de terminal fonctionnant sur la même machine que SecureCRT.

La question est donc - De quelle machine vers quelle machine voulez-vous déplacer des fichiers via le terminal ? (N'oubliez pas que votre machine locale n'a pas de canal de terminal vers la partie serveur de xterm.js).

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

J'aimerais déplacer des fichiers de la machine locale vers la machine distante. La machine distante n'est pas accessible directement par la machine locale, car elle n'a pas d'adresse IP externe.

N'oubliez pas que votre machine locale n'a pas de canal de terminal vers la partie serveur de xterm.js

Existe-t-il une solution de contournement pour cela?

Eh bien, vous pouvez utiliser zssh (avec prise en charge de zmodem), sftp ou scp à partir du proxy.

À moins que quelqu'un ne l'implémente, il n'y a aucun moyen de télécharger / télécharger des fichiers directement depuis le terminal Web de votre navigateur vers la machine distante. L'un des protocoles de modem pourrait être utilisé de cette façon (il existe une implémentation XModem JS), mais comme le navigateur a un accès très limité au système de fichiers, je doute de son utilité. La partie difficile serait de fournir une interaction de téléchargement avec le navigateur pour les gros fichiers (puisque les données atterrissent directement dans le navigateur via le websocket, JS devrait conserver toutes les données jusqu'à ce qu'elles puissent être enregistrées.)

Une autre approche serait d'améliorer la partie serveur avec la fonctionnalité rz/sz et de la mapper de manière transparente avec le navigateur. Cela contournerait les limitations FS du navigateur mais nécessiterait de connecter un autre analyseur au flux du terminal pour détecter l'initialisation 'rz\r' des protocoles du modem.

J'ai travaillé sur une implémentation ZMODEM en JavaScript et je lui fais transférer des fichiers dans les deux sens via xterm.js.

Le navigateur doit en effet mettre en mémoire tampon l'intégralité du fichier lorsqu'il le reçoit. :( C'est vraiment le seul inconvénient, cependant, et ce n'est pas mal à moins que vous n'envoyiez de très gros fichiers. Les téléchargements peuvent être effectués via FileReader, et les téléchargements se font via l'attribut « téléchargement » des éléments <a> .

Je suis toujours en train de le tester et de le documenter, mais l'intégration de ZMODEM est-elle une fonctionnalité qui intéresserait xterm.js ?

@FGasper Nice :)

La bibliothèque elle-même est indépendante de la plate-forme, elle devrait donc fonctionner n'importe où. (Touchons du bois.)

@FGasper a l' air bien  !

Nous pouvons certainement envisager un addon zmodem, s'il fonctionne dans le navigateur.

Quels sont généralement les cas d'utilisation de zmodem ?

Je l'utilise pour effectuer des transferts de fichiers au sein d'une session de terminal vers/depuis mon poste de travail. Cela vous permet de ne pas avoir à scp/sftp ou autre.

Similaire à ceci pour iTerm2 :
https://github.com/mmastrac/iterm2-zmodem

@parisk Les rz / sz pour accomplir cela.

Eh bien, pour xterm.js, c'est un complément parfait, il augmentera l'utilité de xterm.js pour les administrateurs de serveur dans des environnements restreints. :+1:

NB : XMODEM et YMODEM ont tous deux l'inconvénient de ne pas "inviter" l'autre côté qu'il y a un transfert de fichier prêt. (C'est dommage car ils sont beaucoup plus simples !)

ZMODEM envoie ce qui est essentiellement une « chaîne magique » qui peut être surveillée ; puis vous demandez à l'utilisateur « ZMODEM détecté ; procéder au transfert de fichiers ? » À ce stade, la mise en œuvre fournit des moyens soit de fournir des fichiers à transférer, soit d'accepter/ignorer des fichiers comme l'expéditeur les propose.

Pour xterm.js, il serait intéressant de simplement glisser-déposer des fichiers dans le terminal - disons qu'un fichier est enregistré dans le chemin actuel du shell du terminal. Mais c'est très difficile à accomplir à moins que xterm.js puisse contrôler le shell distant lui-même ou au moins récupérer le répertoire de travail actuel à tout moment. Il en va de même pour l'arrière - si une liste ls pouvait être repérée comme faisant référence à des fichiers distants, un glisser-déposer hors du terminal serait pratique. Eh bien je rêve :wink:

Je ne vois pas pourquoi le glisser/déposer rz ne serait pas faisable une fois la session Zmodem démarrée. Cela pourrait être mis en œuvre de plusieurs manières, mais peut-être :

1) Tapez rz dans votre console.
2) Glissez/déposez les fichiers dans.
3) Lancez le transfert.

Question : Comment xterm.js est-il toujours pris en charge par IE ?

Plus de support IE dans la v3 en raison de https://github.com/sourcelair/xterm.js/pull/938 , les développeurs devraient de toute façon l'arrêter.

J'aimerais vous montrer une démo.

J'ai testé mon propre serveur de terminaux, mais j'aimerais utiliser ce que vous avez par défaut.

^^ Est-ce que j'ai raté quelque chose ici ? npm install erreurs pour moi…

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

Peut-être avez-vous oublié git clone ... ? Et pourquoi avec sudo ?

@FGasper

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

Vous exécutez npm install dans votre répertoire personnel, pas dans le répertoire du référentiel.

Existe-t-il un moyen de faire en sorte que node-pty produise du binaire plutôt que des chaînes? ZMODEM est un protocole binaire, mais la démo semble penser que tout est UTF-8. En particulier, quelque chose semble convertir 0x8a en UTF-8 \ufffd

Cela peut être un peu plus compliqué - pour une solution rapide, vous pouvez essayer de désactiver les encodeurs de node-pty ou de définir le type de chaîne sur « binaire », mais cela peut avoir des impacts indésirables sur le transfert de websocket vers xterm.js. Pour autant que je sache, toute la chaîne node-pty <---> websocket <---> xterm.js repose sur des octets UTF-8 qui sont décodés en chaînes JS à la volée. Peut-être besoin d'un correctif plus important pour que les données binaires circulent.

Où est ce paramètre de type de chaîne binary ? (Je ne vois pas cela dans node-pty?)

Pour autant que je sache, les données sont déjà corrompues au moment où elles atteignent app.js , donc le changement de comportement devrait être dans node-pty.

ZMODEM énonce un codage qui échappe à tous les caractères à bits élevés jusqu'à 7 bits, mais il n'a apparemment jamais été réellement implémenté… Forsberg a probablement pensé que cela ne serait jamais nécessaire car toutes les lignes devenaient sécurisées sur 8 bits, heh. :)

Vous pouvez essayer avec {encoding: 'binary'} dans les options ctor ou .setEncoding('binary') à la volée.

Il semble que le node-pty le plus récent permette de paramétrer ou non le mode 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… le node-pty que xterm.js extrait (0.4.1) est assez ancien… peut-être que la version la plus récente inclurait ce drapeau.

L'appel de .setEncoding('binary') ne fonctionne pas … et la transmission de encoding:"binary" à pty.spawn() ne fonctionne pas non plus.

IUTF8 de termios fait une chose différente - il permet une gestion correcte des caractères UTF8 multi-octets dans le périphérique pty (pour la largeur de ligne et l'effacement).
Hmm peut-être à la dure - essayez de supprimer l'encodeur :

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

Cela devrait vous donner des objets tampon au lieu de chaînes (le plus susceptible de se briser vers le haut vers xterm.js).

OK, je l'ai obtenu en passant à node-pty 0.6.4 et en définissant l'encodage sur null . (Je n'avais pas besoin des trucs _readableState .) Il envoie toujours la première ligne de la session shell sous forme de texte, mais tout après est binaire, donc cool.

Il envoie toujours la première ligne de la session shell sous forme de texte ...

Même si vous l'appliquez au constructeur en tant que {encoding: null} ?

Oui, même avec {encoding: null} la première ligne est envoyée sous forme de cadre de texte.

J'ai ceci dans ce que je pense être un état raisonnable pour l'essayer.

1) Configurez https://github.com/FGasper/xterm.js.git en tant que télécommande.
2) Vérifiez la branche zmodem dépôt.
3) git submodule init; git submodule update
4) npm install (Voir ci-dessous.)
5) npm start , puis chargez localhost:3000 dans le navigateur. (Chrome est ce que j'ai testé.)
6) ssh sur une machine sur laquelle lrzsz installé.
7) Tapez rz et envoyez un ou plusieurs fichiers de votre poste de travail vers la télécommande.
8) sz <filename1> <filename2> … enverra les fichiers par lots à votre poste de travail.

(L'interface utilisateur est minimale par conception ; en principe, un déploiement « réel » la peaufinerait davantage.)

Concernant l'étape 4 : Lorsque je viens de tester sur mon poste de travail, j'ai dû résoudre un problème de permissions avec le package node-gyp .

Nice, fonctionne comme un charme (testé avec des fichiers texte dans Firefox).

Juste quelques remarques :

• Est-il possible de déclencher la séquence d'initialisation par accident (par exemple, sortie de données aléatoires) ? Si tel est le cas, le terminal aurait besoin à mon humble avis d'un paramètre "enter file transfer" pour rendre cela explicite.
• Le « Démarrer la session ZMODEM » doit être interrompu, la sélection de « Non » n'interrompt pas rz à l'autre extrémité de l'atm.
• Est-il possible de dessiner une barre de progression / un indicateur dans le widget du terminal pendant que le transfert est en cours ? Ou d'autres trucs plus sophistiqués, atm rz/sz imprime des numéros de statut étranges dans le terminal.

@jerch

1) Oui, il est possible de déclencher la séquence d'initialisation par accident. C'est à cela que sert l'invite « Démarrer la session ZMODEM » : l'utilisateur peut toujours revenir en arrière en cas de besoin.

2) Devrait être corrigé maintenant.

3) L'application reçoit des événements progress en synchronisation avec l'API FileReader du navigateur. Chrome semble donner du contenu avec progress ; Cependant, Firefox ne donne pas réellement le contenu du fichier dans ces événements. Si vous vous envoyez un fichier suffisamment volumineux dans Chrome, vous verrez quelque chose comme :

4) Les caractères étranges au début d'une session sont les parties imprimables de la séquence d'initialisation de réception ZMODEM : ** + ASCII CAN + B01 + 10 caractères hexadécimaux + CR + 0x8a + XON. Je suis d'accord que c'est moche qu'ils aillent à l'écran ; cependant, c'est assez standard dans les terminaux ZMODEM-savvy que j'ai utilisés. Je suppose qu'il pourrait envoyer suffisamment de caractères BS au terminal pour supprimer ces caractères?

Il est également nécessaire d'ajouter un contrôle pour annuler un transfert en cours. Je suis toujours à la recherche de la meilleure façon de gérer cela.

Il est également nécessaire d'ajouter un contrôle pour annuler un transfert en cours. Je suis toujours à la recherche de la meilleure façon de gérer cela.

Peut-être que cela des spécifications aide?

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

Potentiellement. La spécification n'est pas toujours la chose la plus utile ; par exemple, il mentionne une séquence Attn qui est envoyée après un ZSINIT. La spécification semble suggérer que c'est ainsi qu'un expéditeur suspend un envoi de données, mais apparemment, rien n'utilise réellement Attn. De même avec l'option ESC8 : elle n'est pas réellement implémentée dans lrzsz , et puisque c'est l'implémentation de référence de facto, ESC8 est inutilisable, ce qui est dommage car cela contournerait bien ce problème avec le drapeau termios EXTEN.

Je suis un peu pressé par le temps sur d'autres projets en ce moment, mais j'espère y revenir la semaine prochaine.

Si je peux ajouter mes deux cents concernant la forme de ceci pour en faire un plugin xterm : je proposerais de ne pas ajouter du tout d'interface utilisateur, mais de répartir les choses via un événement, similaire aux flux de nœuds. Quelque chose comme

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 cette façon, un consommateur peut créer sa propre interface utilisateur au-dessus du plugin.

@mofux C'est comme ça que je voudrais que cela fonctionne aussi. Les composants de l'interface utilisateur que j'ai mis dans la démo sont uniquement destinés à démontrer les commandes.

@FGasper Bon travail

Je vais ajouter la prise en charge de ZModem pour ttyd lorsque votre api sera prête à l'emploi (https://github.com/tsl0922/ttyd/issues/37), merci pour votre travail.

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

J'ai fait une version ALPHA de zmodem.js. À partir de là, je vais regarder l'interface du plugin pour xterm.js, mais tous ceux qui veulent regarder zmodem.js, n'hésitez pas à le faire et faites-moi savoir comment cela fonctionne pour vous.

L'addon ZMODEM est maintenant fusionné, pour votre information.

système 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

pourquoi ne peut-il pas ouvrir l'explorateur de fichiers ?