Asciinema: 실시간으로 디스크에 쓰기

좋은 캐치 @vvv. 비교적 쉽게 고칠 수 있을 것 같습니다.

나는 이것을 보았다. 현재 생각:

asciinema는 JSON 스트림을 즉시 생성하지 않습니다. 전체 JSON 문자열을 생성하고 전체 stdout이 캡처되면 파일에 저장합니다. 이것은 주로 Go의 JSON 마샬러가 작동하는 방식 때문입니다.

한 가지 가능성은 tmp 파일로 플러시하는 것입니다( foo.json.tmp 기록하는 경우 foo.json ). 다음과 같이 보일 수 있습니다.

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

기본적으로 여러 최상위 개체가 있는 JSON 파일입니다. 처음에는 메타데이터가 있는 JSON 맵이고 나머지는 모두 최종 파일의 stdout 키 아래에 있어야 하는 stdout 인쇄입니다.

복구에 관해서는 스스로 쉽게 할 수 있습니다(vim에서 줄을 옮기기만 하면 됩니다).
이를 자동화하는 새로운 명령 asciinema recover foo.json.tmp foo.json 이 있을 수도 있습니다( asciinema play 의 일부로 복구하는 것이 가장 좋은지 확실하지 않음).

한 가지 가능성은 tmp 파일로 플러시하는 것입니다( foo.json.tmp 기록하는 경우 foo.json ).

좋은 소리! 이 기능은 Emacs의 자동 저장 파일 ( #foo.json# ) 및 Vim 복구 파일 ( .foo.json.swp )과 유사 합니다 .

복구에 관해서는 스스로 쉽게 할 수 있습니다(vim에서 줄을 옮기기만 하면 됩니다).

솔직히 말하면 자동 저장 파일을 수동으로 조작하는 것보다 "복구" 명령이나 가벼운 -r | --recover 옵션을 선호합니다.

이것을 명백하게 말하면 #82도 이 문제를 해결할 것입니다.

@xloem #82는 asciinema.org에 한번에 rec+upload하는 경우에만 적용됩니다. asciinema rec demo.json 를 사용하면 사이트에 자동으로 업로드하지 않고도 파일에 기록할 수 있으며 이 경우 디스크에 증분 쓰기도 똑같이 유용합니다.

나는 #196에서 asciicast v2 형식의 초안 작업을 시작했는데, 이것은 디스크(그리고 파이프, 네트워크, 당신이 가지고 있는 것)에 실시간으로 쓰기를 훌륭하게 해결해야 합니다.

이 PR에서 문서에 대한 직접 링크: https://github.com/asciinema/asciinema/blob/asciicast-v2/doc/asciicast-v2.md

피드백을 높이 평가합니다.

@sickill 파일 형식 변경(JSON 대신 NDJSON )이 출력 파일의 증분 업데이트에 어떻게 적용

일반 JSON 파일의 @vvv 에는 단일 개체가 있고 증분식으로 쓸 수 없습니다. 전체적으로 작성해야 합니다(기술적으로는 가능하지만 충돌 등의 경우 잘못된 JSON 파일로 종료되고 닫힘이 누락됩니다. 괄호). NDJSON(또는 거의 동일한 JSONLines )을 사용하면 하나의 파일에 여러 JSON 개체가 있고 각각의 줄에 있습니다. 따라서 새 데이터로 새 줄을 추가하고 마음대로 중지/충돌하고 파일을 유효하지 않은 상태로 두지 않을 수 있습니다.

동기 부여/해결하는 문제에 대해 더 명확하게 하기 위해 asciicast v2 형식 문서의 초안을 업데이트했습니다.

@sickill 좋은 것은 세션의 시작 시간을 초기 메타데이터에 저장하는 것입니다. 이것은 감사 가능한 ssh 세션을 제공하기 위해 다른 도구에서 추출될 수 있습니다.

또한 메타데이터를 "주입"하는 것이 흥미로울 수 있으므로 생성된 세션에 다음과 같은 태그를 지정할 수 있습니다.

• ssh된 사용자
• 호스트 이름
• 서버 환경

그리고 그것을 일부 외부 UI에 노출시키십시오.

편집: 형식에 대한 PR 이 있는 것 같아서 거기에 댓글을 달겠습니다. :)

현재 원격 직원의 세션 로깅을 위해 asciinema를 설정했습니다.
ssh를 통해 jumphost를 통해 보안 네트워크에 연결합니다. 구할 수 있다는 것,
스트림 및 재생 세션이 발생하면
해당 시나리오에서 asciinema의 유용성.

2017년 4월 25일 화요일 오전 5:17 Jose Diaz-Gonzalez <
[email protected]>은 다음과 같이 썼습니다.

