diff --git a/CLAUDE.md b/CLAUDE.md index 38920b4..6299668 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -132,6 +132,17 @@ GW je VLAN = `.1` (crs326-core L3) · Mgmt VLAN99: core `.99.1`, branch `.99.2`, - 🔴 **Zweite, unabhängige Ursache desselben Falls (08-25): die Sonos-App suchte gar nicht.** Nach der Relay-Reparatur lag weiter nichts an — der Mitschnitt auf der VLAN40-Leitung (`pct exec 108 -- tcpdump -i eth1 -n -s0 -A "udp and host "`) zeigte: **jedes** SSDP-Paket des MacBooks kam von **Chrome** (`ST: urn:dial-multiscreen-org:…dial:1`, `USER-AGENT: Chromium`), **kein einziges** von Sonos. Die App hatte Sockets offen (`*:1900`, `*:6969`, `TCP *:3400`) und redete mit der Cloud, legte aber nichts auf die Leitung. Ursache war das **Local-Network-Gate von macOS**: es stand auf **„an" und griff trotzdem nicht**. Fix = Schalter unter *Datenschutz & Sicherheit → Lokales Netzwerk* **aus, App beenden, wieder an, App starten** (hart: `sudo tccutil reset LocalNetwork com.sonos.macController2`). ⇒ **Merkregel: „die App sucht hunderte Male" ist erst dann ein Befund, wenn der Mitschnitt sagt, WER sucht.** Im Handoff vom Vormittag waren die gezählten 291 Suchen Chrome + eigene Proben; die Zahl hat drei Stunden in die falsche Richtung gezeigt. - 🖥️ **Das MacBook ist dual-homed in VLAN10:** `en5` = **10.40.10.183** (USB-Dock, Default-Route) und `en0` = **10.40.10.82** (WLAN). Die früher als „zweiter Mac" gelesene `.183` ist **dasselbe Gerät** — beim Messen immer beide Beine prüfen. +- 🏠 **Home Assistant: der `http:`-Block in `configuration.yaml` ist WIRKUNGSLOS** (Fund 2026-08-26, + TP31). HA hat die http-Config nach **`.storage/http`** migriert (`"yaml_migration_done": true`); + seither wird die YAML kommentarlos ignoriert — selbst ein ungueltiger Schluessel darin erzeugt + **keinen** Config-Fehler. 🔴 **Die Logzeile fuehrt aktiv in die Irre:** `Received X-Forwarded-For + header from an untrusted proxy ` faellt laut Quelltext nur bei **aktivem** + `use_x_forwarded_for` — man haelt die Option fuer wirksam und die Liste fuer falsch und editiert + die falsche Datei. Richtig ist der WS-Zweischritt **`http/config/configure`** (setzt `pending`, + startet HA neu) → binnen **5 Minuten** **`http/config/promote`**, sonst Auto-Revert auf `stable`. + Merkregel zur Eingrenzung: ein Testskript in `/python_scripts/` + `python_script.reload` — + taucht der Service auf, liest HA das Verzeichnis, und die Frage ist nicht mehr *welche Datei*, + sondern *warum ein gelesener Block nicht wirkt*. - 🐳 **Nautobot auf der DS923 braucht einen abgeschalteten Image-Healthcheck.** Der eingebackene Check ruft alle 10 s `nautobot-server health_check` = einen vollen Django-Start; unter Last dauert der >2 min, die Aufrufe **stapeln sich unbegrenzt** → Speicher alle → `fork()` mit ENOMEM → DSM räumt den ganzen Stack ab (am 2026-08-17 zweimal passiert, Load bis 73 bei 4 Kernen). Im Stack stehen deshalb `healthcheck: disable: true` auf worker+scheduler, `--concurrency=2` und `mem_limit`. **`cpus:` geht auf Synology nicht** (Kernel ohne CFS-Quota, der Stack-Deploy schlägt sonst fehl). - 📜 **~~Omada ES208G = Easy Managed~~ — gegenstandslos** (Gerät abgebaut 2026-07-23, Controller gelöscht). - **L3-Router = `crs326-core` (TP21.1 ✅ 2026-08-08, ersetzt ap1).** Bridge vlan-filtering=yes; VLAN-SVIs `.1` je VLAN mit DHCP (7 Server / 54 Leases); DNS über **DoH** zum CF-Gateway, `verify-doh-cert=yes` (TP23 Stufe 1 ✅ 2026-08-18). Die alte Notiz „core hat kein CA" war zu pessimistisch: es braucht kein Bundle, sondern **genau einen Root** (GTS Root R4, ~1 KB) — die Kette ist Leaf → GTS WE1 → R4. **Beide Firewall-Ketten enden seit 2026-08-18 mit `drop`** (TP5 E3/E4); `TP10-seal-lan` ist `disabled`, Mgmt-Input kommt nur noch aus VLAN10, von HA (`8728`), von Nautobot (`22`) und über `cf-mesh`. **ap1/ap2 sind NUR noch APs** — kein DHCP/DNS/NAT/Routing/WG dort. (Die frühere „TP4: ap1 ist L3-Router"-Zeile ist überholt.) diff --git a/docs/handoff-20260825-agh-dns-cutover.md b/docs/handoff-20260825-agh-dns-cutover.md index f8e0283..33b181a 100644 --- a/docs/handoff-20260825-agh-dns-cutover.md +++ b/docs/handoff-20260825-agh-dns-cutover.md @@ -23,16 +23,11 @@ Auflösung selbst das Kaputte ist. **Nicht ans Ende einer langen Sitzung legen** - ℹ️ `pve-mcp` 400 / `ha-mcp` 403 / `gitea-mcp` 404 sind **keine Proxy-Fehler** — dieselben Codes kommen direkt vom Origin. Nicht als Baustelle behandeln. - 🧹 Der Zertifikatsspeicher hält **17** Zertifikate bei 16 Sites: `grafana` ist verwaist (harmlos). -- 🟡 **`hass` liefert weiter 400 — ungelöst, gehört VOR die CNAME-Umstellung** (nicht vor diesen Schritt). - `http:`-Block steht in `/homeassistant/configuration.yaml` (`use_x_forwarded_for: true`, - `trusted_proxies: 10.40.20.0/24` + `.10` + `.167`), Sicherung `configuration.yaml.bak-20260825-tp31`. - **Die Änderung ist seit 23:18 drin, HA läuft aber noch mit dem Stand von 22:40 — der Neustart fehlt.** - ⚠️ Sowohl der Schreibzugriff als auch der Restart wurden zuletzt vom Auto-Mode-Klassifikator - blockiert; entweder freigeben oder selbst ausführen: - `ha core restart` bzw. `homeassistant.restart`, danach - `curl -o /dev/null -w "%{http_code}\n" --resolve hass.emsenhuber.net:443:10.40.20.40 https://hass.emsenhuber.net/` - - 🔎 **Der Logtext ist der Befund, nicht der Statuscode:** `Received X-Forwarded-For header from an - untrusted proxy 10.40.20.40` ≠ „not set-up for reverse proxies" ⇒ die Option greift, die Liste nicht. +- ✅ **`hass` liefert 200** (gelöst 2026-08-26). Ursache war **nicht** der fehlende YAML-Eintrag: + HA hat die http-Config nach **`.storage/http`** migriert, der `http:`-Block in `configuration.yaml` + ist seither **wirkungslos**. `10.40.20.40` ist über den WS-Zweischritt `http/config/configure` → + `http/config/promote` in die Trusted-Liste gekommen und als `stable` bestätigt. Details in TP31. + ⇒ **Damit ist die CNAME-Umstellung von `hass` nicht mehr blockiert.** - ✅ **Aufgeräumt** (TP31 Schritt 1): LXC `120/121/128/129/130(alt)/131` **und `104`** zerstört, 72/72 PBS-Snapshots weg. Die **14 Snapshots von `ct/104` stehen bewusst** (einzige Grafana-Kopie). - ✅ **Startreihenfolge auf pve repariert** (TP32): HA startet nach MariaDB, Docker, MQTT, z2m25. diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 5eb027c..077d83b 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -1490,24 +1490,30 @@ Dienst `active`+`enabled`, Probe von einem **zweiten Host** (pve, VLAN20) mit `grafana.emsenhuber.net` liegt noch da. Harmlos (Caddy erneuert es nicht mehr), beim Grafana-Wiederaufbau nach TP32 mit aufraeumen. -🔴 **`hass` liefert weiterhin 400 — und der Fix ist NICHT der erwartete Einzeiler.** -Der `http:`-Block ist eingetragen (`use_x_forwarded_for: true` + `trusted_proxies` mit -`10.40.20.40`/`.10`/`.167`, Sicherung `configuration.yaml.bak-20260825-tp31`), Config-Check `valid`, -**HA zweimal voll neu gestartet** — trotzdem antwortet es 400. -- 🔎 **Der Logtext ist der Befund:** `Received X-Forwarded-For header from an untrusted proxy - 10.40.20.40`. Das ist **nicht** die Meldung „not set-up for reverse proxies", die bei - abgeschaltetem `use_x_forwarded_for` kommt ⇒ **die Option greift, nur die Liste zieht nicht.** -- ⚠️ **Was als Beweis NICHT taugt:** die `atime` der `configuration.yaml`. Sie steht auf dem - Schreibzeitpunkt, aber unter **`relatime`** wird sie nur nachgezogen, wenn sie *aelter* als die - `mtime` ist — bei `atime == mtime` bleibt sie stehen. „Datei seit dem Schreiben nicht gelesen" - laesst sich daraus **nicht** ableiten. -- ⏭️ **Naechster Schritt (offen):** Block testweise auf `10.40.20.0/24` verbreitern und neu starten — - faellt der 400 dann weg, liegt es an der Listenauswertung; bleibt er, liest HA eine andere Datei - als die unter `/homeassistant/configuration.yaml`. **Gehoert vor die CNAME-Umstellung von `hass`.** - -🎯 **Kernabnahme: WAN trennen, dann alle Dienste per FQDN.** Das ist die Autarkie, um die es geht. -⚠️ **Preis, offen benannt:** mit Split-Horizon greift **Access innerhalb des Netzes nicht mehr**; dort -tragen TP5-Segmentierung und die App-eigene Auth. +✅ **`hass` liefert 200 — gelöst 2026-08-26, und die Ursache ist eine Falle für jeden Reverse Proxy.** +Der `http:`-Block in `configuration.yaml` war **wirkungslos**: Home Assistant hat die http-Konfiguration +nach **`.storage/http`** migriert (`"yaml_migration_done": true`, `created_at` 2026-08-05). Seither wird +der YAML-Block **ignoriert** — ohne Fehlermeldung. +- 🔎 **Warum das so schwer zu sehen war:** die Logzeile lautet `Received X-Forwarded-For header from an + untrusted proxy 10.40.20.40` und **nicht** „not set-up for reverse proxies". Laut Quelltext fällt die + erste nur bei **aktivem** `use_x_forwarded_for` — was zur Annahme führt, die Option greife und nur die + Liste sei falsch. Tatsächlich kam beides aus `.storage`: `use_x_forwarded_for: true` stand dort längst, + die Liste enthielt `.20.10`, `.20.126`, `.20.167` (die drei cloudflared-Origins) — nur Caddy fehlte. +- 🧪 **Was den Verdacht in die Irre führte, der Reihe nach ausgeschlossen:** Datei-Identität (ein + Testskript in `python_scripts/` tauchte sofort als Service auf ⇒ HA liest dieses Verzeichnis), + Blockposition (nach ganz oben verschoben — keine Änderung), Kommentare/Formatierung (minimaler Block — + keine Änderung), Prozesszeitpunkt (`.ha_run.lock` `start_ts` gegen die Datei-`mtime` gestellt) und + Schema-Validierung (ein absichtlich ungültiger Schlüssel im `http:`-Block erzeugte **keinen** + Config-Fehler — im Nachhinein der eigentliche Beweis). +- ✅ **Der vorgesehene Weg ist ein WS-Zweischritt mit Auto-Revert:** `http/config` lesen → + `http/config/configure` mit der **vollständigen** Config (setzt `pending` und **startet HA neu**) → + innerhalb von **5 Minuten** `http/config/promote`, sonst fällt HA automatisch auf `stable` zurück. + ⚠️ Der Promote ist knapp: HA braucht hier ~2 min bis zur Erreichbarkeit, und der WS-Weg über das + MCP-Add-on antwortet währenddessen mit 502. **Erst promoten, wenn die Wirkung gemessen ist** — genau + dafür ist das Fenster da. +- 🧹 In `configuration.yaml` steht jetzt ein Hinweis-Kommentar statt eines wirkungslosen Blocks. + 📌 **Offen, bewusst nicht heute:** `10.40.41.10/32` (die alte VLAN1-NAS) steht weiterhin in der + Trusted-Liste — Aufräumen kostet denselben Zweischritt inkl. Neustart. #### 🧭 Wo liegt die Source of Truth? — beantwortet 2026-08-26 > **User-Frage:** „schaffen wir es mit überschaubarem aufwand cf und caddy synchron zu halten? wo