Asciinema: Écriture sur disque en temps réel

Bonne prise @vvv. On dirait qu'il peut être réparé assez facilement.

J'ai regardé ça. Réflexions actuelles :

asciinema ne génère pas le flux JSON à la volée - il génère l'intégralité de la chaîne JSON et l'enregistre dans un fichier une fois l'intégralité de la sortie standard capturée. C'est principalement parce que le marshaller JSON de Go fonctionne.

Une possibilité est de vider un fichier tmp ( foo.json.tmp si vous enregistrez dans foo.json ). Cela pourrait ressembler à :

{ "version": 2, "width": 80, "height": 24, "env": { "TERM": "xterm-256color" } ... }
[0.1, "bash-4.3$ "]
[0.3, "l"]
[0.1, "s"]
...
...

Fondamentalement, un fichier JSON avec plusieurs objets de niveau supérieur, d'abord une carte JSON avec des métadonnées, tout le reste étant des impressions standard qui devraient finalement se retrouver sous la clé stdout dans le fichier final.

Quant à la récupération, vous pouvez alors facilement le faire vous-même (en déplaçant simplement les lignes dans vim).
Il pourrait également y avoir une nouvelle commande asciinema recover foo.json.tmp foo.json pour automatiser cela (je ne sais pas si faire de la récupération une partie de asciinema play est le meilleur).

Une possibilité est de vider un fichier tmp ( foo.json.tmp si vous enregistrez dans foo.json ).

