TP48 — Recovery-Lücke: Nicht-GC-Objekte + Evaluation Ansible als Nautobot-Ablösung #75

New Issue

admin · 2026-10-05T19:04:37+02:00

admin commented

2026-10-05 19:04:37 +02:00

Anlass

Beim Abschluss von TP10 (DDNS-Updater, 2026-10-05) fiel auf: der Updater lebt als /system script + DHCP-Client-script-Trigger auf crs326-core — in keinem Template. Ein Recovery von null hätte ihn nicht. Das ist keine Einzelerscheinung, sondern eine systematische Klasse: Objekte, die auf dem Gerät existieren, aber in keinem Soll stehen und von keiner ComplianceRule bewacht werden.

Der Befund ist zugleich der Anlass für eine größere Frage: kann Ansible Nautobot als SSoT vollständig ablösen? Christoph-Anforderung (2026-10-05): „ansible ist durchaus eine option wert! wäre ansible in der lage, nautobot vollständig als ssot abzulösen. 1 tool für doku/deployment und nicht mehrere. und was ich auch gerne sehe: keine indiv-anpassungen falls einfach vermeidbar."

Teil 1 — Die Recovery-Lücke (Inventur)

Ist-Stand auf crs326-core (live geprüft 2026-10-05):

Objekt	Zweck	In einem Template?
`tp10-ddns-bf4`	DDNS-Updater (TP10)	❌
DHCP-Client `client1` `script=tp10-ddns-bf4`	Trigger für den Updater	❌
`/system script environment cfDdnsToken`	Secret (53 Zeichen)	❌ (und darf es nie — Secret-Gebot)
`/system script environment CFWanIP4Cur`	Idempotenz-Zustand	❌ (Laufzeit-State, korrekt)
8 Alt-Skripte (`tp21-dhcp-restore`, `tp21-wan-wg-restore`, `enable-dhcp-servers`, `show-state`, `dns-test`, `fetch-test`, `check-dhcp`, `envtest`)	Recovery-Helfer aus TP21.1	❌
`/system scheduler`	(keiner vorhanden — geprüft)	—

🔴 Nebenbefund, eigener Wert: tp21-wan-wg-restore trägt den WG-Hub-Privkey im Klartext im Skript-Körper:
private-key="9AFGAWR52MqhSizFwdI4RQX/aGpk3gnzka46oVvFfcU="
Das ist der Typ Secret, den TP22-Regel 1 schützt. Das Skript liegt nicht im Git (lebt nur auf dem Gerät), aber es ist ein Recovery-Pfad, den niemand dokumentiert hat. Aufnehmen, nicht sofort anfassen (Christoph-Entscheid 2026-10-05) — die Entscheidung (Skript härten? löschen? Secret nach /system script environment wie bei cfDdnsToken?) fällt mit der vollständigen Liste.

Warum die Lücke unsichtbar ist: Golden Config prüft 29 ComplianceFeatures (live gelesen) — bridge-port, ip-firewall-nat, wifi-* … — keines deckt /system script, /system scheduler oder /system script environment. Und die Compliance-Zahl läuft über config_replace-Maskierung (7 Regeln für Passphrase/Privkey/Password/Secret) — geprüft wird nur, was gerendert wird. Was nicht gerendert wird, ist per Definition nicht „drift".

🟡 Offene Inventur-Frage (nicht geraten): Gibt es weitere nicht-gerenderte Sektionen auf den anderen Geräten (ap1/ap2/ap3/branch)? Diese Session hat nur crs326-core geprüft. Teil der Arbeit.

Teil 2 — Die Evaluation: Ansible als Nautobot-Ablösung?

Was Nautobot heute tatsächlich leistet (live gemessen, nicht angenommen):

Rolle	Träger heute	Ansible-Äquivalent?
Index/Status der TPs	Gitea (seit TP36-Cutover — nicht Nautobot!)	❌ bleibt Gitea (Ansible ist kein Issue-Tracker)
Live-Gerätedaten (Compliance, RouterOS-Version)	Nautobot DCIM + GC	⚠️ teilweise — Ansible Facts + `--check` als Drift-Erkennung
Config-Soll	Nautobot GC Templates (Jinja)	✅ Ansible Templates/Inventar
Config-Ist	Nautobot GC Backup	⚠️ `ansible.netcommon` `gather_facts`/`backup`
Doku/Inventar (133 Interfaces, 38 IPs, 9 Devices, 54 DHCP-Leases)	Nautobot DB + ConfigContexts	❓ offen — Ansible hat keine DB; Inventar wäre YAML/Git

🔴 Der entscheidende Befund für die Bewertung: Nautobot ist heute schon nur teilweise SSoT. Live gezählt:

Datengetrieben (echt aus der Nautobot-DB): Device-Felder, obj.interfaces.all(), ip_addresses.all(), config_context.dhcp_leases, config_context.firewall_filter.
Literal im Jinja (Nautobot ist nicht die Quelle): 7 VLAN-Definitionen, 37 bridge-port-Zeilen, 19 bridge-vlan-Zeilen, die komplette Core-Firewall, NAT/Mangle/Queue/Routen.

