From 3ea8d050d2f3397f59de4fb0f1ab4b14dc987f75 Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Tue, 1 Sep 2026 00:39:19 +0200 Subject: [PATCH] TP39: networking.service in vier LXCs repariert (Ursache = VLAN1-Altlast) 101 iob-master, 102 mqtt5, 106 influxdb2, 107 redis meldeten networking.service und ifupdown-wait-online.service dauerhaft als failed, bei funktionierendem Netz. Folge: alles mit After=network-online.target startet nach einem Reboot nicht -- influxdb2 kam gestern Nacht nicht hoch (Unit enabled, kein Startversuch im Journal). URSACHE, und es ist dieselbe Altlast wie beim toten Resolver: in /etc/network/interfaces standen noch auto-Stanzas aus dem alten VLAN1-Schema (eth0 -> 10.40.41.x, teils mit gateway 10.40.41.254) sowie aus frueheren Versuchen (veth16, veth24, ein Tippfehler eth01) -- alle auf Interfaces, die es im Container gar nicht gibt. ifup -a scheitert daran, waehrend das echte veth20 sauber hochkommt. Der VLAN-Umzug hat die Container umgehaengt, aber die alten Stanzas nie entfernt. FIX: nur Stanzas entfernt, deren Interface in ip -br link fehlt; lo, veth20 und veth20.2 unangetastet. Backup je Container: /etc/network/interfaces.bak-20260901. ABNAHME war ein echter Reboot, nicht systemctl is-active: 106 neu gestartet, influxdb kam nach 5 s VON SELBST hoch, networking active, null failed units. Endstand ueber alle 13 LXC: dns=10.40.20.1 durchgehend, networking ueberall sauber. Ohne Netzbezug bleiben run-rpc_pipefs.mount (101, 150) und proxmox-regenerate-snakeoil.service (108), beide vorbestehend. MESSFALLE, mit in CLAUDE.md aufgenommen: nc -z meldete waehrenddessen neun Dienste gleichzeitig als "Port zu" -- inklusive des SSH-Ports, ueber den diese Session gerade arbeitete, waehrend curl vom selben Host HTTP 200 in 24 ms bekam. Bei "alles gleichzeitig kaputt" zuerst das eigene Werkzeug verdaechtigen. Es waere um ein Haar die zweite falsche Ausfallmeldung dieser Nacht geworden. Co-Authored-By: Claude Opus 5 --- CLAUDE.md | 16 ++++++++++ ...f-20260901-tp16.3-paragraph5-flip-durch.md | 22 ++++++++++---- docs/teilprojekte.md | 30 ++++++++++++++----- 3 files changed, 54 insertions(+), 14 deletions(-) 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).