bf-infra/docs/handoff-20260826-tp31-suffix-sweep.md

Übergabe — nächste Session: TP23 Stufe 2 ∥ TP31 Schritt 4 — AdGuard-Paar + Suffix-Sweep

Vorgänger: handoff-20260825-agh-dns-cutover.md — diese Datei ersetzt sie nicht, sie baut darauf auf. Die drei Funde dort (Rewrites veraltet/nicht wertlos · Redundanz reziprok · Firewall-Vorrat falsch) gelten unverändert und sind hier nicht wiederholt; lies sie zuerst.

Heute (2026-08-26) dazugekommen: Standortsuffix als Regel + nas.emsenhuber.net ist tot.

Was am 2026-08-26 passiert ist

• nas.emsenhuber.net-Rewrite aus AGH entfernt (adguard/AdGuardHome.yaml:208 war die einzige Stelle). Commit 1d569fa. Der Name war reine AGH-Insel: kein CF-CNAME, kein Caddyfile-Eintrag (Caddy hatte von Anfang an ds-bf.emsenhuber.net für Synology-DSM), dig nas.emsenhuber.net @1.1.1.1 = NXDOMAIN. Für niemanden ändert sich die Auflösung.
• Regel dokumentiert (docs/teilprojekte.md TP31-Abschnitt, direkt unter SoT-Tabelle): Hosts, die es an mehreren Standorten gibt, heißen immer <host>.<site>.emsenhuber.net — nas.bf.…, nas.fm.…, nas.dw.…. Kein gemeinsamer Name ohne Suffix. Caddy bleibt pro Standort eigenständig (BF-Caddy kennt ds-bf, FM-Caddy kennt ds-fm); die AGH-Instanzen je Site halten die lokale <host>.<site>-Auflösung.

Was nicht in dieser Session gemacht wurde (und warum)

• Andere AGH-Rewrites ohne Suffix wurden NICHT umbenannt — macmini.emsenhuber.net, mfc.emsenhuber.net, tv.emsenhuber.net, docker.emsenhuber.net, platform-pg.emsenhuber.net, core.emsenhuber.net, ap1.emsenhuber.net, ap2.emsenhuber.net, branch.emsenhuber.net. Begründung: jeder Rewrite hängt an Konsumenten (~/.claude.json, HA, Bookmarks, Doku). Das ist eine eigene Session, kein Schnellschuss. Bewertung einzeln beim Aufbau des AGH-Paars.
• Caddyfile: kein nas.emsenhuber.net drin, nichts zu ändern. Andere Sites (ds-bf.…) bleiben unverändert.
• CF-DNS-Zone: kein nas.…-Eintrag, keine Aktion. Die anderen CF-CNAMEs (pve.emsenhuber.net etc.) sind erst in TP31 Schritt 5 dran (Catch-all-Tunnel, danach werden öffentliche Namen obsolet).
• Live-AGH (adguard_bf1, 10.40.20.16): noch nicht angefasst. Der Rewrite-Satz dort ist noch der alte (= Handoff-Fund 1); die neuen Instanzen 110/111 bekommen ihn von Anfang an richtig.

Was als nächstes ansteht — Auftrag für die nächste Session

User-Auftrag: TP31 Schritt 4 ∥ TP23 Stufe 2 — AdGuard-Paar (agh-bf1/agh-bf2, 10.40.20.36/.37) bauen, DHCP auf AGH umstellen, Split-Horizon etablieren. Plus der Suffix-Sweep für die BF-Hosts.

Reihenfolge:

