Initial import from bf-network-r6.opencode — opencode migration
This commit is contained in:
203
docs/vlan1-rueckbau-howto-manuelle-schritte.md
Normal file
203
docs/vlan1-rueckbau-howto-manuelle-schritte.md
Normal file
@@ -0,0 +1,203 @@
|
||||
# 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)
|
||||
|
||||
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.
|
||||
Reference in New Issue
Block a user