Christoph Emsenhuber
6f8ba8c8b5
sshpass -p schreibt das Passwort in argv, wo es in ps und jedem argv-Trace steht -- die Klasse, an der am 2026-08-22 das Core-Passwort verbrannt ist. Nach gc-transaktion.py (voriger Commit) jetzt auch die fuenf unter routeros/: SSHPASS-Env + sshpass -e. Nachweis, gemessen statt gelesen: - alle 13 subprocess.run mit sshpass tragen env= (per AST geprueft; ohne env waere SSHPASS leer und alles still kaputt) - Signaturen passen zu den Aufrufen (AST-Arity; py_compile findet das NICHT) - echter Lauf des gepatchten Codes gegen den lebenden Core: backup-core.py importiert, IP zur Laufzeit auf 10.40.99.1 -> "name: crs326-core", rc=0 - Passwort in argv? nein. In ps waehrend der Verbindung? nein, 40 Stichproben - Negativkontrolle: derselbe Test mit einem Dummy-Wert ueber die alte -p-Form -> 36 Treffer. Die Probe ist also nicht blind, das "nein" hat Aussagekraft Mitgefixt, weil es im umgebauten Code lag: apply-core-cutover-l3.py griff in run_silent auf ein pw zu, das dort gar nicht existierte -- jeder Fehlerfall endete in einem NameError statt in der gedachten Meldung. Fuer TP30 aendert das NICHTS: der Weg ist zu, der Wert bleibt verbrannt. Posten #1 (MikroTik-admin) bleibt faellig. Im TP so hingeschrieben, damit es niemand als erledigt liest. --- Archivierung (Christoph-Entscheid) --- Beim Fixen fiel auf, dass alle vier Cutover-Skripte auf tote Adressen zeigten: apply-core-cutover-l3.py 10.40.41.211 tot (VLAN41 seit 2026-08-27 weg) backup-core.py 10.40.41.211 tot restore-core.py 192.168.88.1 tot (Werks-Temp-Pfad) backup-ap1.py 10.40.10.1 ANTWORTET -- ist aber der CORE backup-ap1.py war der gefaehrliche: er waere nicht gescheitert, er haette den Core gesichert und die Datei ap1-pre-core-cutover-*.backup genannt. Wer das spaeter zurueckspielt, spielt Core-Config auf einen AP. Entscheid war archivieren, nicht reparieren -- der Cutover ist am 2026-08-08 durch, die Skripte haben ihre Aufgabe erfuellt. Sie liegen jetzt unter routeros/archiv-tp15-cutover/ mit README nach dem Muster von switch/. Die Pfad-Nebenwirkungen des Verschiebens sind ABSICHTLICH nicht repariert (backup-core.py schriebe jetzt ins Archivverzeichnis, apply-core-cutover-l3.py faende seine .rsc nicht mehr) -- sie zu reparieren hiesse, die Skripte wieder lauffaehig zu machen, und das ist gerade nicht die Absicht. Der sshpass-Fix wurde trotzdem VOR dem Verschieben gemacht: Archiv-Code wird abgeschrieben, also soll dort das richtige Muster stehen. import-core-rsc.py bleibt, wo es ist -- als einziges generisch nuetzlich. Sein Default-Host ist ebenfalls tot (--host mitgeben), und in --host steckt ein zweiter latenter Bug: sys.argv[1] wird als RSC-Pfad gelesen, bevor auf --host geprueft wird. NICHT gefixt, eigene Runde. Zeiger gesetzt in: CLAUDE.md (sshpass-Gotcha), teilprojekte.md (TP30), teilprojekte-archiv.md (TP15), Handoff 2026-08-31. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
bf-infra
BF-Netzwerk-Infrastruktur (Caddy, AGH, MikroTik-Konfig, Dokumentation, MCPs).
Aktiver Fork von bf-network-r6 (Claude-Code-Architektur, 2025-2026), ab August 2026
unter OpenCode und anderem LLM weitergepflegt.
Master-Struktur
| Repo | Rolle | Stand |
|---|---|---|
~/dev/bf-infra/ (lokal) |
Aktiver Master, Working-Copy | kein Gitea-Remote (Sicherheitslücke, offen) |
admin/bf-network-r6 (Gitea) |
Archiv, historischer Master | read-only-Header, letzte aktive Commits 2026-08-25 |
admin/bf-golden-config (Gitea) |
Bot-Master (Nautobot 2×/Tag) | intended/ + backups/, nicht manuell |
admin/blaueblueten-n8n (Gitea) |
Master für terpene-Repo | aktiv, lokal synchron |
Was hier lebt
docs/teilprojekte.md— kanonische Steuerung (Ist-Stand, offene TPs, kritischer Pffad)docs/teilprojekte-archiv.md— abgeschlossene TPs (Volltext)docs/handoff-*.md— Session-Übergabencaddy/Caddyfile— Reverse-Proxy BF (siehe TP34 für Migration zu Nautobot/GC)nautobot/— Skripte + Jinja-Template für Golden Configmcp/— MCP-Server-Inventar (SSoT gegen „1000 MCP-Leichen")inventory/— entfernt 2026-08-27 (Pipeline seit 2025-06 stale; Live-Daten via MikroMCP/CF/Portainer)
Status (2026-08-27)
- L3 + WAN-Edge =
crs326-core, alle 4 MikroTik auf RouterOS 7.24 (TP27) - Firewall deny-by-default seit 2026-08-18 (TP5)
- WLAN via CAPsMAN auf dem Core seit 2026-08-17 (TP28)
- Compliance 104/104 grün, 0 Drifts (Golden Config, TP22)
- AdGuard-Paar
agh-bf1/agh-bf2aufgebaut, DHCP noch nicht umgestellt (TP23 Stufe 2 / TP31 Schritt 4) - Caddyfile Reverse-Proxy seit 2026-08-25 (TP31), 16 Sites BF-intern
- terpene.teilzeitladen.xyz: Worker läuft auf Mac mini (10.40.20.167:8890), kein Caddy-Block, kein CF-Tunnel — Backfill via DB-Migration blockiert (Handoff 2026-08-27)
Übergangspfad von bf-network-r6 → bf-infra
- README + Strukturen aktualisiert (dieses File)
- bf-network-r6 im Gitea auf read-only, Header mit Verweis (deine Aktion)
- Inventar-Pipeline gelöscht (XLSX stale, MikroMCP/CF/Portainer liefern Live)
- Caddyfile-Master wandert zu Nautobot/GC (TP34, siehe Handoff 2026-08-27)
- bf-infra bekommt Gitea-Remote (offen, „später")
Werkzeuge (Stand 2026-08-27)
- MikroMCP (RouterOS, 4 Geräte) —
~/.claude.json+opencode.jsonc - pve-mcp (Proxmox, 10.40.20.173) —
opencode.jsonc - home-assistant (HA, 10.40.20.105) —
opencode.jsonc - cloudflare (CF-API, OAuth) —
opencode.jsonc - gitea-mcp (FQDN) —
opencode.jsonc - komodo-mcp (geplant, Migration von Portainer) —
~/dev/bf-infra/mcp/komodo/ - shelly-mcp (Client-lokal Interim, 127.0.0.1:3030) — vor Migration auf zentralen Container