TP34.2 — Interne DNS-Namen als Daten (FQDN aus Nautobot) #73

New Issue

admin · 2026-09-22T13:02:28+02:00

admin commented

2026-09-22 13:02:28 +02:00

Steuerungs-SSoT: Index/Status hier in Gitea; Prosa/Detail im Repo unter docs/teilprojekte.md (Abschnitt TP34.2).

Status: 🔜 (status:todo)
Abschluss: —
Träger-Entscheid: Christoph 2026-09-22 („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: der dort verworfene Gegenstand war Caddyfile-Rendering, hier geht es um interne DNS-Namen als Daten. Kein Zwillings-TP mit neuer Nummer.

Anriss: 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.

Warum: die Namen existieren heute nur am Gerät — Handarbeit mit Freitext-Kommentaren ("caddy -> nautobot :8080"). Damit ist das eine Recovery-Lücke derselben Klasse 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.

Ausdrücklich NICHT Scope: Caddyfile-/Reverse-Proxy-Rendering (der verworfene TP34-Ansatz) — der Caddyfile bleibt manuell.

Abhängigkeit: TP37 ✅ (Datenmodell ipam.Service/IPAddress) · TP45 Schicht A ✅/E offen (die Namen müssen auf die neuen Gast-IPs zeigen) · TP21/22 ✅ (GC-Pipeline). Blockiert nichts.

Nicht Teil dieses TPs: die coolify.bf-Frage (TP45 Schicht C, Port unbekannt — nicht raten).

Steuerungs-SSoT: Index/Status hier in Gitea; **Prosa/Detail** im Repo unter `docs/teilprojekte.md` (Abschnitt `TP34.2`). - Status: 🔜 (status:todo) - Abschluss: — - Träger-Entscheid: Christoph 2026-09-22 („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: der dort verworfene Gegenstand war *Caddyfile-Rendering*, hier geht es um *interne DNS-Namen als Daten*. Kein Zwillings-TP mit neuer Nummer. Anriss: 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**. **Warum:** die Namen existieren heute **nur am Gerät** — Handarbeit mit Freitext-Kommentaren (`"caddy -> nautobot :8080"`). Damit ist das eine **Recovery-Lücke** derselben Klasse 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. **Ausdrücklich NICHT Scope:** Caddyfile-/Reverse-Proxy-Rendering (der verworfene TP34-Ansatz) — der Caddyfile bleibt manuell. **Abhängigkeit:** TP37 ✅ (Datenmodell `ipam.Service`/`IPAddress`) · TP45 Schicht A ✅/E offen (die Namen müssen auf die **neuen** Gast-IPs zeigen) · TP21/22 ✅ (GC-Pipeline). Blockiert nichts. **Nicht Teil dieses TPs:** die `coolify.bf`-Frage (TP45 Schicht C, Port unbekannt — nicht raten).

admin added the status:todo thema:firewall-dns thema:nautobot-doku labels 2026-09-22 13:02:28 +02:00

admin referenced this issue

2026-09-22 13:03:30 +02:00

TP45 — VLAN20/VLAN30 ins TP32-Schema + DNS/FQDN aus Nautobot #71

admin referenced this issue from a commit

2026-09-22 13:19:27 +02:00

TP34.2: C4 → interne DNS-Namen als Daten (Gitea #73)

admin referenced this issue

2026-10-06 06:48:31 +02:00

TP49 — CF-Access: `login_method:github` im include der Terpenfinder-Policy — ✅ behoben (require statt include) #76

Sign in to join this conversation.