Files

Christoph Emsenhuber 5ee0716dda Initial import from bf-network-r6.opencode — opencode migration

2026-08-26 12:44:21 +02:00

10 KiB

Raw Permalink Blame History

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.

Container-Manager-Neustart durchgeführt (2026-08-15) — hat den Hänger behoben, reicht aber nicht

synopkg stop/start ContainerManager (Binary liegt unter /usr/syno/bin/synopkg, nicht im sudo-PATH). Ergebnis:

✅ Alle 14 Container aus der Baseline sind zurück, keiner fehlt. Zusätzlich kam hms-mqtt hoch, der vorher nicht lief (Restart-Policy) — prüfen, ob der bleiben soll.
✅ docker system df beendet sich wieder (vorher: gab die Tabelle aus und hing dann; rc=124).
❌ Aber es ist weiterhin viel zu langsam und schwankt stark: 33 s → 92 s → 3× über 120 s. pyportainer gibt lange vorher auf, die Integration bleibt auf setup_retry.

Wo die Zeit hingeht — gemessen, nicht vermutet:

Aufruf	Dauer
`docker images -q`	84 ms
`docker ps -aq`	95 ms
`docker volume ls -q`	65 ms
`docker system df`	33–92+ s

Das Auflisten ist trivial schnell; die Zeit geht vollständig in die Größenberechnung, also das du-artige Durchlaufen der overlay2-/Volume-Verzeichnisse auf den NAS-Platten. Das ist ein struktureller Nachteil dieser Plattform, kein Defekt — und die HA-Integration ruft system df für jede Umgebung bei jedem Update auf.

Der aussichtsreichste Weg: eigener Portainer-Benutzer für HA

Portainer kann Umgebungszugriff pro Benutzer beschränken. Ein HA-eigener Benutzer mit Zugriff auf ep2, ep20, ep21 — aber nicht ep14 löst das Problem an der Wurzel: die Integration sieht die langsame NAS-Umgebung dann gar nicht.

Wo: Portainer → Users → neuen Benutzer anlegen → Environments → Zugriff auf ep14 entziehen → Access-Token erzeugen → in HA die Portainer-Integration mit diesem Token neu anlegen.

Warum du und nicht ich: Benutzer anlegen und Token erzeugen sind Konto- und Credential-Schritte, die ich grundsätzlich nicht übernehme.

Alternativen, ehrlich bewertet:

Nichts tun — die Integration bleibt auf setup_retry, stört sonst nichts. Völlig vertretbar.
Images aufräumen (6,98 GB / 53 % sind reclaimable) — verkürzt den Durchlauf, aber ob es unter das pyportainer-Limit kommt, ist offen. Ich würde nicht darauf setzen.
ep14 ganz aus Portainer nehmen — kostet die NAS-Verwaltung, schlechter 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)

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

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.

10 KiB Raw Permalink Blame History Unescape Escape