Asciinema: Gravando no disco em tempo real

Boa captura @vvv. Parece que pode ser consertado com bastante facilidade.

Eu olhei para isso. Pensamentos atuais:

asciinema não gera o fluxo JSON em tempo real - ele gera string JSON inteira e a salva em um arquivo, uma vez que tem todo o stdout capturado. Isso ocorre principalmente porque funciona o marshaller JSON de Go.

Uma possibilidade é descarregar para um arquivo tmp ( foo.json.tmp se você gravar em foo.json ). Pode ser parecido com:

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

Basicamente, um arquivo JSON com vários objetos de nível superior, primeiro sendo um mapa JSON com metadados, todo o resto sendo impressões padrão que devem eventualmente terminar sob a chave stdout no arquivo final.

Quanto à recuperação, você poderia facilmente fazer isso sozinho (apenas movendo as linhas no vim).
Também pode haver um novo comando asciinema recover foo.json.tmp foo.json para automatizar isso (não tenho certeza se tornar a recuperação uma parte de asciinema play é o melhor).

Uma possibilidade é descarregar para um arquivo tmp ( foo.json.tmp se você gravar em foo.json ).

Soa bem! Este recurso seria semelhante aos arquivos salvos automaticamente do Emacs ( #foo.json# ) e aos arquivos de recuperação do Vim ( .foo.json.swp .)

Quanto à recuperação, você poderia facilmente fazer isso sozinho (apenas movendo as linhas no vim).

Francamente, eu preferiria o comando "recuperar", ou mesmo uma opção leve -r | --recover , a mexer manualmente com um arquivo de salvamento automático.

Apenas para declarar isso abertamente, # 82 também resolveria esse problema.

@xloem # 82 aplica-se apenas ao caso de rec + upload para asciinema.org em uma etapa. asciinema rec demo.json também permite que você grave em um arquivo sem carregá-lo automaticamente no site e, neste caso, gravar em disco de forma incremental seria igualmente útil.

Comecei a trabalhar em um rascunho do formato asciicast v2 no # 196, que deve resolver muito bem a escrita em tempo real para o disco (e canalização, rede, o que for).

Link direto para o documento deste PR: https://github.com/asciinema/asciinema/blob/asciicast-v2/doc/asciicast-v2.md

Feedback muito apreciado.

@sickill Não vejo como a alteração do formato do arquivo ( NDJSON em vez de JSON) se aplica à atualização incremental do arquivo de saída. Você poderia explicar?

@vvv no arquivo JSON normal você tem um único objeto e não pode escrever nele incrementalmente, tem que ser escrito como um todo (tecnicamente você pode, mas se você travar etc, você acaba com um arquivo JSON inválido, perdendo o fechamento colchetes). Com o NDJSON (ou JSONLines, que é quase idêntico), você tem vários objetos JSON em um único arquivo, cada um em sua própria linha. Assim, você pode adicionar novas linhas com novos dados e parar / travar à vontade e nunca deixar o arquivo inválido.

Eu atualizei o rascunho do documento de formato asciicast v2 para torná-lo mais claro em relação à motivação / quais problemas ele resolve.

@sickill uma coisa que seria bom seria ter a hora de início da sessão armazenada nos metadados iniciais. Isso pode ser extraído em outras ferramentas para fornecer sessões ssh auditáveis.

Além disso, ser capaz de "injetar" metadados pode ser interessante, então você pode potencialmente marcar uma sessão criada com coisas como:

• usuário que ssh'd
• nome de anfitrião
• ambiente de servidor

E ter isso exposto em alguma interface do usuário externa.

EDIT: Parece que há um PR para o formato, então vou comentar lá :)

Atualmente tenho asciinema configurado para registro de sessão de funcionários remotos
conectar via ssh a uma rede segura via jumphost. ser capaz de salvar,
sessões de stream e replay, à medida que ocorrem, aumentariam muito o
utilidade de asciinema em dito cenário.

Na terça-feira, 25 de abril de 2017 às 5:17, Jose Diaz-Gonzalez <
notificaçõ[email protected]> escreveu:

