Evening 2026-10-18: fresh install proven (R-1148), OnlyOffice walk (R-1018), one-sign-in spike (R-1100 READY), Redis volumes (R-1117), CI rows, golden 0.331.0 baked; register 168 -> 168 (closed 6, opened R-1149..R-1154)

2026-10-18 23:12:21 +02:00
parent b9b56c47c0
commit e4f022a0d9
90 changed files with 1634 additions and 22 deletions
@@ -544,6 +544,12 @@ nicety.
  **loses Felhom's backup guarantees** — no PBS verify / monitoring on storage we can't reach. An
  honest signup-time tradeoff, not a hidden one.

+**When the new package reaches the hub (R-978, agent `main` 2026-10-18, unreleased):** a ceremony started again no
+longer replaces the hub's package when it starts. The package travels with the pending ceremony and is uploaded when its
+code is claimed, before the code is handed out (an upload failure is a 502 and the code stays claimable). An abandoned
+ceremony — TTL, a new start, a restart — leaves the first code opening the hub's package. Residual: the typed-back check
+is the browser's, so a code opened and not written down still replaces the package (R-1151).
+
 #### Custody across generations — what the hub retains when a blob is superseded (hub v0.60.0; **contract corrected hub v0.93.0, R-198**)

 A ceremony that seals a *different* passphrase does not destroy the blob it replaces: the hub copies
