diff --git a/REPORT.md b/REPORT.md index eaeeafc..80f157b 100644 --- a/REPORT.md +++ b/REPORT.md @@ -1,42 +1,54 @@ -# REPORT — SMART-coverage capability upgrade + R-50 island-bridge SPIKE (2026-07-25) +# REPORT — R-50 island-bridge SPIKE, empirical attempt 2 (t740): STILL BLOCKED (2026-07-25) -**Overwritten** per the standing rule. felhom.eu's share of the SMART-coverage task (docs) + the R-50 -spike. (Code for the SMART fix is in felhom-agent v0.95.0 + felhom-controller v0.171.0.) +**Overwritten** per the standing rule. This session re-attempted the empirical half of +`SPIKE-island-bridge-2026-07-25.md` on the t740 (per the operator's 2026-07-25 drill-host ruling). +Docs-only; no code, no version bumps. -## Baseline → commits -felhom.eu `770ee5a` → `be2d90f` (capability-map) → **`1d65f44`** (island-bridge spike + ROADMAP). +## t740 access method +Discovery was read-only (no LAN scan): the SSH config's `demo-hp` entry (t740 = Tailscale +`100.76.96.79` / LAN `192.168.0.87`, host_id `demo-hp-bb76ea`) + the hub registry. The t740 has **no +baked SSH key**, so access used the **hub-vaulted G1 break-glass root credential** — +`host_recovery/demo-hp-bb76ea` (read from the hub SQLite via `kubectl cp` + `sqlite3`), `sshpass -e` +(secret redacted, never printed). Connected: `felhom-host`, PVE 9.2.2. -## Capability map — disk-health row upgraded (evidence) -`documentation/architecture/00-capability-map.md`: the "Lemez-egészség felügyelet" row moved -**IMPLEMENTED → PROVEN-LIVE (healthy path + delivery)**. With agent v0.95.0 + controller v0.171.0 the -card on 9201 shows both real disks with real verdicts + model labels ("AirDisk 512GB SSD" → Rendben, -"TOSHIBA MQ04ABF100" → Rendben) — reversing the 2026-07-24 "Nincs adat on a raw UUID" state. Corrected -the earlier "virtualized demo hardware" note (it is a real N100). +## P1 inventory — the finding: there is NO drill VM to probe +- **t740 (`demo-hp`):** `qm list` → **empty**; `/etc/pve/qemu-server/` → **empty**; standalone (no + cluster); only its own LXC guest 9201 + the guest-9201 LVM volumes. **No nested drill PVE VM.** +- **Hub registry:** only `demo-hp-bb76ea` (t740) + `demo-felhom-8363b5` (N100) — **no drill appliance** + (no `2f4b00`/`demo-vm`/`drill` host). +- **felhom-pve:** `qm list` empty (confirmed in attempt 1). +- **DooPlex:** the historical drill appliance `drill.qcow2` exists (`/mnt/5_hdd/felhom.eu/drill/`, 18G) + but is **powered off** — a **golden-bake** VM (bake logs to 0.153.0, last Jul 18–20) whose nested + guest is purged after each bake, so it has **no island-bridge topology** (agent + nested guest + + bootstrap) to probe. DooPlex is the production k3s node and is loaded (~17G of 62G free). -## R-50 island-bridge SPIKE — BLOCKED empirically; design half source-grounded -`documentation/audits/SPIKE-island-bridge-2026-07-25.md` (+ ROADMAP R-50 → "SPIKED (partial)"). -- **Probe 1 (drill env health): ABSENT.** `qm list` on felhom-pve is EMPTY (no nested drill PVE VM - qm300); `pct list` shows only guest 9201; no `2f4b00`/drill config. The throwaway drill appliance was - torn down. **Per the hard drill-only rule, probes 3–8 (bridge / NIC hot-add / island bind / F1 replay - / survival) were NOT run — felhom-pve networking, guest 9201, and the live agent's `listen_addr` were - left UNTOUCHED.** No live GO/NO-GO. -- **Source-grounded findings delivered (read-only):** - - **Address plan:** recommend **link-local `169.254.253.1/30`↔`.2/30`** — structurally uncollidable - with any customer LAN (RFC-3927 is neither routed nor DHCP'd), vs an obscure RFC-1918 /30's small - residual risk. - - **F1 root cause:** the LAN literal is baked in TWO places to move atomically — agent bind - (`config.go:229` ← `felhom-host-install.sh:2226/2162`) + guest dial (`provision/backhalf.go:129` → - `bootstrap.json` endpoint). - - **NEW finding — the dnsmasq trap (CONFIRMED in source):** `LANResolverConfig.WithDefaults` - (`config.go:208–210`) derives the DNS listen-address from `listen_addr`, so moving the bind to the - island silently kills LAN DNS → the spec MUST set `lan_resolver.host_ip = LAN IP` explicitly. - - **Pin:** leaf-DER-SHA256 based (address-independent) → no cert re-issue expected (source-asserted; - empirically unproven without the drill env). - - Provisioning inventory (file:line), cluster-parity (SDN on Peti's 2 nodes), and an implementation - skeleton recorded. -- **Remaining:** a rebuilt drill VM to validate probes 3–8 before any production spec. **STOP — - implementation is a future task.** +**Snapshot: N/A** (no drill VM existed to snapshot). + +## Per-probe outcomes +P2–P7 (bridge create / NIC hot-add / island bind / pin / **F1 replay** / survival) — **NOT RUN.** The +operator's ruling ("drill+build VMs on the HP from now on") is **forward-looking and not yet realized**: +no probeable drill appliance exists on the t740, and the only artifact is a stale bake VM on the +production node. **Per the hard rule ("do not improvise on production"), felhom-pve, the t740 host +networking, and guest 9201 were left UNTOUCHED.** No config was changed anywhere → **the rollback table +is empty**, and there is no island end-state to leave in place. + +## GO/NO-GO: PENDING (unchanged) — the design half still stands +The source-grounded half of the parent doc (address plan `169.254.253.1/30`↔`.2/30`; the F1 two-place +literal; the **dnsmasq trap** — `LANResolverConfig.WithDefaults` derives the DNS listen-addr from +`listen_addr`, so the spec MUST set `lan_resolver.host_ip = LAN IP`; leaf-DER pin → no cert re-issue +expected; provisioning inventory; cluster parity) is unchanged and ready. Only the **empirical** +validation remains blocked. + +## Operator decision + docs +**Operator chose (2026-07-25): they will provision a nested-PVE drill VM on the t740 (agent + a nested +guest); this spike re-runs then.** Commits (docs-only): the spike doc amended (attempt-2 section + +verdict), ROADMAP R-50 note appended, `documentation/operations/nodes.md` gains a "designated drill+build +VM host" subsection (t740 ruling + the not-yet-realized state + break-glass recipe), and the +controller/agent `CLAUDE.md` env tables gain a `demo-hp` row/note. **The build-PIPELINE relocation to the +t740 is explicitly NOT ruled or implemented — only the VM-hosting ruling is recorded.** ## Observations -- The island-bridge spike could not fulfill its empirical half; the honest outcome (env gone → STOP, no - production improvisation) is recorded, and the source analysis gives the future task a real head start. +- The t740 is a genuinely better drill host than DooPlex (dedicated demo node, ~30G RAM / ~49G free + local-lvm, not the production k3s node) — the ruling is sound; it just needs the VM created. +- The t740's agent is **0.93.0**, behind demo-felhom's 0.95.0 — a publish-when-convenient gap (noted in + nodes.md), unrelated to this spike. diff --git a/documentation/audits/SPIKE-island-bridge-2026-07-25.md b/documentation/audits/SPIKE-island-bridge-2026-07-25.md index b1a61df..bc14658 100644 --- a/documentation/audits/SPIKE-island-bridge-2026-07-25.md +++ b/documentation/audits/SPIKE-island-bridge-2026-07-25.md @@ -8,7 +8,32 @@ fixed private addresses, so the control plane survives any router/lease/site mov **validate the whole chain end-to-end on the DRILL environment (qm300 / `demo-vm-felhom-2f4b00`)** before any production spec exists. -## VERDICT UP FRONT: SPIKE BLOCKED (empirically) — drill environment is GONE. +## VERDICT UP FRONT: SPIKE STILL BLOCKED (empirically) — no probeable drill environment exists. + +**Two empirical attempts, both blocked (2026-07-25). Design half below stands; GO/NO-GO PENDING.** + +### Empirical attempt 2 (2026-07-25, PM) — the t740 was checked; there is no drill VM there. +The operator ruled (2026-07-25) that **drill + build VMs are hosted on the HP t740 (`demo-hp`) from +now on**, so this half was re-attempted there. Discovery (read-only, no LAN scan): the t740 = `demo-hp` +(Tailscale `100.76.96.79` / LAN `192.168.0.87`), accessed via the hub-vaulted G1 break-glass root +credential (`host_recovery/demo-hp-bb76ea`; secret redacted). **Findings:** +``` +t740 (demo-hp, PVE 9.2.2): qm list → (empty); /etc/pve/qemu-server/ → empty; standalone (no cluster); + only LXC guest 9201 (its OWN live demo controller). NO nested drill PVE VM. +hub registry: only demo-hp-bb76ea (t740) + demo-felhom-8363b5 (N100) — NO drill appliance. +DooPlex: drill.qcow2 EXISTS (/mnt/5_hdd/felhom.eu/drill/, 18G) but is POWERED OFF — + a GOLDEN-BAKE appliance (bake logs to 0.153.0, last Jul 18–20); its nested + guest (9100) is purged after each bake, so it has no island-bridge topology + (agent + nested guest + bootstrap.json) to probe. DooPlex is the production + k3s node and is loaded (~17G of 62G free). +``` +So the operator's ruling is **forward-looking and not yet realized** — no probeable drill appliance +exists on the t740, and the only artifact is a stale bake VM on the production node. **Per the hard rule +("do not improvise on production"), probes P2–P7 were NOT run; felhom-pve, the t740 host networking, and +guest 9201 were left UNTOUCHED.** **Operator decision (2026-07-25): they will provision a nested-PVE +drill VM on the t740 (agent + nested guest); this task re-runs then.** GO/NO-GO stays PENDING. + +### Empirical attempt 1 (2026-07-25, AM) — drill env was GONE on felhom-pve. **Probe 1 (drill env health check) — FAIL/ABSENT.** On felhom-pve (2026-07-25): diff --git a/documentation/backlog/ROADMAP.md b/documentation/backlog/ROADMAP.md index 5ccff41..82629fb 100644 --- a/documentation/backlog/ROADMAP.md +++ b/documentation/backlog/ROADMAP.md @@ -58,7 +58,7 @@ | R-35 | **Config-apply should not end the customer's session.** The offsite config push bumped `config_version` 10→11 at 16:54:58 and the controller self-restarted (container `StartedAt` 16:54:59Z, back up 16:55:02); in-memory sessions died with it and **customer zero was force-logged-out mid-flow**. | S | idea | Direction: **hot-apply the offbox target** (no restart for a config the running process can adopt), or **persist sessions** across restart. The restart itself is by design — the collateral is not. Evidence `controller-log-full.txt` | | R-36 | **Post-RESET re-enroll leaves offsite "enabled but unprovisioned" — silently.** The hub knows the state and says nothing on the customer page. | S | **SHIPPED (hub v0.67.0, 2026-07-18)** | Both halves delivered. **(1) The warning:** the customer page now names the state and the fix — enabled-but-unprovisioned raises an amber banner saying provisioning is *Save*-triggered (press Save once, then verify), reusing the exact `enabled && type == ""` predicate the offsite re-issue handler already refuses on. **(2) The related sub-item, also done:** the self-bind link is now **auto-minted at customer creation AND at RESET completion**, so the console banner's „e-mailben kapott link" is already true instead of true-once-the-operator-remembers. Extracting the shared `mintAndSendSelfBindLink` core keeps the button and the auto-mint callers on the same F1/F2 honesty rules, and the auto-mint never fails the operation it rides on. **Gap found and closed while wiring it:** `PurgeCustomerResetDBState` does NOT clear `selfbind_tokens`, so a link minted BEFORE a reset would have stayed live across it — the skip paths now clear stale tokens, giving the invariant "after auto-mint, the only live link is one we just issued, or none". Tests assert the banner is ABSENT in all three nominal cases too; red-proofed. — Original analysis: Source-cited behaviour, confirmed live in the rehearsal: **provisioning is Save-triggered** (`configs.go` `applyOffsite`) — which also answers S6's open question — and the re-enroll auto-re-issue **correctly** skips unprovisioned targets (`handler.go`). So nothing is broken; the gap is that nobody is told. Direction: flash it on the customer page. **Interim: an R-3 step.** **Related sub-item:** auto-mint the **self-bind link on customer create/RESET**, so the console banner's „e-mailben kapott link" is always already true instead of true-once-the-operator-remembers | | R-27c | **Customer self-bind, slice 2 — console-passphrase bind.** Viktor's direction: bind using a passphrase shown on the box console, alongside (not instead of) the emailed capability link. | M | idea | **Security constraints from the session ruling, all load-bearing:** passphrase **issued at customer creation**; the global-lookup endpoint must be **spray-hardened** — per-appliance **and** per-IP caps, constant-time comparison, a **single generic failure** (no oracle), alerting on abuse; an **accent-free wordlist** (console keymaps are not Hungarian); the **web capability-link path is RETAINED**; **claim-by-email is RETAINED** as the delivery-channel proof. **Also under this item:** the self-bind email gains the **public universal-ISO download link + two-line instructions** (the DIY case). **Secret-bearing per-customer ISOs are ruled OUT.** Sibling of R-27b (second-box flow) — different axis, both build on the same `/bind/` page | -| R-50 | **[P2-HIGH] Island-bridge control plane — make controller↔agent independent of the LAN.** The agent's `localapi` binds a **LAN literal** (`listen_addr`) and the guest dials that same literal from `bootstrap.json`. Move both onto a **host-internal bridge with a fixed, private address** that no router, DHCP lease, or site move can invalidate, so the control plane is location-independent and golden-image-stable. | M | **SPIKED (partial) 2026-07-25 — empirical BLOCKED, design half source-grounded** | **2026-07-25 spike (`audits/SPIKE-island-bridge-2026-07-25.md`): the drill environment (qm300 / `demo-vm-felhom-2f4b00`) is GONE** (`qm list` empty; only guest 9201 remains), so per the hard drill-only rule the empirical probes (bridge create / NIC hot-add / island bind / **F1 replay** / survival) were NOT run — production was left untouched, **no live GO/NO-GO**. The **source-grounded** half IS done: recommend **link-local `169.254.253.1/30`↔`.2/30`** (structurally uncollidable vs LAN); the F1 literal is baked in TWO places to move atomically (`config.go:229` + `felhom-host-install.sh:2226` for the bind, `provision/backhalf.go:129`/`bootstrap.json` for the guest dial); **NEW dnsmasq trap CONFIRMED in source** — `LANResolverConfig.WithDefaults` (`config.go:208–210`) derives the DNS listen-addr from `listen_addr`, so moving the bind to the island silently kills LAN DNS → the spec MUST set `lan_resolver.host_ip = LAN IP` explicitly; pin is leaf-DER-based (address-independent → no cert re-issue expected); provisioning inventory + cluster-parity (SDN on Peti's 2 nodes) + an implementation skeleton recorded. **Remaining: a rebuilt drill VM to validate probes 3–8 before the production spec.** Origin: `audits/AUDIT-vacation-remote-ops-2026-07-20.md` (F1), where this failed for real. The demo box moved to a remote site, DHCP handed it `.147` instead of `.162`, and the agent then **could not start at all** — `bind: cannot assign requested address`, systemd gave up after 4 retries — taking storage, PBS backup, quiesce, restore-test and DR down for as long as nobody noticed. Mitigated for that window by pinning `vmbr0` static back to `.162`; that is a **window mitigation, not the fix** — it still depends on the site's subnet being `192.168.0.0/24` and free at that address. **Spike-first is mandatory:** validate end-to-end on the drill environment (agent bind + guest dial + TLS SAN/pin + reinstall/golden survival + the bootstrap-config migration for already-deployed boxes) BEFORE any production spec. **Pin fact (verified 2026-07-20, `agentapi/client.go` L105-129 — supersedes the earlier "the SAN set must cover the new address" note in this entry, which was wrong):** the controller-to-agent leg sets `InsecureSkipVerify: true` and replaces chain verification with a custom `VerifyPeerCertificate` that does a raw **SHA-256 match on the leaf DER** against the bootstrap fingerprint. Hostname/SAN therefore never enters verification on this leg, so moving the agent listen address most likely needs **no cert re-issuance** - only the endpoint the guest dials. The spike must still confirm this empirically rather than trust the read. Flips a future "box survives a site/network change" map row | +| R-50 | **[P2-HIGH] Island-bridge control plane — make controller↔agent independent of the LAN.** The agent's `localapi` binds a **LAN literal** (`listen_addr`) and the guest dials that same literal from `bootstrap.json`. Move both onto a **host-internal bridge with a fixed, private address** that no router, DHCP lease, or site move can invalidate, so the control plane is location-independent and golden-image-stable. | M | **SPIKED (partial) 2026-07-25 — empirical BLOCKED, design half source-grounded** | **2026-07-25 spike (`audits/SPIKE-island-bridge-2026-07-25.md`): the drill environment (qm300 / `demo-vm-felhom-2f4b00`) is GONE** (`qm list` empty; only guest 9201 remains), so per the hard drill-only rule the empirical probes (bridge create / NIC hot-add / island bind / **F1 replay** / survival) were NOT run — production was left untouched, **no live GO/NO-GO**. The **source-grounded** half IS done: recommend **link-local `169.254.253.1/30`↔`.2/30`** (structurally uncollidable vs LAN); the F1 literal is baked in TWO places to move atomically (`config.go:229` + `felhom-host-install.sh:2226` for the bind, `provision/backhalf.go:129`/`bootstrap.json` for the guest dial); **NEW dnsmasq trap CONFIRMED in source** — `LANResolverConfig.WithDefaults` (`config.go:208–210`) derives the DNS listen-addr from `listen_addr`, so moving the bind to the island silently kills LAN DNS → the spec MUST set `lan_resolver.host_ip = LAN IP` explicitly; pin is leaf-DER-based (address-independent → no cert re-issue expected); provisioning inventory + cluster-parity (SDN on Peti's 2 nodes) + an implementation skeleton recorded. **Empirical attempt 2 (2026-07-25 PM, on the t740 per the operator's drill-host ruling): STILL BLOCKED — there is NO drill VM on the t740** (`qm list` empty; it is a real demo node running only its own guest 9201). The only drill artifact is a stale golden-bake `drill.qcow2` on the production DooPlex node (off, nested guest purged). The ruling ("drill+build VMs on the HP from now on") is forward-looking and not yet realized. **Operator decision: they will provision a nested-PVE drill VM on the t740 (agent + nested guest); this spike re-runs then.** GO/NO-GO PENDING. **Remaining: a provisioned t740 drill VM to validate probes P2–P7 before the production spec.** Origin: `audits/AUDIT-vacation-remote-ops-2026-07-20.md` (F1), where this failed for real. The demo box moved to a remote site, DHCP handed it `.147` instead of `.162`, and the agent then **could not start at all** — `bind: cannot assign requested address`, systemd gave up after 4 retries — taking storage, PBS backup, quiesce, restore-test and DR down for as long as nobody noticed. Mitigated for that window by pinning `vmbr0` static back to `.162`; that is a **window mitigation, not the fix** — it still depends on the site's subnet being `192.168.0.0/24` and free at that address. **Spike-first is mandatory:** validate end-to-end on the drill environment (agent bind + guest dial + TLS SAN/pin + reinstall/golden survival + the bootstrap-config migration for already-deployed boxes) BEFORE any production spec. **Pin fact (verified 2026-07-20, `agentapi/client.go` L105-129 — supersedes the earlier "the SAN set must cover the new address" note in this entry, which was wrong):** the controller-to-agent leg sets `InsecureSkipVerify: true` and replaces chain verification with a custom `VerifyPeerCertificate` that does a raw **SHA-256 match on the leaf DER** against the bootstrap fingerprint. Hostname/SAN therefore never enters verification on this leg, so moving the agent listen address most likely needs **no cert re-issuance** - only the endpoint the guest dials. The spike must still confirm this empirically rather than trust the read. Flips a future "box survives a site/network change" map row | | R-50b | **[P2] A root-owned privileged host artifact is delivered unversioned from `main` — "which wrapper is on this host?" is unanswerable.** `configs/felhom-pbs-apply` installs to `/usr/local/sbin/felhom-pbs-apply` (0755 root:root) and is the pinned sudoers vector for `create\|reconcile\|grant` against `/etc/pve/priv/storage`. It is fetched by `felhom-host-install.sh:1914` via `fetch_raw`, which hits `raw/branch/main/` — **no tag, no pin, no checksum, and no record in the Day-0 artifact manifest**, unlike the agent binary (sha256-vouched) and the golden image. Three consequences: (1) two hosts installed a week apart can carry different privileged wrapper code while both reporting the same agent version; (2) a host hotfixed in place (felhom-pve, 2026-07-18) is indistinguishable from one that fetched the same content — the fleet has no inventory of it; (3) an accidental push to `main` reaches the next install of every host with no review gate between commit and root-owned deployment. | S–M | **(a) SHIPPED 2026-07-21; (b)/(c) open** | **Surfaced 2026-07-21 while stopping the R-39 v0.90.1 publish** (`felhom-controller/REPORT.md` §5): the publish was cancelled precisely because the version number would have claimed to carry a fix that in fact rides this unversioned channel. Candidate shapes, in increasing cost: (a) record the wrapper's sha256 in the Day-0 artifact manifest beside the agent binary and have the agent report the installed file's hash, so drift is at least *visible*; (b) `fetch_raw` takes a pinned ref (tag or commit) supplied by the manifest rather than `main`; (c) the wrapper becomes a published generic-registry artifact with the same gate ladder as the agent binary. **(a) is the cheap honest first step and would have caught this class already.** Pairs with R-39 (whose remaining fleet half is specced separately) **(a) SHIPPED 2026-07-21 — hub v0.68.0 + agent v0.91.2.** `ArtifactManifest.WrapperSHA256` + an operator field; agents report the installed wrapper's sha256 each cycle and the host page surfaces a mismatch. **An unknown on EITHER side reads as quiet, never as drift** — lighting every host amber on rollout day is how a warning becomes background noise. Live confirmation of exactly the problem: felhom-pve's July-18 in-place hotfix hashed `2888f2ea…`, matching **no commit anyone could name**; it now reports `104db0a4…` against a vouchable manifest value. **(b)/(c) REMAIN OPEN:** the wrapper is still fetched unversioned from `raw/branch/main` — this makes drift *visible*, it does not fix the channel. Also recorded: the 0440 sudoers file is not agent-readable, so its drift stays invisible. | | R-51 | **Dead-primary alerting — a multi-container app whose MAIN container is dead must alert.** Aggregation currently classifies such a stack `unhealthy`, and `IsDownState` deliberately excludes `unhealthy`, so nothing fires. | S | **SHIPPED 2026-07-21 — controller v0.156.0** | Origin: `AUDIT-vacation-remote-ops-2026-07-20.md` (F4). Observed live: `immich-server` was `Exited` for **18 h** with the app 100 % unreachable, and the box produced **no** dead-app banner and **no** `app_start_failed` hub event — while single-container Calibre-Web, down for the same reason, alerted correctly within 90 s. **Constraint (load-bearing): do NOT simply fold `unhealthy` into down.** That exclusion is deliberate (`stacks/manager.go` fix-3, `downstate_test.go`) and reverting it reintroduces the flapping it was added to stop. Direction: distinguish *member-container-exited* from *healthcheck-failing* in the aggregation, and treat a dead primary as down | **SHIPPED 2026-07-21 (controller v0.156.0).** **The diagnosis in this row was WRONG at the source and is corrected here:** aggregation did NOT classify the stack `unhealthy`. `aggregateState`'s final branch returned `StateRunning` for any mix of running and stopped members — the comment said "report as running (partial)" — so the stack read as RUNNING and `IsDownState` had nothing to fire on. The `unhealthy` exclusion was never involved, and the constraint it protects was therefore never in tension with the fix. New `StateDegraded`: a DOWN member whose docker restart policy is `always`/`unless-stopped` means docker was supposed to be keeping it up, so the stack is degraded (a down state, alerting through the EXISTING banner + `app_start_failed` path, unchanged); `no`/`on-failure` is a finished one-shot init/migrate container and stays benign. An UNREADABLE policy counts as supervised — fail-CLOSED, deliberately the opposite of `IsDownState`'s fail-open, because there the *state* is ambiguous while here a member is known dead and only the excuse is missing (P2 census 2026-07-21: all 53 catalog templates / 78 services are `unless-stopped`, zero one-shot containers exist today). `IsDownState` gained `degraded` and NOTHING else — the `unhealthy`/`restarting`/`paused`/`unknown` exclusions are byte-identical and `downstate_test.go` is untouched and green. Red-proof: the mix branch reverted to `return StateRunning` makes the immich fixture and both production-path tests fail with `"running"`. Live leg (STOP-1) pending. Evidence: `felhom-controller/REPORT.md` (2026-07-21) **PROVEN LIVE 2026-07-21 (STOP-1, operator-present).** On guest 9201, `docker stop immich-server` at **12:50:40 CEST** (policy `unless-stopped`, three helpers left running — the exact F4 shape). **12:50:53 — 13 seconds later — the stack read `degraded`** where it read `running` for 18 hours on 2026-07-20. `10:51:11Z` **exactly ONE** `app_start_failed (warn) — Telepített alkalmazás nem fut: Immich` (single-fire verified by count, not by eye). Dashboard rendered the banner *Telepített alkalmazás nem fut: Immich (degraded)* plus the new „Részlegesen leállt" state label. `docker start` at 12:51:37 → `running` by 12:51:52 and the banner **self-cleared** (state-based, as designed). Note the banner appends the raw state in English — `(degraded)` — which is pre-existing behaviour, not introduced here, but now more visible | | R-52 | **Boot desired-state reconciliation — a `deployed: true` app should be running after boot.** The controller *reports* deployed-but-stopped apps (30 s `deadapp-check`) but never starts them, so an app that misses its boot start stays down until a human notices. | M | **SHIPPED 2026-07-21 — controller v0.156.0** | Origin: `AUDIT-vacation-remote-ops-2026-07-20.md` (F5). Observed live: the pre-transport shutdown left `immich-server` and `calibre-web` `Exited`; **10 sibling containers came back and those two did not**, and they were still down ~18 h later. **Includes root-causing why `restart: unless-stopped` did not resurrect them** — both were stopped ~25 s before power-off, so Docker most likely recorded them as user-stopped; that hypothesis is untested because the guest journal is volatile and the controller's own logs were rotated by the container recreate. Direction: a bounded start-once reconciliation (N attempts, reusing the existing boot grace), never a restart loop. Pairs with R-51 — that one is the *alarm*, this one is the *recovery* | **SHIPPED 2026-07-21 (controller v0.156.0), `internal/bootrecon`.** One bounded start-once sweep at controller startup: every deployed, non-protected, not-mid-deploy stack that still HAS containers and is down gets `StartStack`, at most **2 attempts 30 s apart**, then it stops and the alarm owns the problem. Never a restart loop. The whole sweep (5 s settle + one 30 s gap) fits inside the existing 90 s `deadAppBootGrace`, so a successful recovery never alerts and a failed one alerts honestly — asserted by a test rather than left to a comment. **The safety argument is the container gate:** the UI's Stop is `compose down`, which REMOVES the containers, while an interrupted boot leaves them behind as `Exited` — so "deployed, has containers, and they are down" is exactly the boot-orphan signature, and a zero-container stack is never touched. Red-proof: dropping that gate makes the user-stopped app get started, which is the one thing this must never do. **P1 (the `unless-stopped` root-cause probe) is deliberately NOT what this shipped on** — the reconciliation is correct whether or not Docker recorded those two containers as user-stopped, and the probe is recorded as an open question rather than a blocker. Live leg (STOP-1) pending. Evidence: `felhom-controller/REPORT.md` (2026-07-21) **PROVEN LIVE 2026-07-21 (STOP-1, operator-present), and it answered P1 for free.** Fixture on 9201: `docker stop` on bookstack (2 containers, left in place) + calibre-web, and a UI Stop on immich (`compose down` → 0 containers); then `pct reboot 9201`. Result: `10:53:22Z [bootrecon] Boot reconciliation: 1 boot-orphaned app(s) found: [bookstack] — up to 2 attempt(s)` → `10:53:28Z attempt 1/2: started "bookstack" (took 6.0s)` → `complete: 1 app(s) recovered in 1 attempt(s)`, and **ZERO `app_start_failed`** — a successful recovery inside the boot grace is silent, exactly as designed. **P1 IS NOW ANSWERED, and the F5 hypothesis is CONFIRMED:** bookstack carries `restart=unless-stopped`, the Docker daemon came up at ~10:53:15Z, and the container's `StartedAt` is **`10:53:28.05Z` — the exact moment `bootrecon`'s `StartStack` returned**. Docker's own restart policy did NOT resurrect it; a container stopped before shutdown is recorded user-stopped and stays down. Only R-52 brought it back. **BUT the end-to-end "a deliberate Stop survives a reboot" property is NOT true today, for a reason outside R-52 — see R-55.** R-52's own gate is correct and was observed to be: immich (0 containers) was never a candidate | diff --git a/documentation/operations/nodes.md b/documentation/operations/nodes.md index 9c03f7e..cb792d6 100644 --- a/documentation/operations/nodes.md +++ b/documentation/operations/nodes.md @@ -57,7 +57,22 @@ that looked installed and could never call home. Repaired on the console by brid Current, post-repair: `vmbr0` static `192.168.0.87/24`, gw `192.168.0.1`, bridge-port `enp2s0f0`. No trace of `192.168.100.2` remains. `wg-felhom` `10.77.0.3/32` up to the hub. Guest **9201 -`demo-hp`** running. +`demo-hp`** running. Agent **0.93.0** (behind demo-felhom's 0.95.0 — publish when convenient). + +### Designated drill + build VM host (operator ruling, 2026-07-25) + +**Ruling:** drill and build VMs are hosted on the **t740 from now on** — NOT on felhom-pve, and moving +them off DooPlex (the production k3s node). **This is a VM-HOSTING ruling only; the build-PIPELINE +relocation to the t740 is NOT ruled or implemented here.** + +**Current state (verified 2026-07-25):** the ruling is **forward-looking and not yet realized.** The +t740 hosts **no drill/build VM yet** — `qm list` is empty, `/etc/pve/qemu-server/` is empty, it is a +standalone PVE node running only its own LXC guest 9201. The historical drill appliance is still +`drill.qcow2` on **DooPlex** (`/mnt/5_hdd/felhom.eu/drill/`, ~18G, powered off — a golden-bake VM whose +nested guest is purged after each bake). felhom-pve likewise has no drill VM. **A nested-PVE drill VM +(agent + a nested guest) must be provisioned on the t740** before the R-50 island-bridge empirical spike +(`audits/SPIKE-island-bridge-2026-07-25.md`) can run its P2–P7 probes — that spike is blocked on exactly +this. The t740's ~30 GB RAM / ~49 GB free local-lvm suit it as the drill host. ### Access — there is no baked SSH key