TP19: VLAN1-Adressen abgeraeumt (pve .41.100, core .41.211), Prometheus bereinigt

pve: /etc/network/interfaces vmbr0 von inet static auf inet manual, Adresse
raus, angewendet per `ip addr del` ohne ifreload -a. Alle 9 Gaeste weiter
running, Storage aktiv, nur noch vmbr0.20 traegt eine IP.

core: 10.40.41.211 ueber Nautobot GC entfernt. Mgmt .99.1 + 10.40.10.1
intakt, Compliance 17/17 gruen — der letzte offene Drift ist damit weg.

Prometheus: der pauschale 41->20-Ersatz war eine Falle. Gemessen statt
angenommen — nur grafana und n8n liefern echte Metriken. gitea hat /metrics
nicht aktiviert, vaultwarden gibt 404, portainer /api/status liefert JSON
statt Prometheus-Format, node/alertmanager/qdrant sind exited, pihole ist
abgewaehlt. 8 Jobs + alerting-Block auskommentiert, 3 Ziele aktiv und up.

Zwei Korrekturen an eigenen Aussagen:
- Die tote Portainer-Umgebung odroid-m1 war NICHT die Ursache des
  HA-Hangs. Sie ist entfernt, das Symptom blieb. Echte Ursache laut
  HA-Debug-Log: `docker system df` auf ep14 kommt nicht zurueck.
- Auf der NAS ist prometheus.yml fuer den Login-User nicht schreibbar
  (65534:65534, Verzeichnis gehoert adm.christoph). Zwei `cat >`-Pushes
  sind still gescheitert. Schreiben nur per sudo tee + md5sum-Gegenprobe.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/teilprojekte.md

@@ -509,6 +509,13 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 - Abh.: **TP10** (WG-Multi-Site = Transport, Upload-BW-Constraint), **TP14** (Container-Hosts), **TP15** (Node-HW/USV), Muster von **TP16** (reziprokes Per-Host-HA). Kein Blocker für laufende TPs. SSoT dieser Session.
 
 ### TP19 — cudy-Teardown + VLAN1-Client-Retirement ▸ ⏳ WEIT FORTGESCHRITTEN (Live-Sweep 2026-07-16: VLAN1 faktisch schon fast leer) — `docs/tp19-vlan1-cudy-teardown-runbook.md`
