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 <noreply@anthropic.com>

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.
+2. **TP39** (angelegt 2026-09-01, User-Okay) fasst die zwei Restpunkte aus §2 und §3 zusammen:
-3. **`networking.service`** in `101`/`102`/`106`/`107` reparieren (Punkt 3).
+   `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.

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 <id> --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