Christoph Emsenhuber
8d2b4a71e4
- inventory/*: build.py/XLSX-Pipeline seit 2025-06 stale, Inventar erneuert sich nicht seit Core-Cutover; MikroMCP/CF/Portainer liefern Live-Daten. - handoff.md → docs/handoff-20260827-hubert-und-altlasten.md (Konventionsbruch aus der aktuellen Session korrigiert) - README.md: komplettes Rewrite mit Master-Struktur-Tabelle (bf-infra aktiv, bf-network-r6 Archiv, bf-golden-config Bot), Übergangspfad, Status-Block
166 lines
11 KiB
Markdown
166 lines
11 KiB
Markdown
# 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).
|