Files
bf-infra/docs/nas-vlan20/handoff/README.md
Christoph Emsenhuber be85403d2f docs 📄 TP14.1: Omada-Inform/sw2 vertagt (Controller-Login .20.175 fehlt)
Login an der Controller-UI https://10.40.20.175:8043 schlägt fehl →
Inform-Adresse + sw2 re-adopt verschoben. Unkritisch: sw2 „Disconnected"
ist reiner Mgmt-Loss (Easy-Managed switcht mit letzter Config weiter,
Netz läuft). Voraussetzung fürs Nachholen = Controller-Login/Passwort-
Recovery (Creds nicht lokal hinterlegt).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-10 12:48:27 +02:00

92 lines
6.8 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# TP14 — Übergabestatements für neue Sessions
Steuerung: `docs/teilprojekte.md` → **TP14**. Runbook: `docs/nas-vlan20/RUNBOOK.md`.
Reihenfolge: **A → B → C → (D jederzeit nach Token-Scope) → E zuletzt.**
Entscheidung: **sequenzielle Sessions, keine parallelen Branches** (geteilte Live-Infra: 1× NAS,
1× pve-LXC, 1× CF, 1× ap1 → Branches isolieren nur Repo-Files, nicht Infra-State → Kollisionsrisiko).
Portainer-API `https://10.40.41.126:9443` (nach TP14-Session-B → `.20.126`), Key `mcp/portainer/.env`.
Transform-Regeln + Scratch-Skripte: Runbook §„Transform-Regeln". Stack-Files (mit Secrets, gitignored):
`docs/nas-vlan20/stacks/`. Mapping-Regel durchgehend: **letztes Oktett behalten, `.41→.20`.**
---
## TP14.1 — Session A: NAS fertigstellen ✅ DURCH (2026-07-10, außer Omada-Inform)
**Ergebnis:** alle ep14-Container laufen auf vlan20/.20.x (prometheus .151, node-exporter .154,
grafana .109, hms-mqtt .124, dashboard-web .148, qdrant .159, gitea .157 [DB .20.23 ✓],
drawio .139 [intern], oc-tzcharlie .162+cf, oc-johnny2 .161+cf). pve-mcp NEU als Stack id 202
`.20.173` (⚠️ StreamableHTTP am **Root `/`**, nicht `/sse`); `~/.claude.json` `mcpServers.pve-mcp`
neu = `{type:http,url:http://10.40.20.173:3000/}`. Tunnel-Smoke gitea/grafana/vw = 200/302/200.
**Rest-/Nacharbeiten:** (a) ⏸️ **Omada-Inform-Adresse VERTAGT** (2026-07-10): Controller-UI-Login an
`.20.175` schlägt fehl → blockiert, verschoben. sw2 „Disconnected" aber switcht weiter (management-only,
unkritisch). Vor Recovery zuerst **Controller-Login klären** (Passwort-Reset, Creds nicht lokal). (b) ⚠️ alertmanager .153 crash-loopt auf
**pre-existing** Config-Bug (`${TELEGRAM_CHAT_ID}`-Literal), nicht migrationsbedingt. (c) ⚠️ openclaw
shared-DB `.41.122:3306` down (pre-existing). (d) Merke: `OLLAMA_BASE_URL=.41.167`=Mac-mini bleibt
`.41` — **kein Blanket-Env-.41→.20**. Helper: `/private/tmp/nasmig/{redeploy.py,pt.py,omada.py}`.
**Omada-Inform-Fix ⏸️ VERTAGT (2026-07-10):** Controller-UI-Login an `https://10.40.20.175:8043`
klappt nicht → erst **Login/Passwort-Recovery** klären (Creds nicht lokal). Danach: UI → Settings →
Controller → „Controller Hostname/IP" = `10.40.20.175`; dann sw2 forget + re-adopt (L3-Discovery).
Kein Auto-Fix: Open API kein Inform-Setting, kein Controller-Admin-Login lokal, sw2 = statische IP (kein DHCP-138).
<details><summary>Original-Aufgabe (erledigt)</summary>
Kontext: NAS(ep14) ist auf `vlan20`-Macvlan migriert (DSM `.20.10`). Container teils exited.
Aufgabe:
1. Restcontainer starten/redeployen aus `docs/nas-vlan20/stacks/`: **oc-stack(112)** (prometheus/
alertmanager/node-exporter), **default(72)** (hms-mqtt), **nginx(101)** (dashboard-web),
**oc-central(160)**, **oc-charlie(158)**, **oc-johnny2(150)**.
2. **gitea(111)** deployen → `.20.157`; ⚠️ `GITEA__database__HOST` `.20.23` verifizieren (Rewrite-Annahme).
3. **drawio(107)** mit `transform.py` auf vlan20 bringen (`.20.139`) → deployen.
4. **pve-mcp NEU als Stack** (vlan20-only): Spec `docs/nas-vlan20/inspect_pve-mcp.json` — image
`ghcr.io/samik081/mcp-pve:latest`, `PVE_BASE_URL=https://10.40.41.100:8006`, `MCP_PORT=3000`,
`MCP_HOST=0.0.0.0`, `MCP_TRANSPORT=http`; Netz `vlan20` `ipv4_address: 10.40.20.173`. Danach
`~/.claude.json` pve-mcp-URL `.41.173→.20.173`.
5. **omada-controller Inform-Adresse** (UI `https://10.40.20.175:8043`) → `10.40.20.175`, sonst sw2 down.
Verifikation: `pt.py containers` alle `running`/`.20.x`; von `.41`-Host (gw ap1) `curl`/`ping` auf `.20`-IP;
Tunnel `curl -m8 -w %{http_code} https://<host>.emsenhuber.net/` → 200/302.
</details>
## TP14.2 — Session B: pve-Docker-LXC (.126) → VLAN20 (⚠️ ipvlan, nicht macvlan!)
Kontext: pve-LXC(ep2) hängt auf `.41`, Netz `default_external` = **ipvlan** parent `eth0`:
omada-mcp `.176`, adguard_bf1 `.16`, adguard_fm2 `.17`. **Portainer-Server + aktiver CF-Connector laufen
hier.** ⚠️ Reihenfolge kritisch.
Aufgabe:
1. ep2-Stacks (`adguard`, `omada-mcp`) transformieren `.41→.20` (omada-mcp `OMADA_URL` `.41.175→.20.175`).
2. Portainer-Zugangspfad für den Move sichern (URL wandert auf `https://10.40.20.126:9443`).
3. LXC in Proxmox auf VLAN20 taggen + IP `.126→.20.126`.
4. `default_external`(ipvlan) weg → `vlan20`(ipvlan) neu: `-d ipvlan --subnet 10.40.20.0/24
--gateway 10.40.20.1 -o parent=eth0`. Container erst entfernen (`v=false`), dann Netz, dann Stacks redeploy.
5. `mcp/portainer/.env` + `PORTAINER_URL` + CF-Ingress (portainer `.20.126`) nachziehen.
Ergebnis: CF-Connector in VLAN20 = **#1033-Zielbild** (TP11-Track-B/C erledigt). Verifikation: Portainer
unter neuer URL, ep2-Container `.20.x`, Tunnel healthy, pve-lokale Origins (pve-Host `.41.100`) noch erreichbar.
## TP14.3 — Session C: Dormante Stacks vlan20-tauglich + Referenz-Sweep
Aufgabe:
1. `transform.py` auf dormante ep14-Stacks: core(43), openclaw(92), openclaw2(97), oc20260307(119),
openspeedtest(74), speedtest_tracker(80), technikscheiss(42) → `.new`-Files (nicht zwingend deployen;
42/43 waren `default_internal`→wird vlan20-only).
2. Referenz-Sweep `.41→.20` für gewanderte Hosts: **ap1 bf.lan-DNS** (MikroMCP `manage_dns_entry`,
ap1-Mgmt via `10.40.10.1` — s. Memory `ref_ap1_mgmt_access_vlan10`), **CLAUDE.md**, **`~/.claude.json`**
(omada-mcp `.20.176`, pve-mcp `.20.173`), **`docs/ip-plan.md`**, **CF-Ingress-Rest**. SSoT `docs/cf-tunnel-mapping.md`.
## TP14.4 — Session D: CF-Access-Profil für Claude (nicht cutoff-kritisch)
Kontext: `*.emsenhuber.net`-Access-App hat Policy `claude-mcp` (service_token) bereits; Secret fehlt lokal.
CF-Token „claude code mcp" hat jetzt **`Access: Service Tokens: Write`+`Read`** (User bestätigt 2026-07-10).
Aufgabe: `claude-mcp` rotieren (`POST /accounts/{acct}/access/service_tokens/{id}/rotate`) → `CF_ACCESS_CLIENT_ID`/
`CF_ACCESS_CLIENT_SECRET` in `mcp/cloudflare/.env` (chmod600) → dokumentieren. Details: Memory `ref-cf-access-claude-profile`.
## TP14.5 — Session E: Freigabe-Gate → TP5-Firewall (ZULETZT)
Erst wenn ALLE Origins/Connectoren in VLAN20 (nach A+B+C). Least-Privilege je VLAN; Deny-by-default fertigziehen.
---
## Kritische Gotchas (gelten für alle Sessions)
- Macvlan/ipvlan-Parent **exklusiv** → altes `default_external` MUSS weg, bevor `vlan20` anlegbar.
- **Host↔eigene-Macvlan-Isolation:** ein Connector auf demselben Host erreicht dessen Macvlan-Container NICHT
→ Connector muss auf anderem Host in VLAN20 laufen (darum pve-LXC → VLAN20).
- **Portainer lebt im pve-LXC** → dessen Move ändert die Mgmt-URL; Zugang vorher sichern.
- **Container-Removal unkritisch** (Stack-Def + Ownership bleiben); **Recreate via API** macht admin-owned →
besser via Stack-Redeploy (bleibt User-owned). `v=false` = Volumes bleiben.
- Portainer-Macvlan-Assistent legt bei nur Schritt 1 ein **Config-Only-Netz** an (`Driver:null`) → echtes
Netz nur per API in einem Schritt anlegen.