bf-infra/docs/handoff-20260827-hubert-und-altlasten.md

Handoff — 2026-08-27 — TP11b Backfill & neue Infra-Topologie

Vorgänger: TP11b-Plan (~/dev/blaueblueten-n8n/docs/teilprojekte.md, Block "Daten & Automatisierung"), TP31 (docs/teilprojekte.md im bf-infra) — diese Notiz ist kein neues TP, sondern eine Session-übergreifende Beobachtung zur geänderten Infrastruktur + Wunschliste für künftige AI-Sessions (Hubert / künftige Modelle).

TL;DR

• db/006_backfill_kind.sql ist geschrieben (TP11b, idempotent) — wurde nicht ausgeführt. Der Governor wurde in dieser Iteration nicht aktiviert; der Python-Sync-Service (tools/sync_service.py im Container terpene-sync auf LXC 400) bleibt der produktive Crawler. Der Governor-Blueprints-Fix (n8n/{detail,price,governor}.json) ist als Vorbereitung da.
• Infra-Topologie hat sich heute stark geändert: 10.40.41.x → 10.40.20.x (VLAN20 = INFRA), Cloudflare-Tunnel-Modell → Caddy als zentraler Reverse-Proxy auf LXC 130 / 10.40.20.40, Mikrotik-Switches routen direkt, kein cloudflared-Tunnel mehr nötig.
• n8n.emsenhuber.net ist jetzt öffentlich via Caddy (CF-Anycast → Caddy → n8n-Backend). n8n-API mit ~/.secrets/credentials.env → N8N_API_KEY funktioniert von meinem Mac aus.
• terpene.teilzeitladen.xyz ist im neuen Caddy-Setup noch NICHT registriert — der Worker läuft weiter über den alten Hyperdrive-VPC-Pfad. DB-Backfill via Worker ist nicht möglich.

Beobachtungen — was heute (2026-08-27) geändert wurde

1. Netz-Topologie: VLAN-Schema umgestellt

