Asciinema: Schreiben auf Festplatte in Echtzeit

Guter Fang @vvv. Sieht so aus, als ob es relativ einfach repariert werden kann.

Ich habe mir das angeschaut. Aktuelle Gedanken:

asciinema generiert den JSON-Stream nicht im laufenden Betrieb - es generiert den gesamten JSON-String und speichert ihn in einer Datei, sobald der gesamte stdout erfasst wurde. Dies liegt hauptsächlich daran, wie der JSON-Marshaller von Go funktioniert.

Eine Möglichkeit besteht darin, in eine tmp-Datei zu leeren ( foo.json.tmp wenn Sie in foo.json ). Es könnte so aussehen:

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

Im Grunde eine JSON-Datei mit mehreren Objekten der obersten Ebene, zuerst eine JSON-Map mit Metadaten, der Rest sind Standarddrucke, die schließlich in der endgültigen Datei unter dem Schlüssel stdout enden sollten.

Was die Wiederherstellung angeht, können Sie dies leicht selbst tun (nur Linien in vim verschieben).
Es könnte auch einen neuen Befehl asciinema recover foo.json.tmp foo.json um dies zu automatisieren (nicht sicher, ob es das Beste ist, die Wiederherstellung zu einem Teil von asciinema play ).

Eine Möglichkeit besteht darin, in eine tmp-Datei zu leeren ( foo.json.tmp wenn Sie in foo.json ).

Hört sich gut an! Diese Funktion ähnelt Emacs' Auto-Save-Dateien ( #foo.json# ) und Vim- Wiederherstellungsdateien ( .foo.json.swp .)

Was die Wiederherstellung angeht, können Sie dies leicht selbst tun (nur Linien in vim verschieben).

Ehrlich gesagt, würde ich den Befehl "Wiederherstellen" oder sogar eine einfache Option -r | --recover dem manuellen Herumfummeln an einer automatisch gespeicherten Datei vorziehen.

Um dies nur offen zu sagen, würde #82 auch dieses Problem beheben.

@xloem #82 gilt nur für den Fall, dass Sie rec+upload auf asciinema.org in einem Schritt durchführen. asciinema rec demo.json können Sie auch in eine Datei aufnehmen, ohne sie automatisch auf die Site hochzuladen, und in diesem Fall wäre das inkrementelle Schreiben auf die Festplatte ebenso nützlich.

Ich begann in #196 mit der Arbeit an einem Entwurf des asciicast v2 Formats, der das Schreiben in Echtzeit auf Festplatte (und Pipe, Netzwerk, was auch immer) gut lösen sollte.

Direkter Link zum Dokument aus dieser PR: https://github.com/asciinema/asciinema/blob/asciicast-v2/doc/asciicast-v2.md

Feedback sehr geschätzt.

@sickill Ich sehe nicht, wie die Änderung des Dateiformats ( NDJSON anstelle von JSON) auf die inkrementelle Aktualisierung der Ausgabedatei

@vvv in einer normalen JSON-Datei haben Sie ein einzelnes Objekt und Sie können nicht inkrementell darauf schreiben, es muss als Ganzes geschrieben werden (technisch können Sie, aber wenn Sie abstürzen usw., dann erhalten Sie eine ungültige JSON-Datei, die das Schließen fehlt Klammern). Mit NDJSON (oder JSONLines, das fast identisch ist) haben Sie mehrere JSON-Objekte in einer einzigen Datei, jedes in einer eigenen Zeile. Sie können also nach Belieben neue Zeilen mit neuen Daten anhängen und nach Belieben stoppen/abstürzen und die Datei niemals ungültig lassen.

Ich habe den Entwurf des Dokuments im ASCII-Format v2 aktualisiert, um die Motivation / die Probleme, die es löst, klarer zu machen.

@sickill Eine Sache, die gut wäre, wäre, die Startzeit der Sitzung in den anfänglichen Metadaten zu speichern. Dies könnte in anderen Tools extrahiert werden, um prüffähige SSH-Sitzungen bereitzustellen.

Darüber hinaus könnte es interessant sein, Metadaten "injizieren" zu können, sodass Sie eine erstellte Sitzung möglicherweise mit folgenden Dingen versehen können:

• Benutzer, der ssh'd
• Hostname
• Serverumgebung

Und lassen Sie das in einer externen Benutzeroberfläche exponieren.

EDIT: Anscheinend gibt es eine PR für das Format, also werde ich dort kommentieren :)

Ich habe derzeit Asciinema für die Sitzungsprotokollierung von Remote-Mitarbeitern eingerichtet
Verbindung über ssh mit einem sicheren Netz über einen Jumphost. sparen können,
Stream- und Replay-Sitzungen, wie sie auftreten, würden die
Nützlichkeit von Asciinema in diesem Szenario.

Am Di, 25. April 2017 um 5:17 Uhr, Jose Diaz-Gonzalez <
[email protected]> schrieb:

@sickill https://github.com/sickill eine Sache, die gut wäre
sein, dass die Startzeit der Sitzung in den anfänglichen Metadaten gespeichert wird.
Dies könnte in anderen Tools extrahiert werden, um prüffähige SSH-Sitzungen bereitzustellen.

