felhom.eu/documentation/audits/evidence-drill-new-household-2026-09-30/journal.md

Journal — DRILL new household, golden 0.282.0, 2026-09-29/30

Every observable in the order taken. Times are UTC unless marked. Hub log lines print CEST (UTC+2). Screens in screens/. Secrets (owner passphrase, pairing code, setup code, recovery code, generated and typed passwords, tunnel token, the self-bind link token) are held in 0600 files in the session scratchpad and never printed; every evidence file is secret-scanned before commit.

Baselines (re-verified 17:55 UTC)

repo	main	clean
felhom-controller	1cfb1244d635 (v0.282.0)	yes, == origin
felhom-agent	5c68c869b611 (v0.137.0)	yes
felhom.eu	8cadacb553ba (hub v0.125.0)	yes
app-catalog-felhom.eu	64461979250b	yes

Register: 350 rows (register-shape gate), highest id R-718. Disk: /mnt/5_hdd 37 %, / 54 %.

Phase 0.1 — golden 0.282.0

Bake 17:57:22 → 18:04:24 (markers, token-leak 0 with control 1, registry 404 → 206, teardown to virgin); anonymous download 200, 651 170 938 B, sha a3436b5f… == the bake's; vouched 18:49:43 (agent=0.137.0 golden=0.282.0 min_agent="0.131.0"); R-120 negative control refused golden 0.276.0 afterwards, manifest unchanged. Golden-currency gate: OK — the newest released controller has a golden. Record: documentation/tests/golden-0.282.0-2026-09-29/, commit 2bdda11. Evidence: golden/.

Phase 0.2 — the operator's part

The customer. The brief suggested a fresh drill customer. Operator ruling during the run: use the existing tester-1 (domain enkicsifelhom.hu, e-mail tester1@felhom.eu, tunnel token set, off-site shared 100 GB ON, DR tier ON). No customer was created; tester-1 will not be deleted or reset at teardown — only this drill's host record goes. The page read at 18:52: no host enrolled (the last box, tester-1-022354, reported 12 days ago and its host record is gone); floor 0.282.0.

The domain and TLS claim, checked. All four customer domains are their own Cloudflare zones (felhom.eu, enkisfelhom.hu, demo-felhom.eu NS = martha/tony.ns.cloudflare.com). The edge certificate served for felhom.enkisfelhom.hu names *.enkisfelhom.hu, enkisfelhom.hu only — one level. felhom.eu's own hostnames are DNS-only (Let's Encrypt at the origin, e.g. hub.felhom.eu → dooplex.hopto.org), so a proxied <app>.<sub>.felhom.eu would be served by the zone's universal certificate *.felhom.eu, which does not match it. The claim is consistent with what the edge serves; it was not measured end to end (that needs a DNS record on a zone; none was made).

