Asciinema: Escribir en disco en tiempo real

Buen partido @vvv. Parece que se puede arreglar con bastante facilidad.

Miré esto. Pensamientos actuales:

asciinema no genera el flujo JSON sobre la marcha: genera una cadena JSON completa y la guarda en un archivo una vez que se ha capturado todo el stdout. Esto se debe principalmente a cómo funciona el marshaller JSON de Go.

Una posibilidad es descargar en un archivo tmp ( foo.json.tmp si graba en foo.json ). Podría verse así:

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

Básicamente, un archivo JSON con múltiples objetos de nivel superior, primero es un mapa JSON con metadatos, el resto son impresiones estándar que eventualmente deberían terminar por debajo de la clave stdout en el archivo final.

En cuanto a la recuperación, puede hacerlo fácilmente usted mismo (simplemente moviendo las líneas en vim).
También podría haber un nuevo comando asciinema recover foo.json.tmp foo.json para automatizar esto (no estoy seguro si hacer que la recuperación sea parte de asciinema play es lo mejor).

Una posibilidad es descargar en un archivo tmp ( foo.json.tmp si graba en foo.json ).

¡Suena bien! Esta característica se parecería a los archivos de guardado automático de Emacs ( #foo.json# ) y los archivos de recuperación de Vim ( .foo.json.swp .)

En cuanto a la recuperación, puede hacerlo fácilmente usted mismo (simplemente moviendo las líneas en vim).

Francamente, preferiría el comando "recuperar", o incluso una opción ligera -r | --recover , a jugar manualmente con un archivo de guardado automático.

Solo para decir esto abiertamente, el # 82 también solucionaría este problema.

@xloem # 82 se aplica solo al caso en el que rec + carga a asciinema.org en un solo paso. asciinema rec demo.json también le permite grabar en un archivo sin cargarlo automáticamente en el sitio, y escribir en forma incremental en el disco en este caso sería igualmente útil.

Comencé a trabajar en un borrador del formato asciicast v2 en # 196, que debería resolver muy bien la escritura en tiempo real en el disco (y canalización, red, lo que sea).

Enlace directo al documento desde este PR: https://github.com/asciinema/asciinema/blob/asciicast-v2/doc/asciicast-v2.md

Comentarios muy apreciados.

@sickill No veo cómo se aplica el cambio de formato de archivo ( NDJSON en lugar de JSON) a la actualización incremental del archivo de salida. ¿Podrías explicar?

@vvv en un archivo JSON normal, tiene un solo objeto y no puede escribir en él de forma incremental, debe escribirse como un todo (técnicamente puede, pero si falla, etc., termina con un archivo JSON no válido, sin el cierre soportes). Con NDJSON (o JSONLines, que es casi idéntico), tiene varios objetos JSON en un solo archivo, cada uno en su propia línea. Por lo tanto, puede agregar nuevas líneas con nuevos datos y detenerse / bloquearse a voluntad y nunca dejar el archivo inválido.

He actualizado el borrador del documento en formato asciicast v2 para que sea más claro con respecto a la motivación / qué problemas resuelve.

@sickill, una cosa que sería buena sería tener la hora de inicio de la sesión almacenada en los metadatos iniciales. Esto podría extraerse en otras herramientas para proporcionar sesiones ssh auditables.

Además, la posibilidad de "inyectar" metadatos puede ser interesante, por lo que podría etiquetar una sesión creada con cosas como:

• usuario que ssh'd
• nombre de host
• entorno del servidor

Y tener eso expuesto en alguna interfaz de usuario externa.

EDITAR: Parece que hay un PR para el formato, así que comentaré allí :)

Actualmente tengo asciinema configurado para el registro de sesiones de empleados remotos
conectar a través de ssh a una red segura a través de un jumphost. poder ahorrar,
Las sesiones de transmisión y reproducción, a medida que ocurren, mejorarían enormemente la
utilidad del asciinema en dicho escenario.

El martes, 25 de abril de 2017 a las 5:17 a. M., Jose Diaz-Gonzalez <
[email protected]> escribió:

