From f63149a769aebe0062fd1939f68c3758f989815e Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Mon, 5 Oct 2026 19:05:02 +0200 Subject: [PATCH] TP48 (Gitea #75) angelegt: Recovery-Luecke + Ansible-Abloese-Evaluation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Anlass aus TP10-Abschluss: DDNS-Updater lebt als /system script auf dem Core, in keinem Template — Recovery von null haette ihn nicht. Systematische Klasse, nicht Einzelfund. - Gitea #75: TP48 mit status:todo + thema:nautobot-doku angelegt - docs/teilprojekte.md: Prosa-Abschnitt TP48 (Inventur + Evaluationsfragen) - Live gemessener Kernbefund: Nautobot ist heute nur TEILWEISE SSoT — datengetrieben sind nur Device-Felder, interfaces/IPs und zwei ConfigContexts; 7 VLAN-Defs, 37 bridge-port- und 19 bridge-vlan-Zeilen, Core-Firewall, NAT/Mangle/Queue/Routen stehen LITERAL im Jinja. Der Abloese-Vergleich lautet damit 'Ansible vs. Jinja-im-Repo', nicht 'vs. Nautobot-SSoT'. - Nebenbefund dokumentiert (nicht angefasst): WG-Hub-Privkey im Klartext im Recovery-Skript tp21-wan-wg-restore auf dem Core - Korrektur: 'Abloesung durch Komodo' (CLAUDE.md + Archiv) war eine Kategorie-Verwechslung — Komodo verwaltet Container, nicht RouterOS-Config; es kann diese Luecke nicht schliessen Co-Authored-By: Claude Opus 5 --- CLAUDE.md | 4 ++- docs/teilprojekte-archiv.md | 7 +++-- docs/teilprojekte.md | 55 +++++++++++++++++++++++++++++++++++++ 3 files changed, 63 insertions(+), 3 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index 4e2148c..5a81bfb 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -122,7 +122,9 @@ GW je VLAN = `.1` (crs326-core L3) · Mgmt VLAN99: core `.99.1`, branch `.99.2`, 🔴 **Ein GC-Recovery von null erzeugt einen Core, in den Nautobot nicht mehr per SSH kommt** — die Pipeline wäre tot. Gleiche Lücke wie die DHCP-Reservierungen. **Merkregel: was auf dem Gerät existiert, aber nicht im Template, ist eine Recovery-Lücke, auch wenn Compliance 140/140 grün meldet** — die Zahl - prüft nur, was gerendert wird. Ablösung durch Komodo (native MCP) geplant. + prüft nur, was gerendert wird. Systematisch erfasst in **[TP48](docs/teilprojekte.md#tp48)** (Gitea #75), + der auch prüft, ob Ansible Nautobot als SSoT ablösen kann. ⚠️ **Nicht Komodo** — es verwaltet Container, + nicht RouterOS-Config (frühere Notiz hier war eine Kategorie-Verwechslung). --- diff --git a/docs/teilprojekte-archiv.md b/docs/teilprojekte-archiv.md index af0659c..3b5839f 100644 --- a/docs/teilprojekte-archiv.md +++ b/docs/teilprojekte-archiv.md @@ -781,8 +781,11 @@ Quell-IP ohnehin im erlaubten Raum. Die Datei wurde gelöscht; die Erkenntnis st ### ⚠️ Offener Restpunkt (bewusst, eigener TP) **Recovery-Lücke:** das GC-Template rendert **kein `/system script` / `/system scheduler`**. -Ein Recovery von null hätte den DDNS-Updater nicht. Entscheidung vertagt (Ablösung durch Komodo -geplant) — nicht Teil von TP10. +Ein Recovery von null hätte den DDNS-Updater nicht. Nicht Teil von TP10 — +**übernommen von [TP48](teilprojekte.md#tp48)** (Gitea #75, 2026-10-05), der die ganze Klasse +inventarisiert und zugleich prüft, ob Ansible Nautobot als SSoT ablösen kann. +*(Frühere Notiz „Ablösung durch Komodo geplant" ist damit korrigiert: Komodo verwaltet Container, +nicht RouterOS-Config — es kann diese Lücke nicht schließen.)* diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 9f7b710..5dcf806 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -2321,6 +2321,61 @@ eigenes Modell braucht. --- + +### TP48 · Gitea #75 — Recovery-Lücke: Nicht-GC-Objekte + Evaluation Ansible als Nautobot-Ablösung + +> **Anlass:** beim Abschluss von **TP10** (2026-10-05) fiel auf, dass der DDNS-Updater als +> `/system script` + DHCP-Trigger auf `crs326-core` lebt und in **keinem** Template steht — ein +> Recovery von null hätte ihn nicht. Das ist eine **Klasse**, kein Einzelfund. Christophs Frage +> daraus: *„wäre ansible in der lage, nautobot vollständig als ssot abzulösen. 1 tool für +> doku/deployment und nicht mehrere … keine indiv-anpassungen falls einfach vermeidbar."* + +#### Teil 1 — Die Lücke (live geprüft 2026-10-05, `crs326-core`) + +| Objekt | In einem Template? | +|---|---| +| `tp10-ddns-bf4`, DHCP-Client `client1` `script=` | ❌ | +| `/system script environment cfDdnsToken` (**Secret**) | ❌ und darf nie (Secret-Gebot) | +| 8 Alt-Skripte aus TP21.1 (`tp21-dhcp-restore`, `tp21-wan-wg-restore`, …) | ❌ | +| `/system scheduler` | — (keiner vorhanden) | + +🔴 **Nebenbefund:** `tp21-wan-wg-restore` trägt den **WG-Hub-Privkey im Klartext** im Skript-Körper. +Das Skript liegt **nicht im Git** (nur auf dem Gerät), es ist also ein undokumentierter Recovery-Pfad +mit einem Secret darin. **Aufnehmen, nicht sofort anfassen** (Christoph 2026-10-05). + +**Warum unsichtbar:** GC prüft **29 ComplianceFeatures** — **keines** deckt `system script`, +`system scheduler` oder `script environment`. Die Compliance-Zahl prüft nur, **was gerendert wird**; +was nicht gerendert wird, ist per Definition nicht „drift". + +#### Teil 2 — Die Evaluation + +🔴 **Der Befund, der die Fragestellung verschiebt:** Nautobot ist **heute schon nur teilweise SSoT.** +Live gezählt im Template: **datengetrieben** sind nur Device-Felder, `interfaces.all()`, +`ip_addresses.all()` und zwei ConfigContexts (`dhcp_leases`, `firewall_filter`). **Literal im Jinja** +stehen: 7 VLAN-Definitionen, 37 `bridge-port`- und 19 `bridge-vlan`-Zeilen, die Core-Firewall, +NAT/Mangle/Queue/Routen. Der Ablöse-Vergleich lautet also nicht „Ansible vs. Nautobot-SSoT", sondern +„Ansible vs. **Jinja-im-Repo + Gitea + ein paar Nautobot-Felder**". + +| Rolle | Träger heute | Ansible-Äquivalent | +|---|---|---| +| TP-Index/Status | **Gitea** (seit TP36 — nicht Nautobot) | ❌ bleibt Gitea | +| Live-Gerätedaten (Compliance) | Nautobot DCIM + GC | ⚠️ Facts + `--check` | +| Soll-Config | GC-Templates (Jinja) | ✅ Templates/Inventar | +| Ist-Config | GC-Backup | ⚠️ `netcommon` backup | +| Doku/Inventar (133 Interfaces, 38 IPs, 54 Leases) | Nautobot DB | ❓ offen — Ansible hat keine DB | + +**Offene Punkte:** (1) was leistet Nautobot *unersetzlich* (Compliance-Historie, ConfigPlan-Audit, +GitRepository-Sync, Secret-Maskierung)? (2) Kann Ansible Inventar+Soll+Drift aus *einer* Git-Quelle +bedienen? (3) Migrationskosten: 29 Features + 7 `config_replace`-Regeln nachbauen? (4) **Wo bleibt +Doku**, wenn Ansible nur deployt? (5) Werden die heutigen Sonderfälle (Literal-Blöcke wegen bewusster +Schiefstände wie `ether2` in VLAN1) mit Ansible sauberer oder chaotischer? + +**Abgrenzung:** nicht TP21/TP22 (bauen GC auf), nicht TP46 (CF-SSoT). Berührt die Governance-Regel +„Config nur über Nautobot" — bei Trägerwechsel neu zu fassen. Verwandt: TP30 (der WG-Privkey ist ein +Rotations-Kandidat). **Ergebnis = Empfehlung mit Zahlen, keine Migration.** + +--- + ## Abgeschlossene Teilprojekte ▸ [`teilprojekte-archiv.md`](teilprojekte-archiv.md) **34 abgeschlossene TPs** liegen dort im Volltext, unverändert und mit eigenem Inhaltsverzeichnis.