admin
1623a4d5b5
Bake: build-golden.sh v3.0.0 in the drill VM, reverted to virgin and cold-booted.
GOLDEN_SHA256 76a3a98b9e7cc23bf8ae51b38a6272f576df285cb34cd22235ac3f06a31e53ec,
658 079 744 B. All four acceptance markers counted 1; excluding/FATAL/mp1 counted 0.
The 404 pre-gate was proven to work before its 404 was believed — the target URL
404'd while the existing 0.227.1 package 200'd on the same command.
The evidence is the ROUND TRIP: the downloaded bytes match the bake's size and
sha, and ./etc/felhom-controller-image read OUT of the downloaded archive says
gitea.dooplex.hu/admin/felhom-controller:0.228.0.
Vouch: three fields together — golden_version 0.228.0, agent_version 0.130.0,
min_agent 0.129.0 (read from the controller CHANGELOG header, not assumed);
wrapper_sha256 carried through explicitly. agent >= min_agent, so not the R-216
shape. Verified by RE-READING the manifest, never the flash. R-120 gate passed.
Floor raised 0.227.1 -> 0.228.0 (impact preview {"below":3,"valid":true}).
The floor is ACTING: demo-felhom self-updated 0.227.1 -> 0.228.0 in under a
minute and re-registered offsite-integrity by itself. Both demo boxes now
re-read their whole off-site store on the weekly check.
Token hygiene: file->file scp, runner script inside the VM, unit properties
grepped 0. The leak grep on the committed log was proven with a planted copy
(1) before its 0 was believed. Teardown: guest 9100 purged, secrets shredded
after the log was copied out, VM off, disk reverted to virgin.
golden_currency_gate.py red -> green. All 12 felhom.eu gates OK.
5.3 KiB
Golden bake 0.228.0 — 2026-08-31
Baked, published, round-trip verified, vouched, and the fleet floor raised. demo-felhom picked
up the new controller by itself in under a minute.
What was produced
GOLDEN_VERSION |
0.228.0 |
GOLDEN_SHA256 |
76a3a98b9e7cc23bf8ae51b38a6272f576df285cb34cd22235ac3f06a31e53ec |
| size | 658 079 744 B |
| package URL | …/api/packages/admin/generic/felhom-golden/0.228.0/golden.tar.zst |
| baked controller | gitea.dooplex.hu/admin/felhom-controller:0.228.0 |
MinAgent |
0.129.0 — read from the controller CHANGELOG.md header, not assumed |
| script | build-golden.sh v3.0.0 |
| venue | the drill VM on DooPlex, reverted to virgin and cold-booted first |
| template | debian-13-standard_13.6-1_amd64.tar.zst, after pveam update (the virgin snapshot's INDEX is stale too, and the failure reads as a bogus 400 no such template) |
Acceptance markers — counted, not eyeballed
docker OK (overlay2 : 1 ← " docker OK (overlay2; data-root /var/lib/docker)"
including mount point rootfs : 1
including mount point mp0 : 1
upload OK (HTTP 201) : 1
--- must be ZERO ---
excluding : 0
FATAL : 0
mount point mp1 : 0 ← mp1 stopped existing in build-golden.sh v3.0.0 (R-165)
felhom-controller:0.228.0 appears 4 times in the bake log.
The 404 pre-gate was PROVEN TO WORK before its 404 was believed. The target URL returned 404
and, on the same command, the existing 0.227.1 package returned 200 — a positive control, because
a 404 from a check that cannot see anything is not a measurement. The script's own pre-delete then
reported HTTP 404 (404/204 expected): nothing was overwritten.
The evidence is the ROUND TRIP, not the build log
downloaded size : 658079744 bake reported : 658079744
downloaded sha : 76a3a98b…a31e53ec bake reported : 76a3a98b…a31e53ec
And the delivered artifact was asked what it will start — ./etc/felhom-controller-image read
out of the downloaded archive:
gitea.dooplex.hu/admin/felhom-controller:0.228.0
That is the golden naming the controller it will run, read from the bytes a customer's box would actually fetch — not from the build host, and not from the local file.
The vouch — three fields, all checked
| field | value | why it is right |
|---|---|---|
golden_version |
0.228.0 | baked and round-trip verified above |
agent_version |
0.130.0 | published, unchanged, and ≥ min_agent |
min_agent |
0.129.0 | read from the golden's controller CHANGELOG header |
agent_version (0.130.0) ≥ min_agent (0.129.0) — not the R-216 shape, where a floor points above
the agent it is served with. wrapper_sha256 was carried through explicitly, because the handler
clears it when omitted. Verified by RE-READING the manifest, not by trusting the flash
(303 → ?flash=artifacts_set): golden option 0.228.0 SELECTED, agent option 0.130.0 SELECTED, and
all four shas matching what was posted.
The hub's own dropdown independently read data-sha="76a3a98b…" for 0.228.0 straight from Gitea —
the same sha as the round-trip download, from a different reader.
The R-120 gate on this POST refuses a golden below the newest controller the fleet reports; fleet newest was 0.228.0 and the golden is 0.228.0, so it passed rather than being bypassed.
The floor is ACTING, not merely set
Impact preview before the change: {"below":3,"valid":true,"version":"0.228.0"}.
Re-read after: min_controller_version value="0.228.0", DB override: v0.228.0.
demo-felhom self-updated and re-registered its jobs by itself, in under a minute:
[INFO] [selfupdate] Post-update startup: update successful (0.227.1 → 0.228.0)
[INFO] [scheduler] Daily job offsite-integrity scheduled for 2026-09-01 06:00 CEST
[INFO] [offsite-apply] settle-gate: GO — at/above floor 0.228.0 (we are 0.228.0), no managed update running
Nobody deployed to that box. Only demo-hp was ever touched by hand. Both demo machines are on
0.228.0, so both now re-read their whole off-site store on the weekly check — which is the point
of R-399 reaching the fleet, observed rather than assumed.
golden_currency_gate.py went red → green on this bake being recorded.
Token hygiene
Copied file → file (scp), never crossing a shell on either side; the bake ran through a runner
script inside the VM that reads the token itself, so it never reached a command line or a transient
unit's properties:
systemctl show golden-bake -p Environment -p ExecStart | grep -c -F "$(cat /root/.gitea-token)" → 0
The leak grep on the committed log was PROVEN TO WORK before its 0 was believed — a throwaway
copy with the token appended grepped 1, was shred -u'd, and only then was the real log's 0
taken as evidence. A 0 from an untested grep is not a measurement.
Teardown
Build guest 9100 destroyed --purge (pct list then empty); token, runner script, bake script and
log shred -u'd after the log was copied out (standing rule 5); VM powered off, qemu confirmed
gone from ps -eo comm (never pgrep -f, which self-matches), disk reverted to virgin, pidfile
removed. Nothing else provisioned: no hub record, no host record, no storage entry.