Files

T

admin b4edc087fa Tester gate: golden re-baked to 0.188.0, fresh-install proof PASSED — a fresh box is safe to hand to a tester

§7.2 answer: YES. A real day-0 from the existing v1.25.0 ISO reached a claimable,
app-serving box in ~10 minutes unattended, and an app's data came back from the
drive with the guest's app.yaml gone — proven readable by the application over
its own TCP path, with a discriminator (PRE-BACKUP row = 1, POST-BACKUP row = 0).

Part 0: NO ISO rebuild needed, verified against the ISO on disk rather than from
source. It bakes only felhom-bootstrap.sh, its unit and the secret-free pairing
env (full-base64 match, 1 hit each) and 0 hits for any installer, controller or
golden marker. The installer is fetched at run time; the live URL is byte-identical
to repo HEAD (v1.22.0, six days newer than the ISO) and the fresh box ran it.

Part 1: baked 0.188.0 rather than the brief's 0.187.0 — 0.187.0 lacks D5, which
is the very claim Part 2 step 6 tests. Published (404 pre-gate with a 200 control;
anonymous download, 649310288 bytes, sha match), vouched, and consumed by a real
box. R-120's gate exercised BOTH ways: 0.185.1 refused with no write, 0.188.0
allowed — evaluated, not silently skipped.

Part 3: RUNBOOK-manual-build.md cited a "RECORDED" qemu line that is itself
labelled reconstructed and whose source says it was never saved. The real
invocation is now captured from this bake as §4.0, with the bake/publish/teardown
steps; the old entry is marked SUPERSEDED.

Teardown all three layers, hub disposition stated: VM destroyed, scratch storage
removed with space returned exactly, customer sess-g DELETED via full cascade.
sess-f deliberately left (R-131) with its command recorded.

Filed, none fixed: R-128 (false ISO_VERSION invariant comment), R-129 (demo-hp's
"no baked SSH key" is stale — key auth works), R-130 (HARD_MIN_LVM_GIB warns and
proceeds), R-131 (fourth orphaned scratch customer), R-132 (curl's %{redirect_url}
printed the hub operator password into a transcript — HUB_PW needs rotating).

2026-07-31 08:27:36 +02:00

6.0 KiB

Raw Blame History

REPORT — tester gate: golden re-baked to 0.188.0, fresh-install proof PASSED (2026-07-31)

Written as REPORT-<topic>.md per CLAUDE.md:82-87 so the shared REPORT.md (E-2 increment 1) is not clobbered. Full record with every observable: documentation/audits/tester-gate-golden-0.188.0-2026-07-31.md.

Outcome

§7.2 — YES: a fresh install is safe to hand to an external tester. ISO boot → claimable, app-serving box in ~10 minutes unattended, and an app's data restored from the drive with the guest's app.yaml gone, proven readable by the application over its own TCP path.

Golden 0.186.0 → 0.188.0 baked, published, vouched. No ISO rebuilt — Part 0 proved none was needed. No existing box changed; floor still v0.156.0, MinAgent still 0.113.0.

Part 0 — the ISO does not need rebuilding

Verified against the ISO on disk, not from source. It bakes exactly three Felhom payloads (felhom-bootstrap.sh, its unit, the secret-free pairing env) — full-base64 match, 1 hit each — and 0 hits for SCRIPT_VERSION="1.2, felhom-controller, vzdump-lxc-9100. The installer is fetched at run time (felhom-bootstrap.sh:96) and the live URL is byte-identical to repo HEAD (sha ab8b283e…, v1.22.0, committed six days after the ISO). The golden arrives via the hub-vouched artifact manifest (felhom-host-install.sh:423-433). The one genuinely baked, drift-capable thing is felhom-bootstrap.sh itself — currently at repo HEAD.

Proven live, not just argued: the fresh box ran felhom-host-install v1.22.0 and fetched golden v0.188.0, sha-verified.

Part 1 — bake / publish / vouch

Baked 0.188.0, not the brief's 0.187.0: 0.187.0 lacks D5, and Part 2 step 6 is the D5 claim, so that golden could not have passed the proof this task exists for. 0.188.0 satisfies R-120 anyway. Stated rather than absorbed, per standing rule 4.

