SoT: CF und Caddy werden NICHT synchron gehalten - die Doppelpflege faellt
mit Schritt 5/6 weg. Heute stehen 19 Ingress-Regeln und 16 Caddy-Sites
nebeneinander und stimmen fachlich ueberein; im Zielbild haelt CF nur noch
eine Catch-all auf 10.40.20.40. Danach: Caddyfile = Name->Origin,
CF = welcher Name ist oeffentlich (4), AGH = Name->IP intern.
Nebeneffekt: die 12 internen Namen brauchen keinen oeffentlichen DNS mehr.
caddy/cf-sync.py (read-only, Exit 1 bei Drift) findet im ersten Lauf sieben
Abweichungen, alle auf CF-Seite: grafana noch im Ingress, nautobot und
gateway-dw als CNAME ohne Ingress (Quelle der 302), drei *.bf-CNAMEs auf den
zerstoerten NPM, dazu die Wildcard-Access-App, die alles maskiert.
Uebergabe korrigiert nach User-Einwand und Gegenmessung:
- Rewrites sind veraltet, nicht wertlos - Hosts leben auf VLAN20 weiter,
also Ziele umbiegen statt Namen loeschen.
- Die Redundanz existiert doch, reziprok ueber die Standorte: FM antwortet
auf 10.101.0.16/.17 (DS415+) - und beide liefern fuer nas.bf die tote
VLAN1-Adresse. Ein Rewrite-Satz nur im neuen BF-Paar erzeugt
standortabhaengig verschiedene Antworten.
- Vorratsregel auf .16 wird gestrichen statt erweitert (User-Entscheid).
- Cave: emsenhuber.net ist die Domain, bf.lan nur der DHCP-Suffix.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Caddy in LXC 130 ist produktiv: 17 von 17 Zertifikaten per DNS-01 von
Let's Encrypt, Dienst active+enabled, Proxy gegen Host-Header verifiziert
(nautobot 302, gitea 200, pve 200, portainer 200). deploy.sh laeuft
End-to-End; Token per Fingerprint gegengeprueft -- eigenes Zone:DNS:Edit,
nicht das account-weite.
🔴 Fund beim Durchtesten: grafana war seit Langem tot und Cloudflare
Access hat es maskiert. LXC 104 stopped, konfigurativ noch auf VLAN1
(10.40.41.109), waehrend die Ingress-Zeile auf 10.40.20.109 zeigte -- eine
Adresse die es fuer Grafana nie gab. Der FQDN lieferte trotzdem 302, weil
das der Access-Login war. Exakt die Falle aus TP16.3 Paragraph 8, diesmal
in freier Wildbahn: ein toter Dienst sieht hinter Access monatelang
gesund aus.
=> Caddy-Zeile raus (16 Sites), LXC 104 zerstoert, aus dem Backup-Job.
Die 14 PBS-Snapshots bleiben bewusst stehen -- einzige Kopie etwaiger
Dashboards.
hass liefert 400: bekannter trusted_proxies-Punkt aus TP16, gehoert vor
die CNAME-Umstellung.
Split-Horizon entschieden (User): in AdGuard zusammen mit TP23 Stufe 2.
Dokumentiert, was das bedeutet -- heute liefert der DHCP in allen sieben
VLANs den Core als DNS; AGH bekommt niemand. Der Schritt verschiebt die
Aufloesung des ganzen Hauses in einen Container, deshalb als Paar
110/111 bauen. Die geloeschten Altlasten hiessen nicht zufaellig
adguard-bf1/-bf2.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Aufgeraeumt (User-Freigabe): LXC 120/121/128/129/130/131 zerstoert --
alle stopped, onboot=0, alle konfigurativ noch auf totem VLAN1
(10.40.41.116/.117, GW .41.254). pct destroy --purge hat 120 und 128
zugleich aus dem Backup-Job entfernt. 65 von 72 PBS-Snapshots geloescht;
sieben sind PROTECTED und stehen noch -- bewusst nicht ueberschrieben.
Neu nach TP32-Systematik:
- LXC 130 caddy-bf1, VLAN20 tag=20, 10.40.20.40/24, GW/DNS .20.1,
onboot=1, startup order=10 (Core), Debian 13, 4 GB / 512 MB
- Caddy v2.11.4 mit dns.providers.cloudflare (Custom-Build)
- caddy/Caddyfile im Repo, 17 Sites: 4 oeffentlich (vw/hass/n8n/gitea),
13 intern inkl. der vier MCP-Endpunkte und drei HTTPS-Backends
- caddy/deploy.sh liest CF_DNS_API_TOKEN aus ~/.secrets und schreibt es
in die Container-Env -- nie auf stdout, nie in einer Kommandozeile
- 130 in denselben Backup-Job aufgenommen
Caddy laeuft noch NICHT: das eng geschnittene Zone:DNS:Edit-Token fehlt.
Ein Token anzulegen und im Klartext zu handhaben ist nichts, was ich
selbst tue -- der Weg ist ~/.secrets plus deploy.sh.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
