Christoph Emsenhuber
fd05286e4b
Dritter Access-Point ap3 (MikroTik cAP ax, cAPGi-5HaxD2HaxD) kommt dazu und loest mittelfristig ap1 in Technik UG ab. Statt eines neuen TP wandert TP28 aus dem Archiv zurueck -- neue Regel: ein archiviertes TP ist ein geschlossenes, kein versiegeltes Ticket (Christoph-Direktive 2026-08-30). Live am Core: - ether21 ist AP-Trunk (10/20/30/40/50/90/99 tagged, Muster ether15). ⚠️ Erratum: erst war ether22 angenommen und getaggt; der Port hat keinen Link. Gegenprobe ueber die Bridge-Host-Tabelle: auf ether21 sitzt D0:EA:11:FF:16:9D = E01 vom ap3-Label. ether22 wieder leer. - Backups vorher: pre-ap3-20260830.backup/.rsc auf core und ap1. - Compliance vor und nach jeder Aenderung 104/104, 0 Drifts. Golden Config (2 Pushes: e25d654b, 20472cdb): - Core-L2-Block traegt ether21. - AP-Zweig rendert die Bridge-Ports jetzt aus ap.extra_ports statt hartkodiert ether3/4/5. Das war die stille Annahme "AP == hAP ax2 mit 5 Ports"; der cAP ax hat zwei. Default in ap-common = hAP-ax2-Bestand, ap3 ueberschreibt mit []. Dass ap1/ap2 danach zeichengleich rendern, beweist die 0-Drift-Messung. Kanalplan NICHT neu erfunden: TP25 hat ihn am 2026-08-24 fuer genau dieses Geraet gerechnet (DFS vom User genehmigt). ap3 = 5180/Ce + 2437 (ch6, nicht ch1 -- ch1 bleibt fuer ap1, damit 1/6/11 erstmals lueckenlos aufgeht). ap1/ap2 gehen beim Umzug auf 5260/Ce bzw. 5300/Ce, 5220/Ce bleibt Ausweichspur. MikroMCP-Registry (MCP-Lifecycle, User-Freigabe 2026-08-30) -- zwei Drifts: - MIKROMCP_CONFIG_PATH zeigte auf ~/dev/bf-network-r6 (Archiv-Repo); die identische Datei in bf-infra war wirkungslos. Jetzt bf-infra = SSoT. - In opencode.jsonc fehlte MIKROMCP_CONFIG_PATH ganz, hinterlegt waren nur ap1/ap2 -- opencode kannte core/branch gar nicht. Beide Clients zeigen jetzt auf dieselbe Registry; ap3 aufgenommen, rosVersion von stale 7.23/7.19.5 auf 7.24 korrigiert. Neustart des MCP noetig, Registry wird nur beim Start gelesen. Noch offen: physischer Bring-up (Datei liegt bereit), ap1-Radios aus, CAPsMAN-Objekte fuer ap3, Nautobot-Adoption, Messrunde -- und die Passwort-Rotation: das gemeinsame MikroTik-Admin-PW ist in dieser Session durch eine ungefilterte Ausgabe des mikromcp-env-Blocks ins Transkript geraten und gilt als verbrannt (Posten fuer TP30). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
66 lines
2.8 KiB
JSON
66 lines
2.8 KiB
JSON
{
|
|
"$schema": "https://opencode.ai/config.json",
|
|
"instructions": ["CLAUDE.md"],
|
|
"permission": "allow",
|
|
"mcp": {
|
|
"gitea-mcp": {
|
|
"type": "remote",
|
|
"url": "http://10.40.20.167:3000/mcp",
|
|
"enabled": true
|
|
},
|
|
"mikromcp": {
|
|
"type": "local",
|
|
"command": ["npx", "-y", "mikromcp", "serve"],
|
|
"environment": {
|
|
"MIKROMCP_CONFIG_PATH": "/Users/christophemsenhuber/dev/bf-infra/mcp/mikromcp/config/routers.yaml",
|
|
"MIKROMCP_DEFAULT_ROUTER": "ap1"
|
|
},
|
|
"enabled": true,
|
|
"timeout": 30000
|
|
},
|
|
"pve-mcp": {
|
|
"type": "remote",
|
|
"url": "http://10.40.20.173:3000/",
|
|
"enabled": true,
|
|
"timeout": 15000
|
|
},
|
|
"home-assistant": {
|
|
"type": "remote",
|
|
"url": "http://10.40.20.105:9583/private_29X8x73taoNEq6gzmbVdyg",
|
|
"enabled": true,
|
|
"timeout": 15000
|
|
},
|
|
"cloudflare": {
|
|
"type": "remote",
|
|
"url": "https://mcp.cloudflare.com/mcp",
|
|
"enabled": true,
|
|
"timeout": 15000,
|
|
"oauth": {}
|
|
},
|
|
"portainer": {
|
|
"type": "local",
|
|
"command": ["uvx", "--from", "mcp-portainer~=2.42.0", "mcp-portainer"],
|
|
"environment": {
|
|
"PORTAINER_URL": "https://10.40.20.126:9443",
|
|
"PORTAINER_API_KEY": "{env:PORTAINER_API_KEY}",
|
|
"PORTAINER_TLS_VERIFY": "0"
|
|
},
|
|
"enabled": true,
|
|
"timeout": 15000
|
|
},
|
|
"shelly-mcp": {
|
|
"type": "remote",
|
|
"url": "http://10.40.20.180:3030/mcp",
|
|
"headers": {},
|
|
"enabled": true,
|
|
"timeout": 15000
|
|
}
|
|
},
|
|
"command": {
|
|
"handoff": {
|
|
"description": "Session-Übergabe generieren oder laden",
|
|
"template": "Du bist das Handoff-Tool für das BF-Infra-Projekt.\n\n1. Ermittle, was zu tun ist:\n - Lese `docs/handoff-*.md` und finde die neueste Datei (nach Datum).\n - Wenn `$ARGUMENTS` \"resume\" oder einen Dateinamen enthält: lade die genannte oder neueste Handoff-Datei.\n - Wenn `$ARGUMENTS` leer ist oder \"generate\" enthält: generiere eine neue Handoff-Datei.\n\n2. Generieren (`/handoff`):\n - Lese `docs/teilprojekte.md` (Quick-Index-Block, Zeilen ~174-200) für den aktuellen TP-Status.\n - Prüfe offene Config-Transaktionen: `bash` mit `python3 nautobot/gc-transaktion.py status`.\n - Schreibe `docs/handoff-YYYYMMDD-thema.md` mit: Titel, Ausgangslage (was erledigt, was läuft), offene Schritte, Fallen/Gotchas, Einstieg für die nächste Session.\n - Sag dem User, welche Datei erstellt wurde.\n\n3. Laden (`/handoff resume`):\n - Lese die neueste Handoff-Datei vollständig.\n - Gib Zusammenfassung: Thema, Stand, offene Schritte.\n - Frage: \"Soll ich die Arbeit aus dieser Handoff-Datei fortsetzen?\"\n\nWichtig: Keine Secrets in die Handoff-Datei schreiben. Verweise auf existierende Doku statt zu duplizieren. Ziel < 200 Zeilen."
|
|
}
|
|
}
|
|
}
|