rehearsal 2026-10-20: B7 — box destroyed, reinstalled; the forgotten press is a dead end for the household (R-1203, P2)
@@ -0,0 +1,20 @@
|
||||
paperless: 47 documents; originals byte-identical to the manifest 47, not 0
|
||||
immich: 277 assets; originals byte-identical to the manifest 277, not 0
|
||||
nextcloud: manifest 3034 files; byte-identical 3030; missing 3; different 1; extra 4
|
||||
MISSING nextcloud/Csalad/nagy_fajl_1_5GB.bin
|
||||
MISSING nextcloud/Csalad/Kulonleges_nevek/Ödön születésnapja – fénykép lista.txt
|
||||
MISSING nextcloud/Csalad/Kulonleges_nevek/link_a_nagy_fajlra
|
||||
DIFFERS nextcloud/Csalad/Kulonleges_nevek/Ödön születésnapja – fénykép lista.txt
|
||||
EXTRA nextcloud/Csalad/feltoltes_4.jpg
|
||||
EXTRA nextcloud/Csalad/feltoltes_3.jpg
|
||||
EXTRA nextcloud/Csalad/feltoltes_1.jpg
|
||||
EXTRA nextcloud/Csalad/feltoltes_2.jpg
|
||||
mealie: recipes ['Csirkepörkölt', 'Gulyásleves']
|
||||
bookstack: pages ['Családi wiki 0. oldal', 'Családi wiki 1. oldal', 'Családi wiki 2. oldal', 'Családi wiki 3. oldal', 'Családi wiki 4. oldal'] | images 5
|
||||
radicale: PROPFIND 207 | events 2
|
||||
share Filmek: rc 0; 4 files
|
||||
Ödön születésnapja – fénykép lista.txt N 56 Tue Oct 20 17:21:31 2026
|
||||
Ödön születésnapja – fénykép lista.txt N 56 Tue Oct 20 17:21:31 2026
|
||||
Csaladi_film_2 (2026).mkv A 949649288 Tue Oct 20 15:26:40 2026
|
||||
Csaladi_film_1 (2026).mkv A 949649129 Tue Oct 20 15:26:29 2026
|
||||
vaultwarden: items, attachments: 50 2
|
||||
@@ -0,0 +1,3 @@
|
||||
200
|
||||
snapshots for nextcloud: 1
|
||||
2026-10-28T06:37:20Z helyi
|
||||
@@ -0,0 +1,14 @@
|
||||
# B7 step 2 — the box dies
|
||||
ide2: local:iso/rehearsal1020-felhom-installer-1.29.0-pve9.2-1.iso,media=cdrom,size=1665356K
|
||||
name: rehearsal1020-box1
|
||||
scsi0: nvme-scratch:9320/vm-9320-disk-0.raw,size=256G
|
||||
scsi3: nvme-scratch:9320/vm-9320-disk-1.raw,size=200G
|
||||
scsihw: virtio-scsi-single
|
||||
unused0: nvme-scratch:9320/vm-9320-disk-2.raw
|
||||
hard stop at 08:44:37
|
||||
destroy at 08:44:39
|
||||
purging VM 9320 from related configurations..
|
||||
rc=0
|
||||
0
|
||||
0
|
||||
table inet felhom_oob
|
||||
@@ -0,0 +1,6 @@
|
||||
Formatting '/mnt/hdd_1/images/9320/vm-9320-disk-0.raw', fmt=raw size=274877906944 preallocation=off
|
||||
scsi0: successfully created disk 'nvme-scratch:9320/vm-9320-disk-0.raw,size=256G'
|
||||
Formatting '/mnt/hdd_1/images/9320/vm-9320-disk-1.raw', fmt=raw size=214748364800 preallocation=off
|
||||
scsi1: successfully created disk 'nvme-scratch:9320/vm-9320-disk-1.raw,size=200G'
|
||||
created+started 08:44:55
|
||||
Install pressed 08:48:26
|
||||
@@ -0,0 +1,2 @@
|
||||
open 200 Felhom doboz összekötése Ez a hivatkozás már fel lett használva. A doboz összekötése megtörtént. Ha úgy gondolod, hogy ez tévedés, vedd fel a kapcsolatot az ügyfélszolgálattal. Ha ez a te linked volt, és a dobozod még nincs összekötve, új linket küldünk arra az e-mail címre, amelyet a Felhomnál megadtál. Új linket kérek Felhom.eu
|
||||
after press: Felhom doboz összekötése Kész. Ha ez egy valódi hivatkozás volt, és a dobozod még nincs összekötve, néhány percen belül új e-mailt kapsz a regisztrált címedre. Ha nem jön, szólj az ügyfélszolgálatnak. Felhom.eu
|
||||
@@ -86,3 +86,7 @@
|
||||
| 05:58–07:13 | B6 ★7 | DST live: the first 02:30 skipped, the second ran once (01:30:00Z box), PASS; side effects of the 4-day jump: a local whole-box archive and off-site snapshots dated 2026-10-25; W30 |
|
||||
| 07:15–07:58 | B6 ★8 | −2 y (OS raised it to 2026-04-13): „Hub nem elérhető" only, Paperless stopped silently → R-1202; +2 y: whole-box archive dated 2028; back to real time: ep0 WireGuard tunnel dead (handshake replay) → R-1201 (P2); R-1189 (a) half-live |
|
||||
| 07:57–08:45 | B6 ★10 + #15 | 3 days off (box clock 2026-10-28): ONE catch-up, clear household note; a restart mid-catch-up recovered (marker, drive gate, one new catch-up); 8 apps off-site; PASS |
|
||||
| 08:44:37 | B7 | the box dies: hard stop, `qm destroy 9320 --purge` (own VM, own disks) |
|
||||
| 08:44:55–08:53 | B7 | reinstall from the same public ISO, the guide as written; pairing screen after ~5 min. The pairing code was OCR'd into sec (two reads agreed) and blacked out in the screenshot |
|
||||
| ~08:54 | B7 | the forgotten press: the spent link → „Új linket kérek" → „Kész … néhány percen belül új e-mailt kapsz"; NO mail in 4 min (control: older mails found) → R-1203 (P2) |
|
||||
| 08:59 | B7 | the operator asked (in the terminal) to delete host Tester4-816e21 |
|
||||
|
||||
|
After Width: | Height: | Size: 402 B |
|
After Width: | Height: | Size: 155 KiB |
|
After Width: | Height: | Size: 129 KiB |
|
After Width: | Height: | Size: 133 KiB |
|
After Width: | Height: | Size: 148 KiB |
|
After Width: | Height: | Size: 131 KiB |
|
After Width: | Height: | Size: 11 KiB |
|
After Width: | Height: | Size: 79 KiB |
|
After Width: | Height: | Size: 62 KiB |
@@ -0,0 +1,22 @@
|
||||
#!/opt/pw/bin/python
|
||||
"""newlink.py OUTPREFIX — open the household's OLD (spent) bind link and press „Új linket kérek" (B7). Env BIND_TOKEN.
|
||||
Screenshots before and after; prints the visible page text. The token is never printed (the URL is masked)."""
|
||||
import os, re, sys
|
||||
from playwright.sync_api import sync_playwright
|
||||
out = sys.argv[1]
|
||||
with sync_playwright() as p:
|
||||
b = p.chromium.launch(executable_path="/usr/bin/chromium", args=["--no-sandbox"])
|
||||
ctx = b.new_context(locale="hu-HU", extra_http_headers={"Accept-Language": "hu-HU"}, timezone_id="Europe/Budapest",
|
||||
viewport={"width": 390, "height": 844}, device_scale_factor=2, is_mobile=True, has_touch=True)
|
||||
pg = ctx.new_page()
|
||||
r = pg.goto("https://hub.felhom.eu/bind/" + os.environ["BIND_TOKEN"], wait_until="networkidle")
|
||||
print("open", r.status if r else "-", re.sub(r"\s+", " ", pg.inner_text("body"))[:500])
|
||||
pg.screenshot(path=f"{out}-1-old-link-phone-hu.png", full_page=True)
|
||||
btn = pg.get_by_text("Új linket kérek", exact=False)
|
||||
if btn.count():
|
||||
btn.first.click(); pg.wait_for_load_state("networkidle")
|
||||
print("after press:", re.sub(r"\s+", " ", pg.inner_text("body"))[:700])
|
||||
pg.screenshot(path=f"{out}-2-after-press-phone-hu.png", full_page=True)
|
||||
else:
|
||||
print("no „Új linket kérek” button on the page")
|
||||
b.close()
|
||||
@@ -122,6 +122,7 @@ stopping line that lies.
|
||||
| **R-991** | Install & onboarding | P3 | **Nothing a buyer can read says which machines Felhom installs on, and a quarter of the forum beginners own only machines it cannot install on.** FOUND 2026-10-12 (forum research, `audits/forum-research-2026-10-12/FELHOM.md` §2). Searched `documentation/architecture/`, `website/` (`gyik`, `technologiak`, `letoltes`) and `scripts/felhom-host-install.sh`: no CPU-architecture, RAM, disk or network floor is written anywhere. The download page says only that the installer is built on Proxmox VE 9.2 — x86-64 only (inferred from Proxmox, not stated on the page). Of the 33 forum beginners who name what they own, 8 own only a Synology/QNAP/other NAS box, a router with a USB disk or a Raspberry Pi. The selfh.st survey reading reached the same gap independently (R-989, its recommendation 1). **Needs (operator):** the floor itself (RAM and disk minimum; whether thin clients and old laptops with 4–8 GB are accepted) — then one short section on the download page and in the FAQ. Not changed here: the research task forbade website edits. | **WAITING-ON-OPERATOR** — **2026-10-20: R-993 merged here** (one decision, D5): the proposal to approve is `audits/sizing-2026-10-13/SIZING.md` §5 — 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. R-993 also measured that the installer has no floor on the HOST (`autosize_guest_caps` limits only the guest), so whatever minimum is approved, nothing enforces it at install today (full text: `git show 5c487313:documentation/backlog/OPEN-ITEMS.md`). filed 2026-10-12 | the operator naming the floor | Operator: approve or change `SIZING.md` §5 (STATUS D5); then CC writes the section on `letoltes.html` and `gyik.html` (both languages) and files the install-time host floor as its own row if it is wanted. If nothing is done: a buyer with a Pi or a Synology downloads an ISO that cannot run | 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-1203** | Install & onboarding | P2 | **When a box dies and the household reinstalls before the operator deletes the old host, the household is promised a new link mail that never comes, and nothing tells it to ask Felhom.** Rehearsal 2026-10-20 B7 (`audits/rehearsal-2026-10-20/B7-died/`, screens `b7-install/b7-newlink-*`): the old box destroyed 08:44Z, the new one installed from the public ISO and waiting with a pairing code at 08:53Z; the household's spent bind link says „Ez a hivatkozás már fel lett használva … Új linket kérek"; pressed → „Kész. Ha … a dobozod még nincs összekötve, néhány percen belül új e-mailt kapsz". No mail came (mailbox read 4 min later, names only; control: older mails to the same address are found). The hub still counts the dead box as linked, so the self-service path is a dead end; the console keeps waiting. The guide's „delete the old host first" is an OPERATOR step the household cannot see. Related: R-1176 (what happens after the delete), D19. | **OPEN** | — | when the customer already has a host, the new-link page should say so in plain words („a régi dobozod még össze van kötve — írj az ügyfélszolgálatnak") and the operator should get a mail with the host name to delete | CC |
|
||||
|
||||
## Apps & catalog — 14 rows (P3 6, P4 8)
|
||||
|
||||
|
||||