• 10.40.41.x ist tot. Das alte 41.x-Subnetz (ehem. „Server"-VLAN) gibt es nicht mehr. Aktuell gültig: 10.40.20.0/24 = INFRA (LXC-Hosts, Docker, HA, NAS), 10.40.99.0/24 = MGMT (MikroTik-Switches/APs), 10.40.10.0/24 = MAIN (Trusted Clients).
• 10.40.20.40 ist jetzt caddy-bf1 (LXC 130 auf pve) — der zentrale Reverse-Proxy. Bestätigt via curl -I -H "Host: n8n.emsenhuber.net" http://10.40.20.40/ → 308 → HTTPS, und via Cloudflare-Anycast-IP 188.114.96.10 → HTTP 200 (via: 1.1 Caddy).

2. Public-Apps laufen jetzt über Caddy statt Cloudflare-Tunnel

• Was im Caddyfile steht (bf-infra/caddy/Caddyfile): vw.emsenhuber.net, hass.emsenhuber.net, n8n.emsenhuber.net, gitea.emsenhuber.net.
• Was fehlt: terpene.teilzeitladen.xyz (TP31 Schritt 5–6 ist noch offen).
• Cloudflare-Tunnel bf-public ist im CF-Backend angelegt (ID 48d3b0b6-…, heute 05:32 UTC), status: inactive — kein Connector läuft. Die Connector-Config ist im Repo bereits vorbereitet: bf-infra/routeros/cloudflared-bf-public-config.yml + bf-infra/routeros/cloudflared/{ap-bootstrap.rsc,credentials.json}. Der Connector ist als RouterOS-Container auf ap1 + ap2 geplant (arm64, Mikrotik hAP ax²), Bootstrap-Skript liegt vor. Wichtig: Der Tunnel ist NICHT obsolet — er ist Teil von TP31 Schritt 5/6 (Catch-all-Tunnel für die Subdomains, die nicht ins Caddyfile gehören). Token in ~/.secrets/credentials.env (BF_PUBLIC_TUNNEL_TOKEN).

3. DNS-Auflösung aus dem LAN

• terpene.teilzeitladen.xyz ist weder über Public-DNS (@1.1.1.1) noch über den lokalen Resolver (@10.40.20.36 = AGH agh-bf1) auflösbar — beide geben NXDOMAIN. Der Worker bleibt nur via Hyperdrive-VPC erreichbar (nicht aus dem LAN).
• n8n.emsenhuber.net löst sauber via Public-DNS auf 188.114.96.10/.97.10 (CF-Anycast) auf und antwortet mit dem Caddy-Backend. Aus dem LAN funktioniert es also out-of-the-box über den CF-Edge-Pfad, ohne dass AdGuard-Rewrites nötig wären.

DB-Backfill — was schief lief und warum

Der Backfill-SQL ist trivial, aber aus meinem Mac (LAN-IP 10.40.10.82) nicht ausführbar, weil:

• pg_hba.conf auf 10.40.20.20 (platform-pg) erlaubt nur 10.95.10.0/24 (WireGuard-VPN). Nicht 10.40.10.0/24. Auch terpene_ro ist nicht freigeschaltet — der terpene-pg-MCP ist zwar konfiguriert, scheitert aber am pg_hba.conf-Eintrag.
• WireGuard-Interface auf meinem Mac nicht aktiv (kein wg0, keine utun-Adressen in 10.95.10.x). Die RouterOS-Configs für WG-Hub sind da (bf-network-r6/routeros/.secrets/wg-*.conf), aber kein Client-Config für den Mac.
• Worker-Endpoint admin/migrate wäre der richtige Pfad, aber terpene.teilzeitladen.xyz ist im neuen Caddy nicht registriert → kein HTTP-Zugriff aus dem LAN.
• n8n-Credential-Push (terpene_rw als Postgres-Cred in n8n anlegen) wäre eine Alternative, aber du hast den gestoppt („wg. mcp abwarten") — kein Schreibzugriff auf Produktivsysteme ohne explizite Freigabe.

Was bleibt übrig: entweder WireGuard-Client auf dem Mac aktivieren + pg_hba.conf um 10.40.10.82 erweitern (deine Aktion), oder den Worker in Caddy registrieren (TP31 Schritt 5) und dann via admin/migrate arbeiten. Beides ist deine Aktion, nicht meine — ich darf nicht eigenmächtig schreiben.

Wunschliste — was künftige Sessions (Hubert / Nachfolger) brauchen

Das ist meine Perspektive auf das, was ich für produktives Arbeiten brauche. Die Umsetzung ist deine (Infra-Antwort), nicht meine.

A. Direkter DB-Zugriff aus dem LAN (für Ad-hoc-SQL)

• Was ich brauche: ein LAN-fähiges Postgres-Frontend — entweder
  • pg_hba.conf um 10.40.10.0/24 (oder wenigstens 10.40.10.82) erweitern (Trust/SSL),
  • oder ein WireGuard-Client-Setup auf dem Mac, das in 10.95.10.0/24 routet.
• Was ich damit anfange: Counts ziehen, Backfill-SQL ausführen, Schema-Diffs ansehen, EXPLAIN-Tests. Alles read-only oder mit expliziter User-Freigabe.
• Priorität: mittel — die meiste Arbeit geht über den Worker-Endpoint; nur fürs Backfillen oder Schema-Debugging wäre es nützlich.

B. Caddy-API oder Caddy-MCP (für Hot-Reload / Site-Registrierung)

• Was ich brauche: eine API, mit der ich ohne SSH auf den LXC 130 einen Host-Block ins Caddyfile patchen kann, sodass terpene.teilzeitladen.xyz aus dem LAN erreichbar wird.
• Heute: caddy-bf1 hat eine Admin-API auf :2019 (http://10.40.20.40:2019/config/) und die Files liegen in /etc/caddy/Caddyfile. Was fehlt: ein Auth-Layer (heute localhost-only) und ein Workflow, der JSON-Config reinpatcht + caddy reload triggert.
• Priorität: mittel-hoch — sobald die Caddy-API von außen erreichbar + authed ist, kann ich terpene.teilzeitladen.xyz (oder andere Sites) registrieren, ohne dich zu fragen.

C. terpene.teilzeitladen.xyz in Caddy registrieren (TP31 Schritt 5/6)

• Was das löst: Worker-Backend ist aus dem LAN erreichbar; admin/migrate wird callbar; Backfill-SQL kann ich via Service-Token terpene-verify-v2 ausführen.
• Was du dafür brauchst: ein zusätzlicher Host terpene.teilzeitladen.xyz-Block in bf-infra/caddy/Caddyfile, der nach terpene-worker (10.40.20.X) reverse-proxyt. Worker-Backend-IP = ? (steht in worker/wrangler.toml und war mal 10.40.20.167 = Mac mini — der ist seit der Mac-mini-Abschaltung möglicherweise weg). Klären, was heute das Backend ist.

D. Hermes SOUL.md als Inspiration (nicht zum Kopieren)

• Die ~/.hermes/SOUL.md enthält gute Direktiven (targeted, efficient, direct, admit uncertainty). Mein Verhalten in dieser Session war dadurch geleitet, dass ich bei Unsicherheit (Credential-Push) gefragt habe statt geraten habe. Das ist gut.
• Hermes ist nicht mein Maßstab — ich bin Hubert / minimax-m3 / opencode-Session, nicht Nous Hermes. Aber das Pattern „lieber einmal fragen als dreimal raten" sollte für künftige Sessions explizit festgehalten werden. Vorschlag: ein CLAUDE.md-Eintrag in ~/dev/bf-infra/ mit der Direktive „bei Aktionen mit Produktivsystem-Auswirkungen (Credential-Create, Live-Deploy, DB-Write): erst fragen".

Lessons Learned — was ich (Hubert) beim nächsten Mal anders machen würde

1. Früher DNS testen. Ich hätte in Iterationsminute 1 prüfen sollen, ob terpene.teilzeitladen.xyz aus dem LAN auflösbar ist. Statt dessen habe ich den pg_hba-Fehler über mehrere Schritte debuggt. Direkter Caddy-Bypass-Test wäre schneller gewesen.

2. Caddy als Erstes prüfen. Da caddy-bf1 der neue zentrale Reverse-Proxy ist und 10.40.20.40 ARP-erreichbar war, hätte ich dort anfangen sollen statt bei Postgres. Ein curl http://10.40.20.40:2019/config/ (Admin-API, heute localhost-only) hätte mir sofort die Site-Liste gezeigt.

3. Mikrotik-MCP ist Gold wert für LAN-Topologie. ARP-Tabelle auf crs326-core + vlan20 zeigt mir in einem Call, welche Hosts im Server-VLAN leben — schneller als host-Lookups oder nmap. Sollte erste Anlaufstelle sein, wenn „wer ist wo im LAN" gefragt ist.

4. BF_PUBLIC_TUNNEL_TOKEN ist Teil von TP31 Schritt 5/6, nicht obsolet. Der Connector-Container auf den Mikrotik-APs ist die Strategie für die Subdomains, die nicht direkt ins Caddyfile gehören. bf-public ist also „im Setup", nicht „tot". Was aber stimmt: für die 4 Subdomains vw/hass/n8n/gitea.emsenhuber.net ist der Tunnel obsolet — die laufen bereits über Caddy. Wenn der Connector deployed wird, bekommt er nur die „Catch-all"-Route.

Offene Punkte für deine nächste Session (nicht für mich)

• WireGuard-Client auf Mac aktivieren? Wenn ja: Config aus bf-network-r6/routeros/.secrets/ oder neu generieren?
• terpene.teilzeitladen.xyz in Caddy registrieren? Falls ja: welcher Backend-Host/IP? (Worker ist seit Mac-mini-Wegfall vermutlich auf pve/LXC migriert.)
• bf-public Cloudflare-Tunnel — Connector-Container auf ap1+ap2 deployen? routeros/cloudflared/ap-bootstrap.rsc ist die Vorlage. Nach Deployment: Ingress so anpassen, dass die 4 Caddy-Subdomains (vw/hass/n8n/gitea.emsenhuber.net) vom Tunnel-Catchall ausgeschlossen werden — sonst gibts Konflikte (Caddy und Tunnel beanspruchen dieselben Hostnames).
• pg_hba.conf um LAN-IP erweitern? Vertrauensstufe (md5/scert/trust)?

Cross-References

• ~/dev/blaueblueten-n8n/docs/teilprojekte.md → TP11b (Backfill-SQL, Doku)
• ~/dev/blaueblueten-n8n/db/006_backfill_kind.sql (neu, idempotent)
• ~/dev/bf-infra/docs/teilprojekte.md → TP31 (Caddy-Setup, Schritt 5–6 offen)
• ~/dev/bf-infra/caddy/Caddyfile (Caddyfile SSoT)
• ~/.secrets/credentials.env (alle Credentials, inkl. BF_PUBLIC_TUNNEL_TOKEN, N8N_API_KEY, TERPENE_RW_PASSWORD, CF_DNS_API_TOKEN, CF_API_TOKEN)

---

Stand: 2026-08-27, ~16:00 lokal · Hubert (opencode/minimax-m3, Session) · Christoph (Session-Owner). Kein Commit im terpene-Repo (TP11b-Standby). Keine Schreibaktion auf Produktivsysteme in dieser Session (pg_hba, Caddyfile, n8n-Credentials).