felhom.eu/REPORT-day3-2026-10-19.md

REPORT — third day brief, 2026-10-19 (the passphrase locks once the box uses its own key; every ep0 household gets a prune job; demo-hp's address)

In plain words

• The household passphrase no longer gives a live box's keys (your D19). Each box now fetches its config with its own key. The passphrase still works for a new install. A reinstall over a live box needs you to delete the old host first.
• The brief's first shape could not be built as written. "Keys only before a box exists" would have broken every install and every live box's config updates: both use the passphrase after the box record exists. CC stopped and asked; you chose "box key first, then lock".
• ep0: every new household gets its weekly clean-up rule automatically, and the hub alarms on a household without one. tester-1 and Tester-2 got theirs (your yes).
• demo-hp's address stayed demo-hp's for a 30-minute watch after your router change.
• Live now: hub 0.161.0, controller 0.334.0 (the floor), tenant-sync v1.3.0 on ep0.

1. The passphrase (R-1159; 05 §8 [DESIGN R-1159])

• Install-order proof (read before building, the brief's STOP): the passphrase is used AFTER POST /host-enroll:
  • scripts/felhom-host-install.sh:2631 → :480, and :3525: step_agent_install and step_golden fetch the download login from GET /config;
  • felhom-agent/cmd/felhom-agent/main.go:2835: the provision bakes the passphrase into the guest's bootstrap.json;
  • felhom-controller/controller/internal/bootstrap/bootstrap.go:142: the guest's first boot pulls GET /config with it (that is how the box gets its own key);
  • cmd/controller/main.go:1176 (report.ConfigRefresher): every live box re-pulled with it on each config change;
  • :2317: the preflight checks it with /config on every run.
• Your answer: „Box key first, then lock".
• Built:
  • Hub 0.161.0: GET /box-config/{id} (the controller's own key) and passphraseKeysClosed. Passphrase keys are refused (409, no key, operator event passphrase_keys_refused) once a ≥ 0.334.0 controller has reported since the host record was made. /config, /recovery and the /host-enroll reuse path are covered; /artifacts has no key and is unchanged.
  • Controller 0.334.0: the refresh pulls with its own key (report.PullConfigPreferKey). The passphrase is used only against an older hub or before the box has a key, and never as a retry after a refused key.
• Tests:
  • Hub: TestR1159_PassphraseGivesKeysOnlyUntilTheBoxUsesItsOwn (5 cases), TestR1159_BoxPullsItsConfigWithItsOwnKey, TestR1159_BoxConfigMinControllerIsTheReleaseThatPullsWithItsKey.
  • Controller: TestR1159_RefreshUsesTheBoxKey, TestR1159_MainWiresTheKeyFirstRefresh.
  • Red-proofs: lock off → all three keys served; the old pull → 0 key pulls.
• Live on demo-hp (audits/day-2026-10-19c/P4/; the probe ran on the host from the box's own bootstrap.json, printing status codes only):
  • on 0.333.0, the passphrase → 200;
  • after its first 0.334.0 report (14:30:13 UTC), the passphrase → 409, no key, and passphrase_keys_refused was raised (the operator got the mail — CC's probe);
  • its own key → 200; a wrong key → 401.

2. ep0 prune jobs (R-1165; 07 Plane-2 row)

• Automatic: felhom-tenantsync v1.3.0 creates prune-<id> (keep-weekly 2, 03:30, max-depth 0) with a household's namespace unless a job already names it; it removes the job with the household. Its usage answer lists namespaces no job covers.
  • The hub alarms on that list (pbsdr_namespace_without_prune_job). An unread list never reads as "all covered".
  • Tests: 12 script cases (scripts/test_tenantsync_prune.py, run on every push), the checker and the client; each red-proved.
• Dry run before the question (PBS's own, P2/ep0-dry-run-tester.txt; 32 snapshots before and after):
  • tester-1: keep 2026-10-11, 2026-10-18; remove 2026-10-04.
  • Tester-2: keep 2026-10-04.
• Answer: „Yes, add both". After (13:35 UTC, P2/ep0-jobs-after.txt): prune-tester-1 and prune-Tester-2 (keep-weekly 2, 03:30) beside the demo-hp, demo-felhom and operator jobs.
• Script on ep0 (14:07 UTC, the same yes): the installed v1.2.0 matched the repo byte for byte; v1.3.0 is installed (hash = the repo's 36412c6a…), the old copy kept as .bak-1.2.0. Live usage → unpruned: []; fingerprint still answers.

3. demo-hp's address (R-1166)

• A watch every 10 s for 30 minutes (10:59–11:29 UTC): 180 samples, 0 with another MAC, SSH open throughout.
• The host's own MAC (cat /sys/class/net/vmbr0/address): 7c:d3:0a:77:d9:76 — the same as your router entry.
• Note: your DHCP pool is .120–.160, so .104 was never in it. The other device (b8:06:0d:60:45:58) most likely had .104 set by hand. If it comes back, look there.

4. Hub deploy and the controller release

• Hub 0.161.0
  • Image digest: sha256:d56c96a59c86ce2d006938d0980803a12949bcbf027cea2834cabd64118838b8 (clean clone at b6a911c3).
  • Manifest 97f27a75; only Deployment/hub was synced. Result: Synced/Healthy; the running digest is the built one; 0 [ERROR] lines; the ep0 read at 14:13 UTC was OK, with no alarm (every namespace has a job).
  • Checks: the floor was read back; host and controller reports from demo-hp, Tester 1 and demo-felhom arrived after the restart.
• Controller 0.334.0
  • Image digest: sha256:deeabe59d932cd60f8939a37bccf94f145555101fc7be64b6c5cc15f3557031a (from 546eef3); rc.1 ran on demo-hp only.
  • Per-box floors at 14:16:11 UTC. Tester 1 and demo-felhom moved at once; demo-hp moved at 14:30 (from rc.1).
  • Box walk (P5/): 0 unhealthy, 0 refusals, catalog in sync; https-only 28 OK, 0 failures; „Fájlok ↗" with no second login on demo-hp and Tester 1.
  • Global floor 0.334.0 / MinAgent 0.158.1 at 14:31:44 UTC. The per-box floors were cleared.

5. Versions, commits, rows

• Hub 0.161.0 (b6a911c3, manifest 97f27a75); controller 0.334.0 (546eef3); tenantsync v1.3.0 (in b6a911c3, on ep0). No agent change. No i18n fixture changed (no page changed).
• Rows: 163 before, 161 after; closed 3 (R-1159, R-1165, R-1166), opened 1 (R-1167).
• System poster: facts file only (felhom-system-poster.facts.md: new households get their prune job); the drawing's text („one per week, 2 weeks") is still true.
• Teardown:
  • Machine: rc.1 only on demo-hp 9201, now on the release; the probe scripts removed from demo-hp.
  • Host: none.
  • Hub: per-box floors cleared; one passphrase_keys_refused event on demo-hp (CC's probe).
  • ep0: two jobs added and the script replaced, both on the operator's yes; nothing else.

Observations

1. The installer prints „unexpected hub status 409" instead of the hub's sentence when a re-run meets a live box. FILED: R-1167.
2. The brief's „keys only while no host exists" would have broken every install and every live box's config refresh. NOT-A-FINDING: measured before building and put to the operator, who chose the two-step shape (D19); recorded in 05 §8.
3. A reinstall over a live box now gets two operator mails (R-1154's reinstall warning and the refusal). NOT-A-FINDING: both are true and give the same instruction; the 1-hour cooldown limits repeats.
4. An rc build (0.334.0-rc.N) counts as older than 0.334.0, so the lock stays open on an rc. NOT-A-FINDING: by design (an rc runs on demo-hp only, and the floor moves it to the release); proven on rc.1 (200) and the release (409).
5. demo-hp's .104 lies outside the router's DHCP pool, yet another MAC held it this morning. NOT-A-FINDING: the router reservation fixed it (30 minutes clean); the other device's source is noted in R-1166's closing text in case it returns.