From 8aae0f424fbbbfa1d74015648b13ce45a688ae9b Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Wed, 2 Sep 2026 03:19:25 +0200 Subject: [PATCH] TP42: Live-Bestandsaufnahme + Zielschema-Entscheidung (bf.emsenhuber.net) Gegen die Geraete gemessen: .bf.lan ist ueberall weg, DHCP-domain auf emsenhuber.net vereinheitlicht, Core-Static + Caddyfile konsistent auf .bf.emsenhuber.net (deckt sich mit GC-Template). Drift hat ~80% erledigt. Kernkonflikt: DHCP verteilt bare emsenhuber.net, Records leben unter bf.emsenhuber.net -> bare macmini loest nicht. Entscheidung (User): Zielschema = bf.emsenhuber.net (wenig-Arbeit-Weg); .16 (adguard_bf1) abbauen, .17 (=FM) bleibt. Netto-Rest = 2 Infra-Eingriffe: DHCP-domain ->bf.emsenhuber.net ueber die GC-Pipeline (Template Z.133 + push-gc-template.py + Deploy) und .16-Teardown. Kein Core-Objekt haengt an .16 (Firewall/NAT/DNS/Addr-List live geprueft). Co-Authored-By: Claude Opus 4.8 --- docs/teilprojekte.md | 38 +++++++++++++++++++++++++++++++++++--- 1 file changed, 35 insertions(+), 3 deletions(-) diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 6fe61c0..cc6a02d 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -53,6 +53,11 @@ liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur d `caddy/cf-sync.py` von einem Fehlalarm befreit (prüfte nur `http://`, gebaut ist `https://…:443`) und **grün** (nur `ds-bf` als bewusst intern). Schritt-6-Teil „MCP auf FQDN" durch TP35 Schicht 1 umgekehrt (LAN-IP), damit gegenstandslos. +- ⏳ **TP42 Bestandsaufnahme live durch (2026-09-02):** `.bf.lan` ist überall weg, DHCP-domain auf + `emsenhuber.net` vereinheitlicht, Core-Static + Caddyfile konsistent auf `.bf.emsenhuber.net`. + Zielschema **`bf.emsenhuber.net`** entschieden (User). Netto-Rest = 2 Infra-Eingriffe: DHCP-domain + `→bf.emsenhuber.net` über die GC-Pipeline + `.16`-Container-Abbau (`.17`=FM bleibt). Beide live + abgesichert (kein Core-Objekt hängt an `.16`). Wartet auf explizites Go. - 🔜 **TP42 Namens-Vereinheitlichung (2026-09-01, angelegt):** internes `.bf.lan` (Core-DNS, DHCP-Search- Domain) und die `.bf.emsenhuber.net`-Aliase (Caddyfile) auf **einen** Namensraum `emsenhuber.net` ziehen; stale `.16/.17`-Rewrites abbauen; Sollzustand in Nautobot. Handoff: @@ -506,7 +511,7 @@ nachmessen und dann entscheiden**. Blocker gibt es keine mehr. TP5 ist in der Na > | TP38 | 🔜 | OOB-Mgmt: untagged-VLAN99-Port je Switch | — | > | TP40 | 🔜 | HA-Recorder-Retention: 41 GB `states` beschneiden (Okay 09-01) | — | > | TP41 | ⏸️ | CF-Access-Reparatur **zurückgestellt 2026-09-01** (User): **T2/T3/T4/T5 ✅** (GitHub+Google-Login live); **Facebook abgesagt**; **Geli CF-seitig fertig** (zt-humans+geli-Policy) → offen nur noch WARP-Client auf Gelis Gerät, wartet auf User-Info | — | -> | TP42 | 🔜 | Namens-Vereinheitlichung bf.lan→emsenhuber.net: `.bf.lan`/`.bf.emsenhuber.net` aus allen Geräten raus, in Nautobot festhalten | — | +> | TP42 | ⏳ | Namens-Vereinheitlichung: `.bf.lan` **weg**, DHCP unified; Zielschema **`bf.emsenhuber.net`** entschieden — Rest = DHCP-domain via GC + `.16`-Abbau (Go offen) | — | > | TP43 | 🔜 | dw-Standort-DNS-Uplink: eigener Resolver mit site-Overrides (`420.teilzeitladen.xyz`→BF-Caddy/WG), WG-Disconnect bedacht; Geli sofort per WARP | — | > | — | — | **35 archivierte TPs** in `teilprojekte-archiv.md` (inkl. TP39 ✅ 2026-09-01) | — | @@ -3007,8 +3012,35 @@ und `.bf.emsenhuber.net` werden entfernt; Sollzustand in Nautobot dokumentiert. (`.36/.37` bleiben); `.1`-als-DNS-Reste auf Clients sind separat/tolerierbar (User: „bis jetzt kein Problem"). **Abh.:** TP37 (Nautobot-Datenmodell) für Punkt 4; sonst nichts Offenes. -**Status:** 🔜 angelegt 2026-09-01, Ausarbeitung eigene Session. Handoff: -[`docs/handoff-20260901-tp42-naming.md`](handoff-20260901-tp42-naming.md). +#### ✅ Bestandsaufnahme LIVE (2026-09-02) — Drift hat 80 % schon erledigt +Gegen die Geräte gemessen (MikroMCP + dig), nicht aus dem Handoff: + +| Fundstelle | Handoff 09-01 | Live 09-02 | +|---|---|---| +| Core `/ip dns static` | 11× `*.bf.lan` | ✅ **0× `.bf.lan`** — 10× `*.bf.emsenhuber.net` (deckt sich mit GC-Template Z.284–293) | +| DHCP `domain` (7 Netze) | „prüfen" | `emsenhuber.net` (GC-Template Z.133 = gleich ⇒ **keine Drift**), DNS `.36/.37` | +| `.36/.37` (Soll) | aktiv | `vw.emsenhuber.net→.40` ✅ · `macmini.bf.emsenhuber.net→.20.167` ✅ · **`macmini.emsenhuber.net→leer`** ❌ | +| Caddyfile | `*.bf.emsenhuber.net`-Aliase | unverändert, **konsistent** mit Core-Static | +| `.16`/`.17` | tot | laufen (:53), liefern totes VLAN1; **kein Core-Objekt** (Firewall/NAT/DNS-Upstream/Addr-List) hängt an `.16` | + +**Kernkonflikt:** DHCP verteilt `emsenhuber.net` (bare), Records leben unter `bf.emsenhuber.net` ⇒ bare `macmini` löst nicht. + +#### ✅ Entscheidungen (User, 2026-09-02) +1. **Zielschema = `bf.emsenhuber.net`** (der wenig-Arbeit-Weg): DHCP-domain → `bf.emsenhuber.net`, dann + löst `macmini` bare korrekt; Core-Static + Caddyfile bleiben (tragen schon `.bf.`). Öffentliche Zone + `emsenhuber.net` bleibt getrennt. +2. **`.16` (adguard_bf1) abbauen**, **`.17` (adguard_fm2 = Standort FM) NICHT anfassen.** + +#### 🔜 Netto-Rest (2 Eingriffe) — Infra, wartet auf explizites Go +- **(A) DHCP-domain `emsenhuber.net → bf.emsenhuber.net` über GC** (kein Direkt-Write ⇒ keine Drift): + `nautobot/mikrotik_routeros.j2` Z.133 ändern → `routeros/push-gc-template.py` → Nautobot GitRepo-Sync + → `gc-configplan.py --refresh-compliance` → gestaffelter Deploy an **crs326-core** → Live-Verify + (`/ip dhcp-server network`, bare-Name-Auflösung). +- **(B) `.16`-Teardown:** Container `adguard_bf1` auf Docker-LXC `.126` (Portainer ep14) stoppen + entfernen. +- **(C) Nautobot-Soll** (Scope-Punkt 4) bleibt an **TP37** gekoppelt (Datenmodell), separat. + +**Status:** ⏳ Bestandsaufnahme + Entscheidungen durch (2026-09-02); Rest = 2 Infra-Eingriffe + TP37-gekoppelter +Nautobot-Teil. Handoff: [`docs/handoff-20260901-tp42-naming.md`](handoff-20260901-tp42-naming.md). ### TP43 — dw-Standort-DNS-Uplink (site-spezifische Overrides) ▸ 🔜 ANGELEGT 2026-09-01 (User-Okay erteilt)