@sickill https://github.com/sickill una cosa que sería buena sería
ser tener la hora de inicio de la sesión almacenada en los metadatos iniciales.
Esto podría extraerse en otras herramientas para proporcionar sesiones ssh auditables.

Además, la posibilidad de "inyectar" metadatos puede ser interesante, por lo que
potencialmente podría etiquetar una sesión creada con cosas como:

• usuario que ssh'd
• nombre de host
• entorno del servidor

Y tener eso expuesto en alguna interfaz de usuario externa.

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/asciinema/asciinema/issues/127#issuecomment-296872546 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAi2o-cZFmoJOnPeabG0UkPfb8MVR3EMks5rzVfNgaJpZM4FuWm_
.

Utilizo asciinema (bueno, ya no, estoy volviendo al script debido a este problema) para mantener un registro de todas mis sesiones de terminal en CYA, así como como referencia si olvidé lo que hice en el servidor X la semana pasada a las 3 pm. El problema es que, dado que esto solo se descarga en salidas exitosas, la mitad de mis sesiones no tienen datos. Cerrar una ventana para una sesión colgada, por ejemplo, provoca una pérdida total de la grabación de la sesión. Este fue un comportamiento inesperado y bastante decepcionante.

El formato

@sickill - Gracias, es bueno escuchar esto. Lo vigilaré. Realmente preferiría asciinema al script porque puedo incrustar el contenido en nuestro Wiki para otros administradores de sistemas.

@timofonic Puedes hacer tu pregunta aquí y esperar pacientemente. No es necesario enviar spam a todo el mundo haciendo ping a los usuarios de esta manera.

Actualización: la escritura en disco en tiempo real se implementó en el n. ° 196 y será parte de la próxima versión.

Si desea realizar una prueba beta, consulte develop branch y ejecútelo desde el directorio de pago con: python3 -m asciinema rec filename . Realmente agradecería comentarios sobre cómo funciona en varias distribuciones de Linux y macOS 👋

Nota: a partir de hoy, el servidor y el reproductor web no admiten el nuevo formato asciicast, por lo que solo se puede usar para grabación local y reproducción en la terminal.

¡Buen trabajo @sickill! Acabo de probar esto y pude hacerlo funcionar (Ubuntu 17.04).

Sin embargo, una pequeña aclaración; ¿Qué desencadena los vertederos? ¿Es almacenamiento en búfer de archivos o se agotó el tiempo de espera? De cualquier manera, ¿cuáles son los umbrales específicos? Pregunto porque después de hacer un par de ecos rápidos, no vi nada en el archivo, pero a medida que jugaba con él, empezaron a aparecer cosas.

@metasoarous esa es una gran pregunta.

No hay un tiempo de espera explícito ni ningún otro mecanismo para agrupar las escrituras, pasa en tiempo real a través de la cola:

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

para separar el proceso de "escritor":

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

que hace f.write(...) .

Habiendo dicho eso, también observé que está escrito en fragmentos de ~ 8KB, por lo que definitivamente hay algo de almacenamiento en búfer aquí. Sospecho que es TextIOWrapper de Python el responsable aquí.

¿Qué crees que sería mejor aquí? Podemos desactivar el almacenamiento en búfer en el objeto io abierto o implementar un disparador explícito, ya sea f.flush() en cada escritura, o el conteo de bytes / tiempo y el vaciado cuando se alcanza el umbral.

Me imagino que desactivar el almacenamiento en búfer en el objeto io podría ser la solución más fácil, con descargas manuales cada N segundos por segundo. Podría imaginar estrategias más sofisticadas, pero algo parecido a una de esas opciones debería funcionar.

Lo cambié para que ahora establezca explícitamente la política de almacenamiento en búfer en "búfer de línea" (== flush cuando la escritura incluye \n , que es el caso del 100% de las escrituras en nuestro caso) al abrir el archivo para escritura. Si lo extrae y lo prueba ahora, debería ver que el archivo crece de inmediato.

¡Maravilloso! ¡Muchas gracias por su rápida atención!

Dado que esto se ha implementado (en el n. ° 227) y se lanzará con el próximo asciinema 2.0, estoy cerrando este problema.

Nota: si alguien quiere probar esto, consulte v2 branch.