1. LXC 110/111 bauen (Details: Handoff vom 2026-08-25, Abschnitt „Der Auftrag", Punkt 1).
2. Basis-Config übernehmen (Upstream/Bootstrap/Filter aus adguard_bf1); Rewrites neu und mit Suffix setzen:

   heute (alt, ohne Suffix)	neu (*.bf.emsenhuber.net)	Ziel
   —	nas.bf.emsenhuber.net	10.40.20.10
   macmini.emsenhuber.net	macmini.bf.emsenhuber.net	10.40.20.167
   mfc.emsenhuber.net	mfc.bf.emsenhuber.net	10.40.10.6 (Achtung: VLAN10!)
   tv.emsenhuber.net	tv.bf.emsenhuber.net	10.40.40.11
   docker.emsenhuber.net	docker.bf.emsenhuber.net	10.40.20.126
   platform-pg.emsenhuber.net	platform-pg.bf.emsenhuber.net	10.40.20.20
   core.emsenhuber.net	core.bf.emsenhuber.net	10.40.99.1
   ap1.emsenhuber.net	ap1.bf.emsenhuber.net	10.40.99.11
   ap2.emsenhuber.net	ap2.bf.emsenhuber.net	10.40.99.12
   branch.emsenhuber.net	branch.bf.emsenhuber.net	10.40.99.2

3. Caddyfile-Sites mit umbenennen (jede Site, die einen der Hosts oben bedient, bekommt den FQDN mit .bf. — öffentliche Sites vw/hass/n8n/gitea bleiben ohne Suffix, weil sie nicht standortspezifisch sind). Public bleibt Public.
4. Firewall zuerst (Handoff-Fund 3): TP5-E2-Regeln auf .36/.37 ersetzen, per GC.
5. Testen, dann DHCP umstellen VLAN für VLAN (lease-time senken, s. Handoff-Falle).
6. Konsumenten nachziehen, sobald die AGH-Instanzen aktiv sind: ~/.claude.json-MCP-Endpoints sprechen heute IPs roh — gehört zu TP31 Schritt 6, dort umstellen auf *.bf.emsenhuber.net.

Fallen, die jetzt dazu gekommen sind

• 🔴 nas.emsenhuber.net darf nicht zurückkehren. Wer den alten Namen in ~/.claude.json, HA, Bookmarks oder Doku noch hat: jetzt umstellen, nicht später. Der Rewrite ist weg, der Name antwortet nicht mehr.
• 🔴 *.bf.emsenhuber.net ist ein neuer Namespace, kein Alias. Wer vorher core.emsenhuber.net benutzt hat und jetzt core.bf.emsenhuber.net schreibt, muss beide Hops ersetzen — CF-CNAME, AGH-Rewrite, Konsument. Sonst antwortet der neue Name nirgends.
• ⚠️ mfc.bf.emsenhuber.net → 10.40.10.6 liegt auf VLAN10 (Main), nicht VLAN20. Die forward-Regel dafür ist trivial (Core routet das selbst), aber kein jit-admin nötig — Service-Adresse, kein Client.
• ⚠️ tv.bf.emsenhuber.net → 10.40.40.11 ist auf VLAN40 (Media). Der CF-Ingress hat keinen tv.emsenhuber.net-Eintrag, also bleibt das rein intern — keine Catch-all-Auswirkung.

Entscheidungen, die noch ausstehen (zur nächsten Session mitbringen)

• FM-Resolver-2 (10.40.20.17, adguard_fm2): steht im BF-Netz, antwortet für FM — bleibts so oder wird er nach FM umgezogen? Handoff vom 08-25, Fund 2.
• FM zeigt auf tote Ziele (Rewrites →10.40.41.x): wer räumt auf, wann? Eigene Session am DS415+ nötig.
• emsenhuber.net vs. bf.lan als DHCP-Domain-Suffix: Handoff vom 08-25, Zeile 72–78. Nicht nebenbei umstellen, eigener Beschluss.
• Tunnel bf-public + cloudflared auf ap1/ap2: TP31 Schritt 5 — physischer device-mode-Wechsel an den APs, danach CNAME-Umhängung. Reihenfolge: hass/vw/n8n/gitea auf Caddy, dann CNAMEs umhängen.

Einstieg

1. Diese Datei (kurz).
2. handoff-20260825-agh-dns-cutover.md — der eigentliche Auftrag, unverändert gültig.
3. docs/teilprojekte.md → TP31 und → TP23 (Status + Stufen).
4. Heute committet: 1d569fa (Suffix-Regel + nas.emsenhuber.net raus).
5. Live-Stand der AGH-BF-Instanz: adguard_bf1 (10.40.20.16), 24 Rewrites alt, davon nas.emsenhuber.net jetzt entfernt. YAML-Diff zum Ursprung in git log -p adguard/AdGuardHome.yaml.
6. Nicht vergessen: python3 nautobot/gc-transaktion.py status (= leer, seit 2026-08-23).

Was diese Session zurücklässt

• 1 Commit, 2 Dateien (adguard/AdGuardHome.yaml, docs/teilprojekte.md), keine offenen Transaktionen, keine offenen Punkte am Gerät.
• Die Suffix-Regel ist gesetzt — wer ab jetzt einen Host hinzufügt, der es an mehreren Standorten gibt, muss das Schema <host>.<site>.emsenhuber.net benutzen.
• Caddyfile bleibt BF-spezifisch (ds-bf.emsenhuber.net) — die nächste Site (FM) bekommt ihre eigene Caddy-Instanz mit ds-fm.… nach demselben Muster.