From 83bcfaabd04555d6d1cb6e6046a89185ffa67540 Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Tue, 1 Sep 2026 00:29:13 +0200 Subject: [PATCH] TP39 angelegt: LXC-Hygiene auf pve (User-Okay 2026-09-01) Fasst die zwei Restpunkte aus dem Wartungsfenster der Nacht zusammen, statt sie auf zwei TPs zu verteilen -- beides betrifft dieselben pve-LXCs und wird in einem Fenster erledigt: 1. skip-name-resolve auf der MariaDB. Der Reverse-Lookup ist heute nur schnell (21-24 ms statt 10.010 ms), nicht abgeschafft. Vorher mysql.user lesen: Hostname-basierte Grants brechen sonst und sperren vw/HA/gitea aus. Blocker: DB-Credentials noch nicht lokalisiert (Bezug TP30). 2. networking.service + ifupdown-wait-online.service sind in 101/102/106/107 dauerhaft failed, bei vorhandenem Netz. Folge: alles mit After=network-online.target startet nach einem Reboot nicht -- belegt an influxdb2, das nach dem Neustart nicht hochkam (Unit enabled, kein Startversuch im Journal). 101 wurde nie angefasst und zeigt dasselbe, es ist also vorbestehend. Dazu der Resolver-Sweep als wiederkehrende Kontrolle statt Einmalaktion: derselbe Fehlertyp wurde 2026-07-10 (TP14.2a) an NAS und LXC 400 behoben, aber nie im Bestand gesucht -- deshalb lag er hier noch. Die NAS-Container gehoeren mit geprueft (DSM-Fallstrick: Interface-DNS != was dockerd liest). Quick-Index, TP-Abschnitt und Ist-Stand-Block mitgezogen; Handoff verlinkt. Co-Authored-By: Claude Opus 5 --- ...f-20260901-tp16.3-paragraph5-flip-durch.md | 6 +- docs/teilprojekte.md | 60 +++++++++++++++++++ 2 files changed, 64 insertions(+), 2 deletions(-) diff --git a/docs/handoff-20260901-tp16.3-paragraph5-flip-durch.md b/docs/handoff-20260901-tp16.3-paragraph5-flip-durch.md index 85b3eb2..8445b7d 100644 --- a/docs/handoff-20260901-tp16.3-paragraph5-flip-durch.md +++ b/docs/handoff-20260901-tp16.3-paragraph5-flip-durch.md @@ -87,8 +87,10 @@ alte §5.3-Punkt „Caddy sieht den Request" konnte nie funktionieren. 1. **§6 Abbau** — sechs Container + drei Alttunnel. Frühestens nach störungsfreiem Betrieb; Christoph hat den **Flip** vorgezogen freigegeben, **nicht** den Abbau. 🚫 `terpene-cloudflared` (LXC 400) und `fm.emsenhuber.net` bleiben. **Namen lesen, nicht Zeilen zählen.** -2. **`skip-name-resolve`** auf der MariaDB — vorher `mysql.user` gegen Hostname-Grants prüfen. -3. **`networking.service`** in `101`/`102`/`106`/`107` reparieren (Punkt 3). +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. 4. **TP30:** die zwei Nautobot-Tokens rotieren (vom User vertagt, weiterhin offen). 5. **TP14.4:** ohne Service-Token für die Wildcard-App ist `n8n` von außen nicht bis zum Origin prüfbar. 6. **Caddy-Access-Log** (TP31/TP34): der öffentliche Reverse Proxy protokolliert keine Requests. diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 9ac91b4..b85d925 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -41,6 +41,10 @@ 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 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 + betrifft und in einem Fenster erledigt wird. - ✅ **GELÖST 2026-09-01: der 10-Sekunden-Zoll auf `gitea`/`vw`/`hass` — es war Reverse-DNS auf einen toten Resolver.** MariaDB (LXC **302**, `10.40.20.23`) hatte `skip-name-resolve` **auskommentiert** und machte damit bei **jeder neuen Verbindung** einen Reverse-Lookup; ihr `/etc/resolv.conf` zeigte @@ -415,6 +419,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) | — | > | — | — | **34 archivierte TPs** in `teilprojekte-archiv.md` | — | ### TP5.1 — DNS-Visibility & Flow-Observability für Low-Trust-Geräte (Airfryer-Fall) ▸ vorgemerkt @@ -2676,6 +2681,61 @@ folgenden Absicherungen dazu, und die Entscheidung darüber in die Umsetzungs-Se --- +### TP39 — LXC-Hygiene auf pve: Resolver-Altlasten, `networking.service`, DB-Reverse-Lookup ▸ 🔜 **ANGELEGT 2026-09-01 (User-Okay erteilt)** + +**Auslöser:** ein 10-Sekunden-Hänger auf `gitea`, gefunden am Rand des TP16.3-§5-Flips. Er hatte mit +dem Flip nichts zu tun, war aber nur deshalb sichtbar, weil zum ersten Mal jemand systematisch +gemessen hat. Beim Beheben kam eine zweite, unabhängige Altlast zum Vorschein. Beide sind +**Hygiene an denselben pve-LXCs** und gehören in **ein** Wartungsfenster — deshalb ein TP, nicht zwei. + +#### Was am 2026-09-01 bereits erledigt ist (Ausgangslage, nicht Aufgabe) + +- **Ursache des Hängers:** MariaDB (LXC **302**, `10.40.20.23`) hatte `skip-name-resolve` + **auskommentiert** ⇒ Reverse-Lookup bei **jeder neuen Verbindung**; `/etc/resolv.conf` zeigte auf + den **toten** `10.40.41.254` (VLAN1-Altschema). **Gemessen: 10.010 ms je Lookup.** + Pool-Verbindungen waren schnell ⇒ das Symptom wirkte sporadisch. +- **Blast-Radius, per Verbindungstabelle belegt:** an dieser DB hängen **Vaultwarden (`.127`), + Home Assistant (`.105`) und gitea (`.157`)**. +- **Fix ausgerollt** (`pct set --nameserver 10.40.20.1` + Reboot) für **fünf** LXCs: + `302 mariadb`, `102 mqtt5`, `106 influxdb2`, `107 redis`, `150 iob-exposed`. + **Nachher: Lookup 21–24 ms, gitea 0 von 25 Proben langsam** (vorher ~10 % bei 10,1 s). + +#### Scope (was dieses TP noch zu tun hat) + +1. 🔴 **`skip-name-resolve` in der MariaDB aktivieren.** Der Lookup ist heute nur *schnell*, nicht + *abgeschafft* — die Ursache ist entschärft, nicht beseitigt. ⚠️ **Vorher `mysql.user` lesen:** + 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. +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). + Sweep über pve: `for c in $(pct list|awk 'NR>1{print $1}'); do pct exec $c -- grep ^nameserver /etc/resolv.conf; done` +4. 🟡 **Abnahme-Regel festschreiben:** vor jedem geplanten LXC-Neustart `systemctl --failed` lesen + und danach die **Ports gegen vorher** vergleichen — sonst verliert man still einen Dienst + (genau so wäre `influxdb2` durchgerutscht). + +#### Abhängigkeiten + +- Keine blockierenden. Punkt 1 braucht **DB-Credentials** (siehe **TP30**, Credential-Bestand). +- Punkt 2 ist unabhängig und kann zuerst. + +#### Abgrenzung + +- **Nicht** TP16.3: dort geht es um cloudflared/Tunnel: der DNS-Fund kam nur *dabei* ans Licht. +- **Nicht** TP14.2a: das war 2026-07-10 derselbe Fehlertyp an **anderen** Hosts (NAS + LXC 400) und + ist abgeschlossen. **Dass er hier erneut auftrat, ist genau die Begründung für Punkt 3:** + die Klasse wurde damals an den bekannten Stellen behoben, nie im Bestand gesucht. +- **Nicht** TP31/TP34 (Caddy) und nicht TP11 (Monitoring) — obwohl gilt: ein Monitoring, das + DB-Verbindungszeiten kennt, hätte diesen Fall Monate früher gezeigt. + ### TP37 — Nautobot als durchgehende Netzwerkdoku: Hosts/Container/Dienste, erster Anwendungsfall CF-Connectoren ▸ 🔜 ANGELEGT 2026-08-30 (User-Okay erteilt) > **Christophs Formulierung (2026-08-30):** *„können wir das setup mit den cf-connectoren dann auch in > nautobot abbilden. quasi eine durchgehende netzwerkdoku stück für stück. muss eh fast sein, da du auf