The tunnel. Already on the record (R-505: fixed by the operator 2026-09-14, route *.enkicsifelhom.hu → https://traefik). No Cloudflare API token is in the operator's credentials file, so nothing was created or changed in Cloudflare by this run.

The owner passphrase. Read from the customer page's own reveal field into a 0600 file (5 words, 35 characters) — where the operator reads it to hand over.

The self-bind link — an operator step the guide says is not needed. The guide's „Az üzemeltető előtte" §1 says the hub sends the link by itself and no button is needed. For tester-1 the last link went out 2026-09-17 07:25 UTC (at a host delete) and expired 2026-09-24. Hub source (selfbind_mint.go, callers hosts.go:908, configs.go:850, customer_reset.go:162): the link is sent at customer creation, RESET, e-mail set on a customer with no box, and host delete — never when a box registers, and never again for a waiting customer whose link expired. The operator pressed „Send self-bind link" at 18:54:51 (operator-steps.txt); the mail arrived in the tester1@ mailbox at 18:54:52 (read through the Gmail connector — the mailbox this harness could not read on 2026-09-14).

Step 1 — download (18:53:16)

From demo-hp (the household PC): the link on felhom.eu/letoltes → felhom-installer-1.29.0-pve9.2-1.iso, 200, 1 705 324 544 B, 46 s; sha256 dceacae5… == the page == the .sha256 file == the release record documentation/tests/iso-release-1.29.0-2026-09-18/. The page says „legalább 4 GB-os USB kulcs" and names Balena Etcher; the volunteer guide says „legalább 2 GB" and Rufus in DD mode — two documents, two sizes.

Step 2 — install

VM 340 drill-nh0930-new-household on demo-hp: q35/OVMF (pre-enrolled-keys=0), 4 cores, 8 GB, cpu=host, scsi0 200 G · scsi1 50 G · scsi2 50 G qcow2 on nvme-scratch (dir at /mnt/hdd_1, the mount root), MAC bc:24:11:05:fa:37. local-lvm not used. Config: phase1/step2-vm-config.txt.

UTC	screen	what it said / what was done
18:55:40	power on → s01	Felhom logo, „Saját felhőd, saját szabályaid"; entries „Felhom telepítés / Install Felhom" and „Felhom telepítés (szöveges mód) / text"; „Indítás 13 másodperc múlva..."
18:56:04	s02	H4: the text entry chosen (key-drivable)
18:56:5x	s03	English Proxmox EULA → I agree
	s04	„Target harddisk: /dev/sda (QEMU HARDDISK) (200.00 GiB)" pre-selected, with three disks present — the guide says „A telepítő soha nem választ helyetted"
	s05	Hungary · Europe/Budapest · Hungarian — kept as the guide says (H2 of 2026-09-14 removed: the keystrokes are sent as Hungarian-layout scancodes, @ as AltGr+V)
	s06/s07	root password (16 characters, generated, 0600) twice; mail@example.invalid replaced with tester1@felhom.eu
	s10–s13	Hostname pve.example.invalid replaced with felhom.enkicsifelhom.hu (the guide's felhom.<a-te-domained>); IP 192.168.0.107/24 (DHCP, frozen), GW 192.168.0.1, DNS 192.168.0.250 left
	s14	Summary as typed. Focus rests on „Previous", not „Install" — Enter would go back
	s15	H3: auto-reboot unticked (as 2026-09-14)
19:03:14	s16	Install pressed
≤19:10:41	s18	„Success — Installation finished - reboot now?" — ≤ 7 m 27 s after Install; disk 4.0 G
19:10:59	first boot	H3: qm stop, --delete ide2, --boot order=scsi0 in its own qm set, qm start

Step 3 — the first screen and the bind (the volunteer's own link)

19:11:30 — the hub logs appliance registered: new unclaimed box, 31 s after power-on. (A harness search for the MAC on the hub's appliances page matched nothing for 6 min — the page does not print it; the log line is the record.)

Console (s19, code redacted) — Hungarian block then English block, each: „Felhom — a doboz készen áll, és a párosításra vár. · Párosító kód: - · Nyisd meg az e-mailben kapott linket, és add meg ezt a kódot és a Tulajdonosi jelmondatodat (az 5 szót a Felhom üzemeltetőjétől kaptad). · Ez a képernyő magától frissül…". No Proxmox admin-page line (R-496 holds).

The mail „[Felhom] Kösd össze a Felhom dobozodat" (18:54:52): link https://hub.felhom.eu/bind/<token> (7 days), two inputs, 5 tries. It says „Elkészült a Felhom dobozod" — it was sent 16 min before the box existed (R-719's press).

The bind page (hub.felhom.eu/bind/<token>, 200): „Kösd össze a most telepített Felhom dobozodat a fiókoddal…" · Párosító kód · Tulajdonosi jelmondat „…amelyet a beállításkor kaptál" (R-725).

UTC	act	result (phase1/A2-bind-typo.txt, phase1/step3-bind.txt)
19:19:03	A2 part 1: pairing code with its last character changed, right passphrase	200, „A megadott adatok nem megfelelőek. Ellenőrizd a párosító kódot és a tulajdonosi jelmondatot, majd próbáld újra." Hub: self-bind attempt 1/5 failed
19:19:13	the right code + passphrase	200 „Sikeres összekötés. A doboz kb. egy percen belül folytatja a telepítést…" Hub: self-bind SUCCESS: appliance 35 bound to customer tester-1 by customer self-service

The self-bind page is proven through a real mailed link for the first time (H1 of 2026-09-14 is gone: the Gmail connector reads the tester1@ catch-all).

Hub after the bind (CEST): credentials delivered 21:19:31 · host enrolled tester-1-693e79 21:20:07 · reenroll code (gen 7) mailed 21:20:08 · off-site shared credentials re-issued (sub-account 311327) 21:20:18 · break-glass vaulted 21:20:19 · manifest served agent=0.137.0 golden=0.282.0 21:20:20 · WireGuard peer 10.77.0.5/32 on ep0 21:20:37 · PBS-DR re-issued automatically (F-14 path: the previous host was removed through the escrow-ack flow on 2026-09-17), provisioned gen 2, 21:20:38 · controller_started (0.282.0) 21:22:04 · floor 0.282.0 served. Console after the bind (s20): „Felhom — a doboz össze van kötve. V · A beállítás magától folytatódik…" — R-214 holds closed (a stray „V" glyph → R-725).

Step 4 — "ready", and the version

	vouched	landed
agent	0.137.0	0.137.0
controller	golden 0.282.0	0.282.0 from the golden — no self-update

Power-on 19:10:59 → registered 31 s; bind 19:19:13 → controller 2 m 51 s. Infra: traefik:v3.6.7, cloudflared:2026.6.0, filebrowser:1.3.3-stable.

Step 5 — the dashboard, through the public address

The mail „[Felhom] Új beállító kód — újratelepült a szervered" (19:20:08): „A Felhom szervered újratelepült, ezért a vezérlőpultod belépését újra be kell állítani. A korábbi jelszavad már nem érvényes. · Beállító kód: *** · 72 óráig · https://felhom.enkicsifelhom.hu". A customer with an earlier box gets the reinstall wording, not the guide's „Elindult a Felhom szervered" (R-722).

felhom.enkicsifelhom.hu resolved publicly to Cloudflare; through the tunnel GET / → 302 /claim → 200 at 19:22:56, 52 s after the controller started. No intervention (2026-09-14's I1 is gone; R-505's box-side hop proven → closed). Claim page: „A szerver beállítása · Tester 1 · Add meg az e-mailben kapott beállító kódot…". 19:23:09 a harness slip (two form tokens joined → „Érvénytelen űrlap — töltsd újra az oldalt.", no code judged); 19:23:31 claimed → 302 /. Launcher: Filebrowser only; menu includes an English „Debug". Power-on → claimed dashboard: 27 m 51 s (install 7 m 27 s of it; box first boot → claimed 12 m 32 s, of which the bind waited on the harness ~7 min).

Step 6 — three apps (phase1/step6-deploy.txt)

app	kind	POST → running	the stranger (no session, public address) before the setup
bookstack	random first password (Generálás, 24 chars)	202 → 65 s	login page only
audiobookshelf	—	400 „a(z) "Hangoskönyv tár útvonal" (HDD_PATH) mező kitöltése kötelező" — needs a data drive; refused before anything was written	—
actualbudget	gated, status probe	202 → 23 s	API 401 {"error":"this app is waiting for its first setup"}; a browser → the gate page „ActualBudget — Beállításra vár · Ez az alkalmazás még beállításra vár. Jelentkezz be a Felhom vezérlőpultba. · Bejelentkezés"; POST /account/bootstrap 401
vikunja	gated, no probe, sign-up lock (block + own switch)	202 → 12 s	POST /api/v1/register 401 (gate)

• BookStack first password: the settings page's 👁 (/stacks/bookstack/auto-field/reveal) returns the value typed at install (equal: YES); admin@admin.com / password → back to /login (refused); the shown password → /. The app page's first steps: „Jelentkezz be: admin@admin.com és a Beállítások oldalon látható első jelszó" — and still wiki.DOMAIN (R-498).
• actualbudget: „Kész, beállítottam" before the setup → 409 „Az alkalmazás szerint még nincs kész az első beállítás. Hozd létre a fiókodat, aztán próbáld újra." The household (dashboard session) → 3 redirects → the app, felhom_gate cookie; POST /account/bootstrap ok; the gate opened by itself ~12 s later (probe). Stranger after: already-bootstrapped 400, wrong password invalid-password 400.
• vikunja: the household registered csalad through the gate, then pressed „Kész, beállítottam" (card: „Ha kész, nyomd meg ezt a gombot. Addig a telefonos alkalmazások és a család többi tagja nem éri el.") → 200 opened. Stranger register → 403 sign-up is closed on this app; its admin adds new accounts; the running container carries VIKUNJA_SERVICE_ENABLEREGISTRATION=false; app.yaml after_setup ok: true. Front door 404 for ~2 s while vikunja restarted for its switch (R-718).

Step 5b — the recovery code (guide §7)

/backup/escrow at 19:30: „A doboz még készül — a távoli mentés kulcsát pár perc múlva tudod létrehozni…" (preflight: DR tier not applied on this host). The descriptor reached the agent with its next 15-minute host report: ready 19:35:44 (enrolment + 15 m 37 s; claim + 12 m). Banner then: „A távoli mentés szünetel, amíg nem hozod létre a helyreállítási kódot." Ceremony (phase1/step5-recovery-code.txt): start with the dashboard password → done in 5 s; claim → 200, 10 words, English (known, per language); a second claim → 410. Wizard text is formal „Írja fel…" (R-725). /backups/remote after: „A helyreállítási kód letétbe helyezve."

Step 7 — using the apps (phase1/step7-use.txt)

• BookStack: book „Családi receptek NH0930", page „Töltött káposzta" with NH0930-OLDAL … árvíztűrő tükörfúrógép, attachment 262 144 B → read back: sentence 2 (control 0), sha256 equal YES.
• Vikunja: project „Háztartás NH0930", three Hungarian tasks, 64 KiB attachment → read back 3 tasks, sha equal YES.
• The family member through the 15-minute window: before, stranger register 403; „Regisztráció megnyitása 15 percre" (card: „Ehhez az alkalmazás újraindul, és a 15 perc végén még egyszer.") → open_until 19:46:37Z; own switch open after 4 s; „nagymama" registered 200. After (19:48:38): stranger 403, registration_enabled:false, container ENABLEREGISTRATION=false, nagymama logs in.

Step 8 — backups (phase1/step8-*.txt)

/backups verbatim: „Csak egy másolat készül (nincs második meghajtó)…" · „A rendszermentés jelenleg ugyanazon a lemezen van…" · Utolsó teljes mentés 2026-09-29 21:27 (4 perce) 911.2 MB Helyi tároló (local) Naprakész (ran unaided after the claim) · „Következő mentés — 0 órája" (R-724) · Távoli rendszermentés „nincs beállítva" (the tier was not applied yet). /backups/apps: each app „1. mentés Auto helyi · Nincs 2. (off-drive) másolat · 3. mentés Kikapcsolva — Ez az alkalmazás nincs kijelölve távoli mentésre" (R-720). „Mentés most" → 19 s, all three apps a restore point at the true time; „Utolsó adatbázis mentés: 2026-09-29 21:33 (most)"; bookstack MariaDB 58.3 KB 41 tábla OK. No customer alarm. The household pressed „Távoli mentés bekapcsolása" for BookStack only (19:36:39). Operator mails on day one: node_recovered and backup_tier_skipped (R-723).

Step 9 — versions

All three „Naprakész"; template_images == catalog_images (bookstack 26.05.5 + mariadb 12.3, actual-server 26.9.0, vikunja 2.6.0); no newer tested step offered — nothing to press.

Step 10 — remove keeping the data, reinstall (phase1/step10-*)

• 19:37:16 „Leállítás" on actualbudget during the first off-site whole-guest backup's quiesce (started 19:37:01): recorded desired state … stopped, then the backup's early resume restarted it the same second → R-721. Stop again → stopped; „Eltávolítás" refused „Az alkalmazáson mentés vagy visszaállítás fut. Várd meg…" until 19:41:06 (job done 19:38:55; hold released ~2 min later). Removed: volume deleted (the dialog says it always is), backup kept (112 K).
• No „A megőrzött adataimat használom / Tiszta lappal kezdem" choice exists for this app — its data lives in a Docker volume; that choice is for data kept on a drive (this box has none set up). The reinstall page said instead: „Ennek az alkalmazásnak van korábbi mentése, ezért az alábbi mezőket a saját mentése alapján töltöttük ki…".
• Reinstall → gated again, and empty (bootstrapped:false) — correct for an empty app.
• Restore from the kept point (19:33:04) → „1 adatkötet visszaállítva" in 9.5 s; the household's OLD password logs in; the gate opened by itself 10 s later (setup gate OPENED by probe). What the household sees: an empty gated app until it restores, then its data and an open app. It does not stay gated over its own data.

Step 11 — restore BookStack (phase1/step11-restore.txt)

Page deleted through BookStack (page and attachment 404) → restore → „2 adatkötet és az adatbázis visszaállítva" in 26 s → the page's shown password logs in; sentence 2 (control 0), Hungarian 2, attachment sha equal YES; same images (26.05.5 / 12.3).

Step 12 — remove with „delete my data too" (uptime-kuma, phase1/step12-remove-delete.txt)

Stop → remove {remove_hdd_data:true, remove_backups:true} → volumes_removed [uptime-kuma_uptime_kuma_data], hdd_note „Az alkalmazás nem tárolt saját adatot külső meghajtón…", backup removed; after: volumes 0, containers 0, front door 404, restore points [], „Megőrzött adatok: Nincs megőrzött adat". The gate file stayed ~4 min and was then removed by the loop (seen gone at 19:50) — not a finding.

Step 13 — status pages (phase1/step13-status-pages.txt)

R-724 (schedule disagreement, raw timestamp, LAN „nem állapítható meg", „0 órája", R-500 UTC). The monitoring page's „A gazdagép metrikái jelenleg nem elérhetők" is script-toggled — not evidence (as 2026-09-14).

Accidents

• A1 power cut (phase1/A1-power-cut.txt): qm stop 19:50:46, start 19:51:47 (60 s dark) → SSH +21 s, dashboard through the tunnel +123 s, apps Up +124 s; same eight images; BookStack data sha equal; actualbudget's gate stays open; vikunja stranger 403 and switch off; hub: only controller_started. No alarm. Dashboard session did not survive (401) — one re-login.
• A2 typos: bind page (above) and the setup code (phase1/A2-setup-code-typo.txt): the spent code → „Hibás vagy lejárt kód" (one-shot: yes); „Új beállító kód kérése" → mail in < 2 s „[Felhom] Beállító kód a jelszavad visszaállításához"; new code with one letter changed → „Hibás vagy lejárt kód"; right code → 302; old password refused, new accepted.
• A3 phone (phase1/A3-phone.txt, uptime-kuma freshly gated): Android Chrome UA, no session → the gate page (Hungarian, viewport meta present) → „Bejelentkezés" → the dashboard login with next → back into Uptime Kuma, gate cookie set (4 redirects). Understandable. A native app's API call gets English JSON (R-725). Two harness slips (missing Origin; -X POST kept across a redirect) — both 403 „CSRF token missing or invalid", both the harness.

Evidence off the machine, end of phase 1 (19:49)

box-logs-phase1/ (agent journal 3 356 lines, felhom units 3 627, controller 882, box state). Secret scan over 47 files: 0 hits, control 1. Commit 1ec1819.