refactor: 문서 개선 중

2026-09-21 14:30:55 +09:00
parent c93cdea150
commit 805a18f486
1497 changed files with 525837 additions and 59152 deletions
@@ -6,7 +6,11 @@ topic: build-completion-judgment
 topicName: 끝났다는 판정
 project: virtualization
 status: 게시 전
-sourceRevision: 9465582b5d1630eb4ae7c4e078021486919bf6b6
+sourceRevision: import-head 9465582b5d1630eb4ae7c4e078021486919bf6b6 · uncommitted-working-tree snapshot
+evidence:
+  - ../../../final/evidence/raw/lab-state-before-rebuild/15-k3s-precheck.txt
+  - ../../../final/evidence/raw/lab-state-before-rebuild/21-k3s-token.txt
+  - ../../../final/evidence/raw/lab-state-before-rebuild/22-k3s-agent-install.txt
 source:
  - final/document.md#185-가이드-묶음이-스스로-정한-규약
  - final/document.md#188-단계-02-k3s-server-와-agent
@@ -156,7 +160,7 @@ ssh kc-lab-2 "curl -sfL https://get.k3s.io | sudo sh -s - agent \

 ## 확인하지 못한 것

-설치 출력도 `journalctl` 출력도 `final/evidence/` 에 남기지 않았다. `level=fatal msg="Error: --token is required"` 와 `Host key verification failed.` 는 SSOT 본문에서 옮긴 것이고 명령 출력 파일이 근거가 아니다. 토큰 108자도 같다.
+원래 빈 토큰 사건의 `level=fatal msg="Error: --token is required"` 와 당시 설치 출력은 여전히 직접 raw가 없다. 다만 2026-09-17 후속 원문은 현재 정상 경로를 보강한다. `15-k3s-precheck.txt` 에는 별도 precheck에서 `Host key verification failed.`가 남아 있고, `21-k3s-token.txt` 는 재구축 시점의 **비어 있지 않은 토큰**을 길이로 확인했으며, `22-k3s-agent-install.txt` 는 그 토큰으로 agent 설치가 성공한 출력을 담는다. 이 셋은 원래 빈 토큰 실패의 재현이 아니라 **follow-up corroboration**이다. 과거 사건의 토큰 108자와 후속 실행의 길이가 다르더라도 같은 측정으로 덮어쓰지 않는다.

 이 실패를 일부러 다시 만들어 본 기록도 없어서, 빈 토큰으로 설치하면 설치 출력이 성공으로 끝난다는 것은 한 번의 관측이다. 재현이 쉽지 않은 까닭은 이 부의 검증 방식에 있다 — 만드는 명령은 다시 치면 돌고 있는 실험대가 없어지므로 구축할 때 쓴 것을 옮기고 결과 상태를 확인하는 것으로 대신했다. 재현 없이 남길 수 있는 것은 `journalctl` 쪽이고, 그 출력을 `final/evidence/raw/` 에 남기면 진단 절에 증거가 붙는다.

@@ -6,7 +6,10 @@ topic: build-completion-judgment
 topicName: 끝났다는 판정
 project: virtualization
 status: 게시 전
-sourceRevision: 9465582b5d1630eb4ae7c4e078021486919bf6b6
+sourceRevision: import-head 9465582b5d1630eb4ae7c4e078021486919bf6b6 · uncommitted-working-tree snapshot
+evidence:
+  - ../../../final/evidence/raw/lab-state-before-rebuild/14-cloudinit-schema-check.txt
+  - ../../../final/evidence/raw/lab-state-before-rebuild/15-k3s-precheck.txt
 source:
  - final/document.md#187-단계-01-게스트-세-대
  - final/document.md#186-단계-00-lab-host-가상화-준비
@@ -178,18 +181,20 @@ python3 -c 'import yaml,sys; yaml.safe_load(open("kc-lab-1.yaml")); print("YAML

 `0` 과 `2` 와 `YAML OK` 셋이 맞아야 시드를 만든다. 셋이 맞아도 cloud-config 로 유효하지는 않다 — 키 이름을 `users` 대신 `user` 로 친 오타는 이 세 줄을 그냥 통과한다. 그래서 게스트가 한 대라도 떠 있으면 cloud-init 자신의 스키마 검사기를 쓴다.