⇒ Ein Ablöse-Vergleich führt also nicht „Ansible vs. volle Nautobot-SSoT", sondern „Ansible vs. Jinja-im-Repo + Gitea + ein paar Nautobot-Felder". Das verschiebt die Frage: Nautobot liefert weniger, als der Name SSoT vermuten lässt — die Templates sind zu großen Teilen ohnehin Handarbeit im Repo.

Zu klären in der Session:

Was leistet Nautobot unersetzlich? (Kandidaten: Compliance-Historie über Zeit, ConfigPlan-Deploy-Audit, GitRepository-Sync, Secret-Maskierung beim Backup)
Kann Ansible Geräte-Inventar + Soll + Drift aus einer Git-Quelle bedienen, sodass die Nautobot-DB entfällt?
Was kostet die Migration — wie viele der 29 ComplianceFeatures und 7 ConfigReplace-Regeln müssten nachgebaut werden?
Wo bleibt Doku? Christophs Wunsch ist „1 Tool für Doku/Deployment". Ansible ist Deployment; Doku (Interfaces, IP-Plan, DHCP-Reservierungen) hätte dann keinen Träger mehr → Klärungsbedarf.
Keine Individual-Anpassungen: prüfen, ob die heutigen Sonderfälle (Literal-Blöcke wegen „bewusster Schiefstände" wie ether2 in VLAN1) mit Ansible sauberer oder chaotischer würden.

Abgrenzung

Nicht TP21/TP22 (die bauen Nautobot GC auf) und nicht TP46 (CF/Tunnel-SSoT). Dies ist die Frage, ob der SSoT-Träger selbst der richtige ist.
Berührt die Governance-Regel „Config ausschließlich über Nautobot" (teilprojekte.md Kopf) — bei einem Trägerwechsel wäre sie neu zu fassen.
Verwandt: TP30 (Credentials — der WG-Privkey im Skript ist ein Rotations-Kandidat).

Status

Erst Inventur + Evaluation, kein Umbau. Ergebnis der Session = eine Empfehlung mit belegten Zahlen, keine fertige Migration.

Prosa-Abschnitt folgt in docs/teilprojekte.md.

## Anlass Beim Abschluss von **TP10** (DDNS-Updater, 2026-10-05) fiel auf: der Updater lebt als `/system script` + DHCP-Client-`script`-Trigger auf `crs326-core` — **in keinem Template**. Ein Recovery von null hätte ihn nicht. Das ist keine Einzelerscheinung, sondern eine **systematische Klasse**: Objekte, die auf dem Gerät existieren, aber in keinem Soll stehen und von keiner ComplianceRule bewacht werden. Der Befund ist zugleich der Anlass für eine **größere Frage**: **kann Ansible Nautobot als SSoT vollständig ablösen?** Christoph-Anforderung (2026-10-05): *„ansible ist durchaus eine option wert! wäre ansible in der lage, nautobot vollständig als ssot abzulösen. 1 tool für doku/deployment und nicht mehrere. und was ich auch gerne sehe: keine indiv-anpassungen falls einfach vermeidbar."* --- ## Teil 1 — Die Recovery-Lücke (Inventur) **Ist-Stand auf `crs326-core` (live geprüft 2026-10-05):** | Objekt | Zweck | In einem Template? | |---|---|---| | `tp10-ddns-bf4` | DDNS-Updater (TP10) | ❌ | | DHCP-Client `client1` `script=tp10-ddns-bf4` | Trigger für den Updater | ❌ | | `/system script environment cfDdnsToken` | **Secret** (53 Zeichen) | ❌ (und darf es nie — Secret-Gebot) | | `/system script environment CFWanIP4Cur` | Idempotenz-Zustand | ❌ (Laufzeit-State, korrekt) | | 8 Alt-Skripte (`tp21-dhcp-restore`, `tp21-wan-wg-restore`, `enable-dhcp-servers`, `show-state`, `dns-test`, `fetch-test`, `check-dhcp`, `envtest`) | Recovery-Helfer aus TP21.1 | ❌ | | `/system scheduler` | (keiner vorhanden — geprüft) | — | 🔴 **Nebenbefund, eigener Wert:** `tp21-wan-wg-restore` trägt den **WG-Hub-Privkey im Klartext** im Skript-Körper: `private-key="9AFGAWR52MqhSizFwdI4RQX/aGpk3gnzka46oVvFfcU="` Das ist der Typ Secret, den TP22-Regel 1 schützt. Das Skript liegt **nicht im Git** (lebt nur auf dem Gerät), aber es ist ein Recovery-Pfad, den niemand dokumentiert hat. **Aufnehmen, nicht sofort anfassen** (Christoph-Entscheid 2026-10-05) — die Entscheidung (Skript härten? löschen? Secret nach `/system script environment` wie bei `cfDdnsToken`?) fällt mit der vollständigen Liste. **Warum die Lücke unsichtbar ist:** Golden Config prüft **29 ComplianceFeatures** (live gelesen) — `bridge-port`, `ip-firewall-nat`, `wifi-*` … — **keines** deckt `/system script`, `/system scheduler` oder `/system script environment`. Und die Compliance-Zahl läuft über `config_replace`-Maskierung (7 Regeln für Passphrase/Privkey/Password/Secret) — geprüft wird nur, **was gerendert wird**. Was nicht gerendert wird, ist per Definition nicht „drift". 🟡 **Offene Inventur-Frage (nicht geraten):** Gibt es weitere nicht-gerenderte Sektionen auf den anderen Geräten (ap1/ap2/ap3/branch)? Diese Session hat nur `crs326-core` geprüft. Teil der Arbeit. --- ## Teil 2 — Die Evaluation: Ansible als Nautobot-Ablösung? **Was Nautobot heute tatsächlich leistet (live gemessen, nicht angenommen):** | Rolle | Träger heute | Ansible-Äquivalent? | |---|---|---| | **Index/Status der TPs** | **Gitea** (seit TP36-Cutover — *nicht* Nautobot!) | ❌ bleibt Gitea (Ansible ist kein Issue-Tracker) | | **Live-Gerätedaten** (Compliance, RouterOS-Version) | Nautobot DCIM + GC | ⚠️ teilweise — Ansible Facts + `--check` als Drift-Erkennung | | **Config-Soll** | Nautobot GC Templates (Jinja) | ✅ Ansible Templates/Inventar | | **Config-Ist** | Nautobot GC Backup | ⚠️ `ansible.netcommon` `gather_facts`/`backup` | | **Doku/Inventar** (133 Interfaces, 38 IPs, 9 Devices, 54 DHCP-Leases) | Nautobot DB + ConfigContexts | ❓ offen — Ansible hat keine DB; Inventar wäre YAML/Git | 🔴 **Der entscheidende Befund für die Bewertung:** Nautobot ist **heute schon nur teilweise SSoT.** Live gezählt: - **Datengetrieben** (echt aus der Nautobot-DB): Device-Felder, `obj.interfaces.all()`, `ip_addresses.all()`, `config_context.dhcp_leases`, `config_context.firewall_filter`. - **Literal im Jinja** (Nautobot ist *nicht* die Quelle): 7 VLAN-Definitionen, **37** `bridge-port`-Zeilen, **19** `bridge-vlan`-Zeilen, die komplette Core-Firewall, NAT/Mangle/Queue/Routen. ⇒ Ein Ablöse-Vergleich führt also nicht „Ansible vs. volle Nautobot-SSoT", sondern „Ansible vs. **Jinja-im-Repo + Gitea + ein paar Nautobot-Felder**". Das verschiebt die Frage: Nautobot liefert weniger, als der Name SSoT vermuten lässt — die Templates sind zu großen Teilen ohnehin Handarbeit im Repo. **Zu klären in der Session:** 1. Was leistet Nautobot **unersetzlich**? (Kandidaten: Compliance-Historie über Zeit, ConfigPlan-Deploy-Audit, GitRepository-Sync, Secret-Maskierung beim Backup) 2. Kann Ansible **Geräte-Inventar + Soll + Drift** aus **einer** Git-Quelle bedienen, sodass die Nautobot-DB entfällt? 3. Was kostet die Migration — wie viele der 29 ComplianceFeatures und 7 ConfigReplace-Regeln müssten nachgebaut werden? 4. **Wo bleibt Doku?** Christophs Wunsch ist „1 Tool für Doku/Deployment". Ansible ist Deployment; Doku (Interfaces, IP-Plan, DHCP-Reservierungen) hätte dann keinen Träger mehr → Klärungsbedarf. 5. **Keine Individual-Anpassungen:** prüfen, ob die heutigen Sonderfälle (Literal-Blöcke wegen „bewusster Schiefstände" wie `ether2` in VLAN1) mit Ansible sauberer oder chaotischer würden. --- ## Abgrenzung - **Nicht** TP21/TP22 (die bauen Nautobot GC auf) und **nicht** TP46 (CF/Tunnel-SSoT). Dies ist die Frage, ob der SSoT-Träger **selbst** der richtige ist. - **Berührt** die Governance-Regel „Config ausschließlich über Nautobot" (`teilprojekte.md` Kopf) — bei einem Trägerwechsel wäre sie neu zu fassen. - **Verwandt:** TP30 (Credentials — der WG-Privkey im Skript ist ein Rotations-Kandidat). ## Status Erst **Inventur + Evaluation**, kein Umbau. Ergebnis der Session = eine Empfehlung mit belegten Zahlen, keine fertige Migration. Prosa-Abschnitt folgt in `docs/teilprojekte.md`.

admin added the status:todo thema:nautobot-doku labels 2026-10-05 19:04:37 +02:00

admin referenced this issue from a commit

2026-10-05 19:05:05 +02:00

TP48 (Gitea #75) angelegt: Recovery-Luecke + Ansible-Abloese-Evaluation

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: admin/bf-infra#75