From a969efbe6d6a6eef602f78a5e8abf05086837b1e Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Fri, 10 Jul 2026 18:29:25 +0200 Subject: [PATCH] =?UTF-8?q?docs=20=F0=9F=93=84=20pve-mcp=20Single-Session-?= =?UTF-8?q?Fix=20(TP14.2a)=20+=20TP16=20CF-Tunnel=20=F0=9F=94=B4=20hochdri?= =?UTF-8?q?nglich?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - pve-mcp „Failed to connect" = mcp-pve 0.4.8 kann nur 1 MCP-Session ("Server already initialized") → Upgrade 0.6.1 (Per-Session), ✔ Connected. omada-mcp war/ist gesund (frische Session-ID pro Init). - Kollateral: VLAN20-Host-DNS auf NAS+LXC zeigte noch auf totes .41.254 → docker-pull scheitert; LXC pct set .20.1, NAS Synology-DHCP-DNS-Falle. Neuer Gotcha in CLAUDE.md. - TP16 (neu, hochdringlich): FQDNs via CF „sehr unsicher" = #1033-Round-Robin zurück; Live-Snapshot 2026-07-10: bf-Tunnel 2 statt 3 Connectoren, alle frisch (2026.7.1), Origins nach VLAN20-Move erneut asymmetrisch zu auditieren. Co-Authored-By: Claude Opus 4.8 --- CLAUDE.md | 3 ++- docs/teilprojekte.md | 13 +++++++++++++ 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/CLAUDE.md b/CLAUDE.md index ecfef29..bce1f39 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -34,7 +34,7 @@ GW je VLAN = `.1` · APs: ap1=`.1`, ap2=`.2` · Switches: ALLNET=`.11`, Omada=`. | NAS (nas-bf, DS923) | 10.40.41.10 | SSH · Docker (Portainer endpointId=14) | | Omada-Controller | 10.40.41.175 | `https://10.40.41.175:8043` (macvlan auf DS923) | | omada-mcp | 10.40.20.176 | StreamableHTTP `http://10.40.20.176:3000/mcp` · MCP in Claude Code ✓ (pve-LXC) · **TP14.2 2026-07-10: .41→.20, OMADA_BASE_URL→.20.175** | -| pve-mcp | 10.40.20.173 | **StreamableHTTP `http://10.40.20.173:3000/` (Root-Pfad, NICHT /sse)** · NAS-Stack ep14 id 202 (vlan20-only, TP14.1 2026-07-10) · `~/.claude.json` ✓ (wirkt nach Restart) | +| pve-mcp | 10.40.20.173 | **StreamableHTTP `http://10.40.20.173:3000/` (Root-Pfad, NICHT /sse)** · NAS-Stack ep14 (=nas-bf `.20.10`, NICHT LXC .126!) id 202 (vlan20-only, TP14.1 2026-07-10) · **mcp-pve v0.6.1 (Upgrade 2026-07-10: Single-Session-Bug 0.4.8 „Server already initialized" gefixt, TP14.2a)** · `~/.claude.json` ✓ | | Proxmox (pve) | 10.40.41.100 | kein SSH-Key konfiguriert | | Docker-LXC (auf pve) | 10.40.20.126 | Portainer CE 2.40.0 (`https://10.40.20.126:9443`) · **TP14.2 2026-07-10: LXC 400 net0 tag=20/.20.126 (iface heißt jetzt `veth20`, NICHT eth0); Docker-Netz `vlan20`=ipvlan parent `veth20`; adguard_bf1 .20.16, adguard_fm2 .20.17** | | Mac mini | 10.40.41.167 | `ssh macmini` | @@ -59,6 +59,7 @@ GW je VLAN = `.1` · APs: ap1=`.1`, ap2=`.2` · Switches: ALLNET=`.11`, Omada=`. - **ALLNET: nur 1 Telnet-VTY** — stale Sessions blockieren ~15 min. Sauber ausloggen (`exit exit`), nie hammern. - **`save` nicht vergessen** nach ALLNET-Änderungen (sonst nach Reboot weg). - **hAP ax² hat 128 MB Flash, kein USB** → Container NICHT auf dem Router; Container laufen auf NAS/pve. +- **VLAN20-Docker-Hosts: Host-DNS nach dem Umzug prüfen (2026-07-10, TP14.2a):** NAS + pve-LXC zeigten `/etc/resolv.conf` noch auf totes `.41.254` → `docker pull` ghcr scheitert (`EAI_AGAIN`, aber Egress ok!). Fix = `.20.1`: LXC `pct set 400 --nameserver 10.40.20.1`; **Synology-Falle: DSM-„Allgemein"-DNS ≠ was `dockerd` liest** — Interface zieht DNS per DHCP → Fix an der *Netzwerkschnittstelle* „DNS manuell". Laufende Container frieren den `127.0.0.11`-Upstream zum Erstellzeitpunkt ein (Recreate nötig). Merkregel: `docker-pull-hängt` + `dns.lookup EAI_AGAIN` aber `TCP zu ghcr-IP:443 ok` = toter Resolver, nicht Egress. - **ALLNET VLAN-DB final (TP1 ✅):** 40=MEDIA, 50=UNTRUSTED; GE1/GE2/GE8 alle als Trunk mit 10/20/30/40/50/90/99/100. - **Omada-Switch Port 2 = ap2** (Trunk all VLANs), Uplink-Port → ALLNET GE8 (Trunk all), Restports = Access. - **Mesh = NEIN** (beide APs haben wired Trunk-Uplink → Loop-Risiko). diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 4ef985f..bc4e025 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -303,6 +303,10 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". - ✅ **CF-Connector `db713b30` jetzt in VLAN20** (Tunnel `bf.emsenhuber.net` healthy/8 conns) = **löst TP11-Track-B/C** (#1033-Zielbild). Ingress `portainer` .41.126→.20.126. Smoke: portainer/gitea/vw 200, grafana 302. - ✅ Refs nachgezogen: `mcp/portainer/.env` (PORTAINER_URL), `~/.claude.json` (omada-mcp `.20.176`), CLAUDE.md, `docs/ip-plan.md`, `docs/cf-tunnel-mapping.md`. Next = **TP14.3 (Session C, dormante Stacks + Referenz-Sweep ap1-DNS)**. +### TP14.2a — pve-mcp Single-Session-Fix + VLAN20-Host-DNS ▸ ✅ (2026-07-10) +- **pve-mcp „Failed to connect":** Ursache = **mcp-pve v0.4.8** kann im HTTP-Transport nur **eine** MCP-Session (ein globaler `StreamableHTTPServerTransport`, `sessionIdGenerator` gesetzt) → erster Client nach Boot belegt den Slot, jeder weitere Init (neue Claude-Code-Session, `claude mcp list`-Healthcheck, Reconnect) = `400 "Server already initialized"`. **omada-mcp NICHT betroffen** (frische Session-ID pro Init → Per-Session-Transport). **Fix = Upgrade auf 0.6.1** (Per-Session-Map, `serverFactory()` je Session, gleiche Env-Vars = Drop-in); Stack 202 neu deployed, Container `.20.173` = 0.6.1, `Connected to Proxmox VE 9.0.11`, `tools/list` liefert `pve_*`, **Claude Code ✔ Connected**. 3× init hintereinander = 3× 200 mit verschiedenen session-ids (verifiziert). +- **Kollateral-Fund — VLAN20-Host-DNS kaputt (beide Docker-Hosts):** nach dem VLAN20-Umzug zeigten **NAS** *und* **pve-LXC** `/etc/resolv.conf` noch auf totes `.41.254` → `docker pull` ghcr.io scheitert (`EAI_AGAIN` / 5s-Resolver-Timeout; Egress zu ghcr-IP `140.82.x:443` = OK 31 ms, also **nur Resolver tot**, nicht Egress). Fixes: **LXC** `.20.126` → `pct set 400 --nameserver 10.40.20.1` (Christoph). **NAS** → DSM-„Allgemein"-DNS war `.20.1`, ABER die **Netzwerkschnittstelle zog DNS per DHCP** und überschrieb `resolv.conf`; Fix = Schnittstelle „DNS manuell" `10.40.20.1` (Christoph) → NAS pullt wieder direkt. **Merkregel Synology:** GUI-DNS ≠ was `dockerd` liest (Quelle `/etc/resolv.conf`, per DHCP überschreibbar). **Workaround solange NAS-DNS tot:** `docker save`(LXC, hat DNS) → **gzip** (191-MB-tar reißt am Portainer-Agent-Socket-Proxy „context canceled"; ~70 MB gz geht) → Portainer `POST /endpoints/14/docker/images/load` → Stack-Redeploy `pullImage:false`. Gotcha: laufende Container frieren den `127.0.0.11`-Upstream zum Erstellzeitpunkt ein (Recreate nötig; für pve-mcp egal — Proxmox per IP `.41.100`). Memory `ref_pve_mcp_singlesession_and_vlan20_dns`. + ### TP14.3 — Session C: Dormante Stacks vlan20-tauglich + Referenz-Sweep ▸ 🔜 TODO - `transform.py` auf core(43)/openclaw(92)/openclaw2(97)/oc20260307(119)/openspeedtest(74)/speedtest_tracker(80)/technikscheiss(42) → `.new` (42/43 waren `default_internal` → vlan20-only). - Referenz-Sweep `.41→.20`: ap1 bf.lan-DNS (MikroMCP, ap1 via `10.40.10.1`), CLAUDE.md, `~/.claude.json`, `docs/ip-plan.md`, CF-Ingress-Rest. @@ -326,6 +330,14 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". - **Nächster Schritt:** Entscheidungen treffen, dann Konfiguration + Bestellung. - Abh.: TP14 (IP-Migration VLAN1→VLAN20 sollte abgeschlossen sein, damit Ziel-IPs feststehen). +### TP16 — CF-Tunnel-Erreichbarkeit / FQDN-Auflösung härten ▸ 🔴 HOCHDRINGLICH (2026-07-10) — `docs/cf-tunnel-mapping.md`, #1033 +> **Eigenes, hochdringliches Paket** (User-Auftrag 2026-07-10). Setzt #1033 fort: Track A war 2026-06-30 „komplett", aber die Round-Robin-Asymmetrie ist **zurück**, weil (a) alle 3 Connectoren wieder laufen und (b) NAS/pve seither weiter nach VLAN20 gewandert sind (TP14.1/14.2) → Ingress-Origins evtl. erneut asymmetrisch. +- **Symptom (User):** FQDNs über Cloudflare werden **sporadisch / „sehr unsicher"** aufgelöst → #1033-Muster kehrt zurück. „Tunnelerreichbarkeit ggf. neu machen." User hat **alle 3 cloudflared-Images + Container aktualisiert und neu gestartet** (für Diagnose bereit). +- **Live-Snapshot (2026-07-10 ~16:18, cf-MCP):** Tunnel `bf.emsenhuber.net` (`70d6a4cf-…-91fab4fa7270`) = healthy, **8 conns = nur 2 *distinct* Connectoren** (`b797ee1b`, `f480dc69`), cloudflared **`2026.7.1`** (frisch), alle Origins egress via **BF-Public-IP `90.146.35.38`** (= alle Connectoren jetzt BF-/VLAN20-seitig). ⚠️ **User startete 3, CF sieht nur 2** → ein Connector registriert sich NICHT am bf-Tunnel (welcher Host? pve-LXC/NAS/macmini-Logs prüfen). Connector-IDs sind neu — die im Mapping-Doc (`1856dfc3/db713b30/d7454e68`) sind **stale** (Recreate mintet neue). +- **Root-Cause (unverändert #1033):** 3 Connectoren = selber Token → CF round-robined → **jeder Origin muss von ALLEN Connectoren erreichbar sein**, sonst sporadisch 1033. Token-managed Ingress (CF-Dashboard) kann noch `.41`/pve-lokale/stale Origins enthalten, die nur ein Connector erreicht. +- **Next (Reihenfolge):** (1) fehlenden 3. Connector finden (Container-Logs je Host); (2) **Ingress-Origins auditieren** — jeder Hostname → VLAN20-IP, die ALLE Connectoren erreichen (kein `.41`/pve-local/stale); (3) Origins/DNS gegen `docs/cf-tunnel-mapping.md` abgleichen + nachziehen (scoped API-Token `mcp/cloudflare/.env`, OAuth-MCP evtl. read-only); (4) tote Tunnel/Orphan-CNAMEs aufräumen; (5) FQDN-Auflösung im **Loop gegentesten**. **Alternative erwägen:** auf **1 symmetrischen Connector** reduzieren statt 3 asymmetrische (robuster, wenn Symmetrie schwer herstellbar — vgl. #1033 „Stufe 1 pve-only"). +- Abh.: TP14.1/14.2 ✅ (Origins in VLAN20). Verwandt: **TP11** (CF-Tunnel-Track-B/C), #1033. SSoT: `docs/cf-tunnel-mapping.md`. Memory `project_cf_tunnel_1033`. + ### TP-R — Router-Capabilities-Sweep ▸ FERTIG (`docs/research/routeros-capabilities.md`) - **Leitsatz: nativ vor Container, NAS vor Router** (128MB-Flash-Limit). - **Sofort nativ (~0 RAM):** RoMON · Netwatch · Scheduler + Auto-Backup/Mail · SNMP→externes Monitoring · **mDNS-Repeater** · spectral-scan · **CAPsMAN + 802.11r/k/v (Fast-Roaming statt Mesh)** · Back-to-Home/WireGuard. @@ -337,6 +349,7 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". --- ## Reihenfolge / Abhängigkeiten +> 🔴 **QUER & HOCHDRINGLICH: TP16 (CF-Tunnel-Erreichbarkeit / FQDN „sehr unsicher")** — vom User als eigenes, vorrangiges Paket eingekippt (2026-07-10). Läuft neben der VLAN20-Migration; Origins sind jetzt VLAN20-seitig, also anwendbar. Details oben bei TP16. 1. ~~**TP1 (GE8) → TP2 (Omada Controller).**~~ ✅ erledigt 2026-06-15. 2. ~~**TP4 (Router-Cutover L3-Infra + WAN-Edge).**~~ ✅ erledigt 2026-06-15 (L3) + 2026-07-01 (Edge-Cutover, FB physisch weg). 3. **Jetzt: Omada-PVID-Fix** — Omada Access-Profile korrigieren (PVID 10/20, untagNetworkIds bereinigen, sicher P3/P5/P6 zuerst), dann IP-Migration NAS/macmini/pve auf VLAN-Subnetze + DNS-Einträge updaten. **IP-Migration NAS/pve = TP14** (NAS ✅ 2026-07-10, pve 🔜 Session B).