Christoph Emsenhuber
07b595c45a
Zwei Sessions haben denselben Fall bewertet und kamen zu entgegengesetzten Schluessen. Aufgeloest zugunsten der Kollektor-Messung. Der Widerspruch und sein Beleg: - Die Nacht-Session las `get_log ... sinceMinutes=1440` -> total 0 und schloss auf "Fund E geheilt, Hebel 1 committen". Das ist der FLUECHTIGE Ringpuffer des Routers: live nachgemessen 1000 Zeilen, aeltester Eintrag 01.09. 00:38:58 -- keine 9 h Tiefe. Der Core-Reboot 14:36 hatte ihn geleert, der 31.08. Vormittag war darin nicht enthalten. "total 0" hiess "im Puffer nichts", nicht "in 24 h nichts" -- genau die Falle, wegen der am 30.08. der Kollektor gebaut wurde. - Im Kollektor stehen fuer 08:09-14:36 (Hebel 1 ALLEIN, vor dem Upgrade) 124x reauthenticating: 09h=1, 11h=2, 12h=20, 13h=31, 14h=70 -- alle vom iPhone allein, also Client-Befund nach der eigenen Merkregel. Dazu Christophs zwei erlebte Ausfaelle 13:16 und 14:23. Zwischen 09:00 und 14:36 lag kein Reboot. Daraus gehandelt (User-Entscheid: symmetrisch am Geraet, jetzt): - Backup pre-tp25-funde-rollback, dann ft-over-ds=yes + remote-cap provision - Rueckbau-Diff zeigte genau eine Abweichung, kein Kollateral - Abnahme: CAPs durchgehend Ok, ap2 9/9 und ap3 9/9 running, frische DHCP-Lease (~1 min alt), Transaktion "zurueckgebaut", Compliance 140/140 - Der Rueckbau IST das Experiment: bleibt es ruhig, war 7.24.1 die Ursache; kehrt das Haemmern zurueck, hatte die Nacht-Session recht. Bis zur Messung am 2026-09-02 frueh committet niemand. Zwei Nebenbefunde: - gc-configplan.py --refresh-compliance scheitert STILL ohne NAUTOBOT_TOKEN: Meldung ausgegeben, aber Exit-Code 0. Gehoert gefixt. - Compliance ist 140/140, nicht 135/135: es gibt eine 28. ComplianceRule `interface-veth`, angelegt 31.08. 20:04, Urheber offen. Der ap2-Befund der Nacht-Session (2 m Abstand, -80 dBm, 0 Clients auf ap2) bleibt unberuehrt gueltig und ist weiter der beste Hinweis auf die 23:02-Stoerung. CLAUDE.md enthaelt in diesem Commit auch deren TP16.3-Zeile (gemeinsame Datei, Hunks nicht trennbar). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Transaktionen — Teständerungen mit Ablaufdatum
Hier liegen die Akten offener und geschlossener Config-Transaktionen. Werkzeug:
nautobot/gc-transaktion.py.
Wozu
Eine Änderung, die am Gerät steht, aber nicht in der SoT, ist Drift — und Drift sieht bisher immer gleich aus, egal ob er ein Versehen ist oder ein laufender Versuch. Wer testen wollte, hatte die Wahl zwischen „Compliance kaputt" und „gar nicht testen".
Eine Transaktion macht die Absicht sichtbar, ohne die Governance aufzuweichen: der Change geht
weiterhin ausschließlich über Golden Config (gc-manual-plan.py), und die Compliance meldet den
Drift weiterhin. Neu ist nur, dass status ihn zuordnen kann.
| SQL | hier |
|---|---|
BEGIN |
Snapshot des Scope-Abschnitts + Akte mit Gerät, Scope, Grund und Ablaufdatum |
| uncommitted | Change ist am Gerät wirksam und im Testumfeld sichtbar, aber nicht in der SoT |
COMMIT |
Template/Config-Context nachziehen → Compliance grün → Akte schließen |
ROLLBACK |
Rückbau-Vorschlag aus dem Snapshot, prüfen, deployen, Akte schließen |
Drei Regeln, die das Werkzeug erzwingt
--expiresist Pflicht. Eine offene Transaktion ohne Frist ist undokumentierter Drift mit besserem Gewissen.statusmarkiert überfällige Akten.- Der Scope ist eine ComplianceRule, kein Freibrief. Driftet etwas außerhalb des Scopes, meldet
statusdas ausdrücklich als nicht abgedeckt. - Eine offene Transaktion je Gerät — sonst ist beim Rollback nicht mehr entscheidbar, wohin zurück.
Zwei bewusste Grenzen
- Der Rollback pusht nicht selbst. Er schreibt einen Vorschlag aus dem Snapshot;
add-Zeilen aus einem/exportlegen neu an, statt zu ändern, und brauchen meist einset [find …]. Ein Rückbau, den niemand gelesen hat, ist genau die Sorte Automatik, die hier schon zweimal teuer war. - Der Snapshot enthält nur den Scope-Abschnitt. Ein voller
/exportenthält Firewall, Adressen, Benutzerliste und Skriptquellen — nichts davon wird für den Rückbau gebraucht, und diese Akten liegen im Git. Für den Ernstfall gibt es das binäre/system backupauf dem Gerät (--device-backup).
Dateien je Transaktion
| Datei | Inhalt |
|---|---|
<change-id>.json |
die Akte: Gerät, Scope, Grund, Fristen, Status |
<change-id>.snapshot.rsc |
der Scope-Abschnitt vor der Änderung |
<change-id>.commands.rsc |
was deployt wurde |
<change-id>.rollback.rsc |
erst nach rollback — der Vorschlag zum Prüfen |