Files

Christoph Emsenhuber 6f8ba8c8b5 sshpass -p repo-weit weg + vier TP15-Cutover-Skripte archiviert

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>

2026-08-31 08:34:08 +02:00

4.1 KiB

Raw Blame History

📦 ARCHIV — TP15/TP21.1 Core-Cutover (2026-08-06 … 2026-08-08)

Dieses Verzeichnis ist Historie. Die Skripte sind ERLEDIGT und werden nicht mehr ausgeführt. Sie haben den Umzug des L3-Routers von ap1 auf crs326-core begleitet — Backup davor, Staged-Config einspielen, Restore als Rückweg. Der Cutover ist am 2026-08-08 durchgezogen; seither ist crs326-core der produktive L3-Router und ap1 ein reiner CAP. Archiviert am 2026-08-31 auf Christophs Entscheid. Projektkonvention ist fortschreiben statt löschen — dieselbe wie bei switch/.

🔴 Warum sie nicht liegen bleiben durften, wo sie lagen

Alle vier zeigten auf Adressen, die es nicht mehr gibt — und einer davon ist nicht harmlos kaputt, sondern falsch. Live geprüft am 2026-08-31:

Datei	Ziel-IP im Code	Realität
`apply-core-cutover-l3.py`	`10.40.41.211`	❌ tot — das VLAN-Schema `10.40.41.x` ist seit 2026-08-27 abgeschafft
`backup-core.py`	`10.40.41.211`	❌ tot, dito
`restore-core.py`	`192.168.88.1`	❌ tot — Werks-Temp-Pfad; dazu ein hartkodierter Backup-Dateiname vom 2026-08-06
`backup-ap1.py`	`10.40.10.1`	🔴 antwortet — ist aber der CORE (VLAN10-SVI, tcp/22 offen). ap1 ist seit dem Cutover `10.40.99.11`.

🔑 Die Merkregel aus backup-ap1.py ist die wichtigste Zeile in dieser Datei: das Skript wäre nicht gescheitert. Es hätte den Core gesichert und die Datei ap1-pre-core-cutover-*.backup genannt. Wer so ein Backup Monate später zurückspielt, spielt eine Core-Config auf einen AP. Ein Skript, das still das falsche Gerät trifft, ist gefährlicher als eines, das gar nicht läuft — deshalb liegt es hier und nicht mehr neben den benutzbaren Werkzeugen.

Was hier nicht mehr gilt

Datei	Status
`apply-core-cutover-l3.py`	❌ nicht ausführen — tote IP; liest zudem `../tp15-core-cutover-intended.rsc`, das gitignored ist und durch den Verzeichniswechsel ohnehin nicht mehr gefunden würde
`backup-core.py`	❌ nicht ausführen — tote IP; schriebe seine Ausgabe jetzt in dieses Archivverzeichnis (`OUT_DIR = Path(__file__).parent`)
`restore-core.py`	❌ nicht ausführen — tote IP + Dateiname von 2026-08-06
`backup-ap1.py`	🔴 auf keinen Fall ausführen — s. oben, es trifft das falsche Gerät

⚠️ Die Pfad-Nebenwirkungen des Verschiebens sind absichtlich nicht repariert. Sie zu reparieren hieße, die Skripte wieder lauffähig zu machen — das ist genau nicht die Absicht.

✅ Was an ihnen trotzdem noch gepflegt wurde

Am 2026-08-31 sind sie — vor dem Archivieren — von sshpass -p <PW> auf SSHPASS-Env + sshpass -e umgestellt worden, zusammen mit nautobot/gc-transaktion.py und ../import-core-rsc.py. Grund: -p schreibt das Passwort in argv, wo es in ps und jedem argv-Trace steht — so ist am 2026-08-22 das Core-Passwort verbrannt. Auch Archiv-Code wird kopiert. Wer hier ein Muster abschreibt, soll das richtige abschreiben.

In apply-core-cutover-l3.py wurde dabei ein latenter Bug mitgefixt: run_silent griff auf ein pw zu, das in der Funktion gar nicht existierte — jeder Fehlerfall endete in einem NameError statt in der gedachten Meldung.

Wo die Wahrheit heute steht

Ist-Stand + TP-Steuerung: docs/teilprojekte.md
Config-Weg für Netzgeräte: ausschließlich Nautobot Golden Config (TP21/TP22) — nautobot/gc-configplan.py, Teständerungen als Transaktion über nautobot/gc-transaktion.py
Backup eines Geräts heute: /system backup save direkt am Gerät (so ist am 2026-08-31 pre-tp25-funde-ftoverds.backup auf dem Core entstanden) — kein Skript nötig
Aktuelle Adressen: crs326-core 10.40.99.1 · crs326-branch 10.40.99.2 · ap1 10.40.99.11 · ap2 10.40.99.12 · ap3 10.40.99.13
Interaktiv/Debug: MikroMCP · noch benutzbar geblieben: ../import-core-rsc.py (generisch, aber ebenfalls mit totem Default-Host — --host mitgeben)

4.1 KiB Raw Blame History