Files
bf-infra/docs/transaktionen
Christoph Emsenhuber 6c2297ad95 Sideboard-Test zurueckgebaut, und was dabei nicht verschwindet
TEST-ether3-trunk-ap1-sideboard ist zurueckgerollt und geschlossen: ether3
faellt aus allen tagged-Listen und ist in VLAN40 wieder untagged (Sideboard-
Access-Port). Am Geraet gegengeprueft, Snapshot-Diff leer. crs326-core ist
damit transaktionsfrei.

TP25 Fund (G): ap1 am Sideboard richtet das Wohnzimmer nicht und kostet das
Schlafzimmer (-61 -> -83 dBm). Die Idee "ap1 ersetzt den Sideboard-Switch" ist
damit entschieden -- nein, Platzierung vor eingespartem Geraet. ap2 haengt
jetzt auf 2,5 m, Terrasse subjektiv besser, Nachmessung steht aus.

Korrektur im selben Zug: die erste Fassung von (G) behauptete, der Steering-
Fall entfalle mit dem Rollback. Falsch -- es entfaellt nur die konkrete
Auspraegung. Fund B und C wurden am 08-20 mit ap1 auf ether15 gemessen, also
in genau der Stellung, in die wir zurueckgebaut haben; der Defekt ist
platzierungsunabhaengig und verlagert sich nur. Fund E bleibt die Massnahme
und ist jetzt oberster offener Punkt.

TP12.1 neu (unter TP12, kein Duplikat daneben): Matter/Thread-Commissioning
scheitert an fehlendem IPv6-Routing zwischen VLAN10 und VLAN20 -- nicht an der
Firewall. Der Kostenpunkt des TP ist aber nicht die Adressvergabe, sondern
dass /ipv6 firewall filter leer ist: heute harmlos, ab der ersten Adresse ein
Loch an TP5 vorbei. Reihenfolge deshalb zwingend v6-Firewall vor Adressen.

Runbook + Kommandodateien fuer die temporaere dirtyvader-infra-SSID
(cfg-infra existiert bereits, haengt nur in keiner provisioning-Zeile).
Vorbereitet, nicht deployt.

Repo-lokalen projektstatus-Skill geloescht: er war seit 11. Juli stale
(harte Themenblöcke, kritischer Pfad von TP14.3) und wurde nicht geladen --
aktiv ist der globale.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-22 19:13:26 +02:00
..

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

  1. --expires ist Pflicht. Eine offene Transaktion ohne Frist ist undokumentierter Drift mit besserem Gewissen. status markiert überfällige Akten.
  2. Der Scope ist eine ComplianceRule, kein Freibrief. Driftet etwas außerhalb des Scopes, meldet status das ausdrücklich als nicht abgedeckt.
  3. 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 /export legen neu an, statt zu ändern, und brauchen meist ein set [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 /export enthä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 backup auf 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