Ça a l'air bien! Cette fonctionnalité ressemblerait aux fichiers de sauvegarde automatique d' Emacs ( #foo.json# ) et aux fichiers de récupération Vim ( .foo.json.swp .)

Quant à la récupération, vous pouvez alors facilement le faire vous-même (en déplaçant simplement les lignes dans vim).

Franchement, je préférerais la commande "récupérer", ou même une option légère -r | --recover , à la manipulation manuelle d'un fichier de sauvegarde automatique.

Juste pour le dire ouvertement, #82 résoudrait également ce problème.

@xloem #82 s'applique uniquement au cas où vous rec+téléchargez sur asciinema.org en une seule étape. asciinema rec demo.json vous permet également d'enregistrer dans un fichier sans télécharger automatiquement sur le site, et l'écriture incrémentielle sur le disque dans ce cas serait tout aussi utile.

J'ai commencé à travailler sur un brouillon du format asciicast v2 en #196, qui devrait bien résoudre l'écriture en temps réel sur le disque (et pipe, réseau, que voulez-vous).

Lien direct vers la doc à partir de ce PR : https://github.com/asciinema/asciinema/blob/asciicast-v2/doc/asciicast-v2.md

Commentaires très appréciés.

@sickill Je ne vois pas comment le changement de format de fichier ( NDJSON au lieu de JSON) s'applique à la mise à jour incrémentielle du fichier de sortie. Pourriez-vous expliquer?

@vvv dans un fichier JSON normal, vous avez un seul objet et vous ne pouvez pas y écrire de manière incrémentielle, il doit être écrit dans son ensemble (techniquement, vous le pouvez, mais si vous plantez, etc., vous vous retrouvez avec un fichier JSON invalide, manquant la fermeture supports). Avec NDJSON (ou JSONLines qui est presque identique), vous avez plusieurs objets JSON dans un seul fichier, chacun sur sa propre ligne. Ainsi, vous pouvez ajouter de nouvelles lignes avec de nouvelles données et vous arrêter/se bloquer à volonté et ne jamais laisser le fichier invalide.

J'ai mis à jour le projet de document au format asciicast v2 pour le rendre plus clair en ce qui concerne la motivation / les problèmes qu'il résout.

@sickill une chose qui serait bien serait d'avoir l'heure de début de la session stockée dans les métadonnées initiales. Cela pourrait être extrait dans d'autres outils pour fournir des sessions ssh auditables.

De plus, pouvoir « injecter » des métadonnées peut être intéressant, vous pouvez donc potentiellement baliser une session créée avec des éléments tels que :

• utilisateur qui ssh'd
• nom d'hôte
• environnement serveur

Et faites en sorte que cela soit exposé dans une interface utilisateur externe.

EDIT : Il semble qu'il y ait un PR pour le format, donc je vais commenter là-bas :)

j'ai actuellement configuré asciinema pour l'enregistrement de session d'employés distants
connexion via ssh à un réseau sécurisé via un jumphost. pouvoir économiser,
les sessions de streaming et de rediffusion, au fur et à mesure qu'elles se produisent, amélioreraient considérablement la
utilité de l'asciinema dans ledit scénario.

Le Mar 25 Avr 2017 à 05:17, Jose Diaz-Gonzalez <
[email protected]> a écrit :

@sickill https://github.com/sickill une chose qui serait bien serait
être d'avoir l'heure de début de la session stockée dans les métadonnées initiales.
Cela pourrait être extrait dans d'autres outils pour fournir des sessions ssh auditables.

De plus, pouvoir « injecter » des métadonnées peut être intéressant, vous
pourrait potentiellement marquer une session créée avec des éléments tels que :

• utilisateur qui ssh'd
• nom d'hôte
• environnement serveur

Et faites en sorte que cela soit exposé dans une interface utilisateur externe.

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/asciinema/asciinema/issues/127#issuecomment-296872546 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAi2o-cZFmoJOnPeabG0UkPfb8MVR3EMks5rzVfNgaJpZM4FuWm_
.

J'utilise asciinema (enfin, plus maintenant, je reviens au script à cause de ce problème) pour garder une trace de toutes mes sessions de terminal à CYA ainsi que pour référence si j'oubliais ce que j'ai fait sur le serveur X la semaine dernière à 3 pm. Le problème est que, comme cela ne se vide qu'en cas de sorties réussies, la moitié de mes sessions n'ont pas de données. La fermeture d'une fenêtre pour une session bloquée par exemple, entraîne une perte totale de l'enregistrement de la session. C'était un comportement inattendu et assez décevant.

Le format

@sickill - Merci, c'est bon à entendre. Je vais garder un œil dessus. Je préférerais vraiment asciinema au script car je peux intégrer le contenu dans notre Wiki pour d'autres administrateurs système.

@timofonic Vous pouvez poser votre question ici et attendre patiemment. Il n'est pas nécessaire de spammer tout le monde en pingant les utilisateurs de cette façon.

Mise à jour : l'écriture sur disque en temps réel a été implémentée dans #196 et fera partie de la prochaine version.

Si vous souhaitez le tester en version bêta, extrayez la branche develop et exécutez-le à partir du répertoire de paiement avec : python3 -m asciinema rec filename . J'apprécierais vraiment des commentaires sur la façon dont cela fonctionne sur diverses distributions Linux et macOS 👋

Remarque : à ce jour, le serveur et le lecteur Web ne prennent pas en charge le nouveau format asciicast, il ne peut donc être utilisé que pour l'enregistrement local et la lecture dans le terminal.

Excellent travail @sickill ! Je viens de tester cela et j'ai pu le faire fonctionner (Ubuntu 17.04).

Un peu de clarification cependant; Qu'est-ce qui déclenche les vidages ? S'agit-il de la mise en mémoire tampon du fichier ou d'un délai d'attente ? Dans tous les cas, quels sont les seuils spécifiques ? Je demande parce qu'après avoir fait quelques échos rapides, je n'ai rien vu dans le fichier, mais au fur et à mesure que je jouais avec, des choses ont commencé à apparaître.

@metasoarous c'est une excellente question.

Il n'y a pas de délai d'attente explicite ni aucun autre mécanisme pour regrouper les écritures, cela passe en temps réel dans la file d'attente :

https://github.com/asciinema/asciinema/blob/8e1b6f7da1a0ad4d52e63998b14c1a5133fc7836/asciinema/asciicast/v2.py#L72

pour séparer le processus "writer":

https://github.com/asciinema/asciinema/blob/8e1b6f7da1a0ad4d52e63998b14c1a5133fc7836/asciinema/asciicast/v2.py#L36 -L40

ce qui fait f.write(...) .

Cela dit, j'ai également observé qu'il est écrit en morceaux d'environ 8 Ko, il y a donc certainement une mise en mémoire tampon en cours ici. Je soupçonne que c'est le TextIOWrapper de Python qui est responsable ici.

Selon vous, qu'est-ce qui conviendrait le mieux ici ? Nous pouvons désactiver la mise en mémoire tampon sur l'objet io ouvert ou implémenter un déclencheur explicite, soit f.flush() à chaque écriture, soit le comptage d'octets/temps et le vidage lorsque le seuil est atteint.

J'imagine que la désactivation de la mise en mémoire tampon sur l'objet io pourrait être la solution la plus simple, avec des vidages manuels toutes les N secondes à la seconde près. Je pourrais imaginer des stratégies plus sophistiquées, mais quelque chose de proche de l'un de ces choix devrait faire l'affaire.

Je l'ai modifié afin qu'il définisse maintenant explicitement la politique de mise en mémoire tampon sur "mise en mémoire tampon de ligne" (== flush lorsque l'écriture inclut \n , ce qui est le cas pour 100% des écritures dans notre cas) lors de l'ouverture du fichier en écriture. Si vous tirez et essayez maintenant, vous devriez voir le fichier croître immédiatement.

Merveilleux! Merci beaucoup pour votre attention rapide!

Étant donné que cela a été implémenté (en #227) et sera publié avec le prochain asciinema 2.0, je ferme ce problème.

Remarque : si quelqu'un veut essayer cela, consultez la branche v2 .