admin
059adfb8b8
GOLDEN_VERSION = 0.217.0 GOLDEN_SHA256 = 0276c5f638d140a861daba4ef25129896e259937eec0ae5cba7af42391315ad0 archive volid = local:backup/vzdump-lxc-9100-2026_08_21-21_40_05.tar.zst MinAgent = 0.129.0 (unchanged from 0.216.0) Acceptance markers counted in this run's own bake.log, not paraphrased: docker OK (overlay2 1 including mount point 2 (rootfs and mp0 — there is no mp1) upload OK (HTTP 201) 1 excluding 0 FATAL 0 Published package fetched back over HTTPS: HTTP 200. Token handling: copied file->file, read by a runner script inside the VM, never on a command line. systemctl show of the live unit contained it 0 times. The committed bake.log greps 0 for the literal token AND the grep was first PROVEN to work on that same file by appending the token to a throwaway copy (grep = 1) then shredding it — a 0 from an untested grep is not evidence. Evidence copied off the VM BEFORE teardown. Then destroy 9100 --purge, shred token+runner+script +log inside the VM (0 left), poweroff, waited for qemu using `ps -eo comm` (never `pgrep -f`, which self-matches), and reverted the drill VM to `virgin`. This unblocks the golden-currency gate, which correctly refused the previous push of the register rows: "controller v0.217.0 is released and NO golden carries it". No --no-verify was used. NOT DONE: the vouch. It is operator-gated and is a THREE-field change; vouching golden_version alone would ship this controller onto an agent older than it declares it needs.
Golden bake 0.217.0 — 2026-08-21
Baked from controller image gitea.dooplex.hu/admin/felhom-controller:0.217.0 (R-351/R-352) in the
drill VM on DooPlex, per documentation/runbooks/RUNBOOK-manual-build.md §4.0/§4.1.
GOLDEN_VERSION = 0.217.0
GOLDEN_SHA256 = 0276c5f638d140a861daba4ef25129896e259937eec0ae5cba7af42391315ad0
archive volid = local:backup/vzdump-lxc-9100-2026_08_21-21_40_05.tar.zst
template = debian-13-standard_13.6-1_amd64.tar.zst (listed fresh; the point release rots)
MinAgent = 0.129.0 (from the controller CHANGELOG header — unchanged from 0.216.0)
Acceptance markers, each counted in this run's own bake.log
| Marker | Required | Got |
|---|---|---|
docker OK (overlay2 |
≥1 | 1 |
including mount point (rootfs and mp0 — there is no mp1) |
2 | 2 |
upload OK (HTTP 201) |
≥1 | 1 |
excluding |
0 | 0 |
FATAL |
0 | 0 |
INFO: including mount point rootfs ('/') in backup
INFO: including mount point mp0 ('/var/lib/felhom') in backup
Published package fetched back over HTTPS: HTTP 200 at
https://gitea.dooplex.hu/api/packages/admin/generic/felhom-golden/0.217.0/golden.tar.zst
(the filename is golden.tar.zst, not felhom-golden-<VER>.tar.zst).
Secret handling
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 command line on either side.
systemctl show golden-bake -p Environment -p ExecStart | grep -c -F "$(cat /root/.gitea-token)"
returned 0 while the unit was live.
The committed bake.log was grepped for the literal token: 0 occurrences — and the grep was first
shown to work, by appending the token to a throwaway copy of this same file (grep returned 1),
then shred -u-ing the copy. A 0 from an untested grep is not evidence. Other secret shapes
(RESTIC_PASSWORD, PRIVATE KEY, Authorization:) also 0.
Teardown
Evidence was copied off the VM before teardown, not after. Then: pct destroy 9100 --purge,
shred -u of token + runner + build script + log inside the VM (0 files left), poweroff, waited for
qemu to exit (checked with ps -eo comm, never pgrep -f, which self-matches), and
qemu-img snapshot -a virgin — confirmed back to the single virgin snapshot.
NOT done here
The vouch is a separate, operator-gated act and has not been performed. It is a THREE-field
change (golden_version + agent_version + min_agent); vouching golden_version alone would ship
this controller onto an agent older than it declares it needs.