@@ -0,0 +1,24 @@
+loop=/dev/loop2
+--- lsblk p1 (the bug input)
+{"blockdevices":[{"name":"loop2p1","fstype":null,"pttype":"gpt","mountpoint":null}]}
+--- blkid -p p1 (empty part)
+DEVNAME=/dev/loop2p1
+PART_ENTRY_SCHEME=gpt
+PART_ENTRY_UUID=2b13a20b-f5a4-4906-9e30-985c170a50ad
+PART_ENTRY_TYPE=0fc63daf-8483-4772-8e79-3d69d8477de4
+PART_ENTRY_NUMBER=1
+PART_ENTRY_OFFSET=2048
+PART_ENTRY_SIZE=1048576
+PART_ENTRY_DISK=7:2
+rc=0
+--- blkid -p p2 (ext4)
+TYPE=ext4
+PART_ENTRY_SCHEME=gpt
+PART_ENTRY_NUMBER=2
+rc=0
+Re-reading the partition table failed.: Invalid argument
+--- blkid -p p1 (a dos table inside)
+PTTYPE=dos
+PART_ENTRY_SCHEME=gpt
+rc=0
+ls: cannot access '/root/r1093-scratch.img': No such file or directory
@@ -0,0 +1,4 @@
+## per-customer floors 0.331.0 / MinAgent 0.158.1 — 20:44:00
+tester-1: HTTP/1.1 303 See Other  Location: /customers/tester-1?flash=floor_set  
+demo-hp: HTTP/1.1 303 See Other  Location: /customers/demo-hp?flash=floor_set  
+demo-felhom: HTTP/1.1 303 See Other  Location: /customers/demo-felhom?flash=floor_set  
@@ -0,0 +1,6 @@
+demo-felhom|2026-10-18 20:44:04|0.330.0
+demo-felhom|2026-10-18 20:44:16|0.331.0
+demo-hp|2026-10-18 20:44:04|0.330.0
+demo-hp|2026-10-18 20:44:19|0.331.0
+tester-1|2026-10-18 20:44:03|0.330.0
+tester-1|2026-10-18 20:44:18|0.331.0
@@ -0,0 +1,52 @@
+=== demo-hp (enkisfelhom.hu) 20:45:54
+containers: 24 running; not healthy/running: traefik Up 2 days;
+unhealthy: 0
+2026/10/18 20:44:12 updater.go:855: [INFO] [selfupdate] Post-update startup: update successful (0.330.0 → 0.331.0)
+allow-list refusals since start: 0
+2026/10/18 20:44:13 sync.go:142: [INFO] [sync] Initial sync: Sablonok naprakészek — nincs változás
+installed apps (stacks with app.yaml): 12
+2026/10/18 20:44:14 handlers.go:3887: [INFO] [web] FileBrowser mounts synced (recreated) — 1 storage path(s), config updated
+2026/10/18 20:44:19 filebrowser_gate.go:94: [INFO] [infra] filebrowser: default login refused for this run — joined traefik-public, files.<domain> s
+public https://felhom.enkisfelhom.hu/login: 000
+public https://files.enkisfelhom.hu/: 200
+=== demo-felhom (demo-felhom.eu) 20:46:13
+containers: 9 running; not healthy/running: traefik Up 2 days;
+unhealthy: 0
+2026/10/18 20:44:02 [INFO] [selfupdate] Post-update startup: update successful (0.330.0 → 0.331.0)
+allow-list refusals since start: 0
+2026/10/18 20:44:02 [INFO] [sync] Initial sync: Sablonok naprakészek — nincs változás
+installed apps (stacks with app.yaml): 5
+2026/10/18 20:44:03 [INFO] [web] FileBrowser mounts synced (recreated) — 1 storage path(s), config updated
+2026/10/18 20:44:09 [INFO] [infra] filebrowser: default login refused for this run — joined traefik-public, files.<domain> served (R-1126)
+public https://felhom.demo-felhom.eu/login: 200
+public https://files.demo-felhom.eu/: 200
+=== tester-1 (enkicsifelhom.hu) 20:46:16
+containers: 10 running; not healthy/running: traefik Up 2 days;
+unhealthy: 0
+2026/10/18 20:44:11 [INFO] [selfupdate] Post-update startup: update successful (0.330.0 → 0.331.0)
+allow-list refusals since start: 0
+2026/10/18 20:44:12 [INFO] [sync] Initial sync: Sablonok naprakészek — nincs változás
+installed apps (stacks with app.yaml): 3
+2026/10/18 20:44:13 [INFO] [web] FileBrowser mounts synced (recreated) — 5 storage path(s), config updated
+2026/10/18 20:44:18 [INFO] [infra] filebrowser: default login refused for this run — joined traefik-public, files.<domain> served (R-1126)
+public https://felhom.enkicsifelhom.hu/login: 200
+public https://files.enkicsifelhom.hu/: 000
+## retries 20:47:49
+20:47:49 https://felhom.enkisfelhom.hu/login: 200 0.156759s
+20:47:49 https://files.enkisfelhom.hu/: 200 0.151312s
+20:47:49 https://felhom.enkicsifelhom.hu/login: 200 0.154273s
+20:47:49 https://files.enkicsifelhom.hu/: 200 0.186791s
+20:47:50 https://felhom.demo-felhom.eu/login: 200 0.129644s
+20:47:50 https://files.demo-felhom.eu/: 200 0.148989s
+20:48:00 https://felhom.enkisfelhom.hu/login: 200 0.138598s
+20:48:00 https://files.enkisfelhom.hu/: 200 0.137951s
+20:48:00 https://felhom.enkicsifelhom.hu/login: 200 0.168040s
+20:48:00 https://files.enkicsifelhom.hu/: 200 0.160295s
+20:48:01 https://felhom.demo-felhom.eu/login: 200 0.172388s
+20:48:01 https://files.demo-felhom.eu/: 200 0.177437s
+20:48:11 https://felhom.enkisfelhom.hu/login: 200 0.151194s
+20:48:11 https://files.enkisfelhom.hu/: 200 0.166961s
+20:48:11 https://felhom.enkicsifelhom.hu/login: 200 0.130657s
+20:48:11 https://files.enkicsifelhom.hu/: 200 0.139520s
+20:48:12 https://felhom.demo-felhom.eu/login: 200 0.166568s
+20:48:12 https://files.demo-felhom.eu/: 200 0.148200s
@@ -0,0 +1,33 @@
+control NEGATIVE (a stub answering 200 over plain http): convicted, as it must (200 -)
+== tester-1 (enkicsifelhom.hu): 6 public name(s)
+   OK   control POSITIVE http://felhom.enkicsifelhom.hu/r1033-check?q=1 -> 301 https://felhom.enkicsifelhom.hu/r1033-check?q=1
+   OK   http://files.enkicsifelhom.hu/r1033-check?q=1 -> 301 https://files.enkicsifelhom.hu/r1033-check?q=1
+   OK   http://no-such-name-r1033.enkicsifelhom.hu/r1033-check?q=1 -> 301 https://no-such-name-r1033.enkicsifelhom.hu/r1033-check?q=1
+   OK   http://paperless.enkicsifelhom.hu/r1033-check?q=1 -> 301 https://paperless.enkicsifelhom.hu/r1033-check?q=1
+   OK   http://paste.enkicsifelhom.hu/r1033-check?q=1 -> 301 https://paste.enkicsifelhom.hu/r1033-check?q=1
+   OK   http://wiki.enkicsifelhom.hu/r1033-check?q=1 -> 301 https://wiki.enkicsifelhom.hu/r1033-check?q=1
+== demo-hp (enkisfelhom.hu): 14 public name(s)
+   OK   http://arcade.enkisfelhom.hu/r1033-check?q=1 -> 301 https://arcade.enkisfelhom.hu/r1033-check?q=1
+   OK   http://books.enkisfelhom.hu/r1033-check?q=1 -> 301 https://books.enkisfelhom.hu/r1033-check?q=1
+   OK   http://docs.enkisfelhom.hu/r1033-check?q=1 -> 301 https://docs.enkisfelhom.hu/r1033-check?q=1
+   OK   http://felhom.enkisfelhom.hu/r1033-check?q=1 -> 301 https://felhom.enkisfelhom.hu/r1033-check?q=1
+   OK   http://files.enkisfelhom.hu/r1033-check?q=1 -> 301 https://files.enkisfelhom.hu/r1033-check?q=1
+   OK   http://gist.enkisfelhom.hu/r1033-check?q=1 -> 301 https://gist.enkisfelhom.hu/r1033-check?q=1
+   OK   http://ha.enkisfelhom.hu/r1033-check?q=1 -> 301 https://ha.enkisfelhom.hu/r1033-check?q=1
+   OK   http://no-such-name-r1033.enkisfelhom.hu/r1033-check?q=1 -> 301 https://no-such-name-r1033.enkisfelhom.hu/r1033-check?q=1
+   OK   http://papir.enkisfelhom.hu/r1033-check?q=1 -> 301 https://papir.enkisfelhom.hu/r1033-check?q=1
+   OK   http://paste.enkisfelhom.hu/r1033-check?q=1 -> 301 https://paste.enkisfelhom.hu/r1033-check?q=1
+   OK   http://pdf.enkisfelhom.hu/r1033-check?q=1 -> 301 https://pdf.enkisfelhom.hu/r1033-check?q=1
+   OK   http://plex.enkisfelhom.hu/r1033-check?q=1 -> 301 https://plex.enkisfelhom.hu/r1033-check?q=1
+   OK   http://travel.enkisfelhom.hu/r1033-check?q=1 -> 301 https://travel.enkisfelhom.hu/r1033-check?q=1
+   OK   http://wiki.enkisfelhom.hu/r1033-check?q=1 -> 301 https://wiki.enkisfelhom.hu/r1033-check?q=1
+== demo-felhom (demo-felhom.eu): 8 public name(s)
+   OK   http://felhom.demo-felhom.eu/r1033-check?q=1 -> 301 https://felhom.demo-felhom.eu/r1033-check?q=1
+   OK   http://files.demo-felhom.eu/r1033-check?q=1 -> 301 https://files.demo-felhom.eu/r1033-check?q=1
+   OK   http://gist.demo-felhom.eu/r1033-check?q=1 -> 301 https://gist.demo-felhom.eu/r1033-check?q=1
+   OK   http://no-such-name-r1033.demo-felhom.eu/r1033-check?q=1 -> 301 https://no-such-name-r1033.demo-felhom.eu/r1033-check?q=1
+   OK   http://prowlarr.demo-felhom.eu/r1033-check?q=1 -> 301 https://prowlarr.demo-felhom.eu/r1033-check?q=1
+   OK   http://radarr.demo-felhom.eu/r1033-check?q=1 -> 301 https://radarr.demo-felhom.eu/r1033-check?q=1
+   OK   http://sonarr.demo-felhom.eu/r1033-check?q=1 -> 301 https://sonarr.demo-felhom.eu/r1033-check?q=1
+   OK   http://torrent.demo-felhom.eu/r1033-check?q=1 -> 301 https://torrent.demo-felhom.eu/r1033-check?q=1
+== every public name redirects http -> https
@@ -0,0 +1,15 @@
+## global floor 20:48:56
+HTTP/1.1 303 See Other  Location: /configuration?flash=floor_set  
+## read back (hub.db + -wal + -shm in one tar)
+min_controller_version|0.331.0
+min_controller_version_declared_min_agent|0.331.0=0.158.1
+## clear the per-customer floors 20:49:09
+tester-1: HTTP/1.1 303 See Other  Location: /customers/tester-1?flash=floor_set  
+demo-hp: HTTP/1.1 303 See Other  Location: /customers/demo-hp?flash=floor_set  
+demo-felhom: HTTP/1.1 303 See Other  Location: /customers/demo-felhom?flash=floor_set  
+		, status TEXT NOT NULL DEFAULT 'active', min_controller_version TEXT NOT NULL DEFAULT '', config_version INTEGER NOT NULL DEFAULT 1, dr_tier INTEGER NOT NULL DEFAULT 0, min_controller_declared_min_agent TEXT NOT NULL DEFAULT '', language TEXT NOT NULL DEFAULT 'hu', min_controller_set_at TEXT NOT NULL DEFAULT '', api_key_hash TEXT NOT NULL DEFAULT '');
+demo-felhom|[]|[]
+demo-hp|[]|[]
+tester-1|[]|[]
+Tester-2|[]|[]
+Tester4|[]|[]
@@ -0,0 +1,2 @@
+0.322.0: 310 snapshots restic=restic 0.14.0
+0.331.0: 310 snapshots restic=restic 0.19.1
@@ -0,0 +1,12 @@
+iso=/var/lib/vz/template/iso/felhom-installer-1.29.0-pve9.2-1.iso sha256=dceacae5da247d76
+Formatting '/mnt/hdd_1/images/9302/vm-9302-disk-0.raw', fmt=raw size=128849018880 preallocation=off
+scsi0: successfully created disk 'nvme-scratch:9302/vm-9302-disk-0.raw,size=120G'
+update VM 9302: -boot order=scsi0;ide2
+boot: order=scsi0;ide2
+cores: 4
+ide2: local:iso/felhom-installer-1.29.0-pve9.2-1.iso,media=cdrom,size=1665356K
+memory: 8192
+name: newbox-r1148
+net0: virtio=BC:24:11:0F:7C:57,bridge=vmbr0
+scsi0: nvme-scratch:9302/vm-9302-disk-0.raw,size=120G
+19:43:15
@@ -0,0 +1,22 @@
+install pressed 19:50:19 CEST
+bind posted 20:02:58 CEST
+--- read from the hub DB (copied with its WAL), the box's journal, and the box's own /api/selfupdate/status (all UTC) ---
+17:42:21 hub: customer Tester4 created by the operator; the bind mail sent at once (Gmail catch-all)
+17:43:15 VM 9302 created on demo-hp (8 GB / 4 cores / 120 GB on nvme-scratch at /mnt/hdd_1 root); ISO 1.29.0 (sha256 dceacae5… = published)
+17:50:19 Install pressed (graphical installer, Hungarian layout kept, driven by qm sendkey; screens/)
+~18:02    console: pairing code shown (screens/13-now.png)
+18:02:58 bind through the mailed link + pairing code + owner phrase: „Sikeres összekötés" (03-bind.txt)
+18:03:13 setup-code mail
+18:03:42 hub: host Tester4-31fa0e created
+18:03:43 step 4b/8: „recovery password vaulted at the hub (stored) — now setting it on root@pam"; chpasswd; „[OK] root@pam password vaulted, set, and the PVE login takes it"
+18:03:43 hub: host_recovery.set_at for Tester4-31fa0e (the same second)
+18:03:44 step 5/8: manifest agent v0.159.2 (sha 4d98868e…), golden v0.329.0; agent sha256 verified = hub manifest; bundle 477704ea… verified
+18:04:02 first host report: agent 0.159.2
+18:05:37 first controller report: 0.329.0 (the vouched golden)
+18:05:38 the box's own record: update 0.329.0 -> 0.330.0 initiated_by „auto-floor"; completed 18:05:45
+18:05:51 controller report: 0.330.0
+18:05:54 „Day-0 provision SUCCESS — vmid=9201 host_id=Tester4-31fa0e customer=Tester4"
+18:17:14 CC's own PVE login from DooPlex: vaulted value 200; the installer's typed value 401 (04-pve-login-check.txt)
+18:18:32 dashboard claimed with the mailed setup code (302 /)
+18:19:25 BentoPDF deploy 202; 18:20:05 running, container healthy (07-first-app.txt)
+=> Install pressed to the floor: 15 min 26 s. Bind to the floor: 2 min 47 s. Nobody pressed an update.
@@ -0,0 +1 @@
+Felhom — Doboz összekötése Felhom doboz összekötése Sikeres összekötés. A doboz kb. egy percen belül folytatja a telepítést. Ezt az oldalt bezárhatod — a beállítás a háttérben befejeződik, és a vezérlőpultod hamarosan elérhető lesz. Felhom.eu
@@ -0,0 +1,2 @@
+18:17:14 PVE login with the VAULTED value: HTTP 200
+18:17:17 PVE login with the INSTALLER value (typed at install): HTTP 401
@@ -0,0 +1,7 @@
+GET /claim 200
+csrf_len 64
+HTTP/1.1 302 Found
+Location: /
+18:18:32
+{"ok":true,"data":{"running":false,"last_check":{"current_version":"0.330.0","latest_version":"0.330.0","update_available":false,"checked_at":"2026-10-18T18:06:16Z"},"last_state":{"status":"success","previous_version":"0.329.0","previous_image":"gitea.dooplex.hu/admin/felhom-controller:0.329.0","target_version":"0.330.0","target_image":"gitea.dooplex.hu/admin/felhom-controller:0.330.0","initiated_at":"2026-10-18T18:05:38Z","initiated_by":"auto-floor","completed_at":"2026-10-18T18:05:45Z"}}}
+
@@ -0,0 +1 @@
+{"ok":false,"error":"dashboard not yet claimed"}
@@ -0,0 +1,8 @@
+login 302
+csrf_len 64
+{"ok":true,"data":{"app_config":null,"domain":"tester4.test","logo_url":"/static/assets/bentopdf-logo.svg","metadata":{"display_name":"BentoPDF","description":"Adatvédelmi fókuszú PDF eszköztár","category":"tools","subdomain":"pdf","slug":"bentopdf","catalog_since":"2026-07-12","resources":{"me
+{"ok":true,"message":"Telepítés elindítva – az állapot a kártyán követhető"}
+ deploy 202
+18:19:25
+18:20:05 "state":"running" "deployed":true "state":"running" "deployed":true 
+bentopdf ghcr.io/alam00000/bentopdf:v2.8.6 Up 20 seconds (healthy)
@@ -0,0 +1,255 @@
+2026-10-18T19:53:32+02:00 tester4 systemd[1]: Starting felhom-bootstrap.service - Felhom host bootstrap (fetch + run felhom-host-install.sh unattended, retry until success)...
+2026-10-18T19:53:33+02:00 tester4 felhom-bootstrap.sh[1122]: felhom-bootstrap: console: pvebanner.service masked (it would rewrite /etc/issue with the Proxmox admin URL on every boot)
+2026-10-18T19:53:33+02:00 tester4 felhom-bootstrap.sh[1122]: felhom-bootstrap: console: /etc/issue is the Felhom text (no admin URL)
+2026-10-18T19:53:33+02:00 tester4 felhom-bootstrap.sh[1122]: felhom-bootstrap: PAIRING mode (generic ISO, no baked customer/passphrase) — hub=https://hub.felhom.eu
+2026-10-18T19:53:33+02:00 tester4 felhom-bootstrap.sh[1122]: felhom-bootstrap: registering unclaimed appliance at the hub
+2026-10-18T19:53:33+02:00 tester4 felhom-bootstrap.sh[1122]: felhom-bootstrap: registered — appliance token stored (0600); waiting for the operator or a customer self-bind
+2026-10-18T19:53:33+02:00 tester4 felhom-bootstrap.sh[1122]: felhom-bootstrap: console font -> Lat2-Terminus16 (Latin-2, ő/ű capable)
+2026-10-18T19:53:33+02:00 tester4 felhom-bootstrap.sh[1122]: felhom-bootstrap: not bound yet — polling every 30s until the operator or a customer self-bind lands (this is the normal waiting state, not an error)
+2026-10-18T20:03:04+02:00 tester4 felhom-bootstrap.sh[1122]: felhom-bootstrap: bind DELIVERED — writing credentials to the env and switching to direct install
+2026-10-18T20:03:04+02:00 tester4 felhom-bootstrap.sh[1122]: felhom-bootstrap: fetching host-install: https://felhom.eu/scripts/felhom-host-install.sh
+2026-10-18T20:03:05+02:00 tester4 felhom-bootstrap.sh[1122]: felhom-bootstrap: running host-install (customer=Tester4 mode=appliance hub=https://hub.felhom.eu)
+2026-10-18T20:03:05+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO]   auto-sized guest RAM: 4096 MiB (host 7939 MiB; clamp(host-4096, min 4096, max host-2048), ceiling host-1024)
+2026-10-18T20:03:05+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO]   auto-sized guest cores: 3 (host 4 cores; host-1, min 2)
+2026-10-18T20:03:05+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO] felhom-host-install v1.34.0 — mode=appliance customer=Tester4 vmid=9201
+2026-10-18T20:03:05+02:00 tester4 felhom-bootstrap.sh[3647]: [STEP] 1/8 pre-flight
+2026-10-18T20:03:06+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO]   pve-manager/9.2.2/b9984c6d90a4bd80 (running kernel: 7.0.2-6-pve)
+2026-10-18T20:03:07+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO]   node: tester4 (auto)
+2026-10-18T20:03:07+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO]   agent config: /etc/felhom-agent/agent.json
+2026-10-18T20:03:07+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO]   agent: not installed yet — will be fetched + installed in step 5/8
+2026-10-18T20:03:07+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO]   local-lvm free: ~54 GiB
+2026-10-18T20:03:07+02:00 tester4 felhom-bootstrap.sh[3647]: [WARN] local-lvm free ~54 GiB is below the recommended 120 GiB — the install continues; proceed only if you sized the grows deliberately
+2026-10-18T20:03:07+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO]   free RAM: ~6371 MiB
+2026-10-18T20:03:09+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO]   existing guests on this host: 0 (pct+qm)
+2026-10-18T20:03:09+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO]   archive storage 'local' present
+2026-10-18T20:03:11+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO]   acl storage 'felhom-pbs' not present yet — expected: the PBS-DR tier creates it; the grant is pre-positioned deliberately
+2026-10-18T20:03:11+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO]   dnsmasq: not present before Felhom — recorded; uninstall will remove it again if we install it
+2026-10-18T20:03:12+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO]   hub reachable (https://hub.felhom.eu)
+2026-10-18T20:03:12+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   customer 'Tester4' exists + passphrase valid
+2026-10-18T20:03:13+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO]   golden: none local — will fetch + verify from Gitea in step 7/8
+2026-10-18T20:03:15+02:00 tester4 felhom-bootstrap.sh[3647]: [OK] pre-flight passed
+2026-10-18T20:03:15+02:00 tester4 felhom-bootstrap.sh[3647]: [STEP] 2/8 Proxmox API token
+2026-10-18T20:03:19+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   token minted (secret captured, not logged)
+2026-10-18T20:03:41+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   scoped ACL applied (Base@/, Guest@/pool/felhom + /vms/990000..990009, Store@[local local-lvm felhom-pbs])
+2026-10-18T20:03:42+02:00 tester4 felhom-bootstrap.sh[3647]: [SKIP]   old broad role FelhomAgent already absent
+2026-10-18T20:03:42+02:00 tester4 felhom-bootstrap.sh[3647]: [STEP] 3/8 compute volume grows
+2026-10-18T20:03:42+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO]   auto-computed from a 54 GiB thin pool (16 §7: 50/100/130 GiB)
+2026-10-18T20:03:42+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO]   grows: rootfs +0G (->32G), data +26G (->50G, ONE volume)
+2026-10-18T20:03:42+02:00 tester4 felhom-bootstrap.sh[3647]: [STEP] 4/8 host enrollment (POST /host-enroll)
+2026-10-18T20:03:42+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   host MINTED (first enroll)
+2026-10-18T20:03:43+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO]   host_id: Tester4-31fa0e (api_key captured, not logged)
+2026-10-18T20:03:43+02:00 tester4 felhom-bootstrap.sh[3647]: [STEP] 4b/8 break-glass credential (root@pam console password → hub vault)
+2026-10-18T20:03:43+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO]   recovery password vaulted at the hub (stored) — now setting it on root@pam
+2026-10-18T20:03:43+02:00 tester4 chpasswd[3936]: pam_unix(chpasswd:chauthtok): password changed for root
+2026-10-18T20:03:43+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   root@pam password vaulted, set, and the PVE login takes it (retrieve via the operator /admin path; never logged here)
+2026-10-18T20:03:43+02:00 tester4 felhom-bootstrap.sh[3647]: [WARN]   NOTE: the root@pam password just CHANGED — the old one now fails at the PVE web GUI (:8006).
+2026-10-18T20:03:43+02:00 tester4 felhom-bootstrap.sh[3647]: [WARN]         Retrieve the new one at hub → host page (vaulted recovery credential).
+2026-10-18T20:03:43+02:00 tester4 felhom-bootstrap.sh[3647]: [STEP] 5/8 agent install (fetch + verify + install)
+2026-10-18T20:03:43+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO]   disabled pve-enterprise.sources (Enabled: no)
+2026-10-18T20:03:43+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO]   disabled ceph.sources (Enabled: no)
+2026-10-18T20:03:43+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO]   added pve-no-subscription.sources (suite=trixie)
+2026-10-18T20:03:44+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   apt repos aligned to no-subscription (changed; apt-get update OK)
+2026-10-18T20:03:44+02:00 tester4 felhom-bootstrap.sh[3647]: [WARN]   no git credential in controller.yaml — fetching artifacts ANONYMOUSLY (they are world-readable; sha256 verification unchanged)
+2026-10-18T20:03:44+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO]   manifest: agent v0.159.2 (sha 4d98868e922d6c10…), golden v0.329.0
+2026-10-18T20:03:44+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO]   fetching agent binary v0.159.2 from Gitea …
+2026-10-18T20:03:45+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   verified sha256 4d98868e922d6c10… matches the hub manifest
+2026-10-18T20:03:45+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   installed /usr/local/bin/felhom-agent (felhom-agent 0.159.2)
+2026-10-18T20:03:45+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO]   installing the 'sudo' package (required for the non-root agent model) …
+2026-10-18T20:03:48+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   sudo installed (Sudo version 1.9.16p2)
+2026-10-18T20:03:48+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO]   installing the 'age' package (escrow ceremony identity-wrap dependency) …
+2026-10-18T20:03:51+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   age installed (1.2.1)
+2026-10-18T20:03:51+02:00 tester4 useradd[4161]: new group: name=felhom-agent, GID=990
+2026-10-18T20:03:51+02:00 tester4 useradd[4161]: new user: name=felhom-agent, UID=999, GID=990, home=/home/felhom-agent, shell=/usr/sbin/nologin, from=none
+2026-10-18T20:03:51+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   created service user felhom-agent
+2026-10-18T20:03:51+02:00 tester4 usermod[4169]: add 'felhom-agent' to group 'systemd-journal'
+2026-10-18T20:03:51+02:00 tester4 usermod[4169]: add 'felhom-agent' to shadow group 'systemd-journal'
+2026-10-18T20:03:51+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   added felhom-agent to systemd-journal (unprivileged journal read for NAS verify)
+2026-10-18T20:03:53+02:00 tester4 useradd[4209]: new group: name=felhom-op, GID=1000
+2026-10-18T20:03:53+02:00 tester4 useradd[4209]: new user: name=felhom-op, UID=1000, GID=1000, home=/home/felhom-op, shell=/bin/bash, from=none
+2026-10-18T20:03:53+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   verified sha256 477704ea29809484… matches the hub manifest
+2026-10-18T20:03:54+02:00 tester4 felhom-os-apply[4246]: os-apply: BUNDLE START agent=0.159.2 sha=477704ea29809484 authority=installer files=31 write=30 same=1 kept=0 skipped=0
+2026-10-18T20:03:54+02:00 tester4 felhom-os-apply[4248]: os-apply: BUNDLE WROTE /usr/local/sbin/felhom-selfupdate-guarded (new)
+2026-10-18T20:03:54+02:00 tester4 felhom-os-apply[4249]: os-apply: BUNDLE WROTE /usr/local/sbin/felhom-pbs-apply (new)
+2026-10-18T20:03:54+02:00 tester4 felhom-os-apply[4250]: os-apply: BUNDLE WROTE /usr/local/sbin/felhom-backup-target-apply (new)
+2026-10-18T20:03:54+02:00 tester4 felhom-os-apply[4251]: os-apply: BUNDLE WROTE /usr/local/sbin/felhom-vzdump-partial-clean (new)
+2026-10-18T20:03:54+02:00 tester4 felhom-os-apply[4252]: os-apply: BUNDLE WROTE /usr/local/sbin/felhom-thin-check (new)
+2026-10-18T20:03:54+02:00 tester4 felhom-os-apply[4253]: os-apply: BUNDLE WROTE /usr/local/sbin/felhom-internal-place (new)
+2026-10-18T20:03:54+02:00 tester4 felhom-os-apply[4254]: os-apply: BUNDLE WROTE /usr/local/sbin/felhom-crash-guard (new)
+2026-10-18T20:03:54+02:00 tester4 felhom-os-apply[4255]: os-apply: BUNDLE WROTE /usr/local/sbin/felhom-priv-apply (new)
+2026-10-18T20:03:54+02:00 tester4 felhom-os-apply[4256]: os-apply: BUNDLE WROTE /var/lib/vz/snippets/felhom-guest-hook.sh (new)
+2026-10-18T20:03:54+02:00 tester4 felhom-os-apply[4257]: os-apply: BUNDLE WROTE /usr/local/sbin/felhom-shared-parent.sh (new)
+2026-10-18T20:03:54+02:00 tester4 felhom-os-apply[4258]: os-apply: BUNDLE WROTE /etc/systemd/system/felhom-shared-parent.service (new)
+2026-10-18T20:03:54+02:00 tester4 felhom-os-apply[4259]: os-apply: BUNDLE WROTE /etc/systemd/system/felhom-crash-guard.service (new)
+2026-10-18T20:03:54+02:00 tester4 felhom-os-apply[4260]: os-apply: BUNDLE WROTE /etc/systemd/system/felhom-crash-guard-check.service (new)
+2026-10-18T20:03:54+02:00 tester4 felhom-os-apply[4261]: os-apply: BUNDLE WROTE /etc/systemd/system/felhom-crash-guard-check.timer (new)
+2026-10-18T20:03:54+02:00 tester4 felhom-os-apply[4262]: os-apply: BUNDLE WROTE /etc/felhom/crash-guard.conf (new)
+2026-10-18T20:03:54+02:00 tester4 felhom-os-apply[4263]: os-apply: BUNDLE WROTE /etc/grub.d/01_felhom_oneshot (new)
+2026-10-18T20:03:54+02:00 tester4 felhom-os-apply[4264]: os-apply: BUNDLE WROTE /etc/grub.d/42_felhom_oneshot (new)
+2026-10-18T20:03:54+02:00 tester4 felhom-os-apply[4265]: os-apply: BUNDLE WROTE /etc/systemd/system/felhom-agent.service (new)
+2026-10-18T20:03:54+02:00 tester4 felhom-os-apply[4266]: os-apply: BUNDLE WROTE /etc/systemd/system/felhom-agent-rollback.service (new)
+2026-10-18T20:03:54+02:00 tester4 felhom-os-apply[4267]: os-apply: BUNDLE WROTE /etc/systemd/system/felhom-agent.service.d/felhom-agent-limits.conf (new)
+2026-10-18T20:03:54+02:00 tester4 felhom-os-apply[4268]: os-apply: BUNDLE WROTE /usr/local/sbin/felhom-mgmt-watchdog (new)
+2026-10-18T20:03:54+02:00 tester4 felhom-os-apply[4269]: os-apply: BUNDLE WROTE /etc/tmpfiles.d/felhom-privsep.conf (new)
+2026-10-18T20:03:54+02:00 tester4 felhom-os-apply[4270]: os-apply: BUNDLE WROTE /etc/systemd/system/felhom-mgmt-watchdog.service (new)
+2026-10-18T20:03:54+02:00 tester4 felhom-os-apply[4271]: os-apply: BUNDLE WROTE /etc/systemd/system/felhom-mgmt-watchdog.timer (new)
+2026-10-18T20:03:54+02:00 tester4 felhom-os-apply[4272]: os-apply: BUNDLE WROTE /etc/systemd/system/felhom-sshd.service (new)
+2026-10-18T20:03:54+02:00 tester4 felhom-os-apply[4273]: os-apply: BUNDLE WROTE /etc/felhom-oob.nft (new)
+2026-10-18T20:03:54+02:00 tester4 felhom-os-apply[4274]: os-apply: BUNDLE WROTE /etc/systemd/system/felhom-oob-nft.service (new)
+2026-10-18T20:03:54+02:00 tester4 felhom-os-apply[4275]: os-apply: BUNDLE WROTE /etc/sudoers.d/felhom-op (new)
+2026-10-18T20:03:54+02:00 tester4 felhom-os-apply[4276]: os-apply: BUNDLE WROTE /etc/sudoers.d/felhom-agent (new)
+2026-10-18T20:03:55+02:00 tester4 felhom-os-apply[4395]: os-apply: BUNDLE DONE agent=0.159.2 written=30 same=1 self-check=ok signers-created=False
+2026-10-18T20:03:55+02:00 tester4 felhom-bootstrap.sh[4398]:   os-apply: BUNDLE START agent=0.159.2 sha=477704ea29809484 authority=installer files=31 write=30 same=1 kept=0 skipped=0
+2026-10-18T20:03:55+02:00 tester4 felhom-bootstrap.sh[4398]:   os-apply: BUNDLE WROTE /usr/local/sbin/felhom-mkfs-guarded (new)
+2026-10-18T20:03:55+02:00 tester4 felhom-bootstrap.sh[4398]:   os-apply: BUNDLE WROTE /usr/local/sbin/felhom-selfupdate-guarded (new)
+2026-10-18T20:03:55+02:00 tester4 felhom-bootstrap.sh[4398]:   os-apply: BUNDLE WROTE /usr/local/sbin/felhom-pbs-apply (new)
+2026-10-18T20:03:55+02:00 tester4 felhom-bootstrap.sh[4398]:   os-apply: BUNDLE WROTE /usr/local/sbin/felhom-backup-target-apply (new)
+2026-10-18T20:03:55+02:00 tester4 felhom-bootstrap.sh[4398]:   os-apply: BUNDLE WROTE /usr/local/sbin/felhom-vzdump-partial-clean (new)
+2026-10-18T20:03:55+02:00 tester4 felhom-bootstrap.sh[4398]:   os-apply: BUNDLE WROTE /usr/local/sbin/felhom-thin-check (new)
+2026-10-18T20:03:55+02:00 tester4 felhom-bootstrap.sh[4398]:   os-apply: BUNDLE WROTE /usr/local/sbin/felhom-internal-place (new)
+2026-10-18T20:03:55+02:00 tester4 felhom-bootstrap.sh[4398]:   os-apply: BUNDLE WROTE /usr/local/sbin/felhom-crash-guard (new)
+2026-10-18T20:03:55+02:00 tester4 felhom-bootstrap.sh[4398]:   os-apply: BUNDLE WROTE /usr/local/sbin/felhom-priv-apply (new)
+2026-10-18T20:03:55+02:00 tester4 felhom-bootstrap.sh[4398]:   os-apply: BUNDLE WROTE /var/lib/vz/snippets/felhom-guest-hook.sh (new)
+2026-10-18T20:03:55+02:00 tester4 felhom-bootstrap.sh[4398]:   os-apply: BUNDLE WROTE /usr/local/sbin/felhom-shared-parent.sh (new)
+2026-10-18T20:03:55+02:00 tester4 felhom-bootstrap.sh[4398]:   os-apply: BUNDLE WROTE /etc/systemd/system/felhom-shared-parent.service (new)
+2026-10-18T20:03:55+02:00 tester4 felhom-bootstrap.sh[4398]:   os-apply: BUNDLE WROTE /etc/systemd/system/felhom-crash-guard.service (new)
+2026-10-18T20:03:55+02:00 tester4 felhom-bootstrap.sh[4398]:   os-apply: BUNDLE WROTE /etc/systemd/system/felhom-crash-guard-check.service (new)
+2026-10-18T20:03:55+02:00 tester4 felhom-bootstrap.sh[4398]:   os-apply: BUNDLE WROTE /etc/systemd/system/felhom-crash-guard-check.timer (new)
+2026-10-18T20:03:55+02:00 tester4 felhom-bootstrap.sh[4398]:   os-apply: BUNDLE WROTE /etc/felhom/crash-guard.conf (new)
+2026-10-18T20:03:55+02:00 tester4 felhom-bootstrap.sh[4398]:   os-apply: BUNDLE WROTE /etc/grub.d/01_felhom_oneshot (new)
+2026-10-18T20:03:55+02:00 tester4 felhom-bootstrap.sh[4398]:   os-apply: BUNDLE WROTE /etc/grub.d/42_felhom_oneshot (new)
+2026-10-18T20:03:55+02:00 tester4 felhom-bootstrap.sh[4398]:   os-apply: BUNDLE WROTE /etc/systemd/system/felhom-agent.service (new)
+2026-10-18T20:03:55+02:00 tester4 felhom-bootstrap.sh[4398]:   os-apply: BUNDLE WROTE /etc/systemd/system/felhom-agent-rollback.service (new)
+2026-10-18T20:03:55+02:00 tester4 felhom-bootstrap.sh[4398]:   os-apply: BUNDLE WROTE /etc/systemd/system/felhom-agent.service.d/felhom-agent-limits.conf (new)
+2026-10-18T20:03:55+02:00 tester4 felhom-bootstrap.sh[4398]:   os-apply: BUNDLE WROTE /usr/local/sbin/felhom-mgmt-watchdog (new)
+2026-10-18T20:03:55+02:00 tester4 felhom-bootstrap.sh[4398]:   os-apply: BUNDLE WROTE /etc/tmpfiles.d/felhom-privsep.conf (new)
+2026-10-18T20:03:55+02:00 tester4 felhom-bootstrap.sh[4398]:   os-apply: BUNDLE WROTE /etc/systemd/system/felhom-mgmt-watchdog.service (new)
+2026-10-18T20:03:55+02:00 tester4 felhom-bootstrap.sh[4398]:   os-apply: BUNDLE WROTE /etc/systemd/system/felhom-mgmt-watchdog.timer (new)
+2026-10-18T20:03:55+02:00 tester4 felhom-bootstrap.sh[4398]:   os-apply: BUNDLE WROTE /etc/systemd/system/felhom-sshd.service (new)
+2026-10-18T20:03:55+02:00 tester4 felhom-bootstrap.sh[4398]:   os-apply: BUNDLE WROTE /etc/felhom-oob.nft (new)
+2026-10-18T20:03:55+02:00 tester4 felhom-bootstrap.sh[4398]:   os-apply: BUNDLE WROTE /etc/systemd/system/felhom-oob-nft.service (new)
+2026-10-18T20:03:55+02:00 tester4 felhom-bootstrap.sh[4398]:   os-apply: BUNDLE WROTE /etc/sudoers.d/felhom-op (new)
+2026-10-18T20:03:55+02:00 tester4 felhom-bootstrap.sh[4398]:   os-apply: BUNDLE WROTE /etc/sudoers.d/felhom-agent (new)
+2026-10-18T20:03:55+02:00 tester4 felhom-bootstrap.sh[4398]:   os-apply: BUNDLE DONE agent=0.159.2 written=30 same=1 self-check=ok signers-created=False
+2026-10-18T20:03:56+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   installed every root-owned file from config bundle v0.159.2 (sha 477704ea29809484…; checked, previous copies kept)
+2026-10-18T20:03:56+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   OOB felhom-sshd instance + static belt from the bundle (agent renders config + fills sets once oob.enabled)
+2026-10-18T20:03:56+02:00 tester4 felhom-bootstrap.sh[3647]: [STEP] 5b/8 internal data place (Belső tárhely)
+2026-10-18T20:03:58+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO]   no internal place: only -44 GiB free for it (pool 54, reserve 16, promised 0, planned 82; needs 20)
+2026-10-18T20:03:58+02:00 tester4 felhom-bootstrap.sh[3647]: [STEP] 6/8 agent config + service
+2026-10-18T20:03:59+02:00 tester4 felhom-bootstrap.sh[3647]: [WARN]   backup target: DEGRADED — no eligible second drive, so the whole-system backup stays on the SYSTEM drive.
+2026-10-18T20:03:59+02:00 tester4 felhom-bootstrap.sh[3647]: [WARN]   It protects against file corruption but NOT against a disk failure. Attach a second drive and assign it in the dashboard.
+2026-10-18T20:03:59+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO]   creating island bridge vmbr9 (portless, 169.254.253.1/30)
+2026-10-18T20:03:59+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   vmbr9 up: 169.254.253.1/30
+2026-10-18T20:03:59+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO]   R-50 island ON: local_api=169.254.253.1:8443 (vmbr9); guest net1=169.254.253.2/30; lan_resolver.host_ip=192.168.0.109
+2026-10-18T20:03:59+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO]   node=tester4  local_api=169.254.253.1:8443  tls_fp=25:C4:B3:61:78:4A…
+2026-10-18T20:03:59+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   wrote /etc/felhom-agent/agent.json (0600 felhom-agent)
+2026-10-18T20:04:00+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   agent --selftest (read-only) passed
+2026-10-18T20:04:03+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   felhom-agent service active (non-root felhom-agent reads the config OK)
+2026-10-18T20:04:03+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   wrote /etc/felhom/os-trust.json + operator-signers (felhom-op-1) — the root-owned slow-lane anchors
+2026-10-18T20:04:03+02:00 tester4 felhom-bootstrap.sh[3647]: [STEP] 7/8 golden archive
+2026-10-18T20:04:03+02:00 tester4 felhom-bootstrap.sh[3647]: [WARN]   no git credential in controller.yaml — fetching artifacts ANONYMOUSLY (they are world-readable; sha256 verification unchanged)
+2026-10-18T20:04:04+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO]   fetching golden v0.329.0 from Gitea → /var/lib/vz/dump/vzdump-lxc-9100-2026_10_18-20_04_04.tar.zst
+2026-10-18T20:04:15+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   verified sha256 58dc40df555676d8… matches the hub manifest
+2026-10-18T20:04:16+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   golden imported + verified: local:backup/vzdump-lxc-9100-2026_10_18-20_04_04.tar.zst
+2026-10-18T20:04:16+02:00 tester4 felhom-bootstrap.sh[3647]: [STEP] 8/8 provision guest 9201
+2026-10-18T20:04:17+02:00 tester4 felhom-bootstrap.sh[3647]: [SKIP]   pool felhom already exists
+2026-10-18T20:04:17+02:00 tester4 felhom-bootstrap.sh[5665]: === felhom-agent 0.159.2 selftest=provision (vmid=9201 customer=Tester4 hostname=tester4) ===
+2026-10-18T20:04:17+02:00 tester4 felhom-bootstrap.sh[5665]:   --- front half: bring-up (provision) local:backup/vzdump-lxc-9100-2026_10_18-20_04_04.tar.zst → vmid 9201 ---
+2026-10-18T20:05:11+02:00 tester4 felhom-bootstrap.sh[5665]: time=2026-10-18T20:05:11.381+02:00 level=INFO msg="bring-up: pool membership re-asserted" vmid=9201 pool=felhom
+2026-10-18T20:05:11+02:00 tester4 felhom-bootstrap.sh[5665]:   [OK] front half: vmid 9201 up (boot+running) in 54s; MAC=BC:24:11:13:D8:4F
+2026-10-18T20:05:11+02:00 tester4 felhom-bootstrap.sh[5665]:   --- back half: mint per-guest token + populate bootstrap config mount ---
+2026-10-18T20:05:11+02:00 tester4 sudo[6764]:     root : PWD=/ ; USER=root ; COMMAND=/usr/bin/chown --reference=/var/lib/felhom-agent /var/lib/felhom-agent/guests /var/lib/felhom-agent/guests/9201
+2026-10-18T20:05:11+02:00 tester4 sudo[6764]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=0)
+2026-10-18T20:05:11+02:00 tester4 sudo[6764]: pam_unix(sudo:session): session closed for user root
+2026-10-18T20:05:11+02:00 tester4 sudo[6767]:     root : PWD=/ ; USER=root ; COMMAND=/usr/bin/chown -R 100000:100000 /var/lib/felhom-agent/guests/9201/bootstrap
+2026-10-18T20:05:11+02:00 tester4 sudo[6767]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=0)
+2026-10-18T20:05:11+02:00 tester4 sudo[6767]: pam_unix(sudo:session): session closed for user root
+2026-10-18T20:05:11+02:00 tester4 sudo[6770]:     root : PWD=/ ; USER=root ; COMMAND=/usr/sbin/pct set 9201 -mp9 /var/lib/felhom-agent/guests/9201/bootstrap,mp=/etc/felhom-bootstrap,ro=1
+2026-10-18T20:05:11+02:00 tester4 sudo[6770]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=0)
+2026-10-18T20:05:12+02:00 tester4 sudo[6770]: pam_unix(sudo:session): session closed for user root
+2026-10-18T20:05:12+02:00 tester4 sudo[6851]:     root : PWD=/ ; USER=root ; COMMAND=/usr/sbin/pct set 9201 -onboot 1
+2026-10-18T20:05:12+02:00 tester4 sudo[6851]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=0)
+2026-10-18T20:05:13+02:00 tester4 sudo[6851]: pam_unix(sudo:session): session closed for user root
+2026-10-18T20:05:13+02:00 tester4 sudo[7056]:     root : PWD=/ ; USER=root ; COMMAND=/usr/sbin/pct set 9201 --hookscript local:snippets/felhom-guest-hook.sh
+2026-10-18T20:05:13+02:00 tester4 sudo[7056]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=0)
+2026-10-18T20:05:14+02:00 tester4 sudo[7056]: pam_unix(sudo:session): session closed for user root
+2026-10-18T20:05:14+02:00 tester4 sudo[7479]:     root : PWD=/ ; USER=root ; COMMAND=/usr/bin/mkdir -p /mnt/felhom-drives
+2026-10-18T20:05:14+02:00 tester4 sudo[7479]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=0)
+2026-10-18T20:05:14+02:00 tester4 sudo[7479]: pam_unix(sudo:session): session closed for user root
+2026-10-18T20:05:14+02:00 tester4 sudo[7485]:     root : PWD=/ ; USER=root ; COMMAND=/usr/sbin/pct set 9201 -mp8 /mnt/felhom-drives,mp=/mnt/felhom-drives
+2026-10-18T20:05:14+02:00 tester4 sudo[7485]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=0)
+2026-10-18T20:05:15+02:00 tester4 sudo[7485]: pam_unix(sudo:session): session closed for user root
+2026-10-18T20:05:15+02:00 tester4 felhom-bootstrap.sh[5665]: time=2026-10-18T20:05:15.845+02:00 level=INFO msg="provision: back-half complete" vmid=9201 mount=mp9 guest_path=/etc/felhom-bootstrap endpoint=169.254.253.1:8443
+2026-10-18T20:05:15+02:00 tester4 felhom-bootstrap.sh[5665]:   [OK] back half: bootstrap mount mp9 → /etc/felhom-bootstrap on vmid 9201 (host dir /var/lib/felhom-agent/guests/9201/bootstrap)
+2026-10-18T20:05:15+02:00 tester4 felhom-bootstrap.sh[5665]:   local-api endpoint 169.254.253.1:8443 · leaf fp 7df7cb57504e66d1a1c688fd6d54e4c6c0a1970781c6ac65d2198a1b6e448f22 · token: minted (not printed)
+2026-10-18T20:05:15+02:00 tester4 felhom-bootstrap.sh[5665]: === selftest=provision OK — guest 9201 provisioned + bootstrap-mounted (KEPT) ===
+2026-10-18T20:05:15+02:00 tester4 felhom-bootstrap.sh[5665]:     next: reboot the guest → the golden's baked controller-bootstrap unit deploys the controller,
+2026-10-18T20:05:15+02:00 tester4 felhom-bootstrap.sh[5665]:     which PULLS its controller.yaml from the hub (retrieval passphrase) and merges in this local_api.
+2026-10-18T20:05:15+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   provision completed
+2026-10-18T20:05:15+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO]   rebooting guest 9201 so the baked controller-bootstrap unit picks up the mount
+2026-10-18T20:05:16+02:00 tester4 pct[7627]: <root@pam> starting task UPID:tester4:00001DDF:00011AB9:6AD50A5C:vzreboot:9201:root@pam:
+2026-10-18T20:05:16+02:00 tester4 pct[7647]: requesting reboot of CT 9201: UPID:tester4:00001DDF:00011AB9:6AD50A5C:vzreboot:9201:root@pam:
+2026-10-18T20:05:27+02:00 tester4 pct[7627]: <root@pam> end task UPID:tester4:00001DDF:00011AB9:6AD50A5C:vzreboot:9201:root@pam: OK
+2026-10-18T20:05:27+02:00 tester4 felhom-bootstrap.sh[3647]: [STEP] verify
+2026-10-18T20:05:28+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   pct status: running
+2026-10-18T20:05:29+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   onboot: 1
+2026-10-18T20:05:30+02:00 tester4 felhom-bootstrap.sh[8525]:     mp0: local-lvm:vm-9201-disk-1,mp=/var/lib/felhom,backup=1,size=50G
+2026-10-18T20:05:30+02:00 tester4 felhom-bootstrap.sh[8525]:     mp8: /mnt/felhom-drives,mp=/mnt/felhom-drives
+2026-10-18T20:05:30+02:00 tester4 felhom-bootstrap.sh[8525]:     rootfs: local-lvm:vm-9201-disk-0,size=32G
+2026-10-18T20:05:32+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   pool: guest 9201 is a member of felhom
+2026-10-18T20:05:33+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   acl: FelhomAgentBase@/ present (user+token)
+2026-10-18T20:05:34+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   acl: FelhomAgentGuest@/pool/felhom present (user+token)
+2026-10-18T20:05:36+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   acl: FelhomAgentStore@/storage/local present (user+token)
+2026-10-18T20:05:37+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   acl: FelhomAgentStore@/storage/local-lvm present (user+token)
+2026-10-18T20:05:38+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   acl: FelhomAgentStore@/storage/felhom-pbs present (user+token)
+2026-10-18T20:05:40+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   acl: FelhomAgentGuest@/vms/990000 present (user+token)
+2026-10-18T20:05:41+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   acl: FelhomAgentGuest@/vms/990001 present (user+token)
+2026-10-18T20:05:42+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   acl: FelhomAgentGuest@/vms/990002 present (user+token)
+2026-10-18T20:05:43+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   acl: FelhomAgentGuest@/vms/990003 present (user+token)
+2026-10-18T20:05:45+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   acl: FelhomAgentGuest@/vms/990004 present (user+token)
+2026-10-18T20:05:46+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   acl: FelhomAgentGuest@/vms/990005 present (user+token)
+2026-10-18T20:05:47+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   acl: FelhomAgentGuest@/vms/990006 present (user+token)
+2026-10-18T20:05:48+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   acl: FelhomAgentGuest@/vms/990007 present (user+token)
+2026-10-18T20:05:49+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   acl: FelhomAgentGuest@/vms/990008 present (user+token)
+2026-10-18T20:05:51+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   acl: FelhomAgentGuest@/vms/990009 present (user+token)
+2026-10-18T20:05:51+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   authz signers: 2 (operator-signed self-update armed)
+2026-10-18T20:05:52+02:00 tester4 felhom-bootstrap.sh[3647]: [OK]   controller: Up 6 seconds (healthy) (after ~0s)
+2026-10-18T20:05:53+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO]   controller image: gitea.dooplex.hu/admin/felhom-controller:0.330.0
+2026-10-18T20:05:54+02:00 tester4 felhom-bootstrap.sh[3647]: [WARN]   cloudflared not visible yet
+2026-10-18T20:05:54+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO]   (confirm in the hub UI that host Tester4-31fa0e reports guest 9201)
+2026-10-18T20:05:54+02:00 tester4 felhom-bootstrap.sh[3647]: [OK] Day-0 provision SUCCESS — vmid=9201 host_id=Tester4-31fa0e customer=Tester4 golden=local:backup/vzdump-lxc-9100-2026_10_18-20_04_04.tar.zst
+2026-10-18T20:05:54+02:00 tester4 felhom-bootstrap.sh[3647]: [INFO] root@pam was rotated + vaulted at step 4b — retrieve at hub → host page (the old GUI password no longer works).
+2026-10-18T20:05:54+02:00 tester4 felhom-bootstrap.sh[1122]: felhom-bootstrap: host-install SUCCESS — writing done-flag, disabling unit, scrubbing secrets
+2026-10-18T20:05:54+02:00 tester4 systemd[1]: felhom-bootstrap.service: Deactivated successfully.
+2026-10-18T20:05:54+02:00 tester4 systemd[1]: Finished felhom-bootstrap.service - Felhom host bootstrap (fetch + run felhom-host-install.sh unattended, retry until success).
+2026-10-18T20:05:54+02:00 tester4 systemd[1]: felhom-bootstrap.service: Consumed 1min 32.507s CPU time, 884.4M memory peak.
+=== agent
+2026-10-18T20:04:00+02:00 tester4 systemd[1]: Started felhom-agent.service - Felhom host agent (Proxmox host tier; hub control loop + PBS verify + storage watchdog).
+2026-10-18T20:04:00+02:00 tester4 felhom-agent[4670]: time=2026-10-18T20:04:00.468+02:00 level=INFO msg="felhom-agent daemon starting" version=0.159.2 host_id=Tester4-31fa0e hub_url=https://hub.felhom.eu interval_s=900
+2026-10-18T20:04:01+02:00 tester4 felhom-agent[4670]: time=2026-10-18T20:04:01.336+02:00 level=INFO msg="backup: restore-test scheduler starting (per-archive due-check)" eval_interval=6h0m0s settle=24h0m0s
+2026-10-18T20:04:01+02:00 tester4 felhom-agent[4670]: time=2026-10-18T20:04:01.336+02:00 level=INFO msg="pbs: verify loop starting" cadence=6h0m0s
+2026-10-18T20:04:01+02:00 tester4 felhom-agent[4670]: time=2026-10-18T20:04:01.336+02:00 level=INFO msg="storage: watchdog starting" interval=5s debounce=15s
+2026-10-18T20:04:01+02:00 tester4 sudo[4892]: felhom-agent : PWD=/ ; USER=root ; COMMAND=/usr/sbin/lvs --reportformat json --units b -o lv_name,data_percent,metadata_percent -- pve/data
+2026-10-18T20:04:01+02:00 tester4 sudo[4936]: felhom-agent : PWD=/ ; USER=root ; COMMAND=/usr/sbin/lvs --reportformat json --units b -o lv_name,data_percent,metadata_percent -- pve/data
+2026-10-18T20:04:01+02:00 tester4 felhom-agent[4670]: time=2026-10-18T20:04:01.874+02:00 level=INFO msg="selfheal: node watchdog starting" mode=appliance interval_s=60
+2026-10-18T20:04:01+02:00 tester4 felhom-agent[4670]: time=2026-10-18T20:04:01.875+02:00 level=INFO msg="guestnet: watchdog starting" interval=1m0s min_heal_interval=10m0s max_heals_per_hour=3 settle=3m0s
+2026-10-18T20:04:01+02:00 tester4 felhom-agent[4670]: time=2026-10-18T20:04:01.925+02:00 level=INFO msg="guest-power: watchdog started" interval=1m0s max_attempts=3
+2026-10-18T20:04:01+02:00 tester4 felhom-agent[4670]: time=2026-10-18T20:04:01.925+02:00 level=INFO msg="fstrim: weekly guest disk trim starting" schedule="weekly, due Wednesday from 10:00 host-local time; starts only 10:00-20:59; never beside a backup or restore-test"
+2026-10-18T20:04:01+02:00 tester4 felhom-agent[4670]: time=2026-10-18T20:04:01.925+02:00 level=INFO msg="janitor: starting (restore-test scratch retry + stale-lock sweep)" interval=10m0s
+2026-10-18T20:04:01+02:00 tester4 felhom-agent[4670]: time=2026-10-18T20:04:01.925+02:00 level=INFO msg="controller-supervisor: started" interval=30s confirm_sweeps=2 crashloop_max=3 crashloop_window=15m0s slow_crashloop_max=5 slow_crashloop_window=24h0m0s guests_dir=/var/lib/felhom-agent/guests
+2026-10-18T20:04:02+02:00 tester4 felhom-agent[4670]: time=2026-10-18T20:04:02.544+02:00 level=INFO msg="wgtunnel: registered with hub" pubkey="pUKC3lzCxXNARPkI70LtbsxdyW9QateJH1VDhAnvYD8=" assigned_ip=10.77.0.6/32 existed=false generation=1 sync=ok
+2026-10-18T20:04:03+02:00 tester4 felhom-agent[4670]: time=2026-10-18T20:04:03.198+02:00 level=INFO msg="wgtunnel: tunnel conf applied" endpoint=167.233.158.164:443 dns_name=ep0.felhom.eu assigned_ip=10.77.0.6/32 action=enable
+2026-10-18T20:04:07+02:00 tester4 sudo[5602]: felhom-agent : PWD=/ ; USER=root ; COMMAND=/usr/bin/systemctl restart dnsmasq
+2026-10-18T20:04:22+02:00 tester4 sudo[5850]: felhom-agent : PWD=/ ; USER=root ; COMMAND=/usr/sbin/lvs --reportformat json --units b -o lv_name,data_percent,metadata_percent -- pve/data
+2026-10-18T20:04:42+02:00 tester4 sudo[5963]: felhom-agent : PWD=/ ; USER=root ; COMMAND=/usr/sbin/lvs --reportformat json --units b -o lv_name,data_percent,metadata_percent -- pve/data
+2026-10-18T20:05:02+02:00 tester4 sudo[6050]: felhom-agent : PWD=/ ; USER=root ; COMMAND=/usr/sbin/lvs --reportformat json --units b -o lv_name,data_percent,metadata_percent -- pve/data
+2026-10-18T20:05:13+02:00 tester4 sudo[6939]: felhom-agent : PWD=/ ; USER=root ; COMMAND=/usr/sbin/lvs --reportformat json --units b -o lv_name,data_percent,metadata_percent -- pve/data
+2026-10-18T20:05:16+02:00 tester4 sudo[7665]: felhom-agent : PWD=/ ; USER=root ; COMMAND=/usr/sbin/lvs --reportformat json --units b -o lv_name,data_percent,metadata_percent -- pve/data
+2026-10-18T20:05:17+02:00 tester4 sudo[7695]: felhom-agent : PWD=/ ; USER=root ; COMMAND=/usr/sbin/lvs --reportformat json --units b -o lv_name,data_percent,metadata_percent -- pve/data
+2026-10-18T20:05:22+02:00 tester4 sudo[7847]: felhom-agent : PWD=/ ; USER=root ; COMMAND=/usr/sbin/lvs --reportformat json --units b -o lv_name,data_percent,metadata_percent -- pve/data
+2026-10-18T20:05:31+02:00 tester4 sudo[9006]: felhom-agent : PWD=/ ; USER=root ; COMMAND=/usr/sbin/lvs --reportformat json --units b -o lv_name,data_percent,metadata_percent -- pve/data
+2026-10-18T20:05:31+02:00 tester4 sudo[9182]: felhom-agent : PWD=/ ; USER=root ; COMMAND=/usr/sbin/lvs --reportformat json --units b -o lv_name,data_percent,metadata_percent -- pve/data
+2026-10-18T20:05:32+02:00 tester4 sudo[9449]: felhom-agent : PWD=/ ; USER=root ; COMMAND=/usr/sbin/lvs --reportformat json --units b -o lv_name,data_percent,metadata_percent -- pve/data
+2026-10-18T20:05:33+02:00 tester4 sudo[9536]: felhom-agent : PWD=/ ; USER=root ; COMMAND=/usr/sbin/lvs --reportformat json --units b -o lv_name,data_percent,metadata_percent -- pve/data
+2026-10-18T20:05:42+02:00 tester4 sudo[9917]: felhom-agent : PWD=/ ; USER=root ; COMMAND=/usr/sbin/lvs --reportformat json --units b -o lv_name,data_percent,metadata_percent -- pve/data
+2026-10-18T20:05:43+02:00 tester4 felhom-agent[4670]: time=2026-10-18T20:05:43.703+02:00 level=INFO msg="controller-swap: image file written, restarting bootstrap" vmid=9201 target=gitea.dooplex.hu/admin/felhom-controller:0.330.0
+2026-10-18T20:05:43+02:00 tester4 sudo[9961]: felhom-agent : PWD=/ ; USER=root ; COMMAND=/usr/sbin/pct exec 9201 -- systemctl restart felhom-controller-bootstrap.service
@@ -0,0 +1,7 @@
+2026-10-18 18:04:02|0.159.2|0|0||
+2026-10-18 18:19:07|0.159.2|1|1||9201
+33652|2026-10-18 18:05:37|0.329.0|1
+33653|2026-10-18 18:05:51|0.330.0|1
+33657|2026-10-18 18:18:34|0.330.0|1
+33658|2026-10-18 18:19:27|0.330.0|1
+33659|2026-10-18 18:20:46|0.330.0|1
@@ -0,0 +1,6 @@
+login 302
+{"data":{"powering_off":true},"ok":true}
+ poweroff 202
+18:24:15
+18:24:45 VM 9302: status: stopped
+Tester4-31fa0e|2026-10-18 18:24:18|2026-10-18T18:24:15Z
@@ -0,0 +1,12 @@
+read 1: 9302 name=newbox-r1148
+read 2: 9302 name=newbox-r1148
+scsi0: nvme-scratch:9302/vm-9302-disk-0.raw,size=120G
+purging VM 9302 from related configurations..
+Configuration file 'nodes/demo-hp/qemu-server/9302.conf' does not exist
+ls: cannot access '/mnt/hdd_1/images/9302': No such file or directory
+      VMID NAME                 STATUS     MEM(MB)    BOOTDISK(GB) PID       
+       341 night1004-tester1    running    8192             200.00 1851      
+VMID       Status     Lock         Name                
+9201       running                 demo-hp             
+9202       running                 demo-hp-scratch     
+9401       stopped                 upgrade-harness     
@@ -0,0 +1,33 @@
+# R-1148 — a fresh install from nothing with installer 1.34.0 (2026-10-18 evening)
+
+Throwaway customer **Tester4** (created by the operator; domain `tester4.test`, a reserved name that never resolves; no
+off-site, no PBS-DR — nothing on ep0). VM 9302 `newbox-r1148` on demo-hp (Tier 1; 8 GB / 4 cores / 120 GB raw on
+`nvme-scratch` = `/mnt/hdd_1` root) from the public ISO 1.29.0 (checksum = the published one). The ISO fetches
+`felhom-host-install.sh` at run time from `https://felhom.eu/scripts/` — served 1.34.0 (`SCRIPT_VERSION` read live). The
+graphical installer was driven with `qm sendkey`, the Hungarian keyboard kept, as a household would. The household's
+path: the mailed bind link + the pairing code on the console + the owner phrase (the operator put it in a 0600 file;
+shredded after), then the mailed setup code.
+
+| file | what it shows |
+|---|---|
+| `02-timeline.txt` | every step with its time (UTC below the line) |
+| `03-bind.txt` | the bind page's answer: „Sikeres összekötés" |
+| `04-pve-login-check.txt` | CC's own PVE API login from DooPlex, status codes only: the **vaulted** value 200; the value typed at install 401 |
+| `05-claim-and-version.txt` | the claim (302 /) and the box's own `/api/selfupdate/status`: 0.329.0 → 0.330.0, `initiated_by: auto-floor` |
+| `07-first-app.txt` | BentoPDF installed through the dashboard's API: deploy 202, running, healthy |
+| `08-bootstrap-journal.txt` | the box's `felhom-bootstrap` journal (scanned for secret shapes: 0) |
+| `09-hub-reports.txt` | the hub's host reports (agent 0.159.2) and the controller's own reports (0.329.0, then 0.330.0) |
+| `10-poweroff.txt` | the household's „turn off" (202), the hub's `deliberate_off_at` |
+| `99-teardown.txt` | the name read back twice, VM 9302 destroyed with its disk; the other VMs listed |
+| `screens/` | installer and console |
+
+**Step 4b (R-1145) in the full sequence:** `recovery password vaulted at the hub (stored) — now setting it on root@pam`
+→ chpasswd → `[OK] root@pam password vaulted, set, and the PVE login takes it`, all at 18:03:43 UTC; the hub's
+`host_recovery.set_at` is the same second. **The golden and the agent:** the hub manifest named agent v0.159.2 (sha
+`4d98868e…`) and golden v0.329.0 — the two vouched artifacts; both verified by sha256. The box came up on 0.329.0 and
+moved to the floor 0.330.0 by itself 2 min 47 s after the bind.
+
+Not walked: an SSH key login — CC logged in with the vaulted password (`sshpass -f`, file 0600, shredded after).
+
+**Left for the operator (session only):** delete customer Tester4 on the hub — allowed from 19:09 UTC (the last report
+18:24:18 + the 45-minute stale threshold); a 409 before that is by design (R-599).
@@ -0,0 +1,8 @@
+18:41:08
+25293 bytes, mtime 2026-10-18 18:40:29.429360235 +0000, owner 1000
+text: R1018 BEFORE EDITED-FB-1849
+2026/10/18 20:39:38 POST    | 200 | 172.18.0.7      | admin        | 0ms          | "/api/office/callback?auth=[redacted]&path=%2Fr1018%2Fteszt.docx&source=SCRATCH+HDD"
+2026/10/18 20:39:53 POST    | 200 | 172.18.0.7      | admin        | 0ms          | "/api/office/callback?auth=[redacted]&path=%2Fr1018%2Fteszt.docx&source=SCRATCH+HDD"
+2026/10/18 20:39:53 [INFO ] OnlyOffice Server is downloading file: /r1018/teszt.docx (documentId: 795feeebca16ab3ab1aae0dd352e9932fffa9efe0a9a927d6c3100ce98f20e6d)
+2026/10/18 20:40:29 [INFO ] OnlyOffice callback: successfully saved document to path=/r1018/teszt.docx
+2026/10/18 20:40:29 POST    | 200 | 172.18.0.7      | admin        | 5ms          | "/api/office/callback?auth=[redacted]&path=%2Fr1018%2Fteszt.docx&source=SCRATCH+HDD"
@@ -0,0 +1,4 @@
+text: R1018 NC BEFORE
+18:45:21
+text:  EDITED-NC-1847R1018 NC BEFORE EDITED-NC-1844
+18:47:25
@@ -0,0 +1,14 @@
+18:48:16 files /login 502
+18:48:31 files /login 502
+18:48:46 files /login 502
+18:49:01 files /login 502
+18:49:16 files /login 502
+18:49:31 files /login 502
+18:49:46 files /login 502
+18:50:01 files /login 502
+18:50:16 files /login 502
+18:50:31 files /login 502
+18:50:46 files /login 502
+18:51:01 files /login 502
+18:51:16 files /login 502
+18:51:31 files /login 200
@@ -0,0 +1,7 @@
+18:51:56 goto https://files.enkisfelhom.hu/files/SCRATCH%20HDD/r1018/teszt.docx -> https://files.enkisfelhom.hu/files/SCRATCH%20HDD/r1018/teszt.docx
+18:52:11 shot 11-fb-after-stop
+18:52:11 eval -> []
+18:52:11 goto https://cloud.enkisfelhom.hu/apps/onlyoffice/78 -> https://cloud.enkisfelhom.hu/apps/onlyoffice/78
+18:52:27 shot 12-nc-after-stop
+18:52:27 eval -> ["Nextcloud", [], "Nextcloud\nPage not found\n\nThe page could not be found on the server or you may not be allowed to view it.\n\nBack to Nextcloud\n\nNextcloud – a safe home for all your data"]
+LOG ('http', 404, 'https://cloud.enkisfelhom.hu/apps/onlyoffice/78')
@@ -0,0 +1,6 @@
+## rc.1 walk 19:12:09
+FileBrowser file text: R1018 BEFORE EDITED-FB-1849
+Nextcloud file text:  EDITED-NC-1847R1018 NC BEFORE EDITED-N RC1-NC-OKC-1844
+## rc.1 FileBrowser walk, second try 19:14:39
+mtime 2026-10-18 19:13:58.691684571 +0000
+FileBrowser file text: R1018 BEFORE EDITED-FB-1849 RC1-FB-OK
@@ -0,0 +1,10 @@
+stop pressed 19:14:54
+{"ok": true, "message": "Stack onlyoffice stop completed"}
+      1 19:15:06 files 200
+      1 19:15:08 files 502
+     43 19:15:10 files 200
+2026/10/18 19:15:06 manager.go:1463: [INFO] [stacks] Restarting stack: filebrowser
+2026/10/18 19:15:07 manager.go:1493: [INFO] [stacks] Stack filebrowser restarted successfully (took 1.1s)
+2026/10/18 19:15:07 lifecycle.go:61: [INFO] [integrations] Integration onlyoffice:filebrowser suspended (stack onlyoffice stopped)
+2026/10/18 19:15:07 lifecycle.go:61: [INFO] [integrations] Integration onlyoffice:nextcloud suspended (stack onlyoffice stopped)
+2026/10/18 19:15:09 filebrowser_gate.go:94: [INFO] [infra] filebrowser: default login refused for this run — joined traefik-public, files.<domain> served (R-1126)
@@ -0,0 +1,31 @@
+# R-1018 — the OnlyOffice links, live (2026-10-18 evening)
+
+Scratch 9202 (demo-hp, Tier 0), controller 0.330.0 then 0.331.0-rc.1. OnlyOffice 9.4.0 and Nextcloud 34.0.4 installed
+through the dashboard API (`POST /api/stacks/<n>/deploy`), each link switched on through `POST /api/integrations/
+onlyoffice/<target>` — the calls the app page makes. The browser: Playwright's headless Chrome shell on DooPlex, the box's
+public names (`files.`, `office.`, `cloud.` `enkisfelhom.hu`) mapped to 9202's LAN address (`--host-resolver-rules`), as
+in `audits/filebrowser-memory-ci-2026-10-17/tools/cdp_shot.py`; the driver is in the session scratchpad (`cdp.py`). The
+FileBrowser and Nextcloud passwords came from the dashboard's own reveal buttons into 0600 files, typed by CDP, never
+printed. Test documents: `r1018/teszt.docx` on the scratch drive, `r1018-nc.docx` in Nextcloud (WebDAV).
+
+| Step | 0.330.0 | 0.331.0-rc.1 |
+|---|---|---|
+| link on → files.<domain> | **502 for 4 min 8 s** (FileBrowser re-created off traefik-public, R-1126, until the next 5-min round) | 200 throughout |
+| FileBrowser → open .docx | editor frame loads, document never does: OnlyOffice fetched `https://files.<domain>/api/resources/download…` → **403** (the public name leads to another box, 9201) — `screens/04` | opens (`screens/15`) |
+| FileBrowser → edit, close, read the file on the drive | — (by-hand `server.internalUrl` on 0.330.0: „R1018 BEFORE EDITED-FB-1849", `01-filebrowser-save-readback.txt`) | „… RC1-FB-OK", mtime 19:13:58 (`05-rc1-walk.txt`) |
+| Nextcloud → open .docx | opens, edits, „All changes saved" (`screens/09`) — **but the file keeps the old text**: Nextcloud fetched `http://onlyoffice:80cache/files/…`, „Track: 78 status 2 error" (`02-nextcloud-save-readback.txt`) | the link re-applied the value with its slash at OnlyOffice's start; the file holds „RC1-NC-OK" |
+| OnlyOffice stopped | FileBrowser: no editor frame; Nextcloud `/apps/onlyoffice/78` **404** — the revoke-on-stop rule (`lifecycle.go:10-13`) holds (`04-after-stop-browser.txt`, `screens/11`, `12`); files.<domain> **502 for 3 min 38 s** (`03-files-outage-after-stop.txt`) | one 502 sample (≈ 2 s), FileBrowser re-published 3 s after its restart (`06-rc1-files-after-stop.txt`) |
+
+Red-proofs of the three fixes: `redproof-fix1.txt` (FileBrowser `server.internalUrl`), `redproof-fix2.txt` (Nextcloud
+`DocumentServerInternalUrl` slash), `redproof-fix3.txt` (the gate after `RestartStack("filebrowser")`).
+
+Also seen, not fixed (outside the links): FileBrowser's `/api/resources/preview` answers 500 for the .docx (an office
+preview goes through OnlyOffice's converter); Nextcloud's previews log `Request to http://onlyoffice:80converter` on
+0.330.0 — the same missing slash, fixed with it.
+
+One first rc.1 FileBrowser attempt showed OnlyOffice's „Connection is lost" after the driver clicked two fixed spots
+where pop-ups had been the time before (none were there); the next attempt, with no blind clicks, saved. No restart of
+either container happened in between (both „Up 5–6 minutes").
+
+Teardown: OnlyOffice removed through the product (`remove_hdd_data`, `remove_backups`: both volumes removed). Nextcloud
+stays on 9202 for Part 6 of the same brief; the test documents are removed with it.
@@ -0,0 +1,9 @@
+## red-proof 1: the internalUrl line removed
+=== RUN   TestFileBrowserConfig_R1018_InternalURLIsTheContainer
+    infra_test.go:269: server.internalUrl = "" — OnlyOffice would be handed the public files address
+--- FAIL: TestFileBrowserConfig_R1018_InternalURLIsTheContainer (0.00s)
+FAIL
+FAIL	gitea.dooplex.hu/admin/felhom-controller/internal/infra	0.008s
+## restored
+--- PASS: TestFileBrowserConfig_R1018_InternalURLIsTheContainer (0.00s)
+ok  	gitea.dooplex.hu/admin/felhom-controller/internal/infra	0.007s
@@ -0,0 +1,10 @@
+## red-proof 2: the slash removed from ncDocServerInternalURL
+=== RUN   TestNextcloudApply_R1018_InternalAddressesTakeAPath
+    onlyoffice_nextcloud_test.go:34: DocumentServerInternalUrl "http://onlyoffice:80" + "cache/files/data/2153553391_5872/output.docx/output.docx" is not a URL: parse "http://onlyoffice:80cache/files/data/2153553391_5872/output.docx/output.docx": invalid port ":80cache" after host
+    onlyoffice_nextcloud_test.go:34: DocumentServerInternalUrl "http://onlyoffice:80" + "converter?shardkey=thumb_1" is not a URL: parse "http://onlyoffice:80converter?shardkey=thumb_1": invalid port ":80converter" after host
+--- FAIL: TestNextcloudApply_R1018_InternalAddressesTakeAPath (0.00s)
+FAIL
+FAIL	gitea.dooplex.hu/admin/felhom-controller/internal/integrations	0.007s
+## restored
+--- PASS: TestNextcloudApply_R1018_InternalAddressesTakeAPath (0.00s)
+ok  	gitea.dooplex.hu/admin/felhom-controller/internal/integrations	(cached)
@@ -0,0 +1,9 @@
+## red-proof 3: the gate call removed from RestartStack
+=== RUN   TestRestartStack_R1018_FileBrowserPublishedAgainAtOnce
+    filebrowser_restart_gate_test.go:129: FileBrowser was not published again after its restart — files.<domain> stays 502 until a base-stack round
+--- FAIL: TestRestartStack_R1018_FileBrowserPublishedAgainAtOnce (10.31s)
+FAIL
+FAIL	gitea.dooplex.hu/admin/felhom-controller/internal/stacks	10.318s
+## restored
+--- PASS: TestRestartStack_R1018_FileBrowserPublishedAgainAtOnce (0.31s)
+ok  	gitea.dooplex.hu/admin/felhom-controller/internal/stacks	0.320s
@@ -0,0 +1,47 @@
+## 19:43:05 — FileBrowser 1.5.6 with auth.methods.proxy {enabled, header X-Felhom-User} on scratch 9202
+### control route filesopen (no middleware)
+no header:            401
+forged header:        200  body: {"name":"scratch_hdd","size":132976640,"modified":"2026-10-18T20:34:20.752138936+02:00","type":"directory","hidden":fals
+### strip route filesspike (forwardAuth -> controller /api/health, authResponseHeaders [X-Felhom-User])
+no header:            404  body: 
+<!DOCTYPE html>
+<html lang="hu">
+<head>
+<meta charset="utf-8">
+<meta name="viewport" content="width=device-width, initi
+forged header:        404  body: 
+<!DOCTYPE html>
+<html lang="hu">
+<head>
+<meta charset="utf-8">
+<meta name="viewport" content="width=device-width, initi
+forged, other case:   404
+forged, twice:        404
+
+## 19:44:02 — auth stand-in: /always = 200 and NO user header; /cookie = 200 + X-Felhom-User: household-sso only with cookie spike=ok
+### filesspike (forwardAuth /always, authResponseHeaders [X-Felhom-User])
+header [none]: 401 {"status":401,"message":"no token present in request"}
+header [X-Felhom-User: spike-stranger2]: 401 {"status":401,"message":"no token present in request"}
+header [x-felhom-user: spike-stranger3]: 401 {"status":401,"message":"no token present in request"}
+two forged headers: 401 {"status":401,"message":"no token present in request"}
+### filessso (forwardAuth /cookie)
+forged header, no cookie: 401 
+cookie ok, no header: 404 404 page not found 
+cookie ok + forged header attacker: 404 404 page not found 
+### filessso again, on the drive listing (19:44:14)
+cookie ok, no header: 200 {"name":"scratch_hdd","size":132976640,"modified":"2026-10-18T20:34:20.752138936+02:00","t
+cookie ok + forged header attacker: 200 {"name":"scratch_hdd","size":132976640,"modified":"2026-10-18T20:34:20.752138936+02:00","t
+cookie wrong + forged header attacker: 401 
+### FileBrowser's own request log (user column) since 19:43
+2026/10/18 21:43:05[33m GET     | 401 | 172.18.0.3      | N/A          | 0ms          | "/api/resources?path=%2F&source=SCRATCH%20HDD"[0m
+2026/10/18 21:43:05 GET     | 200 | 172.18.0.3      | spike-stra.. | 80ms         | "/api/resources?path=%2F&source=SCRATCH%20HDD"
+2026/10/18 21:44:02[33m GET     | 401 | 172.18.0.3      | N/A          | 0ms          | "/api/resources?path=%2F&source=SCRATCH%20HDD"[0m
+2026/10/18 21:44:02[33m GET     | 401 | 172.18.0.3      | N/A          | 0ms          | "/api/resources?path=%2F&source=SCRATCH%20HDD"[0m
+2026/10/18 21:44:02[33m GET     | 401 | 172.18.0.3      | N/A          | 0ms          | "/api/resources?path=%2F&source=SCRATCH%20HDD"[0m
+2026/10/18 21:44:02[33m GET     | 401 | 172.18.0.3      | N/A          | 0ms          | "/api/resources?path=%2F&source=SCRATCH%20HDD"[0m
+2026/10/18 21:44:14 GET     | 200 | 172.18.0.3      | household-.. | 79ms         | "/api/resources?path=%2F&source=SCRATCH%20HDD"
+2026/10/18 21:44:14 GET     | 200 | 172.18.0.3      | household-.. | 2ms          | "/api/resources?path=%2F&source=SCRATCH%20HDD"
+### an app container on traefik-public talks to FileBrowser directly, no router (19:44:27)
+from nextcloud, no header: 401
+from nextcloud, forged X-Felhom-User: app-forged: 200
+nextcloud networks: nextcloud_nextcloud-internal traefik-public 
@@ -0,0 +1,6 @@
+login 200 token_len 355
+users 200 [(1, 'admin', 'password'), (2, 'spike-stranger', 'proxy'), (3, 'household-sso', 'proxy'), (4, 'app-forged', 'proxy')]
+delete spike-stranger 200 
+delete household-sso 200 
+delete app-forged 200 
+users after 200 [(1, 'admin')]
@@ -0,0 +1,11 @@
+0
+2026/10/18 21:46:05 [INFO ] Auth Methods             : [password]
+0
+controller.yml
+filebrowser.yml
+forwarded.yml
+serverstransports.yml
+felhom-filebrowser traefik-public 
+filesspike: 404
+filesopen: 404
+files: 401
@@ -0,0 +1,59 @@
+# R-1100 — one sign-in for the dashboard and FileBrowser: the spike (2026-10-18 evening)
+
+Measured on scratch 9202 (demo-hp, Tier 0): FileBrowser Quantum `gtstef/filebrowser:1.5.6-stable` (source read at tag
+`v1.5.6-stable`, commit `5d9b4df2`), Traefik v3.7.13, controller 0.331.0-rc.1. Nothing was built; every change on 9202 was
+removed (`03-teardown.txt`). Evidence: `01-strip.txt` (every request and answer), `02-teardown-users.txt`.
+
+## What FileBrowser's proxy auth is (source, at the pinned tag)
+
+- The config key is **`auth.methods.proxy`** (`backend/common/settings/auth.go:58`, json `proxy` — not `proxyAuth`, as the
+  row said), with `enabled` and `header` (`auth.go:75-78`: „FileBrowser blindly accepts the header value as username").
+- Any request that carries the header is that user (`backend/http/middleware.go:302-307` on login, `:384-401` on every API
+  call, `:494-520` `getProxyUser`). **A name FileBrowser has never seen is created on the spot**
+  (`backend/http/auth.go:81-106`), with the user defaults. A name that exists as a password user is refused
+  (`auth.go:107-108`, `ErrWrongLoginMethod`) — so the household's `admin` cannot be reached by a header; a header user
+  is a separate FileBrowser user.
+
+## What was measured
+
+| Request | Answer |
+|---|---|
+| a route with no middleware, forged `X-Felhom-User: spike-stranger` | **200 — the drive's listing**; FileBrowser created the user |
+| Traefik `forwardAuth` that answers 200 and sets NO user header, `authResponseHeaders: [X-Felhom-User]`; forged header (also lower-case, also twice) | **401** from FileBrowser („no token present") — Traefik removed the client's header |
+| `forwardAuth` that sets `X-Felhom-User: household-sso` only for a valid cookie; cookie ok + forged `attacker` | 200 as **`household-sso`** (FileBrowser's own request log names the user) — the auth answer replaced the forged value |
+| the same, wrong cookie + forged header | 401 from the auth step; FileBrowser never reached |
+| **from inside the Nextcloud container**, straight to `http://filebrowser:80`, forged header | **200** — no Traefik on that path |
+
+So: **Traefik can pass the header only for a valid session and strips one a client sends — proven.** But the header is
+also trusted from any container that reaches FileBrowser's port, and every app sits on `traefik-public` with it.
+
+## The three things a build must solve
+
+1. **The session cannot be read on `files.<domain>`.** The dashboard cookie `felhom_session` has no `Domain`
+   (`controller/internal/web/auth.go:197-205`), so a browser never sends it to `files.<domain>`, and a forward-auth there
+   sees nothing. **Do not widen it to `Domain=<domain>`**: every app's subdomain — third-party code — would then receive the
+   dashboard session. Instead a files-only ticket: „Fájlok ↗" goes through the dashboard, which mints a one-time,
+   ~60-second token; `files.<domain>/_felhom/sso?t=…` (a Traefik route to the controller) swaps it for a host-only,
+   HttpOnly, Secure cookie for `files.<domain>`; the forward-auth checks that cookie and answers the header.
+2. **Any app container can forge the header** (measured). Two cheap closes, either enough, both better:
+   (a) **the header name is a per-box secret** (`X-Felhom-User-<32 hex>`), written only into FileBrowser's config and
+   Traefik's dynamic file — an app that does not know the name cannot send it; (b) FileBrowser **off `traefik-public`**:
+   Traefik joins `felhom-filebrowser` instead (and OnlyOffice too, for its `server.internalUrl`, R-1018). (b) changes the
+   R-1126 gate's shape; (a) does not.
+3. **Header users are new FileBrowser users.** The household's files permissions for that user must be set by the box (the
+   user defaults decide today); shares the household made as `admin` stay `admin`'s; logout needs
+   `logoutRedirectUrl` to the dashboard.
+
+## Unchanged by it
+
+- **The password reveal (R-513)** stays: `admin` remains a password user — the fallback when the ticket path fails, and
+  the operator's. The „Fájlok ↗" button would no longer need it.
+- **The R-1126 gate** keeps checking `admin`'s default login; header users do not touch it.
+
+## Cost and recommendation
+
+Controller only (no agent, no hub): a ticket endpoint and a forward-auth endpoint, one Traefik route + middleware, the
+FileBrowser config block with a secret header name, the header user's permissions, tests for each refusal (forged header
+via Traefik; forged header from an app container — with a secret name; stale/replayed ticket; wrong host). About one
+release. **Recommendation: build it with (1) the ticket cookie and (2a) the secret header name**; do not ship header
+trust without 2a — the measured app-container path would hand every app the household's files.
@@ -0,0 +1,41 @@
+run at 19:49:37
+{"ok": true, "message": "Mentés elindítva"}
+2026/10/18 19:49:38 dbdump.go:171: [DEBUG] DiscoverDatabases: skipping container immich-server (image=ghcr.io/immich-app/immich-server:v3.2.4, not a database)
+2026/10/18 19:49:38 dbdump.go:178: [DEBUG] DiscoverDatabases: found postgres container: immich-postgres (id=5865007e1ebd)
+2026/10/18 19:49:38 dbdump.go:198: [DEBUG] DiscoverDatabases: immich-postgres → stack=immich, dbUser=immich, dbName=immich
+2026/10/18 19:49:38 dbdump.go:171: [DEBUG] DiscoverDatabases: skipping container immich-machine-learning (image=ghcr.io/immich-app/immich-machine-learning:v3.2.4, not a database)
+2026/10/18 19:49:38 dbdump.go:171: [DEBUG] DiscoverDatabases: skipping container immich-redis (image=redis:7-alpine, not a database)
+2026/10/18 19:49:39 dbdump.go:277: [DEBUG] DumpOne: starting dump for container=immich-postgres, stack=immich, dbType=postgres, dest=/mnt/sizing-bench/backups/primary/immich/db-dumps/immich-postgres.s
+2026/10/18 19:49:39 dbdump.go:314: [DEBUG] DumpOne: pg_dump command: docker exec 5865007e1ebd pg_dump -U immich -d immich --clean --if-exists --no-owner --no-privileges
+2026/10/18 19:49:40 dbdump.go:424: [DEBUG] DumpOne: completed immich-postgres → immich-postgres.sql (size=51.2 MB, valid=true, tables=71, duration=1.179s)
+2026/10/18 19:49:40 dbdump.go:429: [INFO] [backup] DB dump: immich-postgres → immich-postgres.sql (51.2 MB, 1.179s, 71 tables)
+2026/10/18 19:49:40 data_versions.go:131: [DEBUG] [backup] immich: stamped db-dumps/immich-postgres.sql (53711499 B) with pins [ghcr.io/immich-app/immich-server:v3.2.4@sha256:d317916b28090c33eb36b3084
+2026/10/18 19:49:40 backup.go:1003: [INFO] [backup] Stopping immich for safe volume dump
+2026/10/18 19:49:41 backup.go:877: [DEBUG] [backup] Dumping volume immich_immich_ml_cache for immich
+unit=
+/mnt/sizing-bench/backups/primary/immich/:
+total 36
+drwxr-xr-x 5 root root 4096 19:50:44 .
+drwxr-xr-x 3 root root 4096 14:09:21 ..
+drwxr-xr-x 2 root root 4096 19:50:44 compose
+-rw-r--r-- 1 root root 4889 19:49:49 data-stamps.json
+drwxr-xr-x 2 root root 4096 19:49:40 db-dumps
+-rw-r--r-- 1 root root 7983 19:50:44 manifest.json
+drwxr-xr-x 2 root root 4096 19:49:49 volume-dumps
+
+/mnt/sizing-bench/backups/primary/immich/volume-dumps/:
+total 1111744
+drwxr-xr-x 2 root root      4096 19:49:49 .
+drwxr-xr-x 5 root root      4096 19:50:44 ..
+-rw-r--r-- 1 root root 823764480 19:49:42 immich_immich_ml_cache.tar
+-rw-r--r-- 1 root root 283049472 19:49:47 immich_immich_postgres_data.tar
+-rw-r--r-- 1 root root  31591424 19:49:49 immich_immich_redis_data.tar
+2026/10/18 19:49:41 backup.go:877: [DEBUG] [backup] Dumping volume immich_immich_ml_cache for immich
+2026/10/18 19:49:46 backup.go:877: [DEBUG] [backup] Dumping volume immich_immich_postgres_data for immich
+2026/10/18 19:49:49 backup.go:877: [DEBUG] [backup] Dumping volume immich_immich_redis_data for immich
+2026/10/18 19:49:49 backup.go:1019: [INFO] [backup] Restarting immich after volume dump
+2026/10/18 19:49:59 manager.go:920: [DEBUG] [stacks] restart-policy of down member "immich-server" = "unless-stopped"
+2026/10/18 19:50:44 recovery_unit.go:289: [INFO] [backup] Recovery unit captured for immich → /mnt/sizing-bench/backups/primary/immich (images=4, secrets-referenced=1, data_keys=
+immich_immich_ml_cache
+immich_immich_postgres_data
+immich_immich_redis_data
@@ -0,0 +1,13 @@
+edited /opt/docker/stacks/immich/docker-compose.yml
+132c132
+<     command: redis-server --appendonly no
+---
+>     command: redis-server --save "" --appendonly no
+135,136c135,136
+<     volumes:
+<       - immich_redis_data:/data
+---
+>     tmpfs:
+>       - /data
+152d151
+<   immich_redis_data:
@@ -0,0 +1,44 @@
+restart at 19:52:31
+{"ok": true, "data": {"state": "starting"}, "message": "Stack immich restart requested — state now: starting"}
+immich-server Up About a minute (healthy)
+immich-postgres Up About a minute (healthy)
+immich-machine-learning Up About a minute (healthy)
+immich-redis Up About a minute (healthy)
+mounts: volume:immich_immich_redis_data/data  tmpfs: map[/data:]
+save  
+39
+backgroundTask backupDatabase duplicateDetection editor faceDetection facialRecognition integrityCheck library metadataExtraction migration notifications ocr 
+{"res":"pong"}
+[32m[Nest] 29  - [39m10/18/2026, 9:52:51 PM [32m    LOG[39m [33m[Api:RoutesResolver][39m [32mJobController {/api/jobs}:[39m
+[32m[Nest] 29  - [39m10/18/2026, 9:52:51 PM [32m    LOG[39m [33m[Api:RouterExplorer][39m [32mMapped {/api/jobs, GET} route[39m
+[32m[Nest] 29  - [39m10/18/2026, 9:52:51 PM [32m    LOG[39m [33m[Api:RouterExplorer][39m [32mMapped {/api/jobs, POST} route[39m
+[32m[Nest] 29  - [39m10/18/2026, 9:52:51 PM [32m    LOG[39m [33m[Api:RouterExplorer][39m [32mMapped {/api/jobs/:name, PUT} route[39m
+[32m[Nest] 29  - [39m10/18/2026, 9:52:51 PM [32m    LOG[39m [33m[Api:RouterExplorer][39m [32mMapped {/api/queues/:name/jobs, GET} route[39m
+[32m[Nest] 29  - [39m10/18/2026, 9:52:51 PM [32m    LOG[39m [33m[Api:RouterExplorer][39m [32mMapped {/api/queues/:name/jobs, DELETE} route[39m
+old volume: immich_immich_redis_data labels=map[com.docker.compose.config-hash:730e1778edc1a7fb43e276ccfc1c6e7d304775266ab19bae03c9ebec05eaf65b com.docker.compose.project:immich com.docker.compose.version:5.5.1 com.docker.compose.volume:immich_redis_data]
+used by: immich-redis
+tmpfs /data tmpfs rw,nosuid,nodev,noexec,relatime,mode=755,uid=100000,gid=100000,inode64 0 0
+total 4
+drwxr-xr-x    2 redis    root            40 Oct 18 21:52 .
+drwxr-xr-x    1 root     root          4096 Oct 18 21:52 ..
+[{"Type":"volume","Name":"immich_immich_redis_data","Source":"/var/lib/docker/volumes/immich_immich_redis_data/_data","Destination":"/data","Driver":"local","Mode":"z","RW":true,"Propagation":""}]
+{"com.docker.compose.config-hash":"888272c2acd984cb6996f81bd49b41bdd8d6b2318870cd1a2088ec554dbf0fed"
+"com.docker.compose.depends_on":""
+"com.docker.compose.replace":"immich-redis"
+19:54:10 backgroundTask id= completed=0 failed=0
+19:54:10 library id= completed=0 failed=0
+19:54:10 migration id= completed=0 failed=0
+19:54:10 notifications id= completed=0 failed=0
+19:54:10 metadataExtraction id= completed=0 failed=0
+19:54:10 thumbnailGeneration id= completed=0 failed=0
+19:55:27 backgroundTask id= completed=0 failed=0
+19:55:27 library id= completed=0 failed=0
+19:55:27 migration id= completed=0 failed=0
+19:55:27 notifications id= completed=0 failed=0
+19:55:27 metadataExtraction id= completed=0 failed=0
+19:55:27 thumbnailGeneration id= completed=0 failed=0
+token_len 39
+photos 10 videos 0
+start metadataExtraction (force): 200
+metadataExtraction {'active': 0, 'completed': 0, 'failed': 0, 'delayed': 0, 'waiting': 0, 'paused': 0} {'isPaused': False, 'isActive': False}
+redis: metadataExtraction id=11
@@ -0,0 +1,16 @@
+restore pressed 19:56:29
+302 
+2026/10/18 19:56:29 handlers.go:1831: [DEBUG] [web] backupRestoreHandler: stack=immich snapshot=latest from 172.18.0.3:48626
+2026/10/18 19:56:29 handlers.go:1868: [WARN] [web] restore refused for immich: unit carries no file leg (1 drive path(s))
+---
+immich-server Up 9 minutes (healthy)
+immich-postgres Up 9 minutes (healthy)
+immich-machine-learning Up 9 minutes (healthy)
+immich-redis Up 9 minutes (healthy)
+{"res":"pong"}
+redis mounts: volume:immich_immich_redis_data/data 
+tmpfs /data tmpfs
+immich_immich_redis_data created=2026-10-14T14:06:06Z labels=map[com.docker.compose.config-hash:730e1778edc1a7fb43e276ccfc1c6e7d304775266ab19bae03c9ebec05eaf65b com.docker.compose.project:immich com.docker.compose.version:5.5.1 com.docker.compose.volume:immich_redis_data]
+
+## second-drive unit restore pressed 20:03:36 (unit of 2026-10-18 00:30 UTC, made WITH immich_immich_redis_data.tar)
+302 
@@ -0,0 +1,31 @@
+## Nextcloud: tier-2 copy WITH the Redis volume, started 20:05:16
+{"ok": true, "message": "2. mentés elindítva"}
+20:05:17
+2026/10/18 20:05:17 auth.go:144: [DEBUG] [web] auth: valid session for POST /api/backup/tier2
+2026/10/18 20:05:17 router.go:78: [DEBUG] [api] POST /api/backup/tier2 (path=/backup/tier2)
+2026/10/18 20:05:17 router.go:1323: [INFO] [api] Manual Tier 2 (off-drive) backup triggered
+2026/10/18 20:05:27 tier2.go:470: [INFO] [backup] Tier 2 copied immich → /mnt/felhom-drives/scratch_hdd/backups/secondary/immich (1.2 GB, 2 leg(s), 11s)
+2026/10/18 20:05:30 tier2.go:470: [INFO] [backup] Tier 2 copied nextcloud → /mnt/sizing-bench/backups/secondary/nextcloud (1011.9 MB, 1 leg(s), 3s)
+2026/10/18 20:05:30 tier2.go:470: [INFO] [backup] Tier 2 copied paperless-ngx → /mnt/sizing-bench/backups/secondary/paperless-ngx (125.8 MB, 1 leg(s), 0s)
+2026/10/18 20:05:31 tier2.go:470: [INFO] [backup] Tier 2 copied privatebin → /mnt/felhom-drives/scratch_hdd/backups/secondary/privatebin (8.3 KB, 0 leg(s), 0s)
+2026/10/18 20:05:31 tier2.go:526: [INFO] [backup] Tier 2 run complete: 4 app(s) processed (incl. volume-only — F6)
+/mnt/felhom-drives/scratch_hdd/backups/secondary/immich
+/mnt/felhom-drives/scratch_hdd/backups/secondary/privatebin
+/mnt/sizing-bench/backups/secondary/nextcloud
+/mnt/sizing-bench/backups/secondary/paperless-ngx
+/mnt/sys_drive/felhom-data/backups/secondary/paperless-ngx
+/mnt/felhom-drives/scratch_hdd/backups/primary/nextcloud/volume-dumps/:
+total 964000
+drwxr-xr-x 2 root root      4096 19:50:15 .
+drwxr-xr-x 5 root root      4096 19:50:44 ..
+-rw-r--r-- 1 root root 170889216 19:50:05 nextcloud_nextcloud_db_data.tar
+-rw-r--r-- 1 root root 816219136 19:50:11 nextcloud_nextcloud_html.tar
+-rw-r--r-- 1 root root     11776 19:50:04 nextcloud_nextcloud_redis_data.tar
+
+/mnt/sizing-bench/backups/secondary/nextcloud/recovery-unit/volume-dumps/:
+total 964004
+drwxr-xr-x 2 root root      4096 19:50:15 .
+drwxr-xr-x 5 root root      4096 19:50:44 ..
+-rw-r--r-- 1 root root 170889216 19:50:05 nextcloud_nextcloud_db_data.tar
+-rw-r--r-- 1 root root 816219136 19:50:11 nextcloud_nextcloud_html.tar
+-rw-r--r-- 1 root root     11776 19:50:04 nextcloud_nextcloud_redis_data.tar
@@ -0,0 +1,26 @@
+edited /opt/docker/stacks/nextcloud/docker-compose.yml
+110c110
+<     command: redis-server --appendonly no
+---
+>     command: redis-server --save "" --appendonly no
+113,114c113,114
+<     volumes:
+<       - nextcloud_redis_data:/data
+---
+>     tmpfs:
+>       - /data
+131d130
+<   nextcloud_redis_data:
+restart at 20:06:47
+{"ok": true, "data": {"state": "starting"}, "message": "Stack nextcloud restart requested — state 
+nextcloud Up 52 seconds (healthy)
+nextcloud-db Up 58 seconds (healthy)
+nextcloud-redis Up 57 seconds (healthy)
+tmpfs /data tmpfs
+save  
+{"installed":true,"version":"34.0.4.1","versionstring":"34.0.4","edition":"","maintenance":false,"needsDbUpgrade":false,"productname":"Nextcloud","extendedSupport":false}
+
+cron rc=0
+5
+nextcloud-redis
+webdav GET: 200
@@ -0,0 +1,49 @@
+## Nextcloud second-drive restore pressed 20:09:28 â€” the copy made WITH nextcloud_nextcloud_redis_data.tar; the live compose has NO Redis volume
+302 
+2026/10/18 20:09:28 tier2_whole.go:304: [WARN] [backup] WHOLE restore for nextcloud from the second drive /mnt/sizing-bench/backups/secondary/nextcloud: files by the four rules (never delete, never ov
+2026/10/18 20:09:30 tier2_whole.go:326: [INFO] [backup] whole restore nextcloud: files restored=1 replaced=0 (live kept beside as *.felhom-20261018T200930Z) kept-newer=2 unchanged=106
+2026/10/18 20:09:30 restore_dbcreds.go:114: [INFO] [backup] Restore nextcloud: database password(s) [DB_PASSWORD MYSQL_ROOT_PASSWORD] come from the backup, [] stay as installed (older than the data) â
+2026/10/18 20:09:30 restore_unit.go:393: [INFO] [backup] Restoring nextcloud from recovery unit /mnt/sizing-bench/backups/secondary/nextcloud/recovery-unit: images=3, secrets recovered=3/3, data_keys=
+2026/10/18 20:09:30 restore.go:215: [INFO] [backup] Restoring Docker volume nextcloud_nextcloud_db_data for nextcloud
+---
+Error response from daemon: No such container: nextcloud
+
+
+error: no such object: nextcloud-redis
+Error response from daemon: No such container: nextcloud-redis
+nextcloud_nextcloud_redis_data created=2026-10-18T18:31:13Z labels=map[com.docker.compose.config-hash:d0c5aae5dee81a25758afbc72c23a510ae97ef5e5c37c02afce24bb9b83e5515 com.docker.compose.project:nextcloud com.docker.compose.version:5.6.0 com.docker.compose.volume:nextcloud_redis_data]
+webdav GET after restore: 404
+## after the restore (20:10:37)
+2026/10/18 20:09:30 restore.go:215: [INFO] [backup] Restoring Docker volume nextcloud_nextcloud_db_data for nextcloud
+2026/10/18 20:09:32 restore.go:253: [DEBUG] [backup] Volume nextcloud_nextcloud_db_data restored successfully
+2026/10/18 20:09:32 restore.go:215: [INFO] [backup] Restoring Docker volume nextcloud_nextcloud_html for nextcloud
+2026/10/18 20:09:42 restore.go:253: [DEBUG] [backup] Volume nextcloud_nextcloud_html restored successfully
+2026/10/18 20:09:42 restore.go:215: [INFO] [backup] Restoring Docker volume nextcloud_nextcloud_redis_data for nextcloud
+2026/10/18 20:09:43 restore.go:253: [DEBUG] [backup] Volume nextcloud_nextcloud_redis_data restored successfully
+2026/10/18 20:09:43 restore.go:258: [INFO] [backup] Restored 3 Docker volume(s) for nextcloud
+2026/10/18 20:09:43 restore_db.go:87: [INFO] [backup] Restore nextcloud: replaying DB dump into nextcloud-db (mariadb)
+2026/10/18 20:09:57 restore_db.go:97: [INFO] [backup] Restore nextcloud: replayed 1 DB dump(s)
+2026/10/18 20:10:06 restore.go:298: [DEBUG] [backup] Post-restore health check: nextcloud not yet running, waiting...
+2026/10/18 20:10:11 restore.go:293: [DEBUG] [backup] Post-restore health check: nextcloud is running
+2026/10/18 20:10:11 restore_unit.go:494: [INFO] [backup] Restore-from-unit completed: nextcloud â€” 3 volume(s) of 3 listed, 1 database(s) of 1 listed
+2026/10/18 20:10:11 tier2_restore.go:255: [INFO] [backup] nextcloud: primary unit already carries data â€” left untouched (R-403 never overwrites a richer package with a poorer one)
+2026/10/18 20:10:11 handlers.go:2281: [INFO] [web] Tier-2 whole restore completed (async): stack=nextcloud in 42.745438966s (files restored 1, replaced 0, kept-newer 2, unchanged 106; volumes 3/3, dbs 1/1)
+---
+nextcloud Up 36 seconds (healthy)
+nextcloud-redis Up 41 seconds (healthy)
+nextcloud-db Up 55 seconds (healthy)
+{"installed":true,"version":"34.0.4.1","versionstring":"34.0.4","edition":"","maintenance":false,"needsDbUpgrade":false,"productname":"Nextcloud","extendedSupport":false}
+
+redis mounts: volume:nextcloud_nextcloud_redis_data/data 
+/dev/loop1 /data ext4
+drwxr-xr-x    2 redis    redis         4096 Oct 18 22:09 .
+drwxr-xr-x    1 root     root          4096 Oct 18 22:09 ..
+-rw-------    1 redis    redis         9368 Oct 18 21:50 dump.rdb
+nextcloud_nextcloud_redis_data created=2026-10-18T20:09:42Z labels=map[com.docker.compose.project:nextcloud com.docker.compose.version:5.6.0 com.docker.compose.volume:nextcloud_redis_data]
+total 20
+drwxr-xr-x    2 999      1000          4096 Oct 18 20:09 .
+drwxr-xr-x    1 root     root          4096 Oct 18 20:10 ..
+-rw-------    1 999      1000          9368 Oct 18 19:50 dump.rdb
+used by: nextcloud-redis
+2
+webdav GET after restore: 200
@@ -0,0 +1,13 @@
+## backup run with Immich on the NO-volume compose, 20:11:01
+1
+{"ok": true, "message": "Mentés elindítva"}
+20:12:06
+2026/10/18 20:11:04 backup.go:877: [DEBUG] [backup] Dumping volume immich_immich_ml_cache for immich
+2026/10/18 20:11:09 backup.go:877: [DEBUG] [backup] Dumping volume immich_immich_postgres_data for immich
+2026/10/18 20:11:20 recovery_unit.go:289: [INFO] [backup] Recovery unit captured for immich → /mnt/sizing-bench/backups/primary/immich (images=4, secrets-referenced=1, data_keys=0, portable-carried=
+total 1080892
+drwxr-xr-x 2 root root      4096 20:11:12 .
+drwxr-xr-x 5 root root      4096 20:11:20 ..
+-rw-r--r-- 1 root root 823764480 20:11:05 immich_immich_ml_cache.tar
+-rw-r--r-- 1 root root 283049472 20:11:10 immich_immich_postgres_data.tar
+manifest volume_dumps: ['immich_immich_ml_cache.tar', 'immich_immich_postgres_data.tar']
@@ -0,0 +1,13 @@
+## after the template push (catalog 30eea97) and the sync, 20:25:49
+/opt/docker/stacks/nextcloud/docker-compose.yml:110:    command: redis-server --save "" --appendonly no
+/opt/docker/stacks/nextcloud/docker-compose.yml:113:    tmpfs:
+/opt/docker/stacks/immich/docker-compose.yml:17:#   Redis data         → immich_redis_data       (named volume, NVMe)
+/opt/docker/stacks/immich/docker-compose.yml:132:    command: redis-server --save "" --appendonly no
+/opt/docker/stacks/immich/docker-compose.yml:135:    tmpfs:
+{"ok": true, "data": {"state": "starting"}, "message": "Stack nextcloud restart 
+nextcloud Up 52 seconds (healthy)
+nextcloud-redis Up 57 seconds (healthy)
+nextcloud-db Up 57 seconds (healthy)
+tmpfs /data tmpfs
+save  
+{"installed":true,"version":"34.0.4.1","versionstring":"34.0.4","edition":"","ma
@@ -0,0 +1,22 @@
+22:28:23   [X] remove (with drive data) -> 200 {'ok': True, 'data': {'removed': 'nextcloud', 'volumes_removed': ['nextcloud_nextcloud_db_data', 'nextcloud_nextcloud_html'], 'hdd_paths_removed': ['/mnt/felhom
+22:28:32   [X] after remove: deployed=False leftovers='/opt/docker/stacks/nextcloud'
+remove: 200
+0
+nextcloud_nextcloud_redis_data
+ls: cannot access '/mnt/felhom-drives/scratch_hdd/backups/primary/nextcloud': No such file or directory
+ls: cannot access '/mnt/sizing-bench/backups/secondary/nextcloud': No such file or directory
+/mnt/felhom-drives/scratch_hdd/userdata/nextcloud
+ls: cannot access '/mnt/felhom-drives/scratch_hdd/userdata/r1018': No such file or directory
+S10-box-fresh-768-noswap.txt
+S2-box-positive.txt
+controller.yaml.pre-lock-probe
+daemon.json.bak-2026-10-04
+pgsample.sh
+r626-events.txt
+repoint-night1005.sh
+shots
+sizing
+0
+nextcloud_nextcloud_redis_data map[com.docker.compose.project:nextcloud com.docker.compose.version:5.6.0 com.docker.compose.volume:nextcloud_redis_data]
+nextcloud_nextcloud_redis_data
+0
@@ -0,0 +1,9 @@
+## red-proof: the leftover loop removed from RemoveStack
+=== RUN   TestR1117_RemoveDeletesALabelledVolumeTheDefinitionNoLongerDeclares
+    r1117_leftover_volume_test.go:66: left behind: [app_app_redis_data] — a volume with the app's project label outlived its removal
+--- FAIL: TestR1117_RemoveDeletesALabelledVolumeTheDefinitionNoLongerDeclares (26.02s)
+FAIL
+FAIL	gitea.dooplex.hu/admin/felhom-controller/internal/stacks	26.027s
+## restored
+--- PASS: TestR1117_RemoveDeletesALabelledVolumeTheDefinitionNoLongerDeclares (26.02s)
+ok  	gitea.dooplex.hu/admin/felhom-controller/internal/stacks	26.027s
@@ -26,6 +26,17 @@

 ---

+## 2026-10-18 (evening) — a fresh install from scratch, OnlyOffice saves, Redis without a volume, CI mail link (controller v0.331.0, catalog `30eea97`)
+
+| Row | What | Closed | Evidence |
+|---|---|---|---|
+| **R-1148** | **Installer 1.34.0 is published (operator yes, 2026-10-18) but its default path has not run on a fresh install.** Step 4b now vaults FIRST, then sets the password, then checks a PVE login (R-1145); the SC2066 loop became an `if`. Proven: the harness (52/0, the R1145 cases run the real step with fake commands), `test_hostinstall.py` 40/0, a real `--rotate-recovery-only` on demo-hp (vault time moved, new value 200, old 401). Not proven: a whole fresh install on a machine, where step 4b runs inside the full sequence and `https://127.0.0.1:8006` must answer during it. (P3) | CLOSED 2026-10-18 — **proven on a fresh install:** VM 9302 on demo-hp from the public ISO 1.29.0, which fetched installer **1.34.0** at run time; throwaway customer Tester4 (the operator's). Step 4b in the full sequence: „vaulted at the hub (stored) — now setting it” → chpasswd → „[OK] … the PVE login takes it”, 18:03:43 UTC, the hub's `host_recovery.set_at` the same second; CC's own PVE login from DooPlex: vaulted value 200, the installer's value 401. The manifest named the vouched agent 0.159.2 and golden 0.329.0 (sha-verified); the box came up on 0.329.0 and moved to the floor 0.330.0 by itself (`initiated_by: auto-floor`) 2 min 47 s after the bind; claimed, BentoPDF installed and healthy; turned off by the household's button (deliberate). VM destroyed by name. **The operator keeps Tester4 as the standing fresh-install customer** (2026-10-18); before its next install the old host `Tester4-31fa0e` must be deleted on the Hosts page, or the enroll reuses it and skips the re-issues (memory „reinstall without deleting the host”). | `audits/newbox-2026-10-18/` |
+| **R-1018** | **The OnlyOffice links (FileBrowser, Nextcloud) have no recorded live proof since the move to Proxmox.** `controller/internal/integrations/` holds two handlers; no audit after the Proxmox move shows a document opened from FileBrowser or Nextcloud in OnlyOffice (searched 2026-10-14). The media-app links of `15` §6 will copy this code, including its revoke-on-stop rule (`lifecycle.go:10-13`). (P3) | CLOSED 2026-10-18 — **walked live and fixed, controller v0.331.0 (floor):** on 0.330.0 FileBrowser → OnlyOffice never loaded a document (OnlyOffice fetched the public `files.<domain>` URL: 403) and Nextcloud → OnlyOffice lost every save (`http://onlyoffice:80cache/…` — no slash); switching the link on or off left files.<domain> 502 for 3.5–4 min. Fixed: FileBrowser `server.internalUrl: http://filebrowser:80`, Nextcloud `DocumentServerInternalUrl` with its slash, the R-1126 gate after any FileBrowser restart. On rc.1 both paths open, edit, save and read back; the revoke-on-stop rule holds (no editor in FileBrowser, Nextcloud 404); the stop's outage ≈ 2 s. Each fix red-proofed. | `audits/onlyoffice-2026-10-18/` |
+| **R-1117** | **Immich's and Nextcloud's Redis keep a volume they do not need** (upstream runs both without one; queues and caches only). Deferred from R-1096 on purpose: removing a volume from the compose leaves the old volume on installed boxes, and the nightly dump / an old backup's restore for a volume the compose no longer declares is unchecked. The RDB switch (catalog `5d9450b`) already removed the full-disk danger. (P4) | CLOSED 2026-10-18 — **measured, then changed (catalog `30eea97`):** both Redis services run with `--save ""`, tmpfs `/data`, no volume. On scratch 9202 with the new shape: both apps healthy, Immich's forced metadata job ran (counter 0 → 11, 0 failed), Nextcloud `cron.php` rc 0; the nightly dump skips the dropped volume; a second-drive restore from a copy made WITH the volume succeeded and, by design, brought back that copy's compose. The old volume stays attached under the tmpfs; **a removal left it behind — fixed in controller v0.331.0** (the removal deletes volumes still labelled with the app's project; red-proofed). | `audits/redis-volumes-2026-10-18/` |
+| **R-1135** | **CI's failure mail links the run at the in-cluster Gitea address** (`http://gitea.gitea-system.svc.cluster.local:3000/...`), which a reader outside the cluster cannot open. Seen in the forced test mail 2026-10-17 (job 1997). (P4) | CLOSED 2026-10-18 — the alarm link is now `https://gitea.dooplex.hu/<repo>/actions/runs/<GITHUB_RUN_ID>` in all four workflows (felhom.eu `1fe9f848`, controller `615940d`, agent `79ba884`, catalog `c97eb1c`). The run NUMBER was a second defect: Gitea 1.26 reads it as an id first and opened an unrelated run (felhom.eu runs/1116 → id 1116 = #613). Proof: forced job 2067 (catalog) at 18:46:01Z, one mail (Gmail, 18:46:02Z), link `…/actions/runs/2067`, also printed as `ALARM-LINK` in the job log. | helper evidence in the session scratchpad `p5/`; job 2067 |
+| **R-1136** | **felhom.eu CI runs take ~6.9 minutes and complete, so the 5-minute job timeout R-265 assumes does not hold there** (runs 1996, 1997; `script-tests` alone ~356 s). Found by the R-1129 proof helper 2026-10-17. (P4) | CLOSED 2026-10-18 — measured: the runner's real limit is act_runner 0.6.1's default `runner.timeout` **3 h** (`act-runner-config` sets only capacity, fetch_timeout, fetch_interval); the job-level `timeout-minutes: 5` is parsed and NOT enforced by act_runner 0.6.1 (only step-level is) — 231 felhom.eu jobs ran past 300 s and passed (longest 529 s, job 2038). `script-tests` (~7 min) is far from 3 h: no speed-up. R-265 corrected; the step-level timeout is R-1152. | act_runner v0.6.1 `config.go:128`, `act/runner/runner.go:164`, `step.go:206` |
+| **R-1137** | **A CI rerun may overwrite a failed job's log** — failure mails arrived for controller commits `c02c9d83` and `29a3ce8c` while their jobs (1944, 1959) now read green. UNPROVEN (a reading, 2026-10-17). (P4) | CLOSED 2026-10-18 — **confirmed:** a rerun replaces the job record the `jobs` endpoint shows (same id, `run_attempt` 2, the rerun's conclusion and log); the first attempt survives only as a task in `actions/tasks` (`status` failure) and its log is not readable by the API (controller job 1944 = tasks 1962 fail + 1964 ok; 1959 = 1978 fail + 1980 ok). The pull check in felhom.eu `CLAUDE.md` now reads `actions/tasks` when `run_attempt` > 1 (`b9b56c47`). A scratch-repo red run was not possible: the admin token lacks `write:user` and push-to-create is off — measured on the two real cases instead. | felhom.eu `CLAUDE.md` CI pull-check item 3 |
+
 ## 2026-10-18 (day) — hub 0.158.0 live, „anyway" restarts the apps, vault-first installer 1.34.0, the estimator's Immich figure (controller v0.330.0, agent v0.159.2)

 | Row | What | Closed | Evidence |
@@ -1254,7 +1265,7 @@ Nine rows closed. **Full original text: `git show <this commit>^ -- documentatio
 | **R-258** | **C3 — the customer's per-app backup tick is green on the PRESENCE of a restore point, and its only red condition is a GLOBAL one.** | **CLOSED 2026-08-08 — controller v0.210.0.** `appDumpVerdict` reads THIS app's own dump result; three states, no icon when nothing is known. **Recency deliberately not added** — see the observation in the follow-through section | full text: `git show fddfe00ce268:documentation/backlog/OPEN-ITEMS.md` |
 | **R-259** | **C4 — a disk read that FAILS renders as „0.0 GB / 0.0 GB (0%)" in the nominal colour, on the dashboard's most-looked-at meter.** | **CLOSED 2026-08-08 — controller v0.210.0.** `readDiskUsage` reports success; `SystemInfo.DiskKnown`/`HDDKnown`; the template draws no figure, no percentage and no meter fill when unknown. **The hub leg is deliberately NOT fixed and is now R-266** | full text: `git show fddfe00ce268:documentation/backlog/OPEN-ITEMS.md` |
 | **R-260** | **C5 — the agent reports at least eight decision-bearing facts the hub models NOWHERE, and the sharpest one blinds the check that answers „can the operator get into this box".** | **CLOSED 2026-08-08** — the class is GATED (G-1, `scripts/wire_contract_gate.py`) and the sharpest instance is fixed (hub v0.99.0). The remaining unconsumed facts are **R-264, OPEN** — allowlisted with reasons, which is not the same as decided. See the follow-through section below | full text: `git show fddfe00ce268:documentation/backlog/OPEN-ITEMS.md` |
-| **R-265** | **A CI run can fail with NO LOG PERSISTED, and the alarm mail then points the operator at a log that does not exist.** | **CLOSED 2026-08-08 — `timeout-minutes: 5` on the gates job, and the alarm mail now states elapsed seconds and qualifies its own "names itself in the run log" sentence.** ⚠ **The unknown is NOT closed and must not be read as closed:** whether the `if: failure()` alarm fires for a REAPED job is still unverified. The timeout makes the reap unreachable in practice; it does not answer what happens inside one | full text: `git show fddfe00ce268:documentation/backlog/OPEN-ITEMS.md` |
+| **R-265** | **A CI run can fail with NO LOG PERSISTED, and the alarm mail then points the operator at a log that does not exist.** | **CLOSED 2026-08-08 — `timeout-minutes: 5` on the gates job, and the alarm mail now states elapsed seconds and qualifies its own "names itself in the run log" sentence.** ⚠ **The unknown is NOT closed and must not be read as closed:** whether the `if: failure()` alarm fires for a REAPED job is still unverified. The timeout makes the reap unreachable in practice; it does not answer what happens inside one **⚠ CORRECTED 2026-10-18 (R-1136): the `timeout-minutes: 5` this row closed on has NEVER been in force.** act_runner 0.6.1 parses a job-level `timeout-minutes` and does not enforce it (only step-level is), and 231 felhom.eu jobs ran past 5 minutes and passed (longest 529 s, job 2038). The limits really in force are the runner's 3 h default (`runner.timeout` not set in `act-runner-config`) and Gitea's server-side reapers (defaults: 10 min with no task update, 3 h endless; `app.ini` not read). A hung step on a live runner runs up to 3 h. The unknown stays open: whether `if: failure()` runs for a reaped job. Step-level timeout: R-1152. | full text: `git show fddfe00ce268:documentation/backlog/OPEN-ITEMS.md` |
 | **R-267** | **The Configuration page is 2.6× faster and is still ~10 s, and the remaining cost is ONE Gitea call whose latency swings 20× with load.** Shipped in 0.100.2, v0.100.0. | **CLOSED 2026-08-08 — hub v0.101.0 + a registry prune.** **Final: cold 5.4 s, warm 0.14 s** (was 26.2 s). Three serialisation legs took it to 9.85 s mean, the 60 s in-memory memo took the warm path to a quarter-second, and the prune halved what remains of the cold path. **⚠ TWO CORRECTIONS TO THIS ROW'S OWN EARLIER TEXT, because both were wrong and both mattered.** **(1) "Only 50 generic versions exist" WAS NOT A COUNT, IT WAS A PAGE LIMIT.** `?type=generic&limit=1000` returns at most 50; the 50 I measured was exactly the cap, and three older agent versions (0.81.0, 0.80.0, 0.79.0) only became visible after the first 30 deletions moved them onto page one. **An unpaginated listing is not evidence of a total** — this repo's own "an empty listing is not evidence of emptiness" rule, walked into while measuring. **(2) THE OPERATOR'S "REDUCE THE NUMBER OF ARTIFACTS" WAS THE BETTER CALL AND MY MEASUREMENT SAID OTHERWISE.** I reported it helps "sub-linearly" and "is not the lever". Measured after: trimming to 10+10 took the COLD load from 13.4 s to 5.4 s — a 2.5× improvement on the path the memo cannot help, because the fan-out is per-version. Recorded rather than quietly dropped (the R-96 standing rule). **Pruned to the newest 10 per package on the operator's rule**, with the live-vouched golden/agent/floor asserted into the KEEP set before a single DELETE was issued; 33 deletions, all HTTP 204, and golden 0.210.0 / agent 0.128.0 / agent 0.127.0 verified still fetchable afterwards. `drill-r50` runs agent 0.113.0, now deleted — flagged to the operator first; it is a disposable nested drill VM and only its re-download path is gone | full text: `git show fddfe00ce268:documentation/backlog/OPEN-ITEMS.md` |
 | **R-268** | **A live per-guest local-API token was printed into a session transcript.** Shipped in 169.254.253. | **CLOSED — ROTATED + PROVEN LIVE 2026-08-09** (rehearsal pre-phase, `audits/REHEARSAL-byo-reinstall-2026-08-09.md` §3) | full text: `git show fddfe00ce268:documentation/backlog/OPEN-ITEMS.md` |
 | **R-273** | **RANK 1 — the hub vouched an agent version that was never git-tagged, and every install fleet-wide now fails at step 5/8.** Shipped in 0.127.0, 0.128.0, v0.127.0. | **CLOSED 2026-08-09 — tag pushed, install PROVEN** | full text: `git show fddfe00ce268:documentation/backlog/OPEN-ITEMS.md` |
@@ -123,16 +123,15 @@ stopping line that lies.
 | **R-993** | Install & onboarding | P3 | **Operator: approve the minimum machine in `documentation/audits/sizing-2026-10-13/SIZING.md` §5** (the input R-991's hardware page needs). MEASURED 2026-10-13 on the N100 demo box (61 apps deployed and removed through the product, 15 min at rest each; heavy apps with one real action). Proposal: **minimum** x86-64, 4 cores (N100 class), **8 GB**, 256 GB SSD; **recommended 16 GB**, 512 GB SSD; out: ARM / Raspberry Pi, Synology-QNAP, routers, cloud VPS. Worked from the floor (2.5 GB for the whole box with no apps) + Immich, Jellyfin, Nextcloud, Home Assistant, Vaultwarden, Paperless-ngx at their peaks (5.0 GB) + 50 % headroom ≈ 12.3 GB. 8 GB runs that set without Immich; 16 GB runs all of it twice over. Data for the estimator: `sizing.json`. **2026-10-13 (estimator session) — the installer accepts a host BELOW this minimum:** `autosize_guest_caps` has no floor on the host, only on the guest; on a 4 GB box (MemTotal ≈ 3.5 GiB) the guest gets host − 1 GB ≈ 2.4 GB and Proxmox keeps ≈ 1 GB, where it used ≈ 2.0 GB on the N100 (SIZING.md §1). Whatever minimum is approved, nothing enforces it at install today. The three-verdict wording of §5 now matches the estimator page (`/gepigeny`, R-997). | **WAITING-ON-OPERATOR** — filed 2026-10-13 | the operator's decision | Operator: approve or change §5. If nothing is done: no hardware page; a buyer with a Raspberry Pi can still download the installer (R-991 stays open) | operator |
 | **R-494** | Install & onboarding | P4 | **NARROWED 2026-09-14 by operator ruling → [P3-LOW] the hub COULD create the tunnel at customer creation, for a domain already on Cloudflare. Not blocking: every customer has their own domain and the operator creates the tunnel per day-0 A.1 (`architecture/01-topology-and-trust.md`).** *Original finding, kept:* **[P1-HIGH] A new customer's dashboard has NO reachable address unless the operator hand-makes a Cloudflare tunnel — the link in the setup-code mail is dead.** MEASURED 2026-09-14 on a fresh install from the public ISO (drill intervention **I1**): the claim mail points at `https://felhom.drill0242.felhom.eu`; that name has **no A and no AAAA** record (`dig @1.1.1.1`, control `felhom.enkisfelhom.hu` resolves); the hub has **no tunnel- or DNS-creation code** (`hub/internal/cloudflare/` holds only geo-rule removal; `cf_tunnel_token` is a pasted, optional form field, `configs.go:1478`) — day-0 runbook A.1 makes it a manual Cloudflare-dashboard step that nothing on the customer-create page asks for; the box's own split-horizon resolver on the appliance LAN IP answered `google.com` but not the dashboard name at 13:27:39Z; the agent applied the record at **13:27:44Z** (`lanresolver: applied split-horizon record … ip=192.168.0.158`, 3 m 46 s after the controller started), so the box CAN answer the name — **but only to a device that uses the box as its DNS server, and no document, screen or mail tells a household to do that**; the router and the installer-offered DNS answer nothing. The page was reachable only at the guest's LAN address with the name forced (`curl --resolve …:443:192.168.0.158`). **A volunteer could not have done that.** **What it needs:** an operator ruling — the hub creates the tunnel and DNS at customer creation, or the product gives a household a LAN address that works with no DNS change. | **READY — rank P3-LOW; owner: CC** **Re-ranked 2026-10-03: P3→P4: operator-side automation; the operator creates the tunnel by hand per the day-0 runbook.** | — | — | CC |
 | **R-504** | Install & onboarding | P4 | **[P3-LOW] `iso.felhom.eu` cannot show an index page on its own — its root returns 404, and the download page lives on the website instead.** MEASURED 2026-09-14: `https://iso.felhom.eu/` and `/index.html` → 404; only named objects answer. The host is an R2 bucket behind a custom domain; whether R2 would serve an uploaded `index.html` at `/` was **not measured** (uploading anything to the public bucket is a publication). The ISO v1.27.0 task puts the Hungarian download page at `felhom.eu/letoltes` (published with the ISO, after the operator's yes). **Remaining:** a redirect from `iso.felhom.eu/` to that page needs a Cloudflare rule the session has no credential for. | **WAITING-ON-OPERATOR — rank P3-LOW; owner: operator (Cloudflare rule)** **Re-ranked 2026-10-03: P3→P4: households are sent to the website's download page; the bare address is cosmetic.** | — | — | operator |
-| **R-1148** | Install & onboarding | P3 | **Installer 1.34.0 is published (operator yes, 2026-10-18) but its default path has not run on a fresh install.** Step 4b now vaults FIRST, then sets the password, then checks a PVE login (R-1145); the SC2066 loop became an `if`. Proven: the harness (52/0, the R1145 cases run the real step with fake commands), `test_hostinstall.py` 40/0, a real `--rotate-recovery-only` on demo-hp (vault time moved, new value 200, old 401). Not proven: a whole fresh install on a machine, where step 4b runs inside the full sequence and `https://127.0.0.1:8006` must answer during it. | OPEN — filed 2026-10-18 | — | One fresh appliance install with 1.34.0 on a scratch VM on demo-hp (the ISO proof-VM shape): step 4b's three lines, the vault time, a PVE login with the vaulted value; then discard the unclaimed appliance (the operator's press) | CC |
+| **R-1154** | Install & onboarding | P3 | **A reinstall while the customer's OLD host record still exists skips both clean-slate re-issues (the claim code and the off-site credential) in silence.** `handleHostEnroll` returns the existing host early (mint-once-reuse), so `reissueOnReenroll` is never reached; its own comment assumes „the clean-slate flow deletes the stale host” — nobody does on a plain reinstall. Proven live on the demo-hp reinstall 2026-08-21 (CC memory), never filed. Now recurring: the operator keeps Tester4 as the standing fresh-install customer (2026-10-18), and its old host `Tester4-31fa0e` stays after each teardown. Filed 2026-10-18. | OPEN — filed 2026-10-18 | — | Decide: the enroll re-issues when the old host is stale or off, or the teardown deletes the host first (operator, session only); a test on the enroll path | CC |

-## Apps & catalog — 16 rows (P3 7, P4 9)
+## Apps & catalog — 15 rows (P3 6, P4 9)

 | ID | Category | Sev | What | State | Blocked on | Next action | Owner |
 |---|---|---|---|---|---|---|---|
 | **R-1091** | Apps & catalog | P3 | **Catalog copy that is wrong or stale at the pinned tag, found writing the guides — each needs an operator word or a live check, so none was changed tonight.** From source at each app's tag (evidence per app in `audits/app-guides-2026-10-15/B/`): (1) and (2) **DONE 2026-10-16** (operator decision D12: reword): calcom's use case now names Apple Calendar or a CalDAV calendar instead of Google/Outlook, and bentopdf's tagline and use case say the browser does the work and the file stays on the device (catalog CHANGELOG 2026-10-16); (3) **sabnzbd**, **nzbget** use_cases say Radarr/Sonarr/Jellyseerr hand them jobs — the box wires only qBittorrent and Transmission (`mediawire.go`), and a hand link needs a path mapping; (4) **onlyoffice** first_steps 3–4 tell the household to wire Nextcloud by hand — the integration toggle does it (`internal/integrations/onlyoffice_nextcloud.go`); (5) **glance**, **homepage** first_steps send the household into config files in a Docker volume no household tool reaches; (6) **lubelogger** starts with only the „Dashboard" tab and in miles (shipped `appsettings.json`), so first step 3 cannot be done as written; (7) **home-assistant** first_steps promise auto-discovered devices — the app runs on a Docker bridge, where mDNS/SSDP were measured deaf (spike R-6); (8) **homebox** and **gitea** `add_people` name menus that moved or read differently at the tag; **bookstack** `default_creds` still says `admin@admin.com / password`, which after_install replaces; **dawarich** names the API key's page „Settings" (source suggests the account page); **code-server** says „install your tools" with no sudo; **komga** names the discontinued Tachiyomi; **seerr** `docs_url` points at Overseerr; **wanderer**'s comment still says it cannot close sign-up (R-714 is fixed in the same file); (9) **nzbget** and **grafana** deploy-field descriptions say the password can be changed later — nzbget re-applies its env password at every start and grafana ignores the field after first start (R-1086 is the qBittorrent/Transmission side). | OPEN — filed 2026-10-15 | — | Live-check (5)–(7) and (9) on 9202; fix (3), (4), (8) as copy with the freeze re-admitted; re-run the guide label check for any app whose copy moves | CC |
 | **R-1092** | Apps & catalog | P4 | **Three apps show no guide: plant-it and home-assistant carry one HIDDEN (`checked_version: ""`), emby has none.** plant-it: `lifecycle: abandoned`, and its pinned image does not exist upstream, so there is no screen to check labels against. home-assistant: its frontend follows the browser language and the Hungarian strings are fetched at build time, not kept in git, so the Hungarian labels cannot be checked against source (the draft is written; the shipped frontend in the image could check them). emby: its server's web UI is in no public source at 4.11.0.4. Evidence: `audits/app-guides-2026-10-15/B/`. The other 62 templates show a checked guide (controller ≥ 0.315.0). | OPEN — filed 2026-10-15 | — | home-assistant: check the Hungarian labels against the frontend files in the pinned image (read-only, on a box running it), then set checked_version; emby: label-check against the image's own web files the same way; plant-it: nothing while abandoned | CC |
 | **R-676** | Apps & catalog | P3 | **[P3-LOW] Watch: immich's first start restarted 12 times — decision 28's crash-loop stop (6 in 10 min) would stop it.** From the 2026-09-17 chaos night (DB connection dropped during the first-start geocoding import on a 6 GB guest; it did not recover that night). No healthy app in any drill evidence restarts on a first start (1831 samples, 40 live containers), so the threshold stands; this row exists so the first immich install under v0.269.x is watched. `audits/night-2026-09-24/A3/40-first-start-restarts.txt` **2026-09-25 night (read from source, v0.271.0): a DEPLOY's first start is NOT covered by decision 28's suppression** — `Deploying` clears when `compose up -d` returns (`deploy.go` "Clear deploying flag"), and `ObserveUnhealthy` then samples the app; an automatic update's step, verify and undo ARE covered (`Updating`, pinned by `TestD28_NoCrashLoopStopDuringAnAutomaticStep`). So a first start that restarts ≥ 6 times in 10 min is stopped — which R-676 already accepts for a broken first start; a healthy slow first start would be stopped too. **-- 2026-09-30: the first-start restarts are explained.** immich's first-start geodata import OOM-kills its database at 512M on a guest with no swap (R-732, measured: 61–104 kills); the 2026-09-17 chaos-night case (DB connection dropped during the import on a 6 GB guest) fits it. Fixed in the catalog (`56c4888`, 768M). The watch itself (decision 28 on a DEPLOY's first start) is unchanged. | **OPEN — P3; owner: CC (watch)** | — | — | CC |
-| **R-1018** | Apps & catalog | P3 | **The OnlyOffice links (FileBrowser, Nextcloud) have no recorded live proof since the move to Proxmox.** `controller/internal/integrations/` holds two handlers; no audit after the Proxmox move shows a document opened from FileBrowser or Nextcloud in OnlyOffice (searched 2026-10-14). The media-app links of `15` §6 will copy this code, including its revoke-on-stop rule (`lifecycle.go:10-13`). | **OPEN** — filed 2026-10-14 | — | One live walk on a Tier-0 box: install OnlyOffice + FileBrowser, open a document, save, read it back; then stop one app and record what the link does | CC |
 | **R-1028** | Apps & catalog | P3 | **Plex's claim code can run out during the install, and the box cannot recover it.** plex.tv's code lives 4 minutes from the moment the household copies it; the clock covers the wizard, the image pull (`plexinc/pms-docker` is 351 MB, measured) and the first start. Plex reads `PLEX_CLAIM` only on its first run, and the field is `locked_after_deploy` — so a late code leaves an unclaimed server and the only way back is remove + install again. Reported by the operator during the 2026-10-14 test; on Tester 1's line the pull+start took 8.5 s and the claim worked (`audits/media-all-drives-2026-10-14/``G-auth/G3-plex-claim.txt`), so it bites on a slow line or a slow hand. **K6, 2026-10-14 night (`audits/media-drive-events-2026-10-14/``K6-1-unclaimed-plex.txt`):** an unclaimed Plex starts with no code at all, and `POST /myplex/claim?token=` on the RUNNING server reaches plex.tv (a wrong code → 500 after plex.tv's 401). So the box can pull + start first and ask for the code after: no race. A real claim needs the household's code — the morning step on the throwaway `plex-k6` on Tester 1. Narrowed 2026-10-14 night. **PROVEN 2026-10-15 morning (`K6-2-claim-after-start.txt`):** the operator's real code, given to the RUNNING unclaimed `plex-k6` → 200, `claimed` 0→1, `PlexOnlineToken` written, and the open door closed (no token → 401). `ADVERTISE_IP` was unset and the claim did not need it; whether clients find the server without it was not measurable (the throwaway had no published port). **BUILT 2026-10-15 (v0.313.0):** `after_start` field — not asked at install; the Plex page asks for the code once Plex runs and claims the running server; the gate opens only when Plex says claimed. Proven up to the code on 9201 (G5). | **NARROWED** — the dashboard claim with a real code is the last step | a household Plex code | Claim through the Plex page with a real code (G5c); then close | CC |
 | **R-1029** | Apps & catalog | P3 | **Plex's folder picker shows the drives as identical „media” folders.** With one bind per drive at the same path (`/mnt/felhom-drives/<drive>/userdata/media`), the leaf of every library folder is `media`; the drive's name sits two levels up, so in Plex's picker the household sees several folders all called „media” (reported by the operator during the 2026-10-14 test on Tester 1). It conflicts with `15` §2 reason 2 (the same path everywhere). | **READY** — filed 2026-10-14 | the layout decision (STATUS D9) | Decide in `15` §2: the players (`:ro`, never linked) may get a readable path per drive (e.g. `/media/<drive label>`) without breaking the hardlink rule, which binds only the download/library apps | CC |
 | **R-1071** | Apps & catalog | P3 | **Jellyfin cannot use films that sit on a NAS share (the pilot's OMV), and the pilot's wish is exactly that.** MEASURED 2026-10-15: an OMV SMB share added as „Hálózati tárhely” mounts and verifies (`/mnt/felhom-drives/omv-filmek`) — but only with a user name AND a WRITABLE share (read-only → refused „az alkalmazások nem tudnak rá írni”) — and the household's „Újraindítás most” binds only local drives into Jellyfin (`per-drive binds 1 [/mnt/felhom-drives/filmlemez/userdata/media]`). By design: R-108 (a NAS is browse-only, never an app's namespace); `media_library.go` skips `Kind == "network"`. A design decision, not a defect (R-370). Evidence: `audits/omv-vm-2026-10-15/B6-omv-share.txt`. | WAITING-ON-OPERATOR | Operator: should a media app read a NAS share read-only (a new bind kind), or is the answer „put the films on a drive the box owns”? | Operator rules; if yes, a design note in `15-media-library.md` first. | Operator |
@@ -142,9 +141,9 @@ stopping line that lies.
 | **R-995** | Apps & catalog | P4 | **Removing an app through the product can leave unnamed Docker volumes and an empty import folder behind.** MEASURED 2026-10-13 on demo-felhom after 61 removals (`documentation/audits/sizing-2026-10-13/METHOD.md` „Teardown”, `evidence/leftover-volumes-after-bench.txt`): 8 unnamed volumes (4–72 KB; immich 1, romm 2, privatebin 3, onlyoffice 2 — volumes the images declare themselves) and `userdata/import/{paperless,calibre,grimmory}` (empty, created by the deploy). The removal answered 200 and its own leftover check was clean, because it looks only at labelled volumes. No data risk; disk and tidiness only. Removed by name on the bench. | **READY** — filed 2026-10-13 | — | Make the removal account for the containers' unnamed volumes (and an empty import folder it created), with a test that deploys an image that declares a VOLUME | CC |
 | **R-1067** | Apps & catalog | P4 | **The catalog still carries `pi_compatible:` on every template, and nothing reads it any more.** controller v0.315.0 removed the „Pi kompatibilis" badge and the „csak x86" tag from every page (Raspberry Pi is no longer supported, so one was noise and the other was a warning on almost every app). The `ResourceHints.PiCompatible` struct field and the catalog key were deliberately LEFT: a box still on 0.314.0 reads the key, and removing it would make that box show „csak x86" on every app. **Gated on the floor:** once the fleet floor is at or above 0.315.0, drop `pi_compatible:` from the templates and the field from `stacks.ResourceHints` in the same pair of commits. Harmless until then — an unread key costs nothing. | **BLOCKED** — filed 2026-10-15. Checked 2026-10-16 (apps burndown): the floor is 0.321.0 and demo-hp, Tester 1 and the N100 run 0.321.0, but **Tester-2 still reports 0.292.0** (its newest report 2026-10-04; hub DB with WAL) — so nothing removed. | every box on ≥ 0.315.0 — today Tester-2 | Drop the catalog key and the struct field; grep the hub and the website for Pi wording at the same time (none found 2026-10-15) | CC |
 | **R-1043** | Apps & catalog | P4 | **Sonarr, Radarr and Prowlarr build their login redirect as an absolute `http://` URL.** They trust forwarded headers only from their „Trusted networks” (the household set `192.168.0.0/24`; traefik is `172.18.x`), so they ignore `X-Forwarded-Proto: https` and answer `Location: http://<name>/login` to an https visitor. Since controller v0.312.0 that hop is sent back to https by traefik (a GET, no password), so it is cosmetic; a template could seed traefik's network as trusted. (`audits/https-only-2026-10-14/``1A-3-4.txt`) | **OPEN** — filed 2026-10-14 | — | Seed the docker network as a trusted proxy in the *arr templates (with the R-1030 seed), measure the redirect | CC |
-| **R-1100** | Apps & catalog | P3 | **One sign-in for the dashboard and FileBrowser (proxy auth) — spike first.** Since controller 0.320.0 every app with a folder has „Fájlok ↗", and the box can show FileBrowser's password — but FileBrowser still asks for its OWN login the first time, so the household signs in twice. FileBrowser Quantum has a proxy-auth method (`auth.methods.proxyAuth`, header-trusted) that could take the dashboard session through traefik; nobody has measured it. Design: `architecture/02-controller-module-map.md` „Logins and folders". | OPEN — filed 2026-10-16 (task logins-folders). | — | Spike on demo-hp: proxy auth at the pinned tag (source + measured), a forwardAuth in traefik that answers only for a dashboard session, what a stranger reaching `files.<domain>` with a forged header gets, and what happens to FileBrowser's shares. | CC |
+| **R-1100** | Apps & catalog | P3 | **One sign-in for the dashboard and FileBrowser (proxy auth) — spike first.** Since controller 0.320.0 every app with a folder has „Fájlok ↗", and the box can show FileBrowser's password — but FileBrowser still asks for its OWN login the first time, so the household signs in twice. FileBrowser Quantum has a proxy-auth method (`auth.methods.proxyAuth`, header-trusted) that could take the dashboard session through traefik; nobody has measured it. Design: `architecture/02-controller-module-map.md` „Logins and folders". | **READY** — spike done 2026-10-18 (`audits/proxyauth-spike-2026-10-18/DESIGN-NOTE.md`): Traefik forwardAuth with `authResponseHeaders` strips a client's header (any case, twice) and its own value wins — measured; the config key is `auth.methods.proxy` (not `proxyAuth`); **but an app container reaching `filebrowser:80` directly logs in with a forged header (measured 200)**, and the dashboard cookie is host-only. Build = a files-only ticket cookie + a per-box secret header name. Filed 2026-10-16. | — | Build per the design note (controller only, ~one release), or decide not to | CC |
 | **R-1099** | Apps & catalog | P4 | **The N100 may hold RomM games in the old upload place, now shown under a fake „roms” platform.** Until 2026-10-16 RomM's own upload wrote to the drive's `roms/roms/<platform>/`; after the mapping fix (catalog `fb18471`, R-1089) those files are at RomM's `library/roms/roms/…`. Measured on 9201: such a game showed as missing in its platform and again under a platform „roms” (`audits/romm-ghost-2026-10-16/B/b-after.txt`). Files put in with the file manager are not affected — they are now found. The N100 runs RomM (hub `/apps/romm`); CC does not log in to the lived-in box. | OPEN — filed 2026-10-16 | Operator: look at `roms/roms/` on the N100's drive in the file manager | If it holds platform folders: move them up one level into `roms/`, then run „Scan” in RomM; if it is empty, close | Operator |
-| **R-1117** | Apps & catalog | P4 | **Immich's and Nextcloud's Redis keep a volume they do not need** (upstream runs both without one; queues and caches only). Deferred from R-1096 on purpose: removing a volume from the compose leaves the old volume on installed boxes, and the nightly dump / an old backup's restore for a volume the compose no longer declares is unchecked. The RDB switch (catalog `5d9450b`) already removed the full-disk danger. | DEFERRED — filed 2026-10-17 | — | Measure the dump and an old-backup restore without the volume on 9202; then the template change + an orphan-volume note | CC |
+| **R-1153** | Apps & catalog | P4 | **FileBrowser's preview of a .docx answered 500 while the OnlyOffice link was on** (`/api/resources/preview`, scratch 9202, controller 0.330.0, 2026-10-18). FileBrowser builds an office preview through OnlyOffice's converter from `server.internalUrl` when it is set (`backend/http/preview.go:243` at 1.5.6-stable) and from the request's host when not — so 0.331.0's `internalUrl` (R-1018) may already fix it. Not re-checked: OnlyOffice was removed after the walk. | OPEN — filed 2026-10-18 | — | One preview request on a box with 0.331.0 and the link on | CC |


 ## App updates — 4 rows (P3 4)
@@ -156,12 +155,12 @@ stopping line that lies.
 | **R-683** | App updates | P3 | **[P3-LOW] Watch: after a power cut during an update's health check, the hold named an HOUR-OLD second-drive copy, not the one the update's own backup should have just made.** 2026-09-24 chaos round 3 (nextcloud, `backup_max_age: 1m`): no `backing-up` phase was seen and the hold named Tier 2 at 13:04 for an update pressed at 14:04; the pre-cut controller log was lost with the container (the runner now saves it at arm time — R-320). Round 11, the same action without a power cut, named a fresh 14:34 copy and logged the Tier-2 copy. The sentence was TRUE (it named the copy it offered); the question is why the update did not back up first. Not reproduced; watch the next power-cut drill. `audits/night-2026-09-24/E/round-03*.json`, `E/round-11-controller-pre.log` | **OPEN — P3; owner: CC (watch)** | — | — | CC |
 | **R-785** | App updates | P3 | **[P3-LOW] SparkyFitness is pinned 11 releases and a major behind upstream (v0.17.3; upstream v1.7.3, v1.6.0 dated 2026-07-24).** READ 2026-10-01 (`audits/visitors-2026-10-01/C/bench/C1-previous-tag.txt`). **Needs:** an update walk 0.17 → 1.x through the ladder (bench + box), after R-784 is decided. | **OPEN — rank P3-LOW; owner: CC (after R-784)** | — | — | CC |

-## Backup & restore — 28 rows (P2 3, P3 14, P4 11)
+## Backup & restore — 30 rows (P2 3, P3 16, P4 11)

 | ID | Category | Sev | What | State | Blocked on | Next action | Owner |
 |---|---|---|---|---|---|---|---|
-| **R-978** | Backup & restore | P3 | **Starting the escrow ceremony again can make the customer's written-down recovery code useless: the new package replaces the old one before the new code is confirmed.** It can happen to an ordinary customer who starts and walks away. Fix: keep the previous package until the new code is confirmed. Security review 2026-10-12 (`audits/security-review-2026-10-12/`); detail held off-git for the operator (`/mnt/5_hdd/felhom.eu/evidence/security-review-2026-10-12-PRIVATE/`). | OPEN | — | Fix in the agent with a test | CC |
-| **R-973** | Backup & restore | P3 | **A compromised controller can make the whole-guest backup run again and again, and each run prunes older restore points: the local tier directly, and the off-site tier through the store's own nightly keep-last-2.** So `07` §8 row 10 (ransomware) is weaker than it reads. The second reader confirmed the local half; the off-site half is inferred. Fix: a cadence or daily cap on the local-API backup route, and off-site snapshots that a nightly prune cannot remove. Security review 2026-10-12 (`audits/security-review-2026-10-12/`); detail held off-git for the operator (`/mnt/5_hdd/felhom.eu/evidence/security-review-2026-10-12-PRIVATE/`). | OPEN | — | Add the cap with a test; decide the off-site retention shape | CC |
+| **R-978** | Backup & restore | P3 | **Starting the escrow ceremony again can make the customer's written-down recovery code useless: the new package replaces the old one before the new code is confirmed.** It can happen to an ordinary customer who starts and walks away. Fix: keep the previous package until the new code is confirmed. Security review 2026-10-12 (`audits/security-review-2026-10-12/`); detail held off-git for the operator (`/mnt/5_hdd/felhom.eu/evidence/security-review-2026-10-12-PRIVATE/`). | **OPEN — the fix is in agent `main`, unreleased** (`8561dc8`, 2026-10-18): the new package reaches the hub only when its code is claimed; an abandoned second ceremony leaves the first code opening the hub's package (tests + four red-proofs). Residual R-1151. Rides the next vouched agent release. | — | Release with the operator's yes; then close | CC |
+| **R-973** | Backup & restore | P3 | **A compromised controller can make the whole-guest backup run again and again, and each run prunes older restore points: the local tier directly, and the off-site tier through the store's own nightly keep-last-2.** So `07` §8 row 10 (ransomware) is weaker than it reads. The second reader confirmed the local half; the off-site half is inferred. Fix: a cadence or daily cap on the local-API backup route, and off-site snapshots that a nightly prune cannot remove. Security review 2026-10-12 (`audits/security-review-2026-10-12/`); detail held off-git for the operator (`/mnt/5_hdd/felhom.eu/evidence/security-review-2026-10-12-PRIVATE/`). | **OPEN — the local-half fix is in agent `main`, unreleased** (`f17e197`, 2026-10-18): a cadence cap on `POST /backup` — daily tier ≤ 3 successful runs per rolling 24 h, the weekly off-site tier one per 6 days; a refusal is 429, logged, persisted across a restart, and a CRITICAL degraded status for 24 h (operator-only `agent_capability_degraded`, wording R-1150). *Decided by CC unattended — operator may reverse:* the numbers. **Off-site half, design line (not built):** ep0 prunes the namespace keep-last 2 — a count, so each extra run pushes out the oldest; with the cap a pre-compromise copy survives ≥ ~6 days and each extra attempt alarms; to make it unfloodable, ep0's prune moves to time buckets (e.g. keep-weekly 2) — an ep0/hub prune-job change, the operator's; check that DooPlex's pull copy of ep0 is keep-weekly, not keep-last. Local keep-last 3: R-1149. | — | Release with the operator's yes; decide the off-site prune shape | CC |
 | **R-232** | Backup & restore | P2 | **DooPlex's backup makes every copy inside the same box — and nothing tells anyone when it fails.** Surveyed read-only 2026-08-06 (`audits/RECON-dooplex-backup-2026-08-06.md`). **What works:** five sets, 14/14 successful runs in 14 days; a file was restored from the `data` repo and matched the live original **byte for byte**; every set except two is cross-disk; k3s is integrity-checked on every run. **What the matrix exposes, ranked:** (a) **`notify_failure` is a no-op** — `NOTIFY_ON_FAILURE=true` but `NOTIFY_WEBHOOK_URL` is commented out, so a failed backup notifies **nobody**; the project already has a working Resend path that CI uses. Cheapest item, and it makes every other failure visible. (b) **Nothing leaves the box** — no rclone, no remote repo, no off-site target anywhere; Longhorn's target is `nfs://192.168.0.180:` pointing at DooPlex itself, and the only outbound-looking cron pulls *inbound* from Hetzner for a different project. The machine that runs the hub managing the customers' off-site chain has no off-site copy of its own. (c) **The backup tree is a single writable path** and the restic repos are not append-only — one bad script or ransomware destroys every copy at once. (d) **Two same-disk sets**: `.claude-memory` and the PostgreSQL dumps, whose source directory sits *inside* the backup tree. (e) **Longhorn `retain=1`** — one generation per volume, so a corruption noticed a day late has no earlier copy. (f) **`/opt/backup/docs/BACKUP-RESTORE.md` does not exist** though the systemd unit advertises it. (g) **`secrets/restic-repo` has never held a snapshot** — `backup-secrets.sh` contains no `restic` call; the secrets are GPG files on `sda1` only. (h) **No restore has ever been run** beyond today's single-file probe — the matrix's "ever demonstrated?" column is otherwise entirely empty. **Not a finding:** the restic passphrase. The on-box copy is on `sdb1`, a different disk from the backups, and the **operator holds an offline copy out of band** — so a disk loss is recoverable. The narrow residual is that it is operator-held rather than system-held, unlike the customer case's hub-vaulted escrow, so it should be confirmed current and findable by someone else. **Nothing was changed by the recon.** | **NARROWED 2026-10-08 — owner Viktor.** (a) DONE with the operator's yes in chat: `notify_failure` now mails admin@felhom.eu through Resend; proven by one test mail that reached the inbox (`audits/day-2026-10-08/r232/`; no backup was started). (b) partly: the hub database leaves DooPlex nightly to ep0 (R-173); everything else stays on the box. (c)–(h) unchanged. **2026-10-09 (operator yes in chat): (b) and (h) DONE for Gitea and the secrets.** Nightly 00:20 `felhom-dooplex-offsite` pushes Gitea (614 MB of repositories, the `gitea` database dump taken first, `app.ini`) and the nightly GPG secrets export, encrypted with a NEW key, to ep0 `operator` (`host/dooplex-gitea`) on the hub-DB write-only token — no change on ep0; first push 57 s; restore test weekly (manifest, `git fsck` every repo, `pg_restore --list`), run once: 27 805 files, 10 repos OK; `DooplexGiteaOffsiteStale`/`DooplexGiteaRestoreTestStale` in force (`absent()` included, promtool + 2 red-proofs); every backup unit now mails on failure (`OnFailure=`, dry run reached the inbox). **First real Gitea restore:** into a throwaway on the bench, 10/10 repos, product `main` = live, a file byte for byte, a login (`runbooks/gitea-restore.md`). The hub came back too (R-173, closed). **The registry is left out on purpose:** its images rebuild from the code. **Correction to the recon §7:** the API mirror holds ONE repo (`homelab-manifests`), not all — Gitea had a single copy, on DooPlex. `audits/dooplex-survival-2026-10-09/` **LEFT:** (c) append-only for the on-box tree, (d)–(g) as written; the paper copy of the new key (operator). **READY** for the rest | — | — | operator |
 | **R-893** | Backup & restore | P3 | **After a failed OFF-SITE replay, the rollback pours the NEWER pre-restore copy over the OLDER volume just put back.** Read in source 2026-10-06 (R-638 option A, not measured): `internal/backup/offbox_reconstitute.go` writes the undo copy from the live (newer) database, replaces the volumes with the snapshot's older tars, then — when the replay fails — `rollbackSafetyDump` loads that newer dump over the older database volume. The loader only drops what the dump knows, so tables the newer migration removed stay; and when the snapshot's older definition was written, the rollback branch does not put the newer definition back, so the older app starts on rolled-back data; non-database volumes stay at the snapshot's state. An order change cannot fix it (the only undo is a logical dump, and its volume was replaced). Known limit in `07` §6.3. **-- 2026-10-08 design:** `audits/day-2026-10-08/design-R-893.md` — re-verified; and the screen's „your data is back as it was" (`err.backup.db_restore_failed_rolled_back`) is false for files, other volumes and the app version. Question D8 on STATUS's decision sheet. **-- 2026-10-08 14:16 operator ruling D8 (`09` §3 decision 192):** yes, both, in that order — first the app stays stopped for support (option C), next „put back exactly as it was" (option A). | **NARROWED — 2026-10-09: the first half DELIVERED in controller 0.304.0. Slice 0 (the live measurement) NOT run: 9202 has no off-site, and a dump cannot be cut by hand inside an encrypted off-site copy on Tester 1; it needs a scratch off-site repo — a plan, not a finding.** **NARROWED 2026-10-08 — the first half (D8 option C, the app held stopped) is built on controller main and ships tomorrow; what stays open is the second half, „put back exactly as it was” (option A: a pre-restore copy of the app's volumes and placed files, a fit check, disk for one copy; the slice-0 measurement on 9202 first).** **OPEN — filed 2026-10-06** **2026-10-06 night: verified in source, no code** — `offbox_reconstitute.go:758` (undo dump from the live DB), `:778-860` (files and volumes from the snapshot), `:804` (the snapshot's definition is written when its version differs), `:898` (the rollback loads the newer dump over the older volume; nothing writes the live definition back). Not a reorder fix: it needs R-638 option B (a rebuilding loader) or a pre-restore volume copy (disk cost; R-685's class). Which state a household gets after a failed off-site replay is the operator's call. Next: the 9202 measurement, then the design. | a design: R-638 option B (a loader that rebuilds instead of overlays) or a pre-restore volume copy | Measure it once on 9202 (a forced replay failure after an off-site restore over a migrated app); then a design for the operator | CC |
 | **R-895** | Backup & restore | P2 | **The hub's clean-up-window check trusts the snapshot counts the box sends, so a broken-into box (or past-dated fakes added through the add-only key) can shrink the real off-site history without an alarm.** READ 2026-10-06 night in source (R-822's design): the before/after comparison uses counts the box itself reports (`hub/internal/offsitekeys/service.go:284`, `:343`); new fakes keep the count level. Decision 68 already accepts a box-trusted count. | **NARROWED 2026-10-18 — slice 2 built, not deployed** (hub v0.158.0): the 07:10 audit compares the `snapshots/` listing with yesterday's by name — files gone that no clean-up window explains → `offsite_snapshots_vanished` (error), files no reported box run explains → `offsite_snapshots_unexplained` (warning); operator-only, hub-origin (not in `allowedEventTypes`). First listing = baseline; a move-aside or RESET drops it; vanishing judged on a pinned tier only; files younger than 1 h judged the next day. Red-proofed twice (`snapshot_watch_test.go`). **Not built:** the window's before/after on the hub's own count (design §3.1) and refusing a window while unexplained files exist (§3.2). Unmeasured: the provider shell's `ls -l` time zone (± 3 h slack until then). **Deployed 2026-10-18 12:23 (hub v0.158.0).** The first listing (tomorrow 07:10) is a baseline; the first verdict is 2026-10-20 07:10. **Known limit (independent review 2026-10-18, F2):** `_unexplained` is explained by the box's OWN reported `offsite.last_run`, so whoever holds a box's key can silence it; `_vanished` is judged on the hub's own listing and is not affected. | the operator's yes to deploy hub v0.158.0 | Deploy; read the first 07:10 lines (newest upload vs the box's last run = the time-zone calibration), shrink the slack; then decide §3.1/§3.2 | CC |
@@ -188,13 +187,15 @@ stopping line that lies.
 | **R-878** | Backup & restore | P4 | **A catch-up (R-871) runs the database-dump leg in the DAY, and that leg stops an app with a volume for its copy — the household may notice the stop, and a large volume makes it longer.** MEASURED 2026-10-05 on demo-felhom: the catch-up at 08:25:02 stopped opengist, copied 182.5 KB, started it again — about 1 s, then a few seconds of `health: starting`; the night does exactly the same, unseen. Nothing measured for a large volume. Fix direction (if it matters): skip the volume copy of a running app in a DAYTIME catch-up and leave it to the next night, or warn. `audits/catchup-2026-10-05/partA/live-demo-felhom.txt` | **READY — owner: CC** **2026-10-05 (burn-down night): NEEDS A LIVE MEASUREMENT** — a timed catch-up on 9202 for an app with a multi-GB volume, then the skip-or-warn choice. | — | measure a large volume first | CC |
 | **R-32** | Backup & restore | P4 | **[P2-HIGH] RESET must purge the customer base dir; the orphan card must stay honest; unattributed bytes must be visible.** The rehearsal's S7 said in advance that an orphan card would BE a finding — and one appeared (16:58:14). Cause: RESET's `"hetzner":"ok"` leg destroys the sub-account, but **a Hetzner sub-account is an access-control object, not a data object** — its directory survives, so re-enabling offsite recreated an account over the previous lifecycle's ciphertext, encrypted under a key that same RESET had destroyed. **MIGRATED FROM `ROADMAP.md` 2026-08-22 (R-369) — originally filed 2026-07-21, size M, roadmap state `idea`.** Moved verbatim; nothing added or reinterpreted. The roadmap keeps its copy as history, marked moved. | **OPEN — migrated from ROADMAP 2026-08-22, rank unchanged** **2026-10-06 night: design written** (`audits/night-burndown-2026-10-06/design-R-32.md`) — pick A: purge the repo + set-aside copies through the sub-account's own password login BEFORE deleting it (no main-account credential); the „repo data destroyed" comment at `hub/internal/offsite/offsite.go:276-280` is false for the shared tier; part (3) waits on a read-only measurement (`du` on port 23). Operator: agree to route A. **2026-10-07 07:58: `09` §3 decision 167 — option A yes, and delete the old RESET leftovers once.** **2026-10-07 (Part D step 2, read only):** the hub shows bx11 holding 3.3 GB of data while the four live customers account for ~0.6 GB → **~2.7 GB belongs to no live customer**; no live customer shows a set-aside folder, so the leftovers are in homes whose sub-account is gone, reachable only by the pool box's MAIN account. **The one-time clean-up is STOPPED:** no main-account login for bx11 is held on DooPlex (the API token in the credentials file sees no box). Needs: the main-account login, or the operator lists and deletes in the Hetzner console (`audits/day-2026-10-07/D/D2-listing-readonly.txt`). **2026-10-07: option A DELIVERED (hub 0.142.0):** RESET purges the repo and every `.orphaned-*` through the sub-account's own login before deleting it, and keeps the sub-account if the purge fails (red-proved, `audits/day-2026-10-07/D/`). Not yet seen live (no scratch RESET today). **The one-time clean-up of the ~2.7 GB of leftovers is STOPPED:** it needs the pool box's main-account login (see above). **2026-10-07 14:43 — `09` §3 decision 173: leave the ~2.7 GB of old leftovers for now; re-ranked P2 → P4.** Option A itself is delivered (hub 0.142.0). What stays open is ONLY the leftovers: they were computed (box total minus live customers), never listed, and deleting them needs the pool box's MAIN login, which reaches every customer's data. **Blocker: a safe main-account path.** | — | **Ruling from the run (three parts, deliberately separate):** (1) because RESET destroys custody, the ciphertext it leaves behind is unrecoverable **BY DESIGN** → RESET gains a **main-account purge of the customer base dir** (the existing operator ack already covers it); (2) the **move-aside guard STAYS** for reinstall-*without*-RESET — there custody survives and the card's "history recoverable" promise is true (R-26 depends on exactly that); (3) the operator **Restic tab shows per-customer directory bytes vs attributed snapshot bytes**, so dead data cannot hide. Measured on the pool box that night: **49 M attributed** (2 snapshots, 48.717 MiB) against **1.4 G + 3.0 M unattributed** across TWO `.orphaned-*` dirs. Evidence `restic-and-pool.txt` | CC |
 | **R-1087** | Backup & restore | P4 | **Whole-box copies left on the OLD local target are never pruned after the target moves.** MEASURED 2026-10-15 (storage-identity build B space check): the N100's host root (`local`) holds three copies from 2026-07-28 (5.5–5.7 GB each, ≈ 16.8 GB); its agent's `local_backup_target` is now `felhom-backup` (the USB disk, retention 3), and retention prunes only the current target. On a small-root box such leftovers would starve the local copies (R-548). Evidence: `audits/storage-identity-buildB-2026-10-15/space/felhom-pve-9201.txt`. | OPEN | — | Decide whether the agent prunes its own `vzdump-lxc-<vmid>-*` files on a former target (after a newer copy exists on the new one), or the target move asks; until then, the N100's three July files can be removed by hand with the operator's word. | CC |
+| **R-1149** | Backup & restore | P3 | **The local whole-guest tier prunes keep-last 3, so even with the R-973 cadence cap a compromised controller can replace all three restore points within one day.** A time-bucketed prune (`--prune-backups keep-daily=3`) has the same disk cost and cannot be flooded within a day. It changes `07` §6's retention, so it is the operator's call. Found by the R-973 helper 2026-10-18. | OPEN — filed 2026-10-18 | — | Operator decides keep-last vs keep-daily; then the agent's vzdump argument | operator + CC |
+| **R-1151** | Backup & restore | P3 | **The new escrow package now uploads when its code is claimed (R-978), but the wizard's typed-back check is the browser's alone:** a household that opens the new code and closes the page without writing it down has still replaced the hub's package, and the first code no longer opens it. Gate the upload on the typed-back confirmation with a new controller → agent call. Found 2026-10-18. | OPEN — filed 2026-10-18 | — | Controller + agent: the confirm call; red-proof the abandoned-after-claim case | CC |

 ## Storage & devices — 10 rows (P3 4, P4 6)

 | ID | Category | Sev | What | State | Blocked on | Next action | Owner |
 |---|---|---|---|---|---|---|---|
 | **R-1073** | Storage & devices | P3 | **Felhom in a virtual machine sees no disk health: SMART is UNKNOWN for its own system disk and any passed disk.** MEASURED 2026-10-15 on the OMV-VM copy: every storage target reported `smart.health = UNKNOWN`, all counters null (the guest sees QEMU disks). On the pilot's box the NVMe and the „old, not stable” Toshiba would be watched by OMV only, and Felhom's drive-health alarms (R-330/R-332's whole point) cannot fire. Evidence: the host report in `audits/omv-vm-2026-10-15/README.md` (memory/disk section) and `C-hub-events-Tester4.txt`. | WAITING-ON-OPERATOR | Operator: is a VM install a supported shape, and if so, is „OMV watches SMART” acceptable or must Felhom say on the dashboard that it cannot watch the disks? | Operator rules; then CC adds a household line on the Meghajtók page when SMART is unavailable. | Operator |
-| **R-1093** | Storage & devices | P3 | **An EMPTY partition asks for the typed „data will be erased" confirmation.** MEASURED 2026-10-16 (build B, scratch VM, agent 0.158.1): `POST /api/storage/init` for a blank part → `needs_confirmation`, reason „device has a partition table" — `lsblk` reports the PARENT disk's table (PTTYPE) for a partition, so the agent's probe reads an empty part as data-bearing. Safe direction (more friction, never less), but `16` §6 says an empty part is self-serve and the wizard shows „adatot tartalmaz". Evidence: `audits/storage-identity-buildB-2026-10-15/live/12-partitions-format.txt`. | OPEN | — | In the agent's device probe, ignore a PTTYPE that a partition inherits from its parent (judge only the part's own signature and children); a red-proved test with a blank part fixture. Next agent release. | CC |
+| **R-1093** | Storage & devices | P3 | **An EMPTY partition asks for the typed „data will be erased" confirmation.** MEASURED 2026-10-16 (build B, scratch VM, agent 0.158.1): `POST /api/storage/init` for a blank part → `needs_confirmation`, reason „device has a partition table" — `lsblk` reports the PARENT disk's table (PTTYPE) for a partition, so the agent's probe reads an empty part as data-bearing. Safe direction (more friction, never less), but `16` §6 says an empty part is self-serve and the wizard shows „adatot tartalmaz". Evidence: `audits/storage-identity-buildB-2026-10-15/live/12-partitions-format.txt`. | **OPEN — the fix is in agent `main`, unreleased** (`f7b7308` + `0963bae`, 2026-10-18): lsblk's inherited PTTYPE is ignored only when `blkid -p` on the partition exits 0 with `PART_ENTRY_NUMBER` and the same scheme; every error path stays data-bearing (14-row test, three red-proofs; no sudoers change). Live on demo-hp (a loop file in `/root`, removed): the empty GPT part → blkid rc 0 with only `PART_ENTRY_*`; ext4 → `TYPE`; a table inside → `PTTYPE=dos` (`audits/agent-fixes-2026-10-18/r1093-loop-check.txt`). Not walked: `/api/storage/init` on a VM disk. | — | Release with the operator's yes; one init call on a VM with a spare disk | CC |
 | **R-1062** | Storage & devices | P4 | **The N100's USB drive cannot be split in two without losing the box's whole-guest backup target.** The operator asked (2026-10-15 16:31) for two halves for multi-drive tests. Read first (`audits/n100-lived-in-2026-10-15/B/`): no family files — 2.7 GB nightly vzdumps of guest 9201 (`dump/`, PVE storage `felhom-backup` = the whole-guest backup target), 3.1 GB app backups + an off-site restore copy, 422 MB leftover app data of removed apps, empty media folders. The agent refuses a decommission of a backup target (`refuseIfBackupTarget`) and the N100 has no other drive to move that role to. Nothing changed. | **WAITING-ON-OPERATOR** — filed 2026-10-15 | operator decision | Keep one drive (CC's pick: the lived-in box keeps its local whole-guest backup), or give a word to drop that backup leg / add a second drive first | operator |
 | **R-1064** | Storage & devices | P4 | **Removing a storage path does not mention the cross-drive backup copies it holds.** demo-hp 2026-10-15: `/mnt/sizing-bench` removed through `/settings/storage/remove` (302, „Adattároló eltávolítva") while calibre-web's and paperless-ngx's `cross_drive.destination_path` pointed at it; the copies stay on disk, the records still name the removed path. The in-use check counts HDD_PATH only (`appsUsingPath`). | **OPEN** — filed 2026-10-15 | — | Read what tonight's tier-2 run (01:30) does with the two records; then: name the copies in the removal's confirmation (or count them as in use) | CC |
 | **R-330** | Storage & devices | P3 | **Disk health Phase 2 — the three SMART attributes the wire does not carry.** The failing drive's most telling counter was **187 `Reported_Uncorrect`**, sitting at normalized **1** against threshold **0** with a raw count of **1001** — one point from failing and structurally unable to get there. Also wanted: **199 `UDMA_CRC_Error_Count`** (cabling) and **188 `Command_Timeout`**. None are on the agent→controller wire today, so v0.215.0's ladder could not use them. Phase 2 also persists periodic SMART **samples** (the right home is `metrics.MetricsStore`, NOT the Phase-1 state file, which is one record per disk and must stay that way). **This is a declared WIRE change, so under the G-1 gate the hub must model the new fields in the SAME session** — that is precisely why it was kept out of Phase 1, where it would have turned a one-word severity fix into a three-repo change | **READY** — **2026-10-12: the wire half is CLOSED in this row** — released in agent v0.150.0 (boxes run 0.154.0), controller and hub decode 187/188/199. **Only open work:** the verdict slice (use the three counters in the disk verdict and the household's words) and persisting samples. **READY (M) — NEW 2026-08-14** **2026-10-06 night: the wire half BUILT on main (unreleased):** the agent sends SMART 187 `reported_uncorrect`, 188 `command_timeout` (raw, vendor-packed on some drives — carried as reported), 199 `udma_crc_errors` (pointer + omitempty: unknown is absent, never 0); the controller decodes them and the hub's host-report mirror models them (G-1 wire gate green; it convicted the agent half alone). **Carried only** — no verdict, banner, mail or alarm reads them (`TestR330_CountersChangeNoVerdictYet`); using them changes what a household is told and is the next slice, with persisting samples. Red-proofs `audits/night-burndown-2026-10-06/r330/`. Ships with agent v0.150.0 and the next controller and hub releases. | R-328 (closed) | The verdict slice: 187/188/199 into the disk verdict with tests; then persist samples | CC |
@@ -247,7 +248,7 @@ stopping line that lies.
 | **R-1061** | Box system & updates | P4 | **A per-customer floor reached Tester 1 only at its next 15-minute report, not in seconds.** Set 2026-10-15 12:55:51 UTC for tester-1, demo-hp and demo-felhom together (hub 0.153.0, CC's token): demo-hp and demo-felhom ran 0.314.0 within 13 s (the hub's wake); Tester 1 moved at 13:09:35, its regular report (`audits/gate-restore-2026-10-15/release/03-boxes-move.txt`). It had restarted at 12:54:29 onto rc.1 and logged „hub wait channel active". Why the wake did not reach it is not read (the wake line is DEBUG). No harm: the floor arrived. | **OPEN** — filed 2026-10-15 | — | Read Tester 1's DEBUG ring at the next floor change; compare with the hub's bump log | CC |


-## Monitoring & notifications — 11 rows (P2 1, P3 7, P4 3)
+## Monitoring & notifications — 12 rows (P2 1, P3 7, P4 4)

 | ID | Category | Sev | What | State | Blocked on | Next action | Owner |
 |---|---|---|---|---|---|---|---|
@@ -262,6 +263,7 @@ stopping line that lies.
 | **R-285** | Monitoring & notifications | P4 | **A planned, supervised reinstall pages the operator as if the machine had died — there is no notion of expected downtime anywhere.** During the 2026-08-09 rehearsal the hub sent, all `status: sent` to the operator channel: `host_stale` 08:58 UTC, `node_stale` 09:00, **`host_down` 09:28 (error)**, **`node_down` 09:30 (error)**, `host_leaf_changed` 09:31, `host_recovered` 09:31, `node_recovered` 09:34, `offsite_delivery_stuck` 09:34 — eight operator mails for work that was deliberate, attended and announced. **This is the OPPOSITE gap from the one R-281 filed:** the alarms are not missing, they are indiscriminate. `host_stale` at 30 min and `host_down` at 60 min (`monitor/host_staleness.go:22-23`, `downAfter = 2 * threshold`) cannot distinguish a wiped-on-purpose box from a dead one, and `host_leaf_changed` firing on a reinstall is correct-but-expected. **Note the interaction with the mute used on 2026-08-09 evening:** blocking a customer silences everything, so today the only two settings are *page me for planned work* and *tell me nothing at all*. **What is owed is a middle:** a maintenance window, or an operator-set expected-downtime flag, that suppresses staleness and leaf-change while leaving genuine faults audible | **READY (M) — NEW 2026-08-09** | — | The evidence is the operator's mailbox plus `events`/`notification_log` for 2026-08-09 | CC |
 | **R-1005** | Monitoring & notifications | P4 | **A recovery mail says how long the box was „stale", not how long it was gone: after a 51-minute power cut demo-hp's `host_recovered` read „was stale for 8m" and `node_recovered` „23m".** An operator reading only the recovery mail under-reads the outage (`audits/night-power-2026-10-13/` R6). Same kind, the other way: the off-site mail of 2026-10-14 02:18 was titled „3 of 3 apps failed to back up (offsite run)" while 11 other apps were backed up in that run — only the 3 flagged apps were counted. | **READY** — filed 2026-10-14 | — | CC: add the time since the last report before the gap to both recovery messages, and count every app of the run in the off-site subject, with a test that asserts each text; next hub release | CC |
 | **R-1049** | Monitoring & notifications | P3 | **A pulled drive mails the operator „unexpectedly disconnected” (error), and nothing ever mails that it came back.** MEASURED 2026-10-14 night (`audits/media-drive-events-2026-10-14/K8-hub-mails.txt`, the hub DB with its WAL from the running pod, and the mailbox as the second channel): two pulls → two `storage_disconnected` mails; the hub RECEIVED both `storage_reconnected` and both `health_recovered` (severity info) and logged no notification for any of them — they are not in `recoveredPairedDownTypes` (`hub/internal/notify/dispatcher.go`), so the severity gate drops them. The R-97a shape: told it broke, never told it healed — the operator cannot tell a returned drive from one still gone without opening the hub. **BUILT 2026-10-15 — hub v0.151.0 (`12552aca`): both pairs in `recoveredPairedDownTypes`, cooldowns ended by the next loss (`TestR1049_DriveBackMailsBothEdges`, red-proved). Not deployed: the operator's „yes” first (decision 162); the image build waits for it too.** | **WAITING-ON-OPERATOR** — hub v0.151.0 code pushed, not built, not deployed | the operator's „yes” to the hub deploy | On the „yes”: build + deploy hub v0.151.0; read a „came back” mail on the next pull | CC |
+| **R-1150** | Monitoring & notifications | P4 | **A refused whole-guest backup (the R-973 cap) reaches the operator as `agent_capability_degraded`, whose text reads „agent privileged capability degraded”.** True but misleading for a refused backup; on the night path the controller may also mail its own backup failure. Add a dedicated operator-only type (`whole_guest_backup_refused`: `allowedEventTypes` + `operatorOnlyEvents`) or adjust the text, in the next hub release (a two-repo change: the agent's status name stays). Found 2026-10-18. | OPEN — filed 2026-10-18 | — | Next hub release | CC |


 ## Hub & operator — 12 rows (P3 6, P4 6)
@@ -301,7 +303,7 @@ stopping line that lies.
 | **R-990** | Business & legal | P4 | **Operator: read `documentation/audits/forum-research-2026-10-12/FELHOM.md` §5 and rule on each recommendation.** READ-ONLY research 2026-10-12: three years (#7943–#11092, 2,908 posts, 195 people, 82 beginner threads) of the public PROHARDVER! topic „Home server / házi szerver építése”, tagged and counted by person (`FINDINGS.md`, method and spot-check in `METHOD.md`; no username or post text in git). Ten ranked recommendations, none acted on; the top three: a „which machine works” page (8 of 33 beginners who name their hardware own only a Synology, a router disk or a Raspberry Pi — the installer cannot run there; the same gap is R-989's first recommendation from a different source, and the shipped-page half is R-991), „you do not choose an operating system — we do” (the biggest beginner question, 20 of 82 threads), and „bring your old office PC” as the cheap entry. Catalog gap (≥ 3 people): a DLNA server (7), an ad/DNS blocker (5), a camera recorder (5). | **WAITING-ON-OPERATOR** — filed 2026-10-12 | the operator's reading | Operator: rule on each of the ten (yes / no / later). If nothing is done: nothing changes; the research ages | operator |
 | **R-1035** | Business & legal | P4 | **Did the „felhő tárhely” page earn anything? Two dated checks.** **Baseline (reported by the operator from Search Console, 2026-10-14, last 3 months):** 1 click, 48 impressions, CTR 2.1 %, average position **73.6**; „felhő tárhely” 19 impressions, „felhőtárhely” 5, „felhő alapú tárhely” 3. CC measured separately that the phrase „felhő tárhely” appeared **0 times** on the home, FAQ and backup pages — Google was showing the home page for those queries by accident. `/sajat-felho-tarhely` + `/en/own-cloud-storage` published **2026-10-14**; full baseline, price sources and the power provenance in `audits/seo-2026-10-14/BASELINE.md`. **What to measure, both times:** impressions and average position for „felhő tárhely” and „saját felhő tárhely”, plus the new page's own impressions, clicks and position. **A null result at +4 weeks means nothing on its own** — a new page on a site at position 73.6 takes weeks to months to move, and „felhő tárhely” alone is held by Microsoft, Google and the big list sites; the page aims at the two longer phrases. That is why there are two checks and not one, and why neither should be read as a verdict on the copy. **There is no Search Console connector in this project, so CC cannot read these numbers** — the operator reads them, CC records and compares. **Blocked until the operator asks for indexing** (Search Console → URL-ellenőrzés → the URL → „Indexelés kérése”): until that happens, or Google finds the page itself, both checks read zero for a reason that is not the page. **This is a slow channel and does not replace talking to people.** | **WATCHING** | operator: request indexing, then supply the Search Console read | 2026-11-11: first read (+4 weeks); 2026-12-09: second (+8 weeks), compared with the first | operator + CC |

-## Process & tooling — 33 rows (P3 9, P4 24)
+## Process & tooling — 31 rows (P3 9, P4 22)

 | ID | Category | Sev | What | State | Blocked on | Next action | Owner |
 |---|---|---|---|---|---|---|---|
@@ -335,9 +337,7 @@ stopping line that lies.
 | **R-1127** | Process & tooling | P4 | **The controller's and the catalog's decoy suites run only when someone starts a full gate run by hand** — neither the pre-push hook nor CI (`--fast`) runs them (too slow, or they edit real files), so a decoy that goes quiet is again seen only by chance (R-1115's shape). The agent's runs in CI. Found by the R-1116 helper 2026-10-17. | OPEN — filed 2026-10-17 | — | A scheduled full run (CI cron or the nightly), with a mail on failure | CC |
 | **R-1128** | Process & tooling | P4 | **The controller's decoy suite edits real tracked files (`handler_debug.go`, `update.go`, the locale bundles, templates) and plants `.go` files, with no lock** — a full run while another session edits the controller tree can overwrite that session's edits. felhom.eu's suite took an `flock` after the 2026-10-08 clobber. Found by the R-1116 helper 2026-10-17. | OPEN — filed 2026-10-17 | — | Run the suite in a scratch copy of the tree, or take the felhom.eu-style lock | CC |
 | **R-1123** | Process & tooling | P4 | **`reuse_refs_check.py` treats every git directory beside the repo as a sibling repo**, including stray clones in the workspace (`felhom.eu-media`, `felhom.eu-sizing-push`, `felhom.eu-wt-sizing`), so a citation can resolve against a stale clone and pass. Found by the R-1116 helper 2026-10-17 (it also makes the agent suite 20 s here vs 5 s in CI). | OPEN — filed 2026-10-17 | — | Search only the four known repo names (or the main clones), with a decoy | CC |
-| **R-1135** | Process & tooling | P4 | **CI's failure mail links the run at the in-cluster Gitea address** (`http://gitea.gitea-system.svc.cluster.local:3000/...`), which a reader outside the cluster cannot open. Seen in the forced test mail 2026-10-17 (job 1997). | OPEN — filed 2026-10-17 | — | Use the public Gitea URL in the alarm step's link | CC |
-| **R-1136** | Process & tooling | P4 | **felhom.eu CI runs take ~6.9 minutes and complete, so the 5-minute job timeout R-265 assumes does not hold there** (runs 1996, 1997; `script-tests` alone ~356 s). Found by the R-1129 proof helper 2026-10-17. | OPEN — filed 2026-10-17 | — | Measure the runner's real timeout; correct R-265's assumption or speed up `script-tests` | CC |
-| **R-1137** | Process & tooling | P4 | **A CI rerun may overwrite a failed job's log** — failure mails arrived for controller commits `c02c9d83` and `29a3ce8c` while their jobs (1944, 1959) now read green. UNPROVEN (a reading, 2026-10-17). | OPEN — filed 2026-10-17 | — | Confirm with one deliberate red + rerun on a scratch repo; if true, the CI check must read the first attempt | CC |
+| **R-1152** | Process & tooling | P4 | **felhom CI's 5-minute job timeout is inert** (act_runner 0.6.1 does not enforce a job-level `timeout-minutes`, R-1136), so a hung step runs up to the runner's 3 h. Move it to a step-level `timeout-minutes` on each workflow's gate step (e.g. 20 min for felhom.eu, which runs ~7 min), measured first: a step timeout fails the job AND the `if: failure()` alarm still runs. Needs a scratch repo (the admin token cannot create one — the operator, or a token with `write:user`). Found 2026-10-18. | OPEN — filed 2026-10-18 | — | Measure on a scratch repo, then the four workflows | CC |

 <!-- DUE-CHECKS-BEGIN — machine-readable. Parsed by scripts/due_checks_gate.py.
     One row per dated check. The R-number must have a row above. Dates are UTC.
@@ -203,6 +203,10 @@ produced a false "unreachable" verdict (standing rule 2).
 Create and destroy freely **on a Tier 0 host**. Two exceptions: **`drill-r50`** is a fixture, not
 scratch; and scratch **customers** outlive their VMs in the hub — delete those too, or they accumulate
 (`sess-c` and `sess-d` were both left behind before anyone noticed).
+**One standing exception (operator, 2026-10-18): customer `Tester4` is KEPT** as the fresh-install customer
+(domain `tester4.test`, mail `tester4@felhom.eu` — the Gmail catch-all). Before each new install with it, the operator
+deletes its OLD host record on the Hosts page: an enroll that finds the customer's old host reuses it and skips the claim
+and off-site re-issues in silence.

 **The hub-side teardown waits for the stale threshold — plan for it (R-599).** After the VM is destroyed
 the hub still reads its host as ONLINE until the last report is older than `alerting.stale_threshold`
@@ -0,0 +1,14 @@
+== 2026-10-18T20:52:00Z revert to virgin + cold boot
+revert rc=0
+qemu started
+ssh up after ~18s
+pve-manager/9.2.2/b9984c6d90a4bd80 (running kernel: 7.0.2-6-pve)
+update successful
+system          debian-13-standard_13.6-1_amd64.tar.zst
+calculating checksum...OK, checksum verified
+download of 'http://download.proxmox.com/images/system/debian-13-standard_13.6-1_amd64.tar.zst' to '/var/lib/vz/template/cache/debian-13-standard_13.6-1_amd64.tar.zst' finished
+build-golden.sh sha256 645b3b659cbadebe from felhom-agent 1693da4
+Running as unit: golden-bake.service; invocation ID: b26a0833ce6744f584a73ad589beb99f
+token in unit props: 0
+[golden] build-golden.sh v3.2.0 — baking controller gitea.dooplex.hu/admin/felhom-controller:0.331.0
+[golden] creating build LXC 9100 (nesting=1,keyctl=1, unprivileged; rootfs 32G + ONE data volume 24G @ /var/lib/felhom, backup=1) …
@@ -0,0 +1,3 @@
+## round trip 2026-10-18T20:59:13Z
+sha256 3881de62b0986ccbe5e55580e3f1bb9765d65b8d898f67c6339bac105244f84f bytes 637197198
+bake said 3881de62b0986ccbe5e55580e3f1bb9765d65b8d898f67c6339bac105244f84f
@@ -0,0 +1,10 @@
+== teardown 2026-10-18T20:59:29Z
+purging CT 9100 from related configurations..
+0
+ls: cannot access '/root/.gitea-token': No such file or directory
+ls: cannot access '/root/bake-run.sh': No such file or directory
+ls: cannot access '/root/bake.log': No such file or directory
+qemu running: 0
+revert rc=0
+ID      TAG               VM_SIZE                DATE        VM_CLOCK     ICOUNT
+1       virgin                0 B 2026-07-03 14:12:15  0000:00:00.000          0
@@ -0,0 +1,43 @@
+# Golden 0.331.0 — bake + publish, 2026-10-18 (evening; the floor's version)
+
+Why: the evening brief of 2026-10-18 (Part 7) asks for a golden at the floor that stands, as the LAST release step of the
+night. The floor was raised to 0.331.0 (MinAgent 0.158.1) at 20:48:56 UTC and does not move again tonight. Procedure:
+`documentation/runbooks/RUNBOOK-manual-build.md` §4.0 and §4.1 steps 1–4, in the drill VM on DooPlex. The script came
+from CC's `felhom-agent` clone at `origin/main` (`1693da4`; `build-golden.sh` sha256 `645b3b65…`, the same file as the
+0.329.0 bake).
+
+| | Previous (`../golden-0.329.0-2026-10-18/`) | This bake |
+|---|---|---|
+| `build-golden.sh` | v3.2.0 | same file |
+| Controller | `felhom-controller:0.329.0` (MinAgent 0.158.1) | **`felhom-controller:0.331.0`** (MinAgent **0.158.1**) |
+| Docker engine | the approved set (six pairs) | the same six pairs — the hub's newest approved Docker release `os-docker-20261004-142842` (read from the hub DB tonight) |
+| Template | `debian-13-standard_13.6-1_amd64.tar.zst` | same (after `pveam update`; `_amd64` filtered) |
+
+## Pass markers (from `bake.log`, this folder)
+
+```
+[golden] build-golden.sh v3.2.0 — baking controller gitea.dooplex.hu/admin/felhom-controller:0.331.0
+[golden] Docker engine set PINNED to the approved release: containerd.io=2.3.6-1~debian.13~trixie … docker-compose-plugin=5.6.0-1~debian.13~trixie
+  docker OK (overlay2; data-root /var/lib/docker)
+INFO: including mount point rootfs ('/') in backup
+INFO: including mount point mp0 ('/var/lib/felhom') in backup
+[golden]   upload OK (HTTP 201)
+GOLDEN_VERSION=0.331.0
+GOLDEN_SHA256=3881de62b0986ccbe5e55580e3f1bb9765d65b8d898f67c6339bac105244f84f
+```
+
+No `excluding`, no `FATAL`, no `GOLDEN_DOCKER_PKGS not set`; the unit `Result=success`. Round trip: the registry's file
+downloaded and hashed = the bake's sha, 637,197,198 bytes (`02-round-trip.txt`). Token: the unit's properties grep = 0
+(`00-boot.txt`); the committed log grep = 0, with a working control (= 1 on a copy with the token appended, the copy
+shredded). Teardown: `03-teardown.txt` (CT 9100 purged, token/script/log shredded in the VM, VM off, disk back to
+`virgin`). No controller push after the bake.
+
+## Vouch — the operator's act (never CC's)
+
+Three fields together (runbook §4.1 step 5), Configuration → Day-0 artifacts:
+
+- golden **0.331.0**, sha256 `3881de62b0986ccbe5e55580e3f1bb9765d65b8d898f67c6339bac105244f84f`
+- agent **0.159.2** (already vouched, unchanged), sha256 `4d98868e922d6c10665a6c0da9323e8627ea9c589094e81d27d741e625d9d8f9`
+- min_agent **0.158.1** (0.331.0's MinAgent)
+
+The R-120 gate accepts it: the golden equals the newest controller the fleet reports (0.331.0 on all three test boxes).
@@ -0,0 +1,342 @@
+[golden] build-golden.sh v3.2.0 — baking controller gitea.dooplex.hu/admin/felhom-controller:0.331.0
+[golden] creating build LXC 9100 (nesting=1,keyctl=1, unprivileged; rootfs 32G + ONE data volume 24G @ /var/lib/felhom, backup=1) …
+  Logical volume "vm-9100-disk-0" created.
+  Logical volume pve/vm-9100-disk-0 changed.
+Creating filesystem with 8388608 4k blocks and 2097152 inodes
+Filesystem UUID: 1eb5b0d8-5a90-4c9c-b0e0-955a2de54a99
+Superblock backups stored on blocks: 
+	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
+	4096000, 7962624
+  Logical volume "vm-9100-disk-1" created.
+  Logical volume pve/vm-9100-disk-1 changed.
+Creating filesystem with 6291456 4k blocks and 1572864 inodes
+Filesystem UUID: 1e406149-1c42-4d19-bf3f-898513746062
+Superblock backups stored on blocks: 
+	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
+extracting archive '/var/lib/vz/template/cache/debian-13-standard_13.6-1_amd64.tar.zst'
+Total bytes read: 553512960 (528MiB, 137MiB/s)
+Detected container architecture: amd64
+Creating SSH host key 'ssh_host_rsa_key' - this may take some time ...
+done: SHA256:MPjcumton7btXPX/TTneLuTimHFNXPUVyhANi1WnHnQ root@felhom-golden
+Creating SSH host key 'ssh_host_ecdsa_key' - this may take some time ...
+done: SHA256:npjwkW6W8zF5CLbKHXK7Rp8RZMec+z23dtRbV/P8wKU root@felhom-golden
+Creating SSH host key 'ssh_host_ed25519_key' - this may take some time ...
+done: SHA256:5BbaIK8KpPL9/JLpxPAqgbRmbXL1Tm4yzPjp4Wl7eB4 root@felhom-golden
+[golden] starting + installing Docker (official repo, trixie channel) …
+[golden] Docker engine set PINNED to the approved release: containerd.io=2.3.6-1~debian.13~trixie docker-buildx-plugin=0.37.1-1~debian.13~trixie docker-ce=5:29.8.2-1~debian.13~trixie docker-ce-cli=5:29.8.2-1~debian.13~trixie docker-ce-rootless-extras=5:29.8.2-1~debian.13~trixie docker-compose-plugin=5.6.0-1~debian.13~trixie
+apt-listchanges: Can't set locale; make sure $LC_* and $LANG are correct!
+perl: warning: Setting locale failed.
+perl: warning: Please check that your locale settings:
+	LANGUAGE = (unset),
+	LC_ALL = (unset),
+	LC_CTYPE = (unset),
+	LC_NUMERIC = (unset),
+	LC_COLLATE = (unset),
+	LC_TIME = (unset),
+	LC_MESSAGES = (unset),
+	LC_MONETARY = (unset),
+	LC_ADDRESS = (unset),
+	LC_IDENTIFICATION = (unset),
+	LC_MEASUREMENT = (unset),
+	LC_PAPER = (unset),
+	LC_TELEPHONE = (unset),
+	LC_NAME = (unset),
+	LANG = "en_US.UTF-8"
+    are supported and installed on your system.
+perl: warning: Falling back to the standard locale ("C").
+locale: Cannot set LC_CTYPE to default locale: No such file or directory
+locale: Cannot set LC_MESSAGES to default locale: No such file or directory
+locale: Cannot set LC_ALL to default locale: No such file or directory
+apt-listchanges: Can't set locale; make sure $LC_* and $LANG are correct!
+perl: warning: Setting locale failed.
+perl: warning: Please check that your locale settings:
+	LANGUAGE = (unset),
+	LC_ALL = (unset),
+	LC_CTYPE = (unset),
+	LC_NUMERIC = (unset),
+	LC_COLLATE = (unset),
+	LC_TIME = (unset),
+	LC_MESSAGES = (unset),
+	LC_MONETARY = (unset),
+	LC_ADDRESS = (unset),
+	LC_IDENTIFICATION = (unset),
+	LC_MEASUREMENT = (unset),
+	LC_PAPER = (unset),
+	LC_TELEPHONE = (unset),
+	LC_NAME = (unset),
+	LANG = "en_US.UTF-8"
+    are supported and installed on your system.
+perl: warning: Falling back to the standard locale ("C").
+locale: Cannot set LC_CTYPE to default locale: No such file or directory
+locale: Cannot set LC_MESSAGES to default locale: No such file or directory
+locale: Cannot set LC_ALL to default locale: No such file or directory
+  installed: containerd.io	2.3.6-1~debian.13~trixie
+  installed: docker-buildx-plugin	0.37.1-1~debian.13~trixie
+  installed: docker-ce	5:29.8.2-1~debian.13~trixie
+  installed: docker-ce-cli	5:29.8.2-1~debian.13~trixie
+  installed: docker-ce-rootless-extras	5:29.8.2-1~debian.13~trixie
+  installed: docker-compose-plugin	5.6.0-1~debian.13~trixie
+[golden] no approved guest release given - the template versions stay; first-night count vs an approved release: n/a
+[golden] pending Debian upgrades in the baked guest (what a FUTURE approval may bring): 56
+[golden] baking daemon.json: classic overlay2 driver (containerd-snapshotter OFF) + log rotation …
+[golden] wiring the single data volume (R-165 variant V-c): /var/lib/felhom/{docker,sys_drive} -> binds …
+[golden] verifying Docker works in the build guest (storage driver should be overlay2 on the ext4 data volume) …
+Unable to find image 'hello-world:latest' locally
+latest: Pulling from library/hello-world
+4f55086f7dd0: Pulling fs layer
+4f55086f7dd0: Verifying Checksum
+4f55086f7dd0: Download complete
+4f55086f7dd0: Pull complete
+Digest: sha256:11a3eb1597e864c51b3f56733cb2e8a90bf0c284bfc05f9444d81c558bc848aa
+Status: Downloaded newer image for hello-world:latest
+  docker OK (overlay2; data-root /var/lib/docker)
+  live-restore: on
+  /var/lib/docker is a real mount: /dev/mapper/pve-vm--9100--disk--1[/docker] ext4
+  /mnt/sys_drive is a real mount: /dev/mapper/pve-vm--9100--disk--1[/sys_drive] ext4
+  both paths are ONE filesystem: /dev/mapper/pve-vm--9100--disk--1 23317576
+[golden] baking the in-guest controller image gitea.dooplex.hu/admin/felhom-controller:0.331.0 (no registry cred at deploy) …
+
+WARNING! Your credentials are stored unencrypted in '/root/.docker/config.json'.
+Configure a credential helper to remove this warning. See
+https://docs.docker.com/go/credential-store/
+
+0.331.0: Pulling from admin/felhom-controller
+ecc510c1e359: Pulling fs layer
+c3f83389ce1b: Pulling fs layer
+e81c1fce9826: Pulling fs layer
+63a1406b1961: Pulling fs layer
+d747c9b6922d: Pulling fs layer
+2eabf5e8786f: Pulling fs layer
+4659a8fea0f6: Pulling fs layer
+d747c9b6922d: Waiting
+63a1406b1961: Waiting
+2eabf5e8786f: Waiting
+4659a8fea0f6: Waiting
+e81c1fce9826: Verifying Checksum
+e81c1fce9826: Download complete
+63a1406b1961: Verifying Checksum
+63a1406b1961: Download complete
+d747c9b6922d: Verifying Checksum
+d747c9b6922d: Download complete
+c3f83389ce1b: Verifying Checksum
+c3f83389ce1b: Download complete
+4659a8fea0f6: Verifying Checksum
+4659a8fea0f6: Download complete
+2eabf5e8786f: Verifying Checksum
+2eabf5e8786f: Download complete
+ecc510c1e359: Verifying Checksum
+ecc510c1e359: Download complete
+ecc510c1e359: Pull complete
+c3f83389ce1b: Pull complete
+e81c1fce9826: Pull complete
+63a1406b1961: Pull complete
+d747c9b6922d: Pull complete
+2eabf5e8786f: Pull complete
+4659a8fea0f6: Pull complete
+Digest: sha256:1b11d25ac8074f6bbdc073ea8564e8e9a91a6e245f9d91ce49791011efb73dbf
+Status: Downloaded newer image for gitea.dooplex.hu/admin/felhom-controller:0.331.0
+gitea.dooplex.hu/admin/felhom-controller:0.331.0
+[golden] asking the controller which infra images it manages …
+[golden] baking infra images (4): traefik:v3.7.13 cloudflare/cloudflared:2026.9.3 gtstef/filebrowser:1.5.6-stable gitea.dooplex.hu/admin/felhom-samba:1.2.0 …
+v3.7.13: Pulling from library/traefik
+e2de96513ba9: Pulling fs layer
+b686a4f73445: Pulling fs layer
+78cb21c375ca: Pulling fs layer
+acb2f33459b1: Pulling fs layer
+acb2f33459b1: Waiting
+e2de96513ba9: Verifying Checksum
+e2de96513ba9: Download complete
+b686a4f73445: Verifying Checksum
+b686a4f73445: Download complete
+acb2f33459b1: Verifying Checksum
+acb2f33459b1: Download complete
+e2de96513ba9: Pull complete
+78cb21c375ca: Verifying Checksum
+78cb21c375ca: Download complete
+b686a4f73445: Pull complete
+78cb21c375ca: Pull complete
+acb2f33459b1: Pull complete
+Digest: sha256:24841fe2de7304c149343d877d2923b4c8800a38ba015dea9174c23b20e344a0
+Status: Downloaded newer image for traefik:v3.7.13
+docker.io/library/traefik:v3.7.13
+2026.9.3: Pulling from cloudflare/cloudflared
+2cc7ee286bf3: Pulling fs layer
+c172f21841df: Pulling fs layer
+218cf840d0d9: Pulling fs layer
+f6069939f718: Pulling fs layer
+d6b1b89eccac: Pulling fs layer
+2780920e5dbf: Pulling fs layer
+7c12895b777b: Pulling fs layer
+3214acf345c0: Pulling fs layer
+52630fc75a18: Pulling fs layer
+dd64bf2dd177: Pulling fs layer
+b839dfae01f6: Pulling fs layer
+ebddc55facdc: Pulling fs layer
+c4bc6f35ff5e: Pulling fs layer
+b96fe2995f90: Pulling fs layer
+58c0c263dc73: Pulling fs layer
+bd8962e29291: Pulling fs layer
+cac2ae0193cb: Pulling fs layer
+f0383d5ebc47: Pulling fs layer
+dd64bf2dd177: Waiting
+f6069939f718: Waiting
+d6b1b89eccac: Waiting
+2780920e5dbf: Waiting
+7c12895b777b: Waiting
+3214acf345c0: Waiting
+52630fc75a18: Waiting
+b839dfae01f6: Waiting
+ebddc55facdc: Waiting
+c4bc6f35ff5e: Waiting
+b96fe2995f90: Waiting
+58c0c263dc73: Waiting
+bd8962e29291: Waiting
+cac2ae0193cb: Waiting
+f0383d5ebc47: Waiting
+2cc7ee286bf3: Verifying Checksum
+2cc7ee286bf3: Download complete
+218cf840d0d9: Verifying Checksum
+218cf840d0d9: Download complete
+2cc7ee286bf3: Pull complete
+c172f21841df: Verifying Checksum
+c172f21841df: Download complete
+f6069939f718: Verifying Checksum
+f6069939f718: Download complete
+d6b1b89eccac: Verifying Checksum
+d6b1b89eccac: Download complete
+2780920e5dbf: Verifying Checksum
+2780920e5dbf: Download complete
+c172f21841df: Pull complete
+7c12895b777b: Verifying Checksum
+7c12895b777b: Download complete
+3214acf345c0: Verifying Checksum
+3214acf345c0: Download complete
+52630fc75a18: Verifying Checksum
+52630fc75a18: Download complete
+dd64bf2dd177: Verifying Checksum
+dd64bf2dd177: Download complete
+b839dfae01f6: Verifying Checksum
+b839dfae01f6: Download complete
+ebddc55facdc: Verifying Checksum
+ebddc55facdc: Download complete
+c4bc6f35ff5e: Verifying Checksum
+c4bc6f35ff5e: Download complete
+58c0c263dc73: Verifying Checksum
+58c0c263dc73: Download complete
+bd8962e29291: Verifying Checksum
+bd8962e29291: Download complete
+cac2ae0193cb: Download complete
+218cf840d0d9: Pull complete
+f0383d5ebc47: Verifying Checksum
+f0383d5ebc47: Download complete
+b96fe2995f90: Verifying Checksum
+b96fe2995f90: Download complete
+f6069939f718: Pull complete
+d6b1b89eccac: Pull complete
+2780920e5dbf: Pull complete
+7c12895b777b: Pull complete
+3214acf345c0: Pull complete
+52630fc75a18: Pull complete
+dd64bf2dd177: Pull complete
+b839dfae01f6: Pull complete
+ebddc55facdc: Pull complete
+c4bc6f35ff5e: Pull complete
+b96fe2995f90: Pull complete
+58c0c263dc73: Pull complete
+bd8962e29291: Pull complete
+cac2ae0193cb: Pull complete
+f0383d5ebc47: Pull complete
+Digest: sha256:072c067d25ccbe61d46e18f0d0723255f2bb5304f7317caa95b27031520ff92c
+Status: Downloaded newer image for cloudflare/cloudflared:2026.9.3
+docker.io/cloudflare/cloudflared:2026.9.3
+1.5.6-stable: Pulling from gtstef/filebrowser
+55afa1ecc21d: Pulling fs layer
+8ed8f35f8d4f: Pulling fs layer
+989b226a579c: Pulling fs layer
+660aeead31d5: Pulling fs layer
+4f4fb700ef54: Pulling fs layer
+adce24567e4c: Pulling fs layer
+f17ea56b313b: Pulling fs layer
+6b6f3b3efe88: Pulling fs layer
+4ed1ca4f3fce: Pulling fs layer
+e6fc9c6a5757: Pulling fs layer
+d47782d1182a: Pulling fs layer
+6b6f3b3efe88: Waiting
+4ed1ca4f3fce: Waiting
+e6fc9c6a5757: Waiting
+d47782d1182a: Waiting
+660aeead31d5: Waiting
+4f4fb700ef54: Waiting
+adce24567e4c: Waiting
+f17ea56b313b: Waiting
+55afa1ecc21d: Verifying Checksum
+55afa1ecc21d: Download complete
+660aeead31d5: Verifying Checksum
+660aeead31d5: Download complete
+4f4fb700ef54: Verifying Checksum
+4f4fb700ef54: Download complete
+55afa1ecc21d: Pull complete
+8ed8f35f8d4f: Verifying Checksum
+8ed8f35f8d4f: Download complete
+989b226a579c: Verifying Checksum
+989b226a579c: Download complete
+6b6f3b3efe88: Verifying Checksum
+6b6f3b3efe88: Download complete
+f17ea56b313b: Verifying Checksum
+f17ea56b313b: Download complete
+4ed1ca4f3fce: Verifying Checksum
+4ed1ca4f3fce: Download complete
+e6fc9c6a5757: Download complete
+adce24567e4c: Verifying Checksum
+adce24567e4c: Download complete
+d47782d1182a: Download complete
+8ed8f35f8d4f: Pull complete
+989b226a579c: Pull complete
+660aeead31d5: Pull complete
+4f4fb700ef54: Pull complete
+adce24567e4c: Pull complete
+f17ea56b313b: Pull complete
+6b6f3b3efe88: Pull complete
+4ed1ca4f3fce: Pull complete
+e6fc9c6a5757: Pull complete
+d47782d1182a: Pull complete
+Digest: sha256:7c5d7ac8ffda31294d278063cf9d2e04303b39e6dce1f4c691342240ca7703b8
+Status: Downloaded newer image for gtstef/filebrowser:1.5.6-stable
+docker.io/gtstef/filebrowser:1.5.6-stable
+1.2.0: Pulling from admin/felhom-samba
+e2de96513ba9: Already exists
+0ddbc9f3a6b6: Pulling fs layer
+ce57a3f93416: Pulling fs layer
+fb94eeec2fe1: Pulling fs layer
+fb94eeec2fe1: Verifying Checksum
+fb94eeec2fe1: Download complete
+ce57a3f93416: Verifying Checksum
+ce57a3f93416: Download complete
+0ddbc9f3a6b6: Verifying Checksum
+0ddbc9f3a6b6: Download complete
+0ddbc9f3a6b6: Pull complete
+ce57a3f93416: Pull complete
+fb94eeec2fe1: Pull complete
+Digest: sha256:da96f25033827fbb77d0ee398e86fe5b744e2f29be9de898994533340c97acf9
+Status: Downloaded newer image for gitea.dooplex.hu/admin/felhom-samba:1.2.0
+gitea.dooplex.hu/admin/felhom-samba:1.2.0
+[golden] baking the controller-bootstrap unit (deploys the BAKED controller from the config mount) …
+Created symlink '/etc/systemd/system/multi-user.target.wants/felhom-controller-bootstrap.service' → '/etc/systemd/system/felhom-controller-bootstrap.service'.
+[golden] baking the controller-bootstrap PATH unit (starts the service on bootstrap-mount hot-plug — B1) …
+Created symlink '/etc/systemd/system/multi-user.target.wants/felhom-controller-bootstrap.path' → '/etc/systemd/system/felhom-controller-bootstrap.path'.
+[golden] baking the first-boot SSH host-key regeneration unit (F3) …
+Created symlink '/etc/systemd/system/multi-user.target.wants/felhom-regen-hostkeys.service' → '/etc/systemd/system/felhom-regen-hostkeys.service'.
+[golden] identity-clean + minimize …
+[golden] stop + archive …
+INFO: including mount point rootfs ('/') in backup
+INFO: including mount point mp0 ('/var/lib/felhom') in backup
+INFO: archive file size: 607MB
+INFO: Finished Backup of VM 9100 (00:00:29)
+[golden] DONE. golden archive volid: local:backup/vzdump-lxc-9100-2026_10_18-22_57_23.tar.zst (rootfs 32G + ONE data volume 24G @ /var/lib/felhom, all in the archive)
+[golden] publishing golden (637197198 bytes, sha256 3881de62b0986ccb…) → https://gitea.dooplex.hu/api/packages/admin/generic/felhom-golden/0.331.0/golden.tar.zst
+[golden]   pre-delete existing: HTTP 404 (404/204 expected)
+[golden]   upload OK (HTTP 201)
+GOLDEN_VERSION=0.331.0
+GOLDEN_SHA256=3881de62b0986ccbe5e55580e3f1bb9765d65b8d898f67c6339bac105244f84f
+[golden] Record in the hub operator UI (Configs → Day-0 artifacts): golden 0.331.0 / 3881de62b0986ccbe5e55580e3f1bb9765d65b8d898f67c6339bac105244f84f
+[golden] (the build guest 9100 is stopped; destroy it with: pct destroy 9100 --purge)
				`@@ -0,0 +1 @@`
				`Felhom — Doboz összekötése Felhom doboz összekötése Sikeres összekötés. A doboz kb. egy percen belül folytatja a telepítést. Ezt az oldalt bezárhatod — a beállítás a háttérben befejeződik, és a vezérlőpultod hamarosan elérhető lesz. Felhom.eu`
				`@@ -0,0 +1 @@`
				`{"ok":false,"error":"dashboard not yet claimed"}`