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>