GOLDEN_VERSION=0.188.0
GOLDEN_SHA256=7353d8beb63641f87a848e45f8aa12e465647e1190ad164a65b32ad01fc3d299

Three observables: 404 pre-gate (with a 200 control on 0.186.0 so it is not vacuous), then an anonymous download returning http=200 bytes=649310288 and a matching sha; the manifest read back showing 0.188.0 selected; and the consumer call GET https://hub.felhom.eu/api/v1/artifacts/sess-g returning the pair. Plus a fourth: a real fresh box fetched and sha-verified it.

R-120's gate evaluated and allowed. Exercised both ways rather than inferred from silence — vouching 0.185.1 first produced flash=golden_behind_fleet, the logged artifact vouch REFUSED, and no write (the manifest still read 0.186.0); then 0.188.0 produced Artifact manifest set: agent=0.118.1 golden=0.188.0.

Part 2 — the clean-install proof, on demo-hp

All seven steps PASS. Venue was demo-hp (Tier 0, the designated drill host) using the scratch dir storage at /mnt/nvme-1tb that target-selection.md:38-40 names; local-lvm, drill-r50 and both 9201s untouched.

Highlights: real day-0 pairing → bind → install; a real claim (the code is emailed-only, R-119 — the operator relayed it), with the gate flipping dashboard not yet claimed → authentication required; controller 0.188.0 confirmed from the box; rallly (postgres) + homebox deployed through the real endpoints.

The D5 leg: recovery unit portable-carried=2/2, withheld=0; the carried DB_PASSWORD matched the live one by fingerprint (14c8f515…, never printed); guest app.yaml moved aside; restore returned secrets recovered=2/2. Step 7 read the data from rallly's own network namespace over TCP to rallly-postgres — not the localhost trust socket that produced D5's false pass — and the same path with a wrong password returned FATAL: password authentication failed, proving the credential does real work. The discriminator held: PRE-BACKUP row = 1, POST-BACKUP row = 0.

Part 3 — runbook integrity

RUNBOOK-manual-build.md told the reader to use a "RECORDED" qemu line that is itself labelled reconstructed, and whose source says it "was never saved". The real invocation is now captured from this bake and recorded as canonical in §4.0, alongside the bake/publish/teardown steps, the template-rot warning and where the R-120 gate actually lives. The old runbook's deviation entry is marked SUPERSEDED with a forward pointer.

Teardown — three layers

VM 310 destroyed with --purge --destroy-unreferenced-disks 1; /mnt/nvme-1tb/images/ empty.
cc-scratch removed, storage.cfg back to its original four entries; felhom-backup available 926 492 284 KiB before and after — space returned exactly.
Hub: sess-g and its host record DELETED, full cascade — customer DELETE cascade COMPLETE for sess-g (journal #8) — full teardown, residue purged including appliance_registrations=1. Verified positively: /configs and /hosts both loaded (10160 / 9880 bytes) with 0 hits for sess-g and 0 for the appliance UUID. The gate refused twice first (409 host ONLINE, then 400 missing acknowledgements) — the record cannot be deleted until the destroyed box ages out of ONLINE, ~30 min. sess-f deliberately NOT deleted (R-131); its command is in the audit §7.1. Secrets shredded in the guest and on the box.

Findings — filed, none fixed

R-128 ISO_VERSION/SCRIPT_VERSION comment is false · R-129 demo-hp's "no baked SSH key" is stale (key auth works) · R-130 HARD_MIN_LVM_GIB warns and proceeds — a hard min that is not hard · R-131 sess-f is a fourth orphaned scratch customer · R-132 — curl -w '%{redirect_url}' printed the hub operator password into a session transcript; HUB_PW needs rotating.

Not done, deliberately

No ISO built; no defect fixed; no golden deployed to an existing box; no floor or MinAgent change; offsite/PBS-DR legs not exercised (the task forbids pointing anything at production PBS or the real restic offsite, so sess-g ran DR-tier off); Campaign 10, the demo-hp repartition and subdomain onboarding untouched.

6.0 KiB Raw Blame History