Außerdem könnte es interessant sein, Metadaten "injizieren" zu können
könnte möglicherweise eine erstellte Sitzung mit Dingen wie den folgenden markieren:

• Benutzer, der ssh'd
• Hostname
• Serverumgebung

Und lassen Sie das in einer externen Benutzeroberfläche exponieren.

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/asciinema/asciinema/issues/127#issuecomment-296872546 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAi2o-cZFmoJOnPeabG0UkPfb8MVR3EMks5rzVfNgaJpZM4FuWm_
.

Ich verwende Asciinema (nun, nicht mehr, ich kehre wegen dieses Problems zum Skript zurück), um alle meine Terminalsitzungen für CYA aufzuzeichnen und als Referenz, wenn ich vergessen habe, was ich letzte Woche um 3 auf Server X getan habe Uhr. Das Problem ist, dass die Hälfte meiner Sitzungen keine Daten enthält, da dies nur bei erfolgreichen Exits gespült wird. Das Schließen eines Fensters für eine Sitzung, die aufgehängt ist, führt beispielsweise zum vollständigen Verlust der Sitzungsaufzeichnung. Dies war ein unerwartetes Verhalten und ziemlich enttäuschend.

@gizmonicus asciicast v2 Format und das Schreiben auf die Festplatte in Echtzeit hat für die nächste Version höchste Priorität. Keine ETA, aber das wird bald passieren.

@sickill - Danke, das ist gut zu hören. Ich werde es im Auge behalten. Ich würde Asciinema einem Skript vorziehen, weil ich den Inhalt in unser Wiki für andere Systemadministratoren einbetten kann.

@timofonic Du kannst hier deine Frage stellen und geduldig warten. Es besteht keine Notwendigkeit, jeden zu spammen, indem Sie Benutzer auf diese Weise anpingen.

Update: Das Schreiben auf die Festplatte in Echtzeit wurde in #196 implementiert und wird Teil der nächsten Version sein.

Wenn Sie einen Beta-Test durchführen möchten, checken Sie den develop Zweig aus und führen Sie ihn aus dem Checkout-Verzeichnis aus mit: python3 -m asciinema rec filename . Ich würde mich sehr über Feedback zur Funktionsweise verschiedener Linux-Distributionen und macOS freuen 👋

Hinweis: Derzeit unterstützen der Server und der Webplayer kein neues ASCII-Format, sodass es nur für lokale Aufzeichnungen und die Wiedergabe im Terminal verwendet werden kann.

Tolle Arbeit @sickill! Ich habe das gerade getestet und konnte es zum Laufen bringen (Ubuntu 17.04).

Eine kleine Klarstellung; Was löst die Dumps aus? Ist es Dateipufferung oder ein Timeout? Wie auch immer, was sind die spezifischen Schwellenwerte? Ich frage, weil ich nach ein paar schnellen Echos nichts in der Datei gesehen habe, aber als ich mehr damit herumgespielt habe, tauchten Dinge auf.

@metasoarous das ist eine tolle Frage.

Es gibt kein explizites Timeout oder einen anderen Mechanismus, um die Schreibvorgänge zu stapeln, es geht in Echtzeit durch die Warteschlange:

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

um den "Writer"-Prozess zu trennen:

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

was f.write(...) tut.

Abgesehen davon habe ich auch festgestellt, dass es in ~8-KB-Blöcken geschrieben ist, so dass hier definitiv etwas gepuffert wird. Ich vermute, dass TextIOWrapper von Python hier verantwortlich ist.

Was denkst du wäre hier am besten? Wir können die Pufferung für das geöffnete io-Objekt deaktivieren oder einen expliziten Trigger implementieren, entweder f.flush() bei jedem Schreibvorgang oder das Zählen von Byte/Zeit und das Löschen, wenn der Schwellenwert erreicht wird.

Ich könnte mir vorstellen, dass das Deaktivieren der Pufferung für das io-Objekt die einfachste Lösung ist, mit manuellen Flushes alle N Sekunden eine knappe Sekunde. Ich könnte mir schickere Strategien vorstellen, aber etwas, das einer dieser Entscheidungen nahe kommt, sollte den Zweck erfüllen.

Ich habe es so geändert, dass es jetzt explizit die Pufferungsrichtlinie auf "Zeilenpufferung" setzt (== Flush, wenn das Schreiben \n , was in unserem Fall für 100% der Schreibvorgänge der Fall ist), wenn die Datei zum Schreiben geöffnet wird. Wenn Sie es jetzt ziehen und versuchen, sollten Sie sofort sehen, wie die Datei wächst.

Wunderbar! Vielen Dank für Ihre schnelle Aufmerksamkeit!

Da dies implementiert wurde (in #227) und mit dem kommenden asciinema 2.0 veröffentlicht wird, schließe ich diese Ausgabe.

Hinweis: Wenn jemand dies ausprobieren möchte, dann checken Sie den v2 Zweig aus.