-```bash
+```bash label="[lab host] [reference] historical command"
 ssh donghyeon@192.168.122.11 'umask 077; cat > ~/kc-lab-2.yaml'  < kc-lab-2.yaml
 ssh donghyeon@192.168.122.11 'cloud-init schema -c ~/kc-lab-2.yaml; rm -f ~/kc-lab-2.yaml'
 ```

+이 두 줄은 **당시 문서에 남은 historical command**다. 둘째 줄은 스키마 검사가 실패해도 `; rm` 때문에 파일을 지운다. 따라 하는 절차에서는 검사와 삭제를 분리하고, 검사 성공 여부를 본 뒤 삭제한다.
+
 이 파일에는 콘솔 비밀번호가 평문으로 들어 있어 `/tmp` 가 아니라 자기 홈에 `600` 으로 두고, 검사가 끝나면 바로 지운다.

 ## 확인하지 못한 것

 넷 가운데 SSOT 가 관측으로 표시한 것은 시드를 SATA 로 붙였을 때 AHCI 장치가 보이지 않는 것과 스키마 검사기의 거부 문구뿐이다. YAML 파싱 실패와 `vol-upload` 누락과 네트워크 autostart 셋은 가이드가 막히면 표에 적어 둔 항목이라, 이 실험대에서 실제로 그 증상을 본 것인지 예상해 적은 것인지 SSOT 가 가르지 않았다. 이 글에서 그 셋은 그렇게 되는 구조까지이고 그렇게 됐다가 아니다.

-명령 출력은 원문으로 남아 있지 않다. `Permission denied (publickey)` 도 `cloud-init status: done` 도 약 50초도 SSOT 본문이 근거다. `final/evidence/` 에 그 출력을 담은 파일이 없다. `virsh screenshot` 으로 뜬 화면도 저장해 두지 않았다.
+후속 원문이 생겼다. `14-cloudinit-schema-check.txt` 는 cloud-init 22.4.2가 `sudo` 리스트 표기를 실제로 거부한 출력을 다시 담아 **스키마 거부 claim을 직접 보강한다**. `15-k3s-precheck.txt` 의 `Host key verification failed.` 는 2026-09-17 재구축 중 나온 후속 SSH 관측으로, 원래 사건의 `Permission denied (publickey)`를 재현한 것은 아니다. 원래 `Permission denied (publickey)`, `cloud-init status: done`, 약 50초, `virsh screenshot` 화면은 여전히 SSOT 본문만 근거이고 직접 raw는 없다.

 만드는 명령은 재실행으로 검증되지 않았다. 게스트를 다시 만들면 돌고 있는 실험대가 없어지므로 시드와 관련된 셋은 다시 재현하기 어렵다. 네트워크 autostart 만은 호스트를 재부팅해 확인할 수 있는데 그 기록도 없다.

@@ -6,7 +6,7 @@ topic: build-completion-judgment
 topicName: 끝났다는 판정
 project: virtualization
 status: 게시 전
-sourceRevision: 9465582b5d1630eb4ae7c4e078021486919bf6b6
+sourceRevision: import-head 9465582b5d1630eb4ae7c4e078021486919bf6b6 · uncommitted-working-tree snapshot
 source:
  - final/document.md#190-단계-04-let's-encrypt-와-인증서-갱신
  - final/document.md#189-단계-03-엣지-nginx-라우팅과-호스트-dnat
@@ -63,7 +63,7 @@ post/ 가 아니라 deploy/ 인 까닭 : post/ 는 갱신이 없어도 매번
 nginx : nginx/1.22.1
 certbot 플러그인 : dns-cloudflare
 발급 대상 : -d hyeonworks.com -d '*.hyeonworks.com'
-lineage 디렉터리 : /etc/letsencrypt/live/hyeonworks.com/
+lineage 디렉터리 : /etc/letsencrypt/live/auth.hyeonworks.com/ (2026-09-17 현재 관측)
 nginx 가 읽는 파일 : fullchain.pem · privkey.pem
 타이머 : certbot-renew.timer → certbot-renew.service
 인증서 유효기간 : 오늘 + 90일