Files
felhom.eu/documentation/audits/release-2026-11-03/part2/README.md
T
admin a7e86fd273
gates / gates (push) Successful in 1m57s
Release 2026-11-03 close-out: every box on 0.350.0 with Traefik v3.7.17; golden 0.350.0 + agent 0.172.0 vouched; hub 0.179.0; catalog f4c5c79
Closed: R-1354, R-1347, R-1348, R-1339, R-1351, R-1323, R-1302, R-1352, R-1331, R-1356, R-1359 (235 -> 224). R-548 and R-1361 carry today's readings.
2026-11-03 10:26:23 +01:00

3.1 KiB

Part 2 — golden 0.350.0, one fresh install, 2026-11-03

The bake: documentation/tests/golden-0.350.0-2026-11-03/. VM 9383 release1103-box on demo-hp (6 cores, 10 GiB, raw on nvme-scratch, never the thin pool), from the public ISO 1.30.0 (sha256 = the published one), graphical installer driven by qm sendkey (install/).

The path, exactly. A hub-offered install refuses any golden but the vouched one (R-297), and the brief wanted the proof before the vouch. So: the public installer felhom-host-install.sh 1.36.1, fetched from felhom.eu (sha e18cdd17…), with one added line (installer-the-one-line.diff.txt) that replaces the manifest's agent + golden with 0.172.0 + 0.350.0, run by hand as root in the DIRECT shape of felhom-bootstrap.sh (--customer-id Tester4 --mode appliance --hub-url … --passphrase-file …), not through the bind page. Everything else is the real path: the hub's enroll, the fetch from Gitea, the sha check, the provision.

Three tries, said plainly.

  1. A unit drop-in set FELHOM_INSTALL_URL, but the bootstrap blanks that variable and reads only /etc/felhom/bootstrap.env, so the box bound (bind page, 07:30:55 UTC) and installed the VOUCHED pair: golden 0.344.0, agent 0.171.0, moved by the floor to 0.350.0 about 2 minutes later (first-run-vouched-manifest-journal.txt). It proves the normal path and the floor, not the new golden. CC's mistake; read only at the end. Removed with --uninstall (uninstall-first-run.txt; the typed confirmation fed through ssh -tt on CC's own test VM).
  2. The hub refused the reinstall: 12 tries (CC expected a 45-minute limit; there is none: once a controller has reported, the passphrase stays closed until the operator deletes the host, R-1159). The operator deleted the host at 09:08:12 UTC.
  3. install-log.txt: day-0 SUCCESS 09:11:41 UTC, host Tester4-e286d3.
Check Result (end-state.txt, claim.txt, controller.log.gz, agent-journal.log.gz)
golden on the box sha256 082e2e04… = the bake and the registry
controller 0.350.0 from the golden: controller_started with no controller_updated; 0 ERROR lines
Traefik v3.7.17, image id a72cb2f4…; no v3.7.16 image on the box
hub enrolled, reports, events arrive
claim the mailed setup code, 302 / (the box then offers the recovery page for Tester4's sealed package of 2026-10-24; not entered)
one app BentoPDF: deploy 202, running, healthy, route 200

The hub's own acts on this customer: the fresh installs made the hub re-issue Tester4's PBS token on ep0 (pbsdr F-14 auto re-issue, gen 2) and its off-site key, twice. That is the product's normal hands-free cascade; CC touched nothing on ep0 by hand.

Teardown (teardown.txt): VM 9383 destroyed with its disks; the typed passwords shredded. Left for the operator: delete host Tester4-e286d3 on the Hosts page, from about 11:00 CET (the 45-minute rule).

Vouch: the operator, 10:18:10 CET: golden 0.350.0, agent 0.172.0, bundle cc34b0bc…, min_agent 0.158.1 (vouch-readback.txt: the hub's log and its database with the WAL agree).