diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 6a9d926..cccab95 100644 --- a/docs/teilprojekte.md +++ b/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`). diff --git a/docs/vlan1-rueckbau-howto-manuelle-schritte.md b/docs/vlan1-rueckbau-howto-manuelle-schritte.md new file mode 100644 index 0000000..2bb8cb8 --- /dev/null +++ b/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. diff --git a/routeros/tp19-core-vlan1-address-remove.rsc b/routeros/tp19-core-vlan1-address-remove.rsc new file mode 100644 index 0000000..3e349e8 --- /dev/null +++ b/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."]]])