admin/bf-infra
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases Wiki Activity
113 Commits 5 Branches 0 Tags
7bba0c97cb8a1b13a12c9d8357a9a28244e69c0a
Commit Graph

8 Commits

Author SHA1 Message Date
Christoph Emsenhuber
30301d40e2 TP21: routers.yaml auf finale MGMT-IPs aktualisiert; Sub-TP21.1 CRS326-Branch-Recovery dokumentiert; Nautobot-Image procps-Fix 
- mcp/mikromcp/config/routers.yaml: ap1→10.40.99.11, ap2→10.40.99.12,
  crs326-core→10.40.99.1, crs326-branch→10.40.99.2 (tags aktualisiert).
- docs/teilprojekte.md: TP21.1 angelegt — Branch nach Reboot/Lockout recovery.
- docs/nas-vlan20/nautobot-image/Dockerfile: procps installiert (healthcheck).

Co-Authored-By: Claude <noreply@anthropic.com>
 2026-08-08 11:40:20 +02:00
Christoph Emsenhuber
1578de50c3 TP15/TP16.1: kein RB5009, WG-Mesh auf CRS326; TP21: Golden-Config-Image im Repo 
- RB5009 final gestrichen (User-Entscheid 2026-07-22) — Router bleibt ap1/ap2,
  Referenzen in teilprojekte.md + hw-refresh-requirements.md bereinigt.
- TP16.1 Ziel-Device von ap1 auf CRS326 Core-Switch retargeted (Doku-only,
  Scharfschalten bleibt gated bis TP21 den CRS326 abdeckt), Runbook umbenannt
  auf tp16.1-warp-mesh-native-crs326.md, cf-tunnel-mapping.md §14 + Handoff-
  Prompt mitgezogen.
- TP21: docs/nas-vlan20/nautobot-image/ neu — der Dockerfile/nautobot_config.py/
  allnet_sg8316m_driver.py, aus denen das laufende Custom-Image tatsächlich
  gebaut ist (der bisherige Verweis auf scratch/nautobot-gc-build existierte
  nirgends). Ergänzt napalm-ros + nornir-napalm + librouteros + gepinntes
  setuptools<81 (pkg_resources-Regression), Nornir-Credentials auf
  CredentialsNautobotSecrets umgestellt, Compliance/Intended-Config/SoT-Agg
  aktiviert. Backup/Intended/Compliance-Pipeline live gegen ap1 verifiziert.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
 2026-07-22 19:46:24 +02:00
Christoph Emsenhuber
7636ea399f docs 📄 TP14.2 ✅ pve-Docker-LXC (400) → VLAN20 (#1033 gelöst) 
LXC 400 `docker` net0 tag=20/.20.126; Docker vlan20=ipvlan parent=veth20.
omada-mcp .20.176 (OMADA_BASE_URL→.20.175), adguard .20.16/.17 — running/reachable.
CF-Connector db713b30 jetzt VLAN20 → #1033-Zielbild (Tunnel healthy; portainer/gitea/vw 200).
Refs .41→.20: mcp/portainer/.env, ~/.claude.json omada-mcp, CLAUDE.md, ip-plan, cf-tunnel-mapping.

Gotchas: Proxmox-Token kein VM.Config.Network (Retag via UI); Iface heißt veth20 nicht eth0.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-10 13:34:29 +02:00
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
Christoph Emsenhuber
7f1871eb96 docs 📄 TP14.1 ✅ NAS-Container auf VLAN20 + pve-mcp neu (Session A durch) 
Alle ep14-Container via Portainer-Stack-Redeploy auf vlan20/.20.x (Env
preserved, Volumes intakt): prometheus/node-exporter/grafana, hms-mqtt,
dashboard-web, qdrant, gitea (DB .20.23 ✓), drawio (intern), oc-charlie,
oc-johnny2. pve-mcp NEU als Stack id 202 (.20.173) — StreamableHTTP am
Root-Pfad / (nicht /sse); ~/.claude.json mcpServers.pve-mcp neu angelegt.

Geflaggt (pre-existing, nicht migrationsbedingt): alertmanager crash-loop
(${TELEGRAM_CHAT_ID}-Literal), openclaw shared-DB .41.122 down. Gotcha:
gitea-Stack hatte vlan20-Block auskommentiert → Fix via Disk-Override.
Merke: kein Blanket-Env-.41→.20 (Mac-mini .167 bleibt .41).

OFFEN: Omada-Inform-Adresse → .20.175 (Controller-UI-Task; sw2 static IP,
kein DHCP-138; nur Mgmt-Loss, Netz läuft).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-10 10:47:07 +02:00
Christoph Emsenhuber
5bed507d30 docs 📄 TP14 in Sub-TPs gegliedert (TP14.1–14.5 = Sessions A–E) 
- teilprojekte.md: TP14 Parent (✅ NAS + CF-Ingress) + Sub-TPs TP14.1 (NAS-Rest),
  14.2 (pve-LXC/ipvlan), 14.3 (dormante Stacks + DNS-Sweep), 14.4 (CF-Access-Profil),
  14.5 (Freigabe-Gate → TP5). Analog zu TP3.1/3.2-Muster.
- Handoff-README-Headings auf TP14.x-Nummern gezogen (Konsistenz).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-10 10:08:52 +02:00
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
Christoph Emsenhuber
06e491f609 docs 📄 NAS→VLAN20 Docker-Migration: Runbook + Root-Cause 
Diagnose der Docker-Container-Fehler nach NAS-NIC-Wechsel auf VLAN20:
- Config-Only-Macvlan-Falle (Portainer 2-Schritt, Driver=null → kein Attach)
- Macvlan-Parent ovs_eth0 exklusiv → default_external muss weg für vlan20
- default_internal (172.18) existiert nicht mehr (Range von gitea_default belegt)

RUNBOOK: IP-Mapping .41.X→.20.X (Oktett behalten), Phase-A-Teardown,
Post-Steps (ap1-DNS, CF-Ingress-Repoint, omada-Inform .20.175), CF-Access
claude-mcp-Profil-Status.

Stack-Compose-Files + Inspect-JSONs (docs/nas-vlan20/stacks/, inspect_*.json)
via .gitignore ausgeschlossen — enthalten Live-Secrets.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-09 21:14:49 +02:00