diff --git a/CLAUDE.md b/CLAUDE.md index d0e795d..74a6886 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -222,6 +222,22 @@ GW je VLAN = `.1` (crs326-core L3) · Mgmt VLAN99: core `.99.1`, branch `.99.2`, an derselben MariaDB, und die Annahme „Vaultwarden nutzt SQLite" war schlicht falsch; (c) **ein toter Resolver ist selten allein** — der Sweep über alle LXCs fand **fünf** Container mit `10.40.41.254`. Sweep: `for c in $(pct list|awk 'NR>1{print $1}'); do pct exec $c -- grep ^nameserver /etc/resolv.conf; done` +- 🔌 **`networking.service` failed bei funktionierendem Netz = tote `auto`-Stanzas in + `/etc/network/interfaces`** (Ursache gefunden + behoben 2026-09-01). In vier LXCs standen dort noch + Einträge aus dem **alten VLAN1-Schema** (`eth0` → `10.40.41.x`) und aus früheren Versuchen + (`veth16`, `veth24`, Tippfehler `eth01`) — auf Interfaces, die es im Container gar nicht gibt. + `ifup -a` scheitert daran, das echte `veth20` kommt trotzdem hoch. **Fix:** nur die Stanzas + entfernen, deren Interface in `ip -br link` fehlt (`lo` und die echten behalten), Backup daneben. + 🔴 **Abnahme ist ein echter Reboot, nicht `systemctl is-active`** — der Servicestatus sagt nichts + darüber, ob beim nächsten Start etwas hochkommt. +- 🧪 **Ein Messwerkzeug, das etwas anderes beantwortet als die Frage, kostet mehr Zeit als der Fehler** + (zweimal in einer Nacht, 2026-09-01). (a) **`nc -z` lieferte falsch-negative** „Port zu" für neun + Dienste gleichzeitig — inklusive des SSH-Ports, über den die Session gerade arbeitete; `curl` bekam + von demselben Host **HTTP 200 in 24 ms**. **Bei „alles gleichzeitig kaputt" zuerst das eigene + Werkzeug verdächtigen**, dann das Netz: ein Python-Socket oder `curl` entscheidet in Sekunden. + (b) **Ein Firewall-Zähler taugt nicht als Wegbeweis**, wenn der Client die Verbindung offenhält + (`cloudflared`): er zählt nur NEUE Verbindungen und steht still, obwohl alles läuft — richtig ist + die **Verbindungstabelle** (`/ip firewall connection`). - 🔌 **`networking.service` kann in einem LXC dauerhaft `failed` sein, ohne dass das Netz fehlt** — und dann startet alles mit `After=network-online.target` nach einem Reboot **nicht** (Fund 2026-09-01: `101`, `102`, `106`, `107`; **influxdb2 kam nach dem Neustart nicht hoch**, diff --git a/docs/handoff-20260901-tp16.3-paragraph5-flip-durch.md b/docs/handoff-20260901-tp16.3-paragraph5-flip-durch.md index 89d094f..834db83 100644 --- a/docs/handoff-20260901-tp16.3-paragraph5-flip-durch.md +++ b/docs/handoff-20260901-tp16.3-paragraph5-flip-durch.md @@ -49,15 +49,24 @@ ohne Passwort verweigert) — das ist der nächste konkrete Schritt. --- -## 3. 🔴 Latenter Fund: vier Container überleben keinen Reboot sauber +## 3. ✅ Latenter Fund — gefunden UND behoben: vier Container überlebten keinen Reboot sauber `networking.service` und `ifupdown-wait-online.service` sind in **`101`, `102`, `106`, `107`** fehlgeschlagen. Folge: alles mit `After=network-online.target` startet nach einem Reboot **nicht** — **influxdb2 kam nicht hoch**, Unit `enabled`, **kein Startversuch im Journal**. Von Hand sofort ok. -🔑 **Nicht von dieser Session verursacht:** `101` wurde nie angefasst und zeigt dieselben Units. -Die Container liefen nur 13+ Tage ohne Neustart. **Diese vier sind einen Reboot davon entfernt, -still einen Dienst zu verlieren.** +🔑 **Nicht von dieser Session verursacht:** `101` wurde vor dem Fix nie angefasst und zeigte dieselben +Units. Die Container liefen nur 13+ Tage ohne Neustart, deshalb war es unsichtbar. + +✅ **Behoben 2026-09-01.** **Ursache — dieselbe Altlast wie beim Resolver:** tote `auto`-Stanzas in +`/etc/network/interfaces` aus dem **alten VLAN1-Schema** (`eth0` → `10.40.41.x`) und aus früheren +Versuchen (`veth16`, `veth24`, Tippfehler `eth01`), alle auf **nicht existierende** Interfaces. +`ifup -a` scheiterte daran, während `veth20` sauber hochkam. Entfernt wurden ausschliesslich Stanzas, +deren Interface in `ip -br link` fehlt; Backup je Container `/etc/network/interfaces.bak-20260901`. +🔴 **Abnahme war ein echter Reboot, nicht der Servicestatus:** `106` neu gestartet ⇒ **influxdb kam +nach 5 s von selbst hoch**, `networking active`, null fehlgeschlagene Units. +Endstand: **alle 13 LXCs auf `dns=10.40.20.1`, `networking` überall sauber.** Rest ohne Netzbezug: +`run-rpc_pipefs.mount` (101, 150), `proxmox-regenerate-snakeoil.service` (108). --- @@ -89,8 +98,9 @@ alte §5.3-Punkt „Caddy sieht den Request" konnte nie funktionieren. 🚫 `terpene-cloudflared` (LXC 400) und `fm.emsenhuber.net` bleiben. **Namen lesen, nicht Zeilen zählen.** 2. **TP39** (angelegt 2026-09-01, User-Okay) fasst die zwei Restpunkte aus §2 und §3 zusammen: `skip-name-resolve` auf der MariaDB (vorher `mysql.user` gegen Hostname-Grants prüfen, DB-Zugang - fehlt) und das kaputte `networking.service` in `101`/`102`/`106`/`107`. Dazu der Resolver-Sweep - als **wiederkehrende** Kontrolle, auch über die NAS-Container. + fehlt). **Punkt 2 (`networking.service`) ist am 2026-09-01 bereits erledigt** — offen bleiben + `skip-name-resolve` und der Resolver-Sweep als **wiederkehrende** Kontrolle, auch über die + NAS-Container. 3. **TP30:** die zwei Nautobot-Tokens rotieren (vom User vertagt, weiterhin offen). 4. **TP14.4:** ohne Service-Token für die Wildcard-App ist `n8n` von außen nicht bis zum Origin prüfbar. 5. **Caddy-Access-Log** (TP31/TP34): der öffentliche Reverse Proxy protokolliert keine Requests. diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index b85d925..61810dd 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -41,6 +41,12 @@ liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur d 🚫 **§6 (Abbau) bewusst NICHT** — die drei Alttunnel bleiben als Rückfallebene (healthy/8). 🔴 **Christoph hat den Flip ausdrücklich vorgezogen freigegeben** („aus Gründen"); die 7-Tage-Regel betrifft ohnehin §6, nicht den Flip. +- 🆕 **TP39: `networking.service` in vier Containern repariert (2026-09-01).** Ursache war dieselbe + Altlast wie beim Resolver: tote `auto`-Stanzas in `/etc/network/interfaces` aus dem VLAN1-Schema + (`eth0` → `10.40.41.x`) und alten Versuchen — `ifup -a` scheiterte an Interfaces, die es nicht gibt, + während `veth20` lief. **Abnahme war ein echter Reboot:** influxdb kam danach **von selbst** hoch + (vorher gar kein Startversuch). Alle 13 LXCs stehen jetzt auf `dns=10.40.20.1`, `networking` überall + sauber. **Offen in TP39: nur noch `skip-name-resolve` und der wiederkehrende Sweep.** - 🆕 **TP39 angelegt (2026-09-01, User-Okay):** LXC-Hygiene auf pve — die zwei Restpunkte aus dem Wartungsfenster unten (`skip-name-resolve` auf der MariaDB, kaputtes `networking.service` in vier Containern) plus Resolver-Sweep als wiederkehrende Kontrolle. **Ein** TP, weil beides dieselbe Ecke @@ -419,7 +425,7 @@ nachmessen und dann entscheiden**. Blocker gibt es keine mehr. TP5 ist in der Na > | TP36 | 🔜 | SSoT via Nautobot für teilprojekte.md-Live-Daten + Datei-Aufteilung | — | > | TP37 | 🔜 | Nautobot als Netzwerkdoku: Hosts/Container/Dienste + CF-Connectoren (Okay 08-30) | — | > | TP38 | 🔜 | OOB-Mgmt: untagged-VLAN99-Port je Switch | — | -> | TP39 | 🔜 | LXC-Hygiene pve: Resolver-Altlasten, `networking.service`, DB-Reverse-Lookup (Okay 09-01) | — | +> | TP39 | ⏳ | LXC-Hygiene pve (Resolver ✅ + `networking.service` ✅ 09-01 — offen: `skip-name-resolve`, Sweep) | — | > | — | — | **34 archivierte TPs** in `teilprojekte-archiv.md` | — | ### TP5.1 — DNS-Visibility & Flow-Observability für Low-Trust-Geräte (Airfryer-Fall) ▸ vorgemerkt @@ -2707,13 +2713,21 @@ gemessen hat. Beim Beheben kam eine zweite, unabhängige Altlast zum Vorschein. Grants, die auf **Hostnamen** statt IPs lauten, brechen damit sofort und sperren im schlimmsten Fall alle drei Dienste aus. **Blocker: DB-Zugang** — `root@localhost` ohne Passwort wird verweigert, die Credentials sind noch nicht lokalisiert. -2. 🔴 **`networking.service` + `ifupdown-wait-online.service` reparieren** — in **`101 iob-master`, - `102 mqtt5`, `106 influxdb2`, `107 redis`** dauerhaft `failed`, bei vorhandenem Netz. - Folge: alles mit `After=network-online.target` startet nach einem Reboot **nicht**. - **Belegt:** `influxdb2` kam nach dem Neustart nicht hoch — Unit `enabled`, **kein einziger - Startversuch im Journal**; von Hand sofort lauffähig. - 🔑 **Nicht durch die Session verursacht:** `101` wurde nie angefasst und zeigt dasselbe Bild. - Die Container liefen nur 13+ Tage ohne Neustart, deshalb war es unsichtbar. +2. ✅ **ERLEDIGT 2026-09-01: `networking.service` + `ifupdown-wait-online.service` in `101`, `102`, + `106`, `107` repariert.** **Ursache — dieselbe Altlast wie beim Resolver:** in + `/etc/network/interfaces` standen noch `auto`-Stanzas aus dem **alten VLAN1-Schema** + (`eth0` → `10.40.41.x`) und aus früheren Versuchen (`veth16`, `veth24`, ein Tippfehler `eth01`) — + **alle auf Interfaces, die es im Container nicht gibt.** `ifup -a` scheiterte daran, während das + echte `veth20` sauber hochkam: „failed" bei funktionierendem Netz. + **Fix:** nur die toten Stanzas entfernt (Backup je Container: + `/etc/network/interfaces.bak-20260901`), `lo`/`veth20`/`veth20.2` unangetastet. + **Beweis ist ein echter Neustart, nicht der Servicestatus:** `106` neu gestartet ⇒ **influxdb kam + nach 5 s von selbst hoch**, `networking active`, **null** fehlgeschlagene Units. Genau der Fall, + der vorher scheiterte. + 🔑 **Nicht durch die Session verursacht:** `101` wurde vor dem Fix nie angefasst und zeigte dasselbe + Bild — die Container liefen nur 13+ Tage ohne Neustart, deshalb war es unsichtbar. + 🟡 **Rest, bewusst liegen gelassen:** `run-rpc_pipefs.mount` (101, 150) und + `proxmox-regenerate-snakeoil.service` (108) — vorbestehend, ohne Bezug zu Netz oder DNS. 3. 🟡 **Resolver-Sweep als wiederkehrende Kontrolle**, nicht als Einmalaktion — und über pve hinaus: die **NAS-Container** sind nach derselben Logik zu prüfen (der DSM-Fallstrick von 2026-07-10: „Allgemein"-DNS ≠ was `dockerd` liest, laufende Container frieren den Upstream beim Erstellen ein).