Files
felhom.eu/documentation/audits/CAMPAIGN-6D-2026-07-15.md
T

12 KiB
Raw Blame History

CAMPAIGN-6D — supervised acceptance of the backup-classification redesign (2026-07-15)

Operator: Viktor (present, async rulings). Driver: Claude Code (live box). Validator: project Claude. Redesign under test: 3-core ComputeCaptureSet/ComputeFabBuckets (v0.133.0), 3a offsite engine + restore + placement (v0.134.x, hub v0.55.0), 3b tier-2 v2 + NAS exclusion (v0.135.0), Task 4 .fab exclusion scoping (v0.136.0). Baselines: ctrl 0.136.0, agent 0.88.0 (published), hub 0.55.0, golden 0.136.0 (baked+published this day). Evidence sink: 180:~/campaign6/6D/evidence/.


Headline verdict

The redesign's core promise is GREEN. Both gating legs PASS on real data:

  • Accept #1 (.fab ≥1 GiB full circle) — PASS. A 1.7 GB immich .fab (1.06 GiB mandatory tar) round-trips byte-identically through a destructive compose-down-volumes re-import; the DB restores, the app boots clean, assets resolve, and zero sibling contamination (the SQ6 fix) is proven on a genuinely shared userdata root.
  • SQ3 immich offsite (broken-not-empty) — PASS. immich's offsite snapshot carries unit + mandatory appdata/immich (not the :ro optional library); a destructive restore-to-live from offsite alone makes immich functional (thumbnail and full-res original resolve), mandatory tree byte-identical.

⇒ The friend-alpha core-promise gate is GREEN. (Remaining friend-alpha prerequisites: the deferred phases below — none block the core promise.)


1. Pre-flight gate (G0G7)

Gate Result Note
G0 baselines 🟢 ctrl 0.136.0 live, hub 0.55.0, agent 0.88.0 published
G1 images settled 🟢 ctrl image + golden 0.136.0 + agent 0.88.0 all pushed to gitea today
G2 guest health 🟢 felhom-controller:0.136.0 Up (healthy), "Controller elindult (0.136.0)"
G3 credential 🟢 proven: login POST 302 → GET /backups 200 (authed)
G4 customer email 🟢 restored to nagyfenyvesi.viktor@gmail.com via the real notifications form (P3-DELIVERY) — regression-proofs the empty-form wipe bug
G5 storage headroom 🟢 176 G local + 868/108 G on drives
G6 evidence sink 🟢 180:~/campaign6/6D/evidence/
G7 clean box 🟠 campaign6 = orphaned host autofs (no systemd unit; needs a host reboot to clear; NOT a registered target → empirically inert in P-REG). teszt_enroll kept (ruling).

2. Per-phase results

