e9a5b36ecb54025ae0a689f61e6a37fc40a61cc0
Vor dem Rotieren den Radius erhoben -- und der ist groesser als geplant: das Admin-Konto teilen sich fuenf Konsumenten. Neben ~/.secrets und der MikroMCP-Registry haengen der Nautobot-Stack (Portainer-Redeploy noetig) und VIER HA-mikrotik-Integrationen mit 40 device_tracker daran. Die HA- Eintraege melden supports_reconfigure=false, sind also nicht skriptbar. Christophs Entscheid daraufhin: Konten trennen statt ein Passwort teilen. Nicht das Rotieren ist das Problem, sondern dass ein einziges admin von fuenf Stellen benutzt wird -- sonst kostet jede Rotation wieder vier Re-Auths und einen Stack-Redeploy. Etappe 1 ist durch, rein additiv, kein laufender Dienst beruehrt. Vorher existierte auf allen vier Geraeten nur admin in der Gruppe full. Jetzt: grp-ha read,api,rest-api,test -> user ha grp-nautobot ssh,read,write,test,sensitive -> user nautobot Passwoerter als MIKROTIK_HA_PASS / MIKROTIK_NAUTOBOT_PASS in ~/.secrets. Angelegt ueber ein Skript, das die Werte aus der Datei liest -- bewusst nicht ueber manage_user, dessen password-Parameter im Transkript landet. Abnahme auf allen vier Geraeten: ha liest (am Core 59 DHCP-Leases) und wird beim Schreiben abgewiesen; nautobot kommt per SSH rein und exportiert. Der Export von nautobot ist byte-identisch zu dem von admin (391/56/87/87 Zeilen) -- die GC-Compliance driftet beim Umstellen also nicht, was das Hauptrisiko dieser Etappe war. /user wird von keiner ComplianceRule abgedeckt, die Konten erzeugen selbst keinen Drift. Offen: Konsumenten umhaengen (Nautobot-Stack, 4x HA), dann erst admin rotieren -- danach beruehrt eine Rotation nur noch zwei Dateien. Eigener Fehler protokolliert: eine Enumeration hat das ap1-Passwort im Klartext ins Transkript geschrieben. Selber Wert wie der am 22.08. verbrannte, also keine neue Expositionsklasse -- aber Merkregel ergaenzt, dass Secrets-Enumeration nur Schluesselnamen ausgibt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
docs 🧭 Governance „Config nur via Nautobot" + TP19.1-Stand (ap1-DNS ✅, ap2 vertagt), sw2-IP-Korrektur .41.181, VLAN99-Cutover-Guides sw1/sw2, TP15-Lieferung 17.07., TP20 an Komodo gebunden
bf-network-r6
BF-Netzwerk-Migration (Variante R6+C2). 2× MikroTik hAP ax² + Core ALL-SG8316M.
SSOT & Übergabe: HANDOVER.md — kompletter Status, Architektur + Begründungen, Phasen, Gotchas, Zugänge.
Plan-Origin: ~/.claude/plans/welche-kosteng-nstigen-alternativen-zu-memoized-sparkle.md
Struktur:
docs/vlan-plan.md— VLAN-/Adressplan (final)docs/core-switch-prep.md— Core-Switch Status & Phasendocs/firmware-flash-runbook.md— FW-Flash Historieswitch/cli/CLI-REFERENCE.md— bestätigte CLI-Syntaxswitch/cli/*.cli/*.exp— reproduzierbare Konfig-Scriptsinventory/bf.csv/bf.md— IP-Doku (aus IPs.xlsx gespiegelt)inventory/bf-core-ports.csv/.md— Switch-Port-Map
Aktueller Stand (2026-06-09):
- Phase A (VLAN-Vorbereitung) ✅ abgeschlossen
- Phase B (hAP-Cutover) ⏳ wartet auf MikroTik-Lieferung
- Phase C (Firewall) + Phase D (Adress-Migration) ausstehend
Description
BF-Infrastruktur (Fork von bf-network-r6): MikroTik, Caddy, AGH, Nautobot/GC, MCPs. Master seit 2026-08-27.
Languages
Python
57.9%
RouterOS Script
33.8%
Jinja
6.6%
Shell
1.7%