Christoph Emsenhuber
39e92d336d
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>
170 lines
8.4 KiB
Markdown
170 lines
8.4 KiB
Markdown
# 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.
|