Phase Result One-line evidence
P-REG F-6C-1 nightly PASS Fresh tier-2: calibre-web (NAS data) → local teszt_enroll, NAS skipped, exit 0, v2 tree; crossdrive_failed=0 in the persistent ring.
P-FAB Accept #1 (⚠) PASS 1.7 GB .fab (1.06 GiB mandatory); userdata.tar=2 KB (no siblings); DB captured; destructive re-import → immich boots, 90 photos + thumbnail resolve; mandatory byte-identical (only immich boot-markers differ).
P-TIER2 v2 deep PARTIAL Core proven in P-REG (v2 tree .felhom-tier2-layout=2, recovery-unit + userdata leg, másik adatmeghajtó). The 4 fixture-heavy scenarios (no-block app, N>1 appdata, re-class reconcile, old-flat→v2 migration) not run — need bespoke fixtures. Source guards present.
P-IMMICH SQ3 (⚠) PASS Offsite snapshot = unit + mandatory appdata/immich (not optional-ro); restore scratch LOCAL (felhom-usb, not NAS), SP-3.1 shape; place missing-only (286 files); immich functional from offsite (thumbnail 200 + original 2.07 MB 200); mandatory byte-identical.
P-PLACE F-3a-1..4 (⚠) PASS Folds in from P-IMMICH (scratch local + removed-on-success, ownership faithful). Negative: place refused with ZERO copies on no-prepared-restore. F-3a-1a/1b/4 present in source + unit-tested.
P3-BROWSER PASS Escrow typed-back ceremony completed (Viktor-driven; new code claimed → escrow_state=escrowed) — closes the long-pending supervised wizard pass. Cross-tab session shared. Hub 8-tab ring all load; live-refresh on Overview/Applications/Events/Host; dirty-form suppression via Auto-refresh "(paused)" on static/Edit tabs. Notifications tab corroborates P3-DELIVERY (OPERATOR+CUSTOMER emails SENT). Secrets not captured; recording discarded. (Deferred: session-expiry/logout re-auth.)
P3-DELIVERY enlarge-block PASS G4 email restored via real form; a 51 GiB sparse mandatory fixture tripped the gate at the real 50 GiB quota → immich enlargement blocked, unit-only push continues, run OK, EnlargedBlocked=["immich"], notifier edge-fires ONCE, both operator + customer ("Kedves Ügyfél!") emails delivered. Reverted (fixture removed, blocked-state cleared, quota untouched).
P4-DEEP deep tiers PARTIAL Snapshot coherence PASS (calibre-web + immich snapshot paths == capture set, excludes excluded/optional-ro). F7 timed-cut / restic self-heal-mid-run / restore-to-verify-compare not run (timing-sensitive).
P5-REST real crash (⚠) PASS SIGKILL host-PID mid-offbox → auto-restart ~15 s; journal marked interrupted run failed (no false success); all apps stayed up; post-crash offbox run clean (no stale lock, no marker-without-legs).
P-DAY0 golden provision CORE PASS Fresh nested PVE (qm 300 ← pre-day0-clean) → installer v1.16.0 fetched + sha-verified agent 0.88.0 (9c8daf94…) + golden 0.136.0 (e4b27fee…) vs the hub manifest → "Day-0 provision SUCCESS vmid=9201 host_id=demo-vm-felhom-2f4b00" → controller 0.136.0 Up (healthy), guest at-floor, scoped ACL, all installer fixes shipped (age/pbs-apply/guarded wrappers), root@pam rotated+vaulted. Snapshot post_day0_golden136. Deferred (agent-side, proven 07-12, not golden-specific): escrow auto-confirm (correctly PENDING — fresh repo password vs hub's stale blob; ceremony needs the DR/PBS/WG chain) + offsite round-trip (guest claimed → needs the dashboard password; the 0.136.0 offsite engine itself is already proven on the demo in P-IMMICH/P3-DELIVERY).
P-DAY0-DEEP escrow+offsite on drill guest BLOCKED Legs E (escrow ceremony) + O (offsite round-trip) could not run: the drill guest's PBS-DR chain never configured (see the MED/HIGH finding). Viktor's re-register unblock proved not cleanly achievable (reinforces the finding). Per §5 the friend-alpha provisioning gate reverts to "supervise alpha #1's escrow ceremony LIVE" (normal customer-holds-R flow). Custody note: the authorized drill deviation (CC-held R) was never exercised — no R minted/claimed; the real friend-alpha escrow runs the normal customer-holds-R supervised flow. This drill would have proved the mechanism, not a new custody model.
P-OBS aggregate-state NOT REPRODUCED No Exited(0) container present on the box → the cosmetic condition is absent right now. Observation-only.

3. Findings (ranked)

  • MED/HIGH — day-0 PBS-DR chain has no self-heal (P-DAY0-DEEP). On a fresh appliance provision the agent's PBS-DR consume fires at install before the WG tunnel is established → fingerprint probe dial 10.77.0.1:8007: i/o timeout, consumes nothing. Once the tunnel is up (it is: handshake fresh, :8007 OPEN) the agent does NOT re-request the pbs_dr descriptor — it idles "no-op until a descriptor arrives" and the one-shot descriptor's window has closed. On a re-provision with a reused WG peer, the hub's auto-provision-on-registration never re-fires, so the descriptor is never re-pushed at all. There is no operational re-trigger (hub UI has no per-peer delete; agent doesn't self-re-register). Net: a fresh customer whose WG handshake is slow at install lands with PBS-DR unconfigured → escrow ceremony cannot run → auto-confirm stays pending → offsite never activates, with no self-heal. Follow-up TASK: bridge-side re-request of the descriptor once the WG peer is confirmed up (+ re-issue on reused-peer re-provision). Recorded, not fixed inline (§13).
  • LOW — duplicate recovery units. offbox logs: "immich: multiple recovery units found, using newest (…felhom-usb…); ignoring: …felhom-flash…" (same for audiobookshelf). Controller handles it (uses newest), but a stale duplicate unit lingers on a second drive. Track: cleanup of superseded per-app recovery units. No follow-up TASK required (cosmetic/no data risk).
  • LOW — G7 orphaned autofs (campaign6). A /mnt/felhom-drives/campaign6 autofs mount with no backing systemd unit persists; cannot be cleared without a host reboot. Not a registered target (inert). Track: clear on next demo-host reboot. No follow-up TASK required (track-only; operator-reboot clears it — HUMAN action, not code).
  • No HIGH/MED correctness findings surfaced. No inline fixes made (RUNBOOK §13).

