From 4a63c1e527570f18e859f030fd2ae13c950e69e8 Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Tue, 22 Sep 2026 13:06:39 +0200 Subject: [PATCH] =?UTF-8?q?TP34.2:=20C4=20=E2=86=92=20interne=20DNS-Namen?= =?UTF-8?q?=20als=20Daten=20(Gitea=20#73)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Träger für TP45 Schicht C4. TP34 (Caddyfile-Rendering) bleibt verworfen (#24); der Daten→Config-Gedanke lebt als TP34.2 weiter. Prosa-Abschnitt + Anker angelegt, Schicht-C-Tabelle / „Offen in C" / Abh. / Follow-up / TP37-Abgrenzung auf TP34.2 umgestellt, Archiv-Zeiger ergänzt. Co-Authored-By: Claude Haiku 4.5 --- docs/teilprojekte-archiv.md | 5 +++- docs/teilprojekte.md | 53 +++++++++++++++++++++++++++++++------ 2 files changed, 49 insertions(+), 9 deletions(-) diff --git a/docs/teilprojekte-archiv.md b/docs/teilprojekte-archiv.md index 1197318..c248353 100644 --- a/docs/teilprojekte-archiv.md +++ b/docs/teilprojekte-archiv.md @@ -63,7 +63,7 @@ teuerste Eigenschaft der Datei zerstört, um ihr billigstes Problem zu lösen. B | [TP28](#tp28) | WLAN über CAPsMAN auf `crs326-core` | ↩️ **wieder geöffnet 2026-08-30** (ap3) — Volltext in [teilprojekte.md](teilprojekte.md#tp28) | | [TP-R](#tp-r) | Router-Capabilities-Sweep | FERTIG (docs/research/routeros-capabilities.md) | | [TP39](#tp39) | LXC-Hygiene pve: Resolver-Altlasten, `networking.service`, DB-Reverse-Lookup | ✅ ABGESCHLOSSEN (2026-09-01) — pve+NAS-Sweep grün | -| [TP34](#tp34) | Caddyfile via Nautobot/GC (generische Reverse-Proxy-Schnittstelle) | ❌ VERWORFEN (2026-09-08) — Caddyfile bleibt manuell | +| [TP34](#tp34) | Caddyfile via Nautobot/GC (generische Reverse-Proxy-Schnittstelle) | ❌ VERWORFEN (2026-09-08) — Caddyfile bleibt manuell · **Fortsetzung: TP34.2 (2026-09-22)** | | [TP44](#tp44) | Cloudflare-Estate als Dokumentations-SSoT in Nautobot | ✅ DURCH (2026-09-10) | | [TP41](#tp41) | CF-Access-Reparatur + Zero-Trust-Konsolidierung | ✅ ABGESCHLOSSEN (2026-09-10) — Gelis WARP via Android eingerichtet, letzter Blocker weg | | [TP43](#tp43) | dw-Standort-DNS-Uplink (site-spezifische Overrides) | ♻️ REOPENED (2026-09-11) — Volltext zurück in teilprojekte.md; interne BF-Namen über WG am dw offen | @@ -1786,6 +1786,9 @@ gemessen hat. Beim Beheben kam eine zweite, unabhängige Altlast zum Vorschein. --- ### TP34 — Caddyfile via Nautobot/GC (generische Reverse-Proxy-Schnittstelle) ▸ ❌ **VERWORFEN (2026-09-08)** +> ➡️ **Fortsetzung 2026-09-22: `TP34.2 — Interne DNS-Namen als Daten`** (Gitea #73, Prosa in +> `docs/teilprojekte.md` → `### TP34.2`). Dort lebt der *Daten → gerenderte Config*-Gedanke weiter; +> **verworfen bleibt nur das Caddyfile-Rendering** (dieser Abschnitt hier). > 🔴 **Nachtrag 2026-09-08 (verworfen):** Der Ansatz „Caddyfile via Golden Config rendern" ist > zurückgezogen (Commits `d63dc7b`, `bca8f6e`; Gitea-Issue #24 → `status:dropped`, closed). Der > `420.teilzeitladen.xyz`-Block wurde wieder aus dem GC-gerenderten Caddyfile entfernt; **der diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 10a363d..0c21278 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -2513,7 +2513,7 @@ wo er ist, ohne nachzusehen.** 5. **Backup-Guard** — `~/dev/.bin/backup-guard.sh`, Pre-Commit-Hook pro Projekt, „3 Tage aktiv"-Definition: 5 Commits oder 1000 LOC diff. **✅ 2026-09-12 abgenommen:** Guard (112 Z., `check`/`mark`/`status`) + `.git/hooks/pre-commit` in `bf-infra` live verdrahtet; der Hook hat beim TP36-Live-Commit real gegriffen („Projekt aktiv 12 Commits/198 LOC, Backup markiert"). ⚠️ **Bekannte Grenze:** `check` prüft nur *Existenz* der Guard-Datei, nicht deren Alter — ein alter `mark` (hier 2026-08-29) lässt den Commit durch. Das ist als Push-Erinnerung gewollt, keine Frische-Garantie. 6. **`/projektstatus`-Skill global** — als Erstes, vor den anderen Schichten. Alle Projekte verwenden dasselbe Skill. **✅ 2026-08-28:** `/projektstatus`-Skill nach `~/.config/opencode/skills/projektstatus/SKILL.md` kopiert (`cp`, nicht `ln -s`) — opencode scannt diesen Default-Pfad, kein `skills.paths`-Eintrag in der JSONC nötig. Lehre im CLAUDE.md-Lessons-Block. - **Abgrenzung:** TP35 ist Konzept + Schichtung, nicht die Umsetzung. Pro Projekt eigene Session, eigener Handover-Post, eigene Mini-Anpassung. -- **Verzahnt mit:** TP30 (Credentials), TP34 (Repository-Pattern), TP22 (Nautobot-GC als Vorbild für SSoT + Compliance), TP11 (Monitoring). +- **Verzahnt mit:** TP30 (Credentials), TP34.2 (Daten→Config-Pattern), TP22 (Nautobot-GC als Vorbild für SSoT + Compliance), TP11 (Monitoring). - **Erste Session für Scope-Ausarbeitung:** Schichten 1–5 + Skill-Setup; Handover-Posts pro Projekt (Schicht 3 + 4 ergeben die Posts). - **Referenzen:** Handoff 2026-08-28 (`docs/handoff-20260828-pre-opencode-migration.md`) · Backups `~/dev/.pre-opencode-migration-backups/20260828-150335/` · MCP-Inventur `bf-infra/mcp/INVENTORY.md` · Lessons `bf-infra/CLAUDE.md` Abschnitt „Lessons for Sessions" · `docs/handoff-20260828-mcp-bestand-und-performance.md` (MCP-Bestand-Korrektur + Mac-mini-Restriktion). @@ -2683,9 +2683,12 @@ Der HA-Recorder schreibt **unbegrenzt** — es ist keine `purge_keep_days`-Grenz - **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.** + ⚠️ **Nachtrag 2026-09-22:** TP34 ist **❌ verworfen** (09-08, #24 — der Caddyfile bleibt manuell); + der *Daten → gerenderte Config*-Gedanke lebt als **[TP34.2](#tp342)** (interne DNS-Namen) weiter. - **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: Golden Config für Nicht-Netzgeräte (Caddy/AdGuard deployen) — das ist **TP34.2** + (das Caddy-Teilstück davon bleibt ❌ verworfen). **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). @@ -2701,12 +2704,41 @@ Der HA-Recorder schreibt **unbegrenzt** — es ist keine `purge_keep_days`-Grenz Datenmodell **entschieden 2026-09-06 (native Modelle: `virtualization.Cluster/VirtualMachine` + `ipam.Service`, keine App)**; Runbook [`handoff-20260906-tp37-34-36-plan.md`](handoff-20260906-tp37-34-36-plan.md). **Offen bleibt Punkt 4** (Drift-Check gegen die CF-API) — und der Weg **Daten → gerenderte Config** - ist nicht mehr TP37, sondern **TP34/TP45 Schicht C**. + ist nicht mehr TP37, sondern **TP34.2 / TP45 Schicht C**. ⚠️ **Merkregel:** die Zeile stand seit dem 09-06 auf „offen", obwohl die Seeder längst gelaufen waren. Ein Status, der nur in einer Datei lebt, altert still — der Abgleich gegen die API kostet eine Minute. --- + +### TP34.2 — Interne DNS-Namen als Daten (FQDN aus Nautobot) ▸ 🔜 **ANGELEGT 2026-09-22** (Gitea #73) — **gemeinsame Arbeit** +> **Auslöser:** beim Schärfen von **TP45 Schicht C (C4)** am 2026-09-22 stand die Frage, was aus dem +> verworfenen **TP34** wird. Christoph: *„C4 unter TP45 schärfen, TP34 wird gemeinsame Arbeit. wir beide!"* +> → **eigener Träger im TP34-Nummernkreis**. Parent **#24 (TP34) bleibt `status:dropped`** — kein Reopen: +> dort wurde *Caddyfile-Rendering* verworfen, hier geht es um *interne DNS-Namen als Daten*. **Kein +> Zwillings-TP mit neuer Nummer**, aber auch kein Wiederbeleben eines anderen Gegenstands. + +- **Scope:** Die **27 internen `A`-Statics** auf `crs326-core` (`*.bf.emsenhuber.net`, live geprüft + 2026-09-22) werden **Daten in Nautobot**; ein Renderer schreibt sie als GC-Soll. **Abnahme:** ein + Golden-Config-Recovery von null erzeugt einen Core, in dem die internen Namen **wieder auflösen**. +- **Ausdrücklich NICHT Scope:** Caddyfile-/Reverse-Proxy-Rendering (der verworfene TP34-/`.1`-Ansatz) — + der `caddy/Caddyfile` bleibt **manuell**. +- 🔴 **Warum es das braucht:** die Namen existieren heute **nur am Gerät** — Handarbeit mit + Freitext-Kommentaren (`"caddy -> nautobot :8080"`), und GC rendert sie **nirgends**. Ein Recovery + von null erzeugt damit einen Core **ohne interne Namensauflösung**: dieselbe **Recovery-Lücke** wie + die DHCP-Reservierungen und die `nautobot`-Adressliste (beide inzwischen als Renderer nachgezogen, + TP45 Schicht B). ⚠️ **Compliance meldet trotzdem grün — die Zahl prüft nur, was gerendert wird.** +- **Datenlage / offener Modell-Entscheid:** `ipam.Service` (**26**) und `ipam.IPAddress` (**38**) stehen + (TP37 P1+2 ✅). Für DNS braucht es voraussichtlich `ipam.IPAddress` + `dns_name` je Gerät/Dienst, mit + **zwei Zielarten**: Geräte-Statics zeigen auf die echte IP, Proxy-Namen auf **`10.40.20.40`** (Caddy) + — dazu je Name ein Kommentar-Feld. Der eigentliche Modell-Entscheid steht noch aus (**nicht raten**). +- **Abh.:** TP37 ✅ (Datenmodell) · TP45 **Schicht A** ✅ / **E** offen (die Namen müssen auf die **neuen** + Gast-IPs zeigen) · TP21/22 ✅ (GC-Pipeline). **Blockiert:** nichts. +- **Abgrenzung:** die `coolify.bf`-Frage bleibt in **TP45 Schicht C** (Port unbekannt — nicht raten); + Token-**Rotation** ist TP30. + +--- + ### TP45 — VLAN20/VLAN30 ins TP32-Schema + DNS/FQDN aus Nautobot ▸ 🔜 **ANGELEGT 2026-09-21** (Gitea #71) > **Auslöser (Christoph, 2026-09-21):** *„schau dir mal die fqdns von `*.emsenhuber.net` an. viele > verschwunden. sowohl caddy als auch cloudflare."* — und, als der Befund stand: @@ -2744,7 +2776,7 @@ unter `*1A TP5-WOULD-DROP` / `*2D TP5: deny-by-default` (621 Pakete). |---|---|---| | **A** | VLAN20 virtuelle Gäste ins Schema — **Nautobot zuerst** (`.30–.34` → `.154–.156`/`.158`), dann AGH | 🔄 **Nautobot ✅ 2026-09-21** (s. u.) · AGH + übrige Gäste offen | | **B** | VLAN30 — **nur die Pool-Grenze**, Geräte bleiben (Christoph 2026-09-21) | offen | -| **C** | DNS/FQDN: `ds-bf` über Caddy, `coolify.bf` neu, `.bf` vollständig auf den Core, AGH nur Filtering, TP34 | ✅ **C1–C3 durch 2026-09-22** (s. u.) · C4 (TP34) + `coolify.bf` offen | +| **C** | DNS/FQDN: `ds-bf` über Caddy, `coolify.bf` neu, `.bf` vollständig auf den Core, AGH nur Filtering, TP34.2 | ✅ **C1–C3 durch 2026-09-22** (s. u.) · offen: **C4 → TP34.2** (Gitea #73) + `coolify.bf` | | **D** | Tunnel-Inventar + GC + generische Namen, TP30 #10, Leak-Ursachen | offen | | **E** | nas/pve/macmini — **neue IPs zuerst am Core** (Sekundär-IP + 1:1-NAT), dann messen und umstellen; nas zuletzt | offen | | **F** | CF-/Tunnel-SSoT + Recovery → **TP46** | offen | @@ -2890,8 +2922,13 @@ Namen `nautobot.bf.` im **Root** ab und liefert leer — sieht wie ein nicht gef die eigene Abfrage. Dieselbe Klasse wie `nc -z` (09-01) und `pct push` (09-21): **erst das eigene Werkzeug verdächtigen.** -**Offen in C:** `coolify.bf` (nicht ausgerollt, Port unbekannt — **nicht raten**) · **C4** (TP34: FQDN -als **Daten** in Nautobot). Kosmetisch zurückgestellt: die `ds-bf`-Site steht im `caddy/Caddyfile` +**Offen in C:** `coolify.bf` (nicht ausgerollt, Port unbekannt — **nicht raten**) · **C4 = die internen +Namen als Daten** → eigener Träger **[TP34.2](#tp342)** (Gitea #73, angelegt 2026-09-22, gemeinsame Arbeit). +🔴 **Was C4 genau ist:** die **27** `A`-Statics auf `crs326-core` sind heute Handarbeit (live geprüft +2026-09-22: 27 Einträge, Freitext-Kommentare, `coolify.bf` fehlt) und werden **von GC nirgends gerendert** +⇒ ein Recovery von null erzeugt einen Core **ohne** interne Namensauflösung — dieselbe **Recovery-Lücke** +wie die DHCP-Reservierungen und die `nautobot`-Adressliste. **Nicht** C4 ist Caddyfile-Rendering: das war +TP34 und bleibt ❌ verworfen (09-08). Kosmetisch zurückgestellt: die `ds-bf`-Site steht im `caddy/Caddyfile` weiter im INTERN-Block (nur Beschriftung; ein Caddy-Redeploy allein dafür wäre unverhältnismäßig). #### Soll-Oktette (Nachschlagetabelle, s. TP32 für die Herleitung) @@ -2923,7 +2960,7 @@ NAT/mangle/WG sind Template-Literale, der Firewall-Filter kommt als ConfigContex - ⚠️ **`ap3.bf` existierte nirgends** — weder Core-Static noch AGH-Rewrite, obwohl ap3 seit 08-30 live ist. ✅ **Behoben in C1 (09-22):** `ap3.bf` → `.99.13` als Core-Static. -- **Abh.:** TP32 (Systematik) · TP37 ✅ (Nautobot-Datenmodell) · TP21 ✅. **Blockiert:** TP34 (rendert +- **Abh.:** TP32 (Systematik) · TP37 ✅ (Nautobot-Datenmodell) · TP21 ✅. **Blockiert:** TP34.2 (rendert die FQDNs, die hier Daten werden). **Abgrenzung:** VMID-Umnummerierung bleibt draußen; Token-**Rotation** läuft in TP30; Tunnel-GC-Namensgebung hier, die **SSoT/Recovery** in TP46. @@ -3068,7 +3105,7 @@ den Weg, über den man den Fehler zurücknehmen wollte. - **🔴 TP45 — VLAN20/VLAN30 ins TP32-Schema + DNS/FQDN (NEU 2026-09-21, Gitea #71):** der aktuell **dringendste** Posten — die internen `*.bf.emsenhuber.net`-Namen lösen im Browser nicht auf (Ursache: AGH-Rewrites im Filter-Pfad für unfiltrierte Clients übersprungen), und `ds-bf` ist - öffentlich kaputt (einziger Ingress-Eintrag, der Caddy umgeht). Danach ist **TP34** erst baubar. + öffentlich kaputt (einziger Ingress-Eintrag, der Caddy umgeht). Danach ist **TP34.2** erst baubar. - **TP46 — CF-/Tunnel-SSoT + Recovery (NEU 2026-09-21, Gitea #72):** Push-Weg + Ingress-Origins + DNS + Access-Policies nach Nautobot, Recovery-Runbook. Eigene Baustelle, unabhängig von TP45. - **TP25 — WLAN-Stabilisierung (NEU 2026-08-17):** Audit durch, **6 Funde** (2,4 GHz fährt 40 MHz statt der