admin
877fcd2a38
Both of the drill's HIGH findings are fixed in controller v0.218.0 and confirmed on demo-hp with a negative control first — the same planted, hash-recorded fixture run through the same steps on both builds. R-355: paperless-ngx's PostgreSQL was dumped into a directory for a stack that does not exist, so it never entered the recovery unit, the off-site copy or the restore; and because the same wrong name reached writeSafetyDump, a destructive restore took no undo copy and the fail-closed refusal was never reached. Fixed by reading the compose project label. Sweep proven able to convict before its count was trusted: one affected app of 53. R-354: the off-site restore had no named-volume leg. Now it replays them from the scratch unit, before the database and inside the stopped window, and VolumesReplayed reaches the sentence. The half-false comment beside the skip is corrected and the half that still holds is named. Golden 0.218.0 baked and published, sha 8e427869d13eafb71562b77d1535eef6c7f32b4db24f659b988ec6d7db8f478b, verified by round trip on the downloaded bytes. NOT vouched and the floor NOT raised — both are the operator's decision, and raising the floor is what puts this on demo-felhom, which is still on 0.217.0 and still has both defects. R-367 filed: the dumps already written under the wrong name are stranded. Nothing deletes them (an existing guard), they are adoptable by hand, and doing it automatically would be a migration. Ceiling R-366 -> R-367.
Golden bake — 0.218.0 (2026-08-22)
Baked in the drill VM on DooPlex per documentation/runbooks/RUNBOOK-manual-build.md §4.0/§4.1,
carrying controller v0.218.0 (R-354 + R-355).
GOLDEN_VERSION |
0.218.0 |
GOLDEN_SHA256 |
8e427869d13eafb71562b77d1535eef6c7f32b4db24f659b988ec6d7db8f478b |
| package | https://gitea.dooplex.hu/api/packages/admin/generic/felhom-golden/0.218.0/golden.tar.zst |
| size | 657 026 013 B (archive 626 MB) |
| controller image | gitea.dooplex.hu/admin/felhom-controller:0.218.0 |
| template | debian-13-standard_13.6-1_amd64.tar.zst (listed fresh, not assumed) |
MinAgent |
0.129.0 (from the controller CHANGELOG header — unchanged) |
Pass markers — each checked, with the negative controls
docker OK (overlay2 : 1 -> " docker OK (overlay2; data-root /var/lib/docker)"
including mount point : 2 -> rootfs ('/') and mp0 ('/var/lib/felhom') [there is no mp1]
upload OK (HTTP 201) : 1 -> pre-delete returned HTTP 404 (404/204 expected)
excluding : 0 <- negative control
FATAL : 0 <- negative control
Token hygiene
The Gitea token was copied file → file (scp) and read by a runner script inside the VM, so it
never crossed a shell or a unit property. Verified: systemctl show golden-bake -p Environment -p ExecStart | grep -c -F "$(cat /root/.gitea-token)" → 0.
The leak grep on this committed log was itself proven before its zero was believed: the token was appended to a throwaway copy, grepped (1), the copy shredded, and only then was the committed log's 0 accepted.
Teardown
pct destroy 9100 --purge; token, runner, build script and in-VM log shred -u'd after this log
was copied out; VM powered off; qemu exited; qemu-img snapshot -a virgin restored.
NOT vouched
The hub's Day-0 artifact manifest was not changed and the floor was not raised — both are the
operator's decision. See REPORT.md §12.