Files
keycloak-pattern/docs/evidence/d4a-deploy-hook/README.md
T
DongHyeonkaandClaude Opus 5 e9baac21d5 docs(d4a): the deploy hook works — issuance to serving drops from 38m25s to 1-2s
D-4 named the fix and never ran it. Running it:

  /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh
    #!/bin/sh
    nginx -t && nginx -s reload

certbot reports "Hook 'deploy-hook' ran", the master stays at PID 585 and
the worker is replaced 28829 -> 37252, and the served certificate changes.

One trap worth naming: certbot prefixes the hook output with "ran with error
output" whenever the hook writes anything to stderr, and nginx's routine
types_hash warning goes to stderr. Everything inside is success — "test is
successful", "signal process started". A monitor that greps for "error"
would read a working hook as a failure. The worker PID is what to check.

Timing needed a clock correction. test-server has NTP off and runs 106
seconds fast; the dev machine matches Google and the Let's Encrypt ACME
endpoint exactly. Corrected, the hook's nginx -t lands at 12:27:50 UTC
against the new certificate's SCT at 12:27:49.054 — one second. The
correction validates itself: uncorrected, the hook would have run 104
seconds before the certificate existed.

That same skew is why D-4's gap was reported 106 seconds short; corrected to
2305s in the previous commit.

Remaining and left alone: whether certbot-renew.timer performs a real
renewal, which cannot be tested for about 89 days.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-04 21:35:00 +09:00

1.6 KiB

D-4a — deploy 훅 검증 증거

2026-09-04 12:27 UTC (실제 시각) 해설: docs/experiment-d4a-deploy-hook.md

파일 무엇을 보여주는가
01-hook-verified.txt 판정 전문. 훅 실행 로그 · 워커 PID 교체 · 시계 보정과 SCT 교차검증 · D-4 와의 대조
02-certbot-with-hook.txt certbot renew --force-renewal 원문. Hook 'deploy-hook' ranall renewals succeeded
03-after-state.txt 실행 후 nginx 프로세스와 서빙 인증서

핵심 네 줄

  1. D-4 의 처방은 듣는다. 훅 파일 하나로 발급 → 서빙이 38분 25초에서 1~2초가 됐다. 약 1150배.
  2. Hook 'deploy-hook' ran with error output 을 실패로 읽으면 안 된다. nginx 의 types_hash 경고가 stderr 로 나갔을 뿐이고 내용은 전부 성공이다 — test is successful, signal process started. 로그에서 error 를 grep 하면 성공한 훅을 실패로 오독한다.
  3. 진단 방법이 재확인됐다. 마스터 585 는 그대로, 워커만 28829 → 37252 로 교체. D-4 에서 세운 「마스터 유지 + 워커 교체 = reload」가 그대로 작동한다.
  4. ★ 시계를 섞어 빼면 안 된다. test-server 는 NTP 가 꺼져 106초 빠르다(외부 기준 3회 측정). 이 사실을 적지 않고 계산한 D-4 의 공백은 106초 짧았고, 1~2초를 재는 D-4a 에서는 보정 없이는 훅이 발급보다 104초 먼저 실행된 것이 되어 물리적으로 불가능해진다. 보정은 새 인증서 SCT(12:27:49.054 GMT, CT 로그의 독립 시계)로 교차검증된다.