+- ✅ **VLAN1-Adressen abgeräumt (2026-08-15)** — `docs/vlan1-rueckbau-howto-manuelle-schritte.md`:
+  - **pve `10.40.41.100` weg** (`/etc/network/interfaces`: `vmbr0` von `inet static` auf `inet manual`, Adresszeile raus; angewendet per `ip addr del` **ohne** `ifreload -a`, damit die Bridge nicht durchgetreten wird). Nachher nur noch `vmbr0.20`, keine `41.0/24`-Route, alle 9 Gäste weiter `running`, Storage aktiv. Backup `/root/interfaces.bak-tp19-20260815-183045`.
+  - **Core `10.40.41.211` weg** über Nautobot GC (`routeros/tp19-core-vlan1-address-remove.rsc`). Mgmt `.99.1` + `10.40.10.1` intakt. **Compliance 17/17 grün — der letzte offene Drift auf dem Core ist damit erledigt** (der TP22-Backlog-Punkt „`crs326-core 10.40.41.211`" entfällt).
+  - **HA zeigt auf `10.40.20.100`** (User), **ioBroker** korrigiert (User).
+  - **Prometheus bereinigt.** Der pauschale `41`→`20`-Ersatz war eine Falle: nur `grafana` (`.20.109`) und `n8n` (`.20.167:5678`) liefern echte Metriken. `gitea` hat `/metrics` gar nicht aktiviert, `vaultwarden` gibt 404, `portainer /api/status` liefert JSON statt Prometheus-Format, `node`/`alertmanager`/`qdrant` sind exited, `pihole` ist abgewählt → **8 Jobs + `alerting:`-Block auskommentiert**, 3 aktive Ziele, alle `up`.
+  - 🔴 **NAS-Falle:** `prometheus.yml` gehört `65534:65534`, das Verzeichnis `adm.christoph` → `cat > datei` scheitert still („Permission denied"), während ein `cp` daneben klappt. **Schreiben per `sudo tee` + `md5sum`-Gegenprobe**, nie der Shell-Erfolgsmeldung trauen.
+- ⏳ **OFFEN: HA-Portainer-Integration hängt — Ursache `docker system df` auf nas-bf.** Aus dem HA-Debug-Log: `PortainerTimeoutError … GET /api/endpoints/14/docker/system/df` → `ConfigEntryNotReady` → `setup_retry`. Gemessen: ep2 0,05 s · **ep14 kam nach 180 s nicht zurück** · ep20 0,33 s · ep21 0,98 s. Lokal auf der NAS gibt `docker system df` **die Tabelle aus und beendet sich dann nicht** (rc=124 nach 120 s) — bei harmlosen Mengen (25 Images/13 GB, 10 Volumes/79 MB), also **kein Größen-, sondern ein dockerd-Problem**. Container-Listing auf demselben Endpoint: 0,16 s. **Wahrscheinlicher Fix = Container Manager auf DSM neu starten**, stoppt aber alle NAS-Container → user-gated. ⚠️ Die zuerst genannte Ursache „tote Portainer-Umgebung `odroid-m1`" ist **widerlegt** (entfernt, Symptom blieb; alle übrigen Endpoints antworten in ≤0,16 s).
 - 🔍 **Konkrete Restliste aus dem TP5-Log-Lauf (2026-08-14) — VLAN1 ist nicht leer, es wird noch *aktiv adressiert*.** Der Log-Lauf zeigte, dass **76 % allen Inter-VLAN-Verkehrs** aus VLAN20 nach VLAN1 (`out:bridge`) geht, obwohl dort **nichts mehr antwortet** (alle Ziele im ARP `failed`/`incomplete`). Verursacher sind Konfigurationen, die nie nachgezogen wurden:
   - **`prometheus` (`10.40.20.151`, NAS)** scrapet 10 tote Ziele: `10.40.41.109:3000` · `.126:9443` · `.127:80` · `.147:5678` · `.149:3000` · `.152:3001` · `.153:9093` · `.154:9100` · `.159:6333` · `.23:80`.
   - **`10.40.20.105`** zieht auf `10.40.41.100:8006` = **pve unter seiner alten VLAN1-Adresse** (real `10.40.20.100`).

docs/vlan1-rueckbau-howto-manuelle-schritte.md

@@ -0,0 +1,169 @@
+# VLAN1-Rückbau — Howto für die manuellen Schritte
+
+> Stand 2026-08-15. Gegenstück zum Plan „VLAN1-Rückbau: `.41.211` (Core), `.41.100` (pve),
+> Prometheus-Ziele". Hier steht **nur, was du selbst machen musst** — was ich übernehmen kann,
+> steht unten unter „Was ich mache".
+
+---
+
+## Die eine Regel, die die Reihenfolge bestimmt
+
+`10.40.41.100` ist derzeit der **einzige lebende VLAN1-Host**, und Home Assistant erreicht pve
+heute genau darüber. Dieser Pfad existiert nur, weil der Core noch die Adresse `10.40.41.211`
+trägt und damit die Route zu `10.40.41.0/24` stellt.
+
+➡️ **Schritt 1 und 2 müssen fertig sein, bevor irgendjemand `.41.100` oder `.41.211` entfernt.**
+Sonst reißt die laufende pve-Anbindung ab.
+
+---
+
+## Schritt 1 — Home Assistant: pve-Integration auf `10.40.20.100`
+
+**Wo:** HA-Weboberfläche → Einstellungen → Geräte & Dienste → **Proxmox VE** (Kachel heißt heute
+`10.40.41.100`) → ⋮ → **Neu konfigurieren**. Host auf `10.40.20.100` ändern, Port `8006` bleibt.
+
+**Warum du und nicht ich:** die Integration hat *keinen* Options-Flow (`supports_options: false`),
+nur einen Reconfigure-Flow. Der fragt die Proxmox-Zugangsdaten erneut ab — und Passwörter oder
+API-Token gebe ich grundsätzlich nicht ein. Das ist der Teil, der bei dir bleiben muss.
+
+**Das Netz ist nachweislich nicht das Problem** (falls es wieder hakt, such nicht dort):
+
+- `pveproxy` lauscht auf `*:8006`, `pve-firewall` ist *disabled*, keine iptables-Regel,
+  kein `/etc/default/pveproxy`.
+- `https://10.40.20.100:8006` antwortet aus VLAN10 **und** VLAN20 mit HTTP 200 in ~0,06 s.
+- HA selbst redet längst problemlos mit VLAN20 und VLAN99: `mqtt` → `10.40.20.108`,
+  `influxdb` → `10.40.20.8`, alle vier `mikrotik`-Integrationen auf `.99.x` sind `loaded`.
+
+---
+
+## Schritt 2 — Portainer hängt: `docker system df` auf der NAS ⏳ OFFEN, deine Entscheidung
+
+> ⚠️ **Korrektur (2026-08-15):** meine erste Erklärung — die tote Umgebung `odroid-m1` — war
+> **falsch**. Du hast sie entfernt, die Integration hängt weiter. Alle verbliebenen Endpoints
+> antworten in 0,01–0,16 s. Die Vermutung ist damit widerlegt, nicht nur unbestätigt.
+
+**Die tatsächliche Ursache, aus dem HA-Debug-Log:**
+
+```
+pyportainer.exceptions.PortainerTimeoutError: Timeout error while accessing
+GET https://10.40.20.126:9443/api/endpoints/14/docker/system/df
+   -> UpdateFailed -> ConfigEntryNotReady -> setup_retry
+```
+
+Die HA-Integration ruft beim Setup `docker system df` für **jede** Umgebung auf. Gemessen:
+
+| Endpoint | `docker system df` |
+|---|---|
+| ep2 `pve` | 0,05 s |
+| **ep14 `nas-bf`** | 🔴 **kam nach 180 s nicht zurück** |
+| ep20 `macmini` | 0,33 s |
+| ep21 `nas-fm` | 0,98 s |
+
+Direkt auf der NAS gemessen (`sudo /usr/local/bin/docker system df`): der Befehl **gibt die Tabelle
+aus und beendet sich dann nicht** — Exit-Code 124 nach 120 s, obwohl die Daten längst da waren.
+Die Mengen sind harmlos (25 Images / 13 GB, 21 Container, 10 Volumes / 79 MB), es ist also **kein
+Größenproblem**, sondern ein hängender Aufruf im dockerd der Synology. Das Container-Listing auf
+demselben Endpoint dauert 0,16 s — nur `system df` klemmt.
+
+**Naheliegender Fix, aber deine Entscheidung:** Container Manager auf der DSM neu starten.
+Das setzt den dockerd zurück, **stoppt dabei aber alle NAS-Container** (Nautobot, gitea,
+vaultwarden, prometheus, grafana, pve-mcp, die cloudflared-Connectoren). Das ist nichts, was
+nebenbei passieren sollte — sag, wann es dir passt, dann begleite ich es.
+
+**Bis dahin:** die HA-Portainer-Integration bleibt auf `setup_retry`. Sie stört nichts anderes.
+Alternative ohne NAS-Neustart wäre, ep14 aus Portainer zu nehmen — das kostet aber die
+NAS-Verwaltung und ist der schlechtere Tausch.
+
+---
+
+## Schritt 3 — ioBroker: NAS-Ziel korrigieren
+
+**Wo:** ioBroker auf `10.40.20.107` (LXC 101 `iob-master`), in der betroffenen Adapter-Instanz.
+`10.40.41.10:8080` → **`10.40.20.10:8080`** (die NAS unter ihrer aktuellen Adresse).
+
+Das steckt in der Adapterkonfiguration, nicht in einer Datei, die ich von außen sicher ändern kann.
+
+---
+
+## Schritt 4 — Entscheidung: die 11 gestoppten VLAN1-LXCs
+
+Auf pve stehen 11 **gestoppte** Container mit VLAN1-Adressen und `gw=10.40.41.254` — das ist ap1s
+abgeschaltete Sekundär-IP, dieses Gateway existiert nicht mehr:
+
+| LXC | Name | alte IP |
+|---|---|---|
+| 103 | minarca | `.41.114` |
+| 104 | alpine-grafana | `.41.109` |
+| 109 | node-red | `.41.119` |
+| 115 | hms-mqtt-publisher | `.41.124` |
+| 120 | adguard-bf1 | `.41.116` |
+| 121 | adguard-bf2 | `.41.117` |
+| 128 | nginx-proxy-manager | `.41.123` |
+| 129 | caddy | `.41.118` |
+| 130 | pihole1 | `.41.16` |
+| 131 | pihole2 | `.41.131` |
+| 201 | openproject | `.41.120` |
+
+Solange sie stehen, stören sie nichts. **Wer einen davon startet, landet in einem VLAN ohne
+Gateway.** Je Container zu entscheiden: löschen, oder auf VLAN20 umziehen (`tag=20` + Adresse +
+`nameserver`). Nichts davon ist dringend — es soll nur nicht aus Versehen passieren.
+
+Zusätzlich tragen mehrere *laufende* VLAN20-Gäste noch `nameserver: 10.40.41.254` in der
+LXC-Config. Das greift erst beim nächsten Start neu, ist also eine stille Zeitbombe für später.
+
+---
+
+## Was ich gemacht habe ✅ (2026-08-15)
+
+1. **pve `10.40.41.100` entfernt.** `/etc/network/interfaces`: Adresszeile raus,
+   `iface vmbr0 inet static` → `inet manual`; Bridge-Parameter unangetastet. Angewendet per
+   `ip addr del` **ohne** `ifreload -a`. Backup `/root/interfaces.bak-tp19-20260815-183045`.
+   Nachher: nur noch `vmbr0.20` trägt eine IP, keine `41.0/24`-Route, **alle 9 Gäste weiter
+   `running`**, `pvesm status` alle aktiv, SSH-Sitzung überlebt.
+2. **Core `10.40.41.211` entfernt** über Nautobot GC (`routeros/tp19-core-vlan1-address-remove.rsc`),
+   Backup `core-pre-tp19-vlan1-addr-20260815.backup`. Nachher: keine Adresse auf `bridge`, keine
+   `.41`-Route, Mgmt über `.99.1` **und** `10.40.10.1` intakt.
+   **Compliance 17/17 grün** — der letzte offene Drift auf dem Core ist damit weg.
+3. **Prometheus bereinigt.** Der pauschale `41`→`20`-Ersatz hatte 6 Jobs auf Adressen gesetzt,
+   die es nicht gibt. Ist-Zustand gemessen statt angenommen — **nur 2 Jobs liefern echte Metriken**:
+
+   | Job | Befund | Ergebnis |
+   |---|---|---|
+   | `grafana` `10.40.20.109:3000` | 200, echte Metriken | ✅ aktiv |
+   | `n8n` `10.40.20.167:5678` | 200, echte Metriken | ✅ aktiv |
+   | `gitea` | `.20.157:3000/` gibt 200, aber `/metrics` ist in Gitea **nicht aktiviert** | stillgelegt |
+   | `vaultwarden` | `/metrics` → **404**, exportiert nativ keine Prometheus-Metriken | stillgelegt |
+   | `portainer` | `/api/status` → 200, liefert aber **JSON statt Prometheus-Format** | stillgelegt |
+   | `node`, `alertmanager`, `qdrant` | Container auf der NAS **exited** | stillgelegt |
+   | `pihole` | abgewählt (TP23 = AdGuard); `.20.23` ist ein fremder Dienst | stillgelegt |
+
+   Alle acht **auskommentiert mit Begründung im File**, dazu der `alerting:`-Block (sonst bliebe ein
+   leerer alertmanagers-Eintrag stehen, der Schärfe vortäuscht). Backup
+   `prometheus.yml.bak-20260815`. Nach Reload: **3 aktive Ziele, alle `up`**.
+
+   🔴 **Falle für das nächste Mal — die Datei ist nicht mit dem Login-User schreibbar.**
+   `prometheus.yml` gehört `65534:65534`; das *Verzeichnis* gehört `adm.christoph`. Ein
+   `cat > datei` scheitert an „Permission denied", während ein `cp` daneben klappt — was leicht den
+   Eindruck erweckt, der Schreibvorgang sei durchgegangen. **Schreiben nur per `sudo tee`, und
+   danach per `md5sum` gegen die lokale Fassung prüfen**, nicht der Erfolgsmeldung der Shell trauen.
+
+---
+
+## Abnahme
+
+- pve: `ip -4 addr show vmbr0` ohne `.41`, `ip route` ohne `41.0/24`, `pct list` weiter 9× running.
+- Core: keine `.41`-Adresse, Mgmt über `.99.1` **und** `10.40.10.1` erreichbar.
+- Prometheus: `http://10.40.20.151:9090/api/v1/targets` — alle aktiven Ziele `up`, kein `10.40.41.x`.
+- HA: `proxmoxve` und `portainer` beide auf `loaded`.
+- **Der eigentliche Test:** TP5-Log-Regel kurz einschalten, 5 Minuten laufen lassen, `out:bridge`
+  muss auf **0 Zeilen** stehen. Vorher waren das 76 % des gesamten Inter-VLAN-Verkehrs.
+  Danach ist TP5 Etappe 1 sauber neu startbar.
+
+---
+
+## Nebenbefund
+
+Im HA-Log stehen 79 abgelehnte Anmeldeversuche auf `/api/websocket` von `90.146.33.177` —
+das ist **eure eigene öffentliche IP**, der Verkehr kommt also über den CF-Tunnel herein.
+Vermutlich der ha-mcp-Server mit einem alten Token vor dem Neustart. Wenn die Zahl jetzt nicht
+weiter steigt, war es genau das; wenn doch, lohnt ein zweiter Blick.

routeros/tp19-core-vlan1-address-remove.rsc

@@ -0,0 +1,21 @@
+# TP19 — VLAN1-Bring-up-Adresse vom Core entfernen.
+# Ausgerollt 2026-08-15 ueber Nautobot GC (manual Config Plan), Backup davor:
+# core-pre-tp19-vlan1-addr-20260815.backup
+#
+# `10.40.41.211/24` auf `bridge` (Kommentar TP15-bringup-vlan1) war die letzte
+# .41-Spur auf dem Core und der letzte offene Compliance-Drift (ip-address).
+# Vorher geprueft: keine DNS-Statics, kein DHCP-Server auf `bridge`, kein Netwatch,
+# keine Address-Lists mit .41; `bridge` ist NICHT Mitglied der LAN-Interface-Liste.
+# Mgmt laeuft ueber .99.1 (+ Fallback 10.40.10.1), beides unberuehrt.
+#
+# ERWARTETE NEBENWIRKUNG: die dynamische Connected-Route 10.40.41.0/24 verschwindet
+# mit der Adresse. Das ist gewollt — Restverkehr nach VLAN1 scheitert danach sofort
+# statt in einen Timeout zu laufen.
+#
+# Reihenfolge war bindend und ist erfuellt: HA zeigt auf 10.40.20.100 (Integration
+# `loaded`), pve hat 10.40.41.100 nicht mehr, Prometheus/ioBroker sind umgezogen.
+#
+# Selbstprotokollierend — der Deploy-Job zeigt den Geraete-Output nicht (E1028).
+
+:do { /ip address remove [find address="10.40.41.211/24"] } on-error={ :log info "tp19: remove hat geworfen" }
+:log info ("tp19: ENDE rest-41-adressen=" . [:tostr [:len [/ip address find address~"10.40.41."]]] . " rest-41-routen=" . [:tostr [:len [/ip route find dst-address~"10.40.41."]]])