diff --git a/documentation/backlog/OPEN-ITEMS.md b/documentation/backlog/OPEN-ITEMS.md index 2826a7a4..dce6c19c 100644 --- a/documentation/backlog/OPEN-ITEMS.md +++ b/documentation/backlog/OPEN-ITEMS.md @@ -708,7 +708,7 @@ class (an image `VOLUME` at an unmounted path) is still live — `immich-server` | **R-502** | **[P3-LOW] The bootstrap regression harness is run by NO gate and NO CI — and it had never exercised the pairing banner.** MEASURED 2026-09-14: `grep -rn bootstrap-modes scripts/*.py .gitea/workflows` → nothing; the harness is run by hand in `felhom-iso-assistant:trixie`. While adding the R-496 checks, its fake hub's `register` reply turned out to carry no `pairing_code`, so `print_pairing_banner` returned early in every run: the banner that a household reads first had no test at all until ISO v1.27.0. **Fix shape:** register the harness in `repo_gates.py` behind a container-available check that reports INCONCLUSIVE (never skip-as-pass) when docker is absent, with a decoy. | **READY — rank P3-LOW; owner: CC** | | **R-503** | **[P3-LOW] SPIKE (not built): an install-time disk rule for the public ISO — "exactly one internal disk → install; otherwise stop in Hungarian".** Offered to the operator 2026-09-14 and **not chosen**: the 2026-07-31 ruling (a person chooses the disk) stands. Recorded so a reversal starts from measurements, not from the offer. **What must be measured first:** (1) whether the Proxmox auto-installer's HTTP answer mode can serve a per-machine answer from posted system info without network being a precondition a volunteer can miss; (2) whether USB transport is reliably visible in sysfs (`/sys/block/*/device` path, `removable`) where udev properties were measured blind (SPIKE-universal-iso-1 §3.2); (3) whether any refusal can be shown in Hungarian without modifying the Proxmox installer squashfs. **Reverses two rulings if built — needs an operator word.** | **WAITING-ON-OPERATOR — rank P3-LOW; owner: operator (ruling), CC (spike)** | | **R-504** | **[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)** | -| **R-505** | **[P1-HIGH] A fresh box on customer `tester-1` connects its Cloudflare tunnel but receives NO routes, so the dashboard answers 503 — the doorstep walk's intervention I1, again.** MEASURED 2026-09-14 on VM 331 (ISO 1.27.0, bound 15:47:26Z): `cloudflared` in the guest registered four connections (bud01, vie06, vie05, bud01) and then logged `No ingress rules were defined in provided config (if any) nor from the cli, cloudflared will return 503 for all incoming HTTP requests`; it ran `tunnel run` with the token, the same start mode as demo-hp's guest, and received **0** `Updated to new configuration` events. From DooPlex through public DNS, 12 requests 16:00:49–16:01:46Z → **12 × 503**, and the box logged **exactly 12** "No ingress" warnings in the same window — every request reached this connector. The guest's own front door answers the name (302). **The operator reports the dashboard loads on a phone over mobile data**; that is not explained by these measurements (no Cloudflare access to list the tunnel's connectors). **Leading hypothesis, not established:** the tunnel's routes live somewhere this connector never receives — a locally-managed config on another connector, or routes defined for a different tunnel. **Why P1:** from a network that reaches this connector, a volunteer cannot open their dashboard. **What it needs:** the operator checks the `tester-1` tunnel in Cloudflare Zero Trust (connectors, and public hostnames), or rules which tunnel this record should carry. | **WAITING-ON-OPERATOR — rank P1-HIGH; owner: operator** | +| **R-505** | **[P1-HIGH] A fresh box on customer `tester-1` connects its Cloudflare tunnel but receives NO routes, so the dashboard answers 503 — the doorstep walk's intervention I1, again.** MEASURED 2026-09-14 on VM 331 (ISO 1.27.0, bound 15:47:26Z): `cloudflared` in the guest registered four connections (bud01, vie06, vie05, bud01) and then logged `No ingress rules were defined in provided config (if any) nor from the cli, cloudflared will return 503 for all incoming HTTP requests`; it ran `tunnel run` with the token, the same start mode as demo-hp's guest, and received **0** `Updated to new configuration` events. From DooPlex through public DNS, 12 requests 16:00:49–16:01:46Z → **12 × 503**, and the box logged **exactly 12** "No ingress" warnings in the same window — every request reached this connector. The guest's own front door answers the name (302). **The operator reports the dashboard loads on a phone over mobile data**; that is not explained by these measurements (no Cloudflare access to list the tunnel's connectors). **Leading hypothesis, not established:** the tunnel's routes live somewhere this connector never receives — a locally-managed config on another connector, or routes defined for a different tunnel. **Why P1:** from a network that reaches this connector, a volunteer cannot open their dashboard. **What it needs:** the operator checks the `tester-1` tunnel in Cloudflare Zero Trust (connectors, and public hostnames), or rules which tunnel this record should carry. **CAUSE CONFIRMED AND FIXED BY THE OPERATOR 2026-09-14 (evening), measured with no box:** a throwaway `cloudflared` on DooPlex with the `tester-1` token connected (4 connections) and at 17:12Z received NO configuration — `No ingress rules` per request, public link 503 — so the tunnel had no public hostnames; the box was not at fault. The operator then added one published application route, copied from a demo tunnel. Re-test 17:17Z: `Updated to new configuration … {"hostname":"*.enkicsifelhom.hu","service":"https://traefik"}, {"service":"http_status:404"}`; public requests to `felhom.` and `wiki.` hit ingress rule 0 and failed only on `lookup traefik … no such host` (502), as expected with no box. The earlier report that the phone loaded the dashboard is not reproduced by any measurement. **Remaining:** the box-side hop (cloudflared → traefik in the guest) is proven by the next drill. | **FIXED (operator) — box-side proof in the next drill; owner: CC** | | **R-506** | **[P3-LOW] `day0-install.md` A.1 says "the controller manages per-app hostnames itself via the tunnel" — it does not.** MEASURED 2026-09-14: no code under `felhom-controller/controller/internal` creates tunnel ingress, DNS records or tunnel configurations (`grep -i 'ingress\|cfd_tunnel\|/configurations\|dns_records'` → only comments saying cloudflared is deployed when a token exists; positive control: the geo-restriction CF API use IS found in `cmd/controller/main.go`). The controller's only Cloudflare act is geo-restriction; the tunnel runs `tunnel run` with the token, so its routes come from Cloudflare's remote config set by the operator. A reader following A.1 skips the one step that makes the dashboard reachable (R-505). **Fix shape:** A.1 names the public-hostname step and its service settings, copied from a working tunnel. | **READY — rank P3-LOW; owner: CC (doc), operator (the settings to copy)** | | **R-507** | **[P3-LOW] The proof-install harness cannot drive the graphical installer, so a release's graphical entry is proven only up to its password screen.** MEASURED 2026-09-14 on VM 332 (ISO 1.27.0): `qm sendkey 332 tab` did not move focus (both password copies landed in one field), `mouse_move 1237 772` + `mouse_button 1` did not move the cursor or press Next, while `alt-n` did advance a page. The TUI entry is fully drivable. The gate's "proof install on BOTH menu entries" was met for 1.26.1 (by a person) and not for 1.27.x. **Fix shape:** measure QEMU `input-send-event` with absolute coordinates, or a VNC client on DooPlex; until then a release's graphical proof is an operator click-through. | **READY — rank P3-LOW; owner: CC** | | **R-508** | **[P2-MEDIUM] Customer `tester-1` has no registered e-mail, so neither the self-bind link nor the setup code can reach a volunteer.** MEASURED 2026-09-14: the edit form's `email` value is empty; on bind the hub logged `[ERROR] [claim] claim code generated (gen 1) but customer tester-1 has NO registered email — deliver via resend after setting one`. A volunteer onboarded on this record would sit at „A szerver beállítása" with no code. **What it needs:** the operator sets the volunteer's address on the record before sending the guide (day-0 A.2). The hub's customer page could warn when a record with an unclaimed box has no e-mail — the log line exists, the page says nothing. | **WAITING-ON-OPERATOR — rank P2-MEDIUM; owner: operator (record), CC (page warning)** | diff --git a/documentation/runbooks/day0-install.md b/documentation/runbooks/day0-install.md index a68a86b3..53edb83d 100644 --- a/documentation/runbooks/day0-install.md +++ b/documentation/runbooks/day0-install.md @@ -45,8 +45,10 @@ Tunnels): 1. Create a tunnel named after the customer (e.g. ``). Connector type: Cloudflared. 2. Copy the **tunnel token** (the long base64 string from the `cloudflared service install ` command) — this goes into the hub customer form in A.2. -3. **Add the tunnel's public hostnames** — `felhom.` and `*.` — pointing at the guest's - Traefik, with the same service settings as a working customer's tunnel. **The controller does NOT +3. **Add the tunnel's published application route** (Zero Trust → Networks → Tunnels → the tunnel → + Published application routes): hostname **`*.`**, path `*`, service **`https://traefik`**, + catch-all `http_status:404`. The wildcard covers `felhom.` and every app subdomain. (Measured + 2026-09-14 on `tester-1`: this exact route arrives at a connector as `Updated to new configuration`.) **The controller does NOT create routes or DNS** (R-506, measured 2026-09-14: it only starts `cloudflared` with the token and uses the API token for geo rules). A tunnel with no public hostnames connects and answers **503** for everything — cloudflared logs `No ingress rules were defined` (R-505). Make sure the domain is on