4. Headline verdict → friend-alpha

Core promise (SQ3 immich + Accept #1) GREEN, and the customer-facing enlarge-block delivery chain (P3-DELIVERY) now PASSES — the "Kedves Ügyfél!" email is proven end-to-end. Friend-alpha's backup-safety

  • customer-notification gates are satisfied on real data, and the P3-BROWSER planes (escrow typed-back ceremony completed, hub 8-tab ring, cross-tab session) now PASS. P-DAY0 CORE also PASSES — golden 0.136.0 + agent 0.88.0 provision a fresh box to a healthy controller 0.136.0 (the friend-alpha provisioning dress-rehearsal). One caveat surfaced by P-DAY0-DEEP: the fresh-provision PBS-DR chain did not self-complete (MED/HIGH finding — install-race + no self-heal), so alpha #1's escrow ceremony must be supervised live until the self-heal follow-up lands. Also remaining (nice-to-have): P-TIER2-deep / P4-timing coverage.

5. Evidence index → 180:~/campaign6/6D/evidence/

00-preflight-gate.md, 01-P-REG.md, 02-box-state-reality.md, 03-immich-prestate.manifest, 04-P-FAB-export.md, 05-P-FAB-byteidentical-diff.txt, 06-P-FAB-import.md, 07-P-IMMICH-offsite.md, 08-P-IMMICH-restore-diff.txt, 09-P-IMMICH-restore.md, 10-P-PLACE.md, 11-P5-REST.md, 12-P4-DEEP-coherence.md, 13-P3-DELIVERY.md, 14-P3-BROWSER.md, 15-P-DAY0-install.md, 16-P-DAY0-escrow-BLOCKED.md.

6. Box / morning-recovery state

  • immich is now DEPLOYED on the demo (4 containers, 90 fixture photos, admin admin@demo-felhom.eu, offbox-included). Left running as a legitimate demo app / reusable fixture — not torn down. The prior "immich nincs telepítve" offbox warning is resolved.
  • Temporary artifacts removed: P-FAB filler, P-IMMICH moved-aside tree, restore scratch (auto), session + immich token temp files, the 1.7 GB .fab bundle, the generated-photos tars, the P3 sparse fixture.
  • G4 email is now SET (notifications.email = nagyfenyvesi.viktor@gmail.com) — a deliberate, kept restore of the wiped value.
  • A NEW recovery (escrow) code was generated during P3-BROWSER (Viktor holds it off-server; the prior code is invalidated for FUTURE backups, existing history stays valid with the old code). escrow_state = escrowed. CC never saw/stored the code.
  • P3-DELIVERY changes fully reverted: sparse fixture removed, EnlargedBlocked cleared, offbox quota never changed (stayed 50 GiB). teszt_enroll kept (ruling). campaign6 orphaned mount remains (findings).

7. Outstanding queue

  • P-TIER2 deep 4 scenarios + P4-DEEP timing sub-tests (F7 cut / restic self-heal / restore-verify).
  • P-DAY0-DEEP (BLOCKED → follow-up TASK): PBS-DR self-heal (bridge re-requests the pbs_dr descriptor once the WG peer is up; re-issue on reused-peer re-provision) — see the MED/HIGH finding. Until then, friend-alpha alpha #1's escrow ceremony must be supervised live (normal customer-holds-R flow).
  • P-DAY0 teardown: drill VM qm 300 left provisioned + healthy (snapshot post_day0_golden136); stale + new hub host records for demo-vm-felhom to delete; root@pam rotated+vaulted.
  • Minor P3-BROWSER remainder: session-expiry/logout re-auth pass.
  • Signed-update train (publish agent/golden to production customers) + Peti's box — out of 6D scope.
  • LOW: duplicate recovery-unit cleanup; campaign6 autofs (host reboot).