@sickill https://github.com/sickill uma coisa que seria boa seria
ser ter a hora de início da sessão armazenada nos metadados iniciais.
Isso pode ser extraído em outras ferramentas para fornecer sessões ssh auditáveis.

Além disso, ser capaz de "injetar" metadados pode ser interessante, então você
poderia potencialmente marcar uma sessão criada com coisas como:

• usuário que ssh'd
• nome de anfitrião
• ambiente de servidor

E ter isso exposto em alguma interface do usuário externa.

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/asciinema/asciinema/issues/127#issuecomment-296872546 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAi2o-cZFmoJOnPeabG0UkPfb8MVR3EMks5rzVfNgaJpZM4FuWm_
.

Eu uso asciinema (bem, não mais, estou voltando ao script por causa deste problema) para manter um registro de todas as minhas sessões de terminal para CYA, bem como para referência se eu esqueci o que fiz no servidor X na semana passada às 3 PM. O problema é que, como isso só funciona em saídas bem-sucedidas, metade das minhas sessões não tem dados. Fechar uma janela para uma sessão interrompida, por exemplo, causa uma perda total da gravação da sessão. Este foi um comportamento inesperado e bastante decepcionante.

O formato

@sickill - Obrigado, é bom ouvir isso. Vou ficar de olho nisso. Eu realmente preferiria asciinema ao script porque posso incorporar o conteúdo em nosso Wiki para outros administradores de sistemas.

@timofonic Você pode fazer sua pergunta aqui e esperar pacientemente. Não há necessidade de enviar spam para todos, executando o ping dos usuários dessa forma.

Atualização: a gravação no disco em tempo real foi implementada no # 196 e fará parte do próximo lançamento.

Se você gostaria de testá-lo em beta, verifique develop branch e execute-o a partir do diretório de checkout com: python3 -m asciinema rec filename . Agradeço muito o feedback sobre como funciona em várias distros Linux e macOS 👋

Nota: a partir de hoje, o servidor e o reprodutor web não suportam o novo formato asciicast, então ele pode ser usado para gravação local e reprodução no terminal apenas.

Ótimo trabalho @sickill! Acabei de testar e consegui fazer funcionar (Ubuntu 17.04).

Um pouco de esclarecimento; O que desencadeia os lixões? É buffer de arquivo ou tempo limite? De qualquer forma, quais são os limites específicos? Eu pergunto porque depois de fazer alguns ecos rápidos, eu não vi nada no arquivo, mas conforme eu brincava mais com ele, coisas começaram a aparecer.

@metasoarous, essa é uma ótima pergunta.

Não há tempo limite explícito ou qualquer outro mecanismo para agrupar as gravações, isso ocorre em tempo real pela fila:

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

para separar o processo "escritor":

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

o que faz f.write(...) .

Tendo dito isso, eu também observei que ele está escrito em pedaços de ~ 8 KB, então definitivamente há algum buffer acontecendo aqui. Suspeito que TextIOWrapper do Python seja o responsável aqui.

O que você acha que seria melhor aqui? Podemos desligar o armazenamento em buffer no objeto IO aberto ou implementar o acionador explícito, f.flush() em cada gravação ou contagem e liberação de bytes / tempo quando o limite é atingido.

Eu imagino que desligar o buffer no objeto io pode ser a solução mais fácil, com liberações manuais a cada N segundos por segundo. Eu poderia imaginar estratégias mais sofisticadas, mas algo próximo a uma dessas escolhas deve resolver o problema.

Eu mudei para que agora defina explicitamente a política de buffer para "buffer de linha" (== flush quando a gravação inclui \n , que é o caso de 100% das gravações em nosso caso) ao abrir o arquivo para gravação. Se você puxar e tentar agora, verá o arquivo crescendo imediatamente.

Maravilhoso! Muito obrigado pela sua rápida atenção!

Dado que isso foi implementado (em # 227) e será lançado com o asciinema 2.0, estou encerrando este problema.

Nota: se alguém quiser experimentar, verifique v2 branch.