TP48 (Gitea #75) angelegt: Recovery-Luecke + Ansible-Abloese-Evaluation
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 <noreply@anthropic.com>
This commit is contained in:
@@ -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
|
🔴 **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,
|
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
|
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).
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|||||||
@@ -781,8 +781,11 @@ Quell-IP ohnehin im erlaubten Raum. Die Datei wurde gelöscht; die Erkenntnis st
|
|||||||
|
|
||||||
### ⚠️ Offener Restpunkt (bewusst, eigener TP)
|
### ⚠️ Offener Restpunkt (bewusst, eigener TP)
|
||||||
**Recovery-Lücke:** das GC-Template rendert **kein `/system script` / `/system scheduler`**.
|
**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
|
Ein Recovery von null hätte den DDNS-Updater nicht. Nicht Teil von TP10 —
|
||||||
geplant) — 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.)*
|
||||||
|
|
||||||
|
|
||||||
<a id="tp14"></a>
|
<a id="tp14"></a>
|
||||||
|
|||||||
@@ -2321,6 +2321,61 @@ eigenes Modell braucht.
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
<a id="tp48"></a>
|
||||||
|
### 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)
|
## Abgeschlossene Teilprojekte ▸ [`teilprojekte-archiv.md`](teilprojekte-archiv.md)
|
||||||
|
|
||||||
**34 abgeschlossene TPs** liegen dort im Volltext, unverändert und mit eigenem Inhaltsverzeichnis.
|
**34 abgeschlossene TPs** liegen dort im Volltext, unverändert und mit eigenem Inhaltsverzeichnis.
|
||||||
|
|||||||
Reference in New Issue
Block a user