admin/bf-infra
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
c51704fd8463c72e335962b4a5626943fe5b10a9
bf-infra/docs/nas-vlan20/handoff
History
Christoph Emsenhuber c51704fd84 docs 📄 TP14 angelegt: Host/Container-IP-Migration VLAN1→VLAN20 (NAS ✅, pve 🔜) 
- teilprojekte.md: neuer TP14 (Docker-Cutover NAS+pve) + Querverweise TP11 (Track-B/C) + Reihenfolge #3.
- NAS ep14 ✅ auf vlan20-Macvlan; CF-Ingress v116; Root-Cause Config-Only-Macvlan-Falle dokumentiert.
- Handoff docs/nas-vlan20/handoff/README.md: paste-fertige Anschlussstatements Session A–E
  (sequenzielle Sessions, keine parallelen Branches — geteilte Live-Infra).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-10 09:46:59 +02:00
..
README.md
docs 📄 TP14 angelegt: Host/Container-IP-Migration VLAN1→VLAN20 (NAS ✅, pve 🔜)
2026-07-10 09:46:59 +02:00

README.md

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.

Session A — NAS fertigstellen

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.

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.

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.

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.

Session E — 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.
Reference in New Issue View Git Blame Copy Permalink