@sickill https://github.com/sickill
세션의 시작 시간을 초기 메타데이터에 저장해야 합니다.
이것은 감사 가능한 ssh 세션을 제공하기 위해 다른 도구에서 추출될 수 있습니다.

또한 메타데이터를 "주입"할 수 있는 것이 흥미로울 수 있으므로
잠재적으로 생성된 세션에 다음과 같은 태그를 지정할 수 있습니다.

• ssh된 사용자
• 호스트 이름
• 서버 환경

그리고 그것을 일부 외부 UI에 노출시키십시오.

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/asciinema/asciinema/issues/127#issuecomment-296872546 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAi2o-cZFmoJonPeabG0UkPfb8MVR3EMks5rzVfNgaJpZM4FuWm_
.

나는 asciinema를 사용하여(이 문제 때문에 더 이상 스크립트로 되돌리고 있습니다) CYA에 대한 모든 터미널 세션의 기록을 유지하고 지난 주 3시에 서버 X에서 한 일을 잊어버린 경우 참조용으로 사용합니다. 오후. 문제는 이것이 성공적인 종료 시에만 플러시되기 때문에 내 세션의 절반에 데이터가 없다는 것입니다. 예를 들어 중단된 세션에 대한 창을 닫으면 세션 기록이 완전히 손실됩니다. 이것은 예상치 못한 행동이었고 상당히 실망스러웠습니다.

@gizmonicus asciicast v2 형식 및 실시간 디스크 쓰기는 다음 릴리스에서 가장 높은 우선 순위입니다. ETA는 없지만 곧 그렇게 될 것입니다.

@sickill - 감사합니다.

@timofonic 여기에 질문을 하고 참을성 있게 기다릴 수 있습니다. 이런 식으로 사용자에게 핑을 보내 모든 사람에게 스팸 메일을 보낼 필요가 없습니다.

업데이트: 실시간으로 디스크에 쓰기가 #196에서 구현되었으며 다음 릴리스의 일부가 될 것입니다.

당신이 베타 테스트에하고 싶은 경우는 체크 아웃 develop 지점과 함께 체크 아웃 디렉토리에서 실행 : python3 -m asciinema rec filename . 다양한 Linux 배포판과 macOS에서 작동하는 방식에 대한 피드백을 주시면 감사하겠습니다 👋

참고: 현재 서버와 웹 플레이어는 새로운 asciicast 형식을 지원하지 않으므로 로컬 녹음 및 터미널 내 재생에만 사용할 수 있습니다.

잘했어 @sickill! 방금 이것을 테스트했고 작동하도록 할 수 있었습니다(Ubuntu 17.04).

그래도 약간의 설명; 무엇이 덤프를 유발합니까? 파일 버퍼링입니까 아니면 시간 초과입니까? 어느 쪽이든, 특정 임계 값은 무엇입니까? 몇 가지 빠른 에코를 수행한 후 파일에서 아무 것도 볼 수 없었기 때문에 묻습니다. 하지만 더 많이 가지고 놀면서 무언가가 나타나기 시작했습니다.

@metasoarous 좋은 질문입니다.

쓰기를 일괄 처리하는 명시적인 시간 초과 또는 기타 메커니즘이 없으며 대기열을 통해 실시간으로 진행됩니다.

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

"작가" 프로세스를 분리하려면:

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

f.write(...) 합니다.

하지만 ~8KB 청크로 쓰여진 것도 관찰했기 때문에 여기에 버퍼링이 발생하고 있습니다. Python의 TextIOWrapper 가 여기에 책임이 있다고 생각합니다.

여기서 뭐가 제일 좋을 것 같니? 열린 io 객체에서 버퍼링을 끄거나 모든 쓰기에서 f.flush() 또는 임계값에 도달할 때 바이트/시간 계산 및 플러시를 수행하는 명시적 트리거를 구현할 수 있습니다.

나는 io 객체에서 버퍼링을 끄는 것이 가장 쉬운 해결책일 수 있다고 상상합니다. 가까운 초에 N초마다 수동 플러시를 하는 것입니다. 나는 더 멋진 전략을 상상할 수 있지만 그 선택 중 하나에 가까운 것이 트릭을 수행해야합니다.

쓰기를 위해 파일을 열 때 버퍼링 정책을 "라인 버퍼링"으로 명시적으로 설정하도록 변경했습니다(== 쓰기에 \n 포함 시 플러시, 이 경우 쓰기의 100% 경우). 지금 당겨서 시도하면 파일이 즉시 증가하는 것을 볼 수 있습니다.

훌륭한! 빠른 관심 감사합니다!

이것이 구현되었고(#227에서) 곧 출시될 asciinema 2.0과 함께 출시될 예정이므로 이 문제를 마무리하겠습니다.

참고: 누구든지 이것을 시도하고 싶다면 v2 지점을 확인하십시오.