44 lines
5 KiB
Markdown
44 lines
5 KiB
Markdown
# Result: independent R5 follow-up review
|
|
|
|
Base SHA: `ca28be6ae629d3d67936475ea5896b6f70f6e1e4`
|
|
Reviewed SHA: `c5ede46bd1c31b1e23434538fdb8a1cd925751a6`
|
|
Result SHA: `c5ede46bd1c31b1e23434538fdb8a1cd925751a6` (review only; no source changes)
|
|
Files changed by this reviewer: this report and its inbox task record only.
|
|
|
|
## Review result
|
|
|
|
The prior **MEDIUM is CLOSED for the runbook/documentation deliverable**. The prior **LOW is CLOSED**. I found no new CRITICAL, HIGH, or MEDIUM finding in the reviewed delta.
|
|
|
|
The prior MEDIUM was that the runbook had no executable HAProxy no-restart reload procedure. At `docs/STAGE1_DEPLOYMENT_RUNBOOK.md:414-457`, the revised procedure first requires PID 1 to be `haproxy`, an exact `-W`/`-Ws` argument, and manual confirmation that its `-f` paths match the complete validated config set (`:416-425`). It stops without signalling if those checks fail. The reload function repeats the PID/mode check, snapshots Docker ID/start time/restart count, requires existing worker PIDs, sends USR2 specifically to the confirmed container master, waits for a new worker PID, and verifies the container remains running with unchanged identity/start/restart count (`:435-455`). The operator invokes it only after config/source gates (`:459-464`). This is a concrete, conditionally safe procedure, not an instruction to guess at or alter the deployed process model.
|
|
|
|
That signal choice agrees with the [official HAProxy 3.0 Management Guide](https://docs.haproxy.org/3.0/management.html), which documents `-W` as master-worker mode and SIGUSR2 to the master as a reload mechanism. The coordinator reports it separately exercised the exact function against an official HAProxy 3.0 image: worker handoff occurred with Docker ID, StartedAt, and RestartCount unchanged, while a non-master PID 1 was rejected before a signal. I did not rerun that container test.
|
|
|
|
The prior LOW was the ordering that could route TLS requests to Caddy before Caddy loaded its site configuration. It is closed by the explicit activation order at `docs/STAGE1_DEPLOYMENT_RUNBOOK.md:374-392`: when needed, first add and reload only the HTTP-01 challenge route; next validate and reload Caddy with Basic Auth; only after that succeeds add and reload the TLS SNI route. The HTTP route is constrained to the exact Host and `/.well-known/acme-challenge/` prefix in `deploy/randomayzer.haproxy.cfg` (lines 18-26), so this staging does not expose the new TLS route prematurely.
|
|
|
|
The follow-up also adds explicit source/active config-tree backup comparisons at `docs/STAGE1_DEPLOYMENT_RUNBOOK.md:318-325`, complementing the single-file and inode checks. Rollback now restores and reloads Caddy before using the same gated HAProxy handoff procedure (`:509-525`).
|
|
|
|
## Commands actually run
|
|
|
|
- `git rev-parse HEAD` — `c5ede46bd1c31b1e23434538fdb8a1cd925751a6`.
|
|
- `git status --short` — showed pre-existing `AGENTS.md` modification and shared task artifacts; no source changes by this reviewer.
|
|
- `git diff --stat ca28be6ae629d3d67936475ea5896b6f70f6e1e4 c5ede46bd1c31b1e23434538fdb8a1cd925751a6` — scoped follow-up change summary.
|
|
- `git diff --no-ext-diff --unified=15 ca28be6ae629d3d67936475ea5896b6f70f6e1e4 c5ede46bd1c31b1e23434538fdb8a1cd925751a6 -- docs/STAGE1_DEPLOYMENT_RUNBOOK.md deploy/randomayzer.haproxy.cfg` — inspected the review delta.
|
|
- `git show c5ede46bd1c31b1e23434538fdb8a1cd925751a6:docs/STAGE1_DEPLOYMENT_RUNBOOK.md | nl -ba | sed -n '140,550p'` — inspected final line references.
|
|
- `git show c5ede46bd1c31b1e23434538fdb8a1cd925751a6:docs/STAGE1_DEPLOYMENT_RUNBOOK.md | nl -ba | sed -n '275,325p;374,480p;509,528p'` — verified cited reload, ordering, tree-compare and rollback locations.
|
|
- `git diff --check ca28be6ae629d3d67936475ea5896b6f70f6e1e4 c5ede46bd1c31b1e23434538fdb8a1cd925751a6` — exit 0.
|
|
- Read the official HAProxy 3.0 Management Guide at `https://docs.haproxy.org/3.0/management.html` for master-worker/SIGUSR2 semantics.
|
|
|
|
Coordinator reports Caddy/HAProxy config validation and syntax checks for 25 Bash blocks passed. Those checks were not rerun by this reviewer. No full application gates, Docker test, live VPS command, or container mutation was performed by me.
|
|
|
|
## UNVERIFIED and remaining blockers
|
|
|
|
- Actual VPS PID 1, HAProxy argv/config paths, mounts, active/source equality, master-worker mode, and successful live handoff remain UNVERIFIED. The runbook explicitly stops before editing/signalling unless those preconditions are established on the VPS.
|
|
- Actual Caddy admin endpoint, routing topology, HTTP-01 issuance/renewal, DNS/WireGuard/firewall preconditions, and existing-site baselines remain UNVERIFIED. No live acceptance or phase closure is claimed.
|
|
- No remaining code-review blocker in the two prior findings; live operation remains gated on the documented operator preconditions and acceptance checks.
|
|
|
|
## Severity status
|
|
|
|
- CRITICAL: none.
|
|
- HIGH: none.
|
|
- MEDIUM: prior no-command finding CLOSED for the runbook; deploy-time process model remains UNVERIFIED.
|
|
- LOW: prior activation-order window CLOSED by the staged HTTP-01, Caddy, then TLS route sequence.
|