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>
MCP-Control-Plane — BF
Zentrale, versionierte MCP-Server für BF. Übersicht aller MCPs: INVENTORY.md. Ziel: ein nachvollziehbarer Satz MCPs (gegen "1000 MCP-Leichen"), zentral als Container, FQDN-adressiert.
MikroMCP (MikroTik ap1/ap2)
REST-primär + guarded SSH; RouterOS-7-nativ; Safety: dry-run, plan_changes/apply_plan/rollback_change,
Confirmation-Tokens, RBAC, Audit-Log. Image: ghcr.io/alikarami/mikromcp:latest.
Zwei Betriebsarten
- A — lokal stdio (schnell, kein Netz-Exposure): läuft dort wo Claude läuft, RBAC = built-in superadmin, keine Tokens/Secret nötig. Gut für sofortige WLAN-Arbeit. Trotzdem in INVENTORY eintragen.
- B — Docker HTTP auf Mac mini (zentral, Ziel):
docker-compose.yml. Erfordert Confirmation-Secret + Bearer-Token-Identität. Endpoint später hinter NPM (FQDN+Auth).
RouterOS-User (beide APs) — NICHT admin verwenden
/user group add name=mcp policy=read,write,api,rest-api,test,ssh,sniff,!ftp,!policy,!password
/user add name=mcp-api group=mcp password=<stark>
(ftp nur falls upload_file gebraucht wird; sniff nur für torch. SSH-Dienst muss laufen für
ping/traceroute/torch/run_command — REST blockt diese Befehle generell.)
B deployen (Mac mini 10.40.41.167)
openssl rand -hex 32 # -> MIKROMCP_CONFIRMATION_SECRET
# identities.yaml aus identities.example.yaml bauen (Token: openssl rand -hex 32, dann bcrypt-Hash):
node -e "const b=require('bcryptjs');b.hash(process.argv[1],12).then(console.log)" <raw-token>
scp -r mcp/mikromcp 10.40.41.167:/opt/docker/mikromcp
ssh 10.40.41.167 'cd /opt/docker/mikromcp && cp .env.example .env' # .env + config/identities.yaml füllen
ssh 10.40.41.167 'cd /opt/docker/mikromcp && docker compose up -d && docker compose logs --tail=50'
Smoke-Test: curl -s http://10.40.41.167:3000/health bzw. MCP-Initialize mit Bearer-Token.
In Claude Code einhängen
- A (stdio):
claude mcp add mikromcp -- npx -y mikromcp+ ENV (MIKROMCP_CONFIG_PATH,ROUTER_AP1_USER/PASS, …). - B (http):
claude mcp add --transport http mikromcp http://10.40.41.167:3000(HeaderAuthorization: Bearer <raw-token>). Nach FQDN: URL aufhttps://<fqdn>umstellen.
omada-mcp (TP-Link ES208G)
Wartet auf: Omada-Controller (≥6.1.x, ../../omada/docker-compose.yml, Ziel pve-LXC 10.40.41.126) up +
ES208G adoptiert. Env: OMADA_BASE_URL, OMADA_CLIENT_ID/SECRET, OMADA_OMADAC_ID, OMADA_SITE_ID,
OMADA_STRICT_SSL=false (self-signed). Tools: Switch-Ports/VLAN/Firewall CRUD. Details: INVENTORY.md.
Sicherheit (wichtig)
Ein MikroMCP/omada-mcp-HTTP-Endpoint kann Infrastruktur administrieren. Daher: nur auf LAN-IP binden, dedizierte Nicht-admin-User, Confirmation-Secret gesetzt, Audit-Log an, später NPM+Auth+TLS+FQDN davor.