f651b31a7a
gates / gates (push) Successful in 22s
Closes the delivery gap v0.207.0 opened this session. Until now the gate was correctly red and a machine installed today would have received 0.206.0 — the release written, tested and pushed, and not delivered. Round trip is the evidence, not the build log: the published bytes were downloaded back (656 879 192 B, sha256 20ec9602…22995, both identical to what the bake reported) and ./etc/felhom-controller-image read OUT of the downloaded archive says felhom-controller:0.207.0 — the delivered artifact naming the controller it will start. Acceptance markers were the ones R-233 re-captured from a real log: docker OK (overlay2…) x1, including mount point rootfs AND mp0 x2 (there is no mp1 since build-golden.sh v3.0.0), upload OK (HTTP 201) x1, excluding 0, FATAL 0. The 404 pre-gate ran WITH a control so a 404 could not mean 'wrong URL': 0.206.0 -> 200, 0.207.0 -> 404. The token never crossed a shell — copied file->file, read by a runner script inside the VM; systemctl show grep for the value returned 0. The token-leak grep on the COMMITTED log returned 0, and that 0 is evidence because a planted copy returned 1 before being shredded. Vouch was a three-field change with all three checked deliberately: MinAgent 0.127.0 read from the golden's controller CHANGELOG header, agent_version already >= it, min_agent not above agent_version (not the R-216 shape). Verified by re-reading the manifest rather than trusting the flash. The R-120 gate did not refuse. Drill VM restored to virgin; qemu confirmed exited with ps -eo comm, not a self-matching pgrep -f. R-242: the bake half is done and the --no-verify bypass declared earlier today is now historical. Its remaining half is UNCHANGED — nothing gates the VOUCH itself, so a baked-but-unvouched golden still passes the currency gate silently.
133 lines
6.5 KiB
Markdown
133 lines
6.5 KiB
Markdown
# Golden 0.207.0 — baked, published, round-trip verified, VOUCHED (2026-08-08)
|
|
|
|
**Closes the delivery gap opened by controller v0.207.0** (R-249 / R-252 / R-253). Until this bake,
|
|
`golden_currency_gate.py` was correctly red and **a machine installed today would have received
|
|
0.206.0** — the release written, tested and pushed, and not delivered. Evidence: `bake.log` (325
|
|
lines, beside this file).
|
|
|
|
## Where it ran
|
|
|
|
The **drill VM on DooPlex** (`/mnt/5_hdd/felhom.eu/drill/drill.qcow2`, internal snapshot `virgin`) —
|
|
the accepted Tier-2 exception **for bakes**, per `runbooks/target-selection.md`. Launched with the
|
|
canonical §4.0 line (`if=virtio` is load-bearing; the guest expects `/dev/vda`), cold-booted because
|
|
the snapshot is disk-only (0 B `VM_SIZE`). **Restored to `virgin` afterwards**, verified.
|
|
|
|
Liveness was checked with `ps -eo comm | grep -c qemu-system-x86`, never `pgrep -f`, which
|
|
self-matches its own command line and reports a false "still running".
|
|
|
|
## The inputs, listed rather than assumed
|
|
|
|
| | |
|
|
|---|---|
|
|
| host | `drill-pve`, `pve-manager/9.2.2`, 40 G free on `/` |
|
|
| template | **`debian-13-standard_13.6-1_amd64.tar.zst`** — listed with `pveam available` on the day, because *the exact point release rots*; checksum verified on download |
|
|
| build script | `felhom-agent/configs/build-golden.sh` **v3.0.0**, from a clean tree at `703db166e762` (`git status` empty, `HEAD == origin/main`) |
|
|
| controller baked | `gitea.dooplex.hu/admin/felhom-controller:0.207.0` — a **required** argument; `GOLDEN_VERSION` is derived from it |
|
|
|
|
## The token never crossed a shell
|
|
|
|
Copied **file → file** (`scp ~/.gitea-token → /root/.gitea-token`, `0600`), and the bake launched
|
|
through a runner script **inside** the VM that reads the file itself. The older `--setenv=` form put
|
|
the value where `systemctl show` prints it.
|
|
|
|
```
|
|
systemctl show golden-bake -p Environment -p ExecStart | grep -c -F "$(cat /root/.gitea-token)"
|
|
→ 0
|
|
```
|
|
|
|
## The 404 pre-gate, with a control so a 404 cannot mean "wrong URL"
|
|
|
|
```
|
|
felhom-golden/0.206.0/golden.tar.zst → 200 ← the control: the URL SHAPE is right
|
|
felhom-golden/0.207.0/golden.tar.zst → 404 ← the pre-gate: nothing to overwrite
|
|
```
|
|
|
|
The filename is `golden.tar.zst`, **not** `felhom-golden-<VER>.tar.zst` — a wrong URL 404s for the
|
|
wrong reason and passes even when the version already exists (R-233).
|
|
|
|
## Acceptance markers — each captured from this run's real log
|
|
|
|
| marker | count | verbatim |
|
|
|---|---|---|
|
|
| storage driver | **1** | ` docker OK (overlay2; data-root /var/lib/docker)` |
|
|
| mount points — rootfs **and mp0**, and **there is no mp1** | **2** | `INFO: including mount point rootfs ('/') in backup` · `INFO: including mount point mp0 ('/var/lib/felhom') in backup` |
|
|
| upload | **1** | `[golden] upload OK (HTTP 201)` |
|
|
| `excluding` | **0** | — |
|
|
| `FATAL` | **0** | — |
|
|
|
|
`Result=success`, `ExecMainStatus=0`. Archive 626 MB; guest 9100 archived in 43 s.
|
|
|
|
> **These are the markers R-233 re-captured from a real log.** The pre-2026-08-06 runbook asked for
|
|
> `overlay2 OK` and an `mp1` mount point — neither of which the script can print (mp1 stopped existing
|
|
> in `build-golden.sh` v3.0.0 when R-165 collapsed the two data volumes into one). A reader following
|
|
> that literally greps for a string that can never appear and reads `0`.
|
|
|
|
## The publish, and the round trip — the published BYTES, not the local file
|
|
|
|
```
|
|
GOLDEN_VERSION=0.207.0
|
|
GOLDEN_SHA256=20ec9602c0634f65086708d2c65865e89693c917e2e026ceb687eb9dcce22995
|
|
```
|
|
|
|
Downloaded back from `https://gitea.dooplex.hu/api/packages/admin/generic/felhom-golden/0.207.0/golden.tar.zst`:
|
|
|
|
| | |
|
|
|---|---|
|
|
| size | **656 879 192 B** — identical to what the bake reported |
|
|
| sha256 | **`20ec9602…22995`** — identical |
|
|
| **`./etc/felhom-controller-image` read OUT of the downloaded archive** | **`gitea.dooplex.hu/admin/felhom-controller:0.207.0`** |
|
|
|
|
**That last line is the one that matters:** it is not a claim about what was built, it is the delivered
|
|
artifact saying which controller it will start.
|
|
|
|
## The vouch — a THREE-field change, all three checked deliberately
|
|
|
|
`MinAgent` was **read from the golden's controller `CHANGELOG.md` header**, not assumed:
|
|
`## v0.207.0 — … — MinAgent 0.127.0`.
|
|
|
|
| field | before | after | why |
|
|
|---|---|---|---|
|
|
| `golden_version` | 0.206.0 | **0.207.0** | the new bake |
|
|
| `agent_version` | 0.127.0 | **0.127.0** | already **≥ MinAgent 0.127.0** — checked, not skipped |
|
|
| `min_agent` | 0.127.0 | **0.127.0** | equals the controller's declared `MinAgent` |
|
|
|
|
**`min_agent` is not above `agent_version`** — that is the R-216 shape, which hub v0.97.0 HOLDS rather
|
|
than serving past. **In the event this was a one-field move, and it is recorded as three because
|
|
checking all three is the point:** `golden_version` alone ships a controller onto an older agent than
|
|
it declares it needs.
|
|
|
|
`POST /configuration/artifacts` → **303 `?flash=artifacts_set`**. The **R-120 gate did not refuse** —
|
|
a refusal redirects to `?flash=golden_behind_fleet` and writes nothing. The sha the hub offered for
|
|
0.207.0 matched the bake's `GOLDEN_SHA256` exactly, which is an independent confirmation that the
|
|
package it will serve is the one baked here.
|
|
|
|
**Verified by re-reading the manifest, not by the flash:** `golden_version 0.207.0` · `agent_version
|
|
0.127.0` · `min_agent 0.127.0` · `min_controller_version 0.156.0`.
|
|
|
|
**Vouching is reversible** — re-select the previous values and Save; the 0.206.0 package was not
|
|
deleted (the publish step's pre-delete targets only its own version).
|
|
|
|
## Teardown
|
|
|
|
`pct destroy 9100 --purge` (`pct list` empty after) · token, runner, build script and in-VM log
|
|
`shred -u`'d, `/root` residue check clean · `poweroff` · qemu confirmed exited via `ps -eo comm` ·
|
|
**`qemu-img snapshot -a virgin` restored**, snapshot list re-read.
|
|
|
|
**Token-leak grep on the log that is COMMITTED here — and a `0` is only evidence once the grep is
|
|
shown to work:**
|
|
|
|
```
|
|
grep -c -F "<token>" bake.log → 0
|
|
grep -c -F "<token>" <copy with the token appended> → 1 ← the control; copy then shredded
|
|
```
|
|
|
|
## What this does and does not change
|
|
|
|
**Does:** a fresh Day-0 install now lands on **controller 0.207.0** — carrying R-249's fix (the
|
|
retrieval passphrase is no longer in the settings page's body) and R-252/R-253's restore copy.
|
|
`golden_currency_gate.py` is **green** for the first time since v0.207.0 was released.
|
|
|
|
**Does not:** the gate checks the **bake**, not the vouch — its own docstring says so, which is why
|
|
the vouch is evidenced separately above. **R-242's remaining half is untouched: nothing gates the
|
|
vouch itself.**
|