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`).