admin
a7e86fd273
gates / gates (push) Successful in 1m57s
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.
26 lines
3.1 KiB
Markdown
26 lines
3.1 KiB
Markdown
# 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).
|