From 709cc626bbf903c057b0cdfec19c9349aa3fe1ed Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Sun, 30 Aug 2026 12:19:24 +0200 Subject: [PATCH] TP37 angelegt: Nautobot als durchgehende Netzwerkdoku (CF-Connectoren als erster Fall) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit User-Okay 2026-08-30. Auslöser ist der TP16.3-Schnitt: um ihn zu planen, mussten sechs cloudflared-Container über drei Hosts per SSH und Portainer-API zusammengesucht werden -- die Zuordnung Tunnel->Connector->Host existierte nirgends als Datensatz, nur in Prosa. Befund live gegen die Nautobot-API gelesen: Devices 8 (4 aktiv, 4 decommissioned), Apps nur golden-config ipam.Service 0 · CustomField 0 · Relationship 0 · VirtualMachine 0 · Tag 0 Nautobot kennt heute ausschliesslich die vier MikroTik. Weder Caddy noch AdGuard noch pve/NAS/macmini noch Nautobot selbst sind erfasst. Konsequenz fuer den Zuschnitt: TP37 ist zuerst eine Datenmodell-Frage (Substrat + Dienste), erst danach eine Connector-Frage. Damit liefert es das Fundament, das TP34 (Caddyfile via GC) und TP36 (SSoT fuer teilprojekte.md) ebenfalls brauchen -- Reihenfolge TP37 vor TP34, festgehalten in beiden. Abgrenzung explizit: kein Golden Config fuer Nicht-Netzgeraete (das ist TP34), keine Cloudflare-Writes aus Nautobot heraus. Einschraenkung benannt: die GC-Pipeline ist heute schlank und 104/104 compliant; Punkt 1-2 daher als eigener abnehmbarer Schritt mit Compliance-Gegenprobe, nicht als Nebeneffekt. Alle drei Stellen nachgezogen: Quick-Index, TP-Abschnitt, Ist-Stand-Block. Co-Authored-By: Claude Opus 5 --- docs/teilprojekte.md | 58 +++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 57 insertions(+), 1 deletion(-) diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 7d76996..dda1c6e 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -33,6 +33,13 @@ Mgmt (VLAN99, Ist 2026-08-16): core `.99.1` · branch `.99.2` · ap1 `.99.11` · liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur die TP-Abschnitte.)* - 🆕 **MCP-Bestand 2026-08-28 korrigiert:** **9 MCPs identisch** in `~/.claude.json` und `~/.config/opencode/opencode.jsonc` (vorher Asymmetrie 7 vs. 11 — `portainer-mcp`/`shelly-mcp` raus, `gitea-mcp`/`n8n-mcp` rein). **Mac mini = n8n-Host, NICHT zentraler MCP-Host** (Performance-Restriktion); zentraler MCP-Host = **DS923** (`nas-bf`, Portainer Endpoint 14). Inventur-Stand `mcp/INVENTORY.md` + Policy `docs/mcp-host-policy.md`. - 🆕 **MCP-Migration FQDN→IP (2026-08-29, TP35 Schicht 1):** `gitea-mcp` und `n8n-mcp` in `~/.config/opencode/opencode.jsonc` von CF-FQDN auf LAN-IP umgestellt — `gitea-mcp` → `http://10.40.20.167:3000/mcp` (macmini, **ohne** Bearer, intern), `n8n-mcp` → `http://10.40.20.167:3001/mcp` (mit `Bearer {env:N8N_MCP_BEARER}`). **Befund dabei:** der Handoff 1.2 nannte für gitea-mcp die falsche IP `.157:3000` (das ist die Gitea-Web-UI, `400 Invalid CSRF`); der echte gitea-mcp läuft auf `.167:3000` (`serverInfo: gitea-mcp 0.0.10`). `cloudflare`-MCP bleibt auf dem offiziellen FQDN (User-Direktive). +- 🆕 **TP37 angelegt (2026-08-30, User-Okay):** Nautobot soll durchgehende Netzwerkdoku werden, erster + Anwendungsfall die CF-Connectoren. 🔴 **Befund dabei, live gegen die API:** Nautobot kennt heute + **nur die 8 Netzgeräte** (4 aktiv, 4 decommissioned) — `ipam.Service`, `CustomField`, `Relationship`, + `VirtualMachine` und `Tag` sind **alle 0**, installiert ist nur `golden-config`. Kein Host, kein + Container, kein Dienst ist erfasst. **TP37 ist damit zuerst eine Datenmodell-Frage** und liefert das + Fundament, das **TP34** (Caddyfile via GC) und **TP36** (SSoT für diese Datei) ebenfalls brauchen — + Reihenfolge: **TP37 vor TP34**. - 🆕 **CF-Public-Strang eingedampft (2026-08-30, TP16.3 grosser Schnitt):** **12 Hostnames** aus Ingress **und** DNS entfernt — `pve`/`portainer`/`pve-mcp`/`ha-mcp`/`ds-bf`/`ccu`/`iobroker`/`z2m25`/`pbs` plus die drei CF-Access-SSH-Ziele. Ingress: `bf-mm` 6→4, `bf-nas` 6→3, `bf-pve` 9→2. **Öffentlich @@ -242,7 +249,7 @@ nachmessen und dann entscheiden**. Blocker gibt es keine mehr. TP5 ist in der Na > | TP34 | 🔜 | Caddyfile via Nautobot/GC (Stub, Inventur-Handoff 2026-08-27) | — | > | TP35 | ⏳ | MCP-Schichtung + 3-Schicht-CLAUDE.md + Backup-Guard (Schicht 1+3+6 ✅) | — | > | TP36 | 🔜 | SSoT via Nautobot für teilprojekte.md-Live-Daten + Datei-Aufteilung | — | -> | TP37 | 💡 | CF-Connectoren in Nautobot abbilden (**vorgeschlagen 2026-08-30, dein Okay fehlt**) | — | +> | TP37 | 🔜 | Nautobot als Netzwerkdoku: Hosts/Container/Dienste + CF-Connectoren (Okay 08-30) | — | > | — | — | **34 archivierte TPs** in `teilprojekte-archiv.md` | — | ### TP5.1 — DNS-Visibility & Flow-Observability für Low-Trust-Geräte (Airfryer-Fall) ▸ vorgemerkt @@ -2078,6 +2085,55 @@ kann in Ruhe nachziehen. --- +### TP37 — Nautobot als durchgehende Netzwerkdoku: Hosts/Container/Dienste, erster Anwendungsfall CF-Connectoren ▸ 🔜 ANGELEGT 2026-08-30 (User-Okay erteilt) +> **Christophs Formulierung (2026-08-30):** *„können wir das setup mit den cf-connectoren dann auch in +> nautobot abbilden. quasi eine durchgehende netzwerkdoku stück für stück. muss eh fast sein, da du auf +> den mikrotiks ja nur via gc/nautobot deployst."* + +- **Auslöser:** der TP16.3-Schnitt am 2026-08-30. Um ihn zu planen, mussten **sechs `cloudflared`-Container + über drei Hosts hinweg per SSH und Portainer-API zusammengesucht** werden (LXC400 `.126`, macmini `.167`, + NAS `.10`), und die Zuordnung Tunnel→Connector→Host existierte **nirgends als Datensatz** — nur verstreut + in Prosa. Dieselbe Suche fällt bei jedem weiteren Eingriff erneut an. +- 🔴 **Befund (live gegen die API gelesen 2026-08-30) — das Fundament fehlt, nicht nur die Connector-Zeilen:** + ``` + Devices: 8 (ap1, ap2, crs326-core, crs326-branch + cudy1/cudy2/sw1/sw2 decommissioned) + Apps: golden-config Platform: 1 (RouterOS) + ipam.Service: 0 · CustomField: 0 · Relationship: 0 · VirtualMachine: 0 · Tag: 0 + ``` + Nautobot kennt heute **ausschließlich die vier MikroTik**. Kein Host, kein Container, kein Dienst ist + erfasst — weder Caddy (`caddy-bf1`), noch AdGuard (`agh-bf1`/`bf2`), noch pve/NAS/macmini, noch Nautobot + selbst. ⇒ **TP37 ist zuerst eine Datenmodell-Frage, erst danach eine Connector-Frage.** +- **Scope (Vorschlag, Reihenfolge ist der Punkt):** + 1. **Substrat abbilden** — pve/NAS/macmini als Hosts, die LXCs und Docker-Container als + `virtualization.VirtualMachine` (Cluster je Host). Damit existiert erstmals ein Ort, an dem + „wo läuft was" steht. + 2. **Dienste abbilden** — `ipam.Service` je exponiertem Port (Caddy `:80/:443`, AdGuard `:53`, + Nautobot `:8080`, n8n `:5678`, …). Das ist Nautobot-Kernmodell, **keine eigene App nötig**. + 3. **CF-Connectoren als erster Anwendungsfall** — Tunnel (`bf-public`, historisch `bf-mm`/`bf-nas`/`bf-pve`) + als Objekt, Connector als Relation Tunnel↔Host, Ingress-Regel als Hostname→Backend-Paar. + Modellwahl offen: Custom Fields + Relationships auf Bestandsmodellen **oder** eine kleine eigene App. + 🔴 **Erst Punkt 1–2 entscheiden, dann diese Frage** — umgekehrt entsteht ein Modell für einen Sonderfall. + 4. **Drift-Check** — Skript liest CF-API (`cfd_tunnel` + `configurations`) und vergleicht gegen Nautobot, + analog `nautobot/gc-configplan.py --refresh-compliance`. **Read-only zuerst**; ob Nautobot je nach + Cloudflare *schreibt*, ist eine spätere, eigene Entscheidung. +- **Abgrenzung (wichtig, sonst überlappt es mit zwei offenen TPs):** + - **TP34** (Caddyfile via GC) rendert *Config aus Daten*. TP37 liefert **die Daten**, auf denen TP34 + aufsetzt — Punkt 1+2 sind TP34s fehlende Voraussetzung. **TP37 vor TP34.** + - **TP36** (SSoT für `teilprojekte.md`) rendert *Doku aus Daten* und braucht dieselben Custom Fields. + Läuft parallel, gleiches Fundament. + - **Nicht** in TP37: Golden Config für Nicht-Netzgeräte (Caddy/AdGuard deployen) — das ist TP34. + **Nicht** in TP37: Cloudflare-Writes aus Nautobot heraus. +- **Abh.:** TP21/TP22 ✅ (Nautobot + GC-Pipeline stehen) · TP32 ✅ (Nummern-Systematik liefert die + Klassifikation für Punkt 1) · TP16.3 (liefert den Anwendungsfall und den Beleg, warum es fehlt). + Hängt an **nichts Offenem**. +- ⚠️ **Ehrliche Einschränkung:** Nautobot ist bis heute bewusst schlank (8 Devices, 0 Custom Fields) — + die Pipeline ist stabil und **104/104 compliant**. TP37 vergrößert die Angriffsfläche dieser Pipeline. + Deshalb Punkt 1–2 als eigener, abnehmbarer Schritt **mit Compliance-Gegenprobe danach**, nicht als + Nebeneffekt von Punkt 3. +- **Status:** 🔜 angelegt 2026-08-30, Scope-Ausarbeitung in eigener Session. Kein Runbook. + +--- + ## Abgeschlossene Teilprojekte ▸ [`teilprojekte-archiv.md`](teilprojekte-archiv.md) **34 abgeschlossene TPs** liegen dort im Volltext, unverändert und mit eigenem Inhaltsverzeichnis.