admin/bf-infra
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases Wiki Activity

inventur + tp34: Architektur-Vorschlag Caddyfile-via-Nautobot/GC

Browse Source 
- Handoff-Datei docs/handoff-20260827-inventur-und-architektur.md mit Drift-Befund
  (10 Punkte), Asymmetrie (bf-infra lokal-only / bf-golden-config Gitea-only),
  Inventar-Entscheidung, Architektur-Skizze (Nautobot-Datenmodell +
  GC-Workflow), Übergangsplan, Selbstkritik.
- TP34 in docs/teilprojekte.md als Stub mit Verweis auf Handoff-Architektur-
  Abschnitt. Quick-Index-Eintrag (Zeile 207).
- Erster Anwendungsfall: terpene.teilzeitladen.xyz (Mac-mini-Backend
  10.40.20.167:8890, Caddy-Block kommt als Quick-Win).
This commit is contained in:
Christoph Emsenhuber
2026-08-27 21:35:53 +02:00
parent 8d2b4a71e4
commit 218b79188b
2 changed files with 142 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

131
docs/handoff-20260827-inventur-und-architektur.md Normal file
View File

@@ -0,0 +1,131 @@
# Handoff 2026-08-27 — Inventur + Asymmetrie + Architektur-Vorschlag
> Bezug: TP34 (Caddyfile via Nautobot/GC, neu, Stub-Eintrag in `docs/teilprojekte.md`).
> Inventur-Session mit Christoph, alles Read-Only geprüft (CF-API live, MikroMCP-ARP live,
> Gitea-REST live).
## TL;DR
- `bf-infra` ist **aktiver Fork** von `bf-network-r6`; aktiv gepflegt, **kein Gitea-Remote** → Backup-Lücke.
- `admin/bf-network-r6` (Gitea) = historischer Master, letzte aktive Commits 2026-08-25 → auf read-only stellen (deine Aktion).
- `admin/bf-golden-config` (Gitea) = Bot-Master (Nautobot BACKUP/GENERATE 2×/Tag) → kein lokaler Mirror.
- `admin/blaueblueten-n8n` (Gitea) = Master für terpene-Repo, aktiv.
- Inventar-Pipeline gelöscht (XLSX stale seit 2025-06-05, vor Core-Cutover; Live-Daten via MikroMCP/CF/Portainer).
- Architektur-Vorschlag: **Caddyfile als Generated aus Nautobot/GC**, nicht handgeschrieben (TP34).
## Drift-Befund (Phase 0)
| # | Quelle A | Quelle B | Konflikt | Einschätzung „wahrscheinlich richtig" |
|---|---|---|---|---|
| **D1** | `inventory/bf.csv`/`bf.md` (219× `10.40.41.x`) | CLAUDE.md / teilprojekte.md (`10.40.20.x`) | Inventar führt altes VLAN1-Subnetz | Inventar war tot; **gelöscht**. CLAUDE.md ist richtig. |
| **D2** | Caddyfile → `10.40.20.167:5678` | Mac mini ARP-reachable | Konsistent | Caddyfile ist richtig, Tunnel ist nur Ingress für CF-CNAMEs. |
| **D3** | `cf-tunnel-mapping.md` §15-Tabelle: `terpene-db` 1 Connector | Live CF-API: `terpene-db` 4 Connectoren | Doku-Drift | Live ist richtig, Doku-Stand 08-25. |
| **D4** | `STATUS.md` Z.47: „Ingress `terpene.teilzeitladen.xyz` → `macmini:8890`" | Live: kein Tunnel hat diesen Hostname | Doku-Lüge | STATUS.md ist veraltet; **kein CNAME, kein Ingress**. Worker läuft nur über CF-Workers-Custom-Domain `420.teilzeitladen.xyz`. |
| **D5** | `~/.claude.json` enthält `terpene-pg` MCP | `pg_hba.conf` blockiert `10.40.10.0/24` | Geistereintrag | MCP konfiguriert, scheitert aber. Entscheidung offen (Fix oder Austragen). |
| **D6** | `~/.claude.json` 9 MCPs vs. `mcp/INVENTORY.md` 4 | Unterschiedlicher Scope | Beide richtig | `~/.claude.json` = globaler Werkzeugkasten, INVENTORY = BF-Netz-SSoT. Keine Synchronisation nötig, Notiz reicht. |
| **D7** | `memory/project_tp2_topology.md` | TP2 RETIRED (Omada) | Tote Memory-Datei | **Gelöscht** (im selben Commit mit Inventar). |
| **D8** | `handoff.md` im Root | Konvention: `docs/handoff-YYYYMMDD-thema.md` | Konventionsbruch | **Verschoben** zu `docs/handoff-20260827-hubert-und-altlasten.md`. |
| **D9** | `cf-tunnel-mapping.md` §10: `bf-nas = 70d6a4cf` | Live: `bf-nas = 220c9958` | §10 stale, §15-Nachtrag korrigiert | §15 hat es; §10 nicht. Kosmetik. |
| **D10** | Gitea `bf-network-r6/docs/cf-tunnel-mapping.md` | Lokal `~/dev/bf-infra/docs/cf-tunnel-mapping.md` | Gitea ist 1 Comm voraus, lokal ist Import-Stand | Gitea ist Master; Lokal ist veraltet (kein Sync). |
## Veraltet / tot (bereits aufgelöst)
| # | Was | Aktion |
|---|---|---|
| T1 | `inventory/bf.csv`, `bf.md`, `IPs.xlsx`, `build.py`, `bf-core-ports.*` | gelöscht (Commit 1) |
| T2 | `memory/project_tp2_topology.md` | gelöscht |
| T3 | `handoff.md` im Root | verschoben nach `docs/handoff-20260827-…` |
| T4 | `STATUS.md` Z.47 (Mac-mini-Ingress) | offen, manuelle Edit (nächste terpene-Session) |
| T5 | `bf-public` Tunnel (inactive, 0 Connector) | bewusst aufgehoben, Teil von TP31 Schritt 5/6 |
## Asymmetrie (Repo-Struktur)
| Repo | Lokal? | Gitea? | Master? |
|---|---|---|---|
| `bf-infra` | ✅ Working-Copy | ❌ kein Remote | **lokal** (Sicherheitsrisiko) |
| `bf-network-r6` | ✅ Mirror | ✅ Master (read-only geplant) | Gitea |
| `bf-golden-config` | ❌ kein Mirror | ✅ Master (Nautobot-Bot) | Gitea |
| `blaueblueten-n8n` | ✅ Mirror | ✅ Master | Gitea + lokal synchron |
**Dringlichkeit:** `bf-infra` ohne Remote = alle Edits nur lokal, kein Backup. **Festplattencrash = Datenverlust.**
## Inventar-Entscheidung
- Pipeline war seit **2025-06-05** tot: `IPs.xlsx` (Quelle) ist nicht aktualisiert, `build.py` rendert nur.
- Inventar ist seit Core-Cutover (2026-08-08) **inhaltlich falsch** (alle IPs `10.40.41.x`).
- Live-Daten kommen jetzt aus **MikroMCP** (ARP/DHCP/Interface je Router), **CF-API** (Tunnel/Ingress), **pve-mcp** (VM/LXC), **Portainer/Komodo** (Container).
- **Entscheidung: Inventar-Datei löschen.** Live-Tooling deckt den Bedarf.
## Architektur-Vorschlag (TP34 — Caddyfile via Nautobot/GC)
### Warum
Heute ist der Caddyfile (16 Sites, `bf-infra/caddy/Caddyfile`) **manuell gepflegt**. Problem:
- **Manuelle Edits** erlauben Drift.
- **Keine generische Schnittstelle**: andere Projekte (terpene, blaueblueten-n8n) können keine Sites anlegen, ohne Christoph zu fragen.
- **Kein Compliance-Check**: ein fehlerhafter Block bleibt stehen, bis jemand manuell vergleicht.
- **Keine Transaktionen**: ein kaputter Eintrag bricht die ganze Datei.
### Zielbild
Caddyfile wird **generated** aus einem **Nautobot-Datenmodell** + **Golden Config Pipeline**, identisch zum bestehenden Workflow für Router-Configs.
### Datenmodell (Skizze)
Nautobot-Entities:
- **Site**: `bf`, `fm`, `dw` (Standort, gehört zu ggf. `cf-public` Catch-all)
- **Host**: `vw.bf.emsenhuber.net` — mit Attributen `site`, `public` (boolean), `access_policy` (optional)
- **Backend**: `10.40.20.127` (Vaultwarden) — mit Attributen `protocol` (http/https), `tls_insecure` (bool), `host_header` (optional)
- **SiteBinding**: Host ↔ Backend (m:n, falls mehrere Backends pro Host)
### GC-Workflow (Skizze)
1. **Generate**: Golden Config rendert aus Nautobot-Daten den Caddyfile.
2. **Diff**: gegen die Live-Version auf `caddy-bf1` (Caddy-Admin-API `:2019/config/`).
3. **Compliance**: Pflichtfelder (jeder Host braucht Backend, jeder Backend braucht Protokoll), keine hardcoded IPs in Caddyfile, keine `tls_insecure_skip_verify` ohne Annotation.
4. **Transaktion**: Snapshot vor Deploy, Rollback bei Fehler.
### Erster Anwendungsfall: terpene.teilzeitladen.xyz
- Backend: `http://10.40.20.167:8890` (Mac mini, Caddy dort bedient PostgREST + sync + web)
- Access: CF-Access mit Service-Token `terpene-verify-v2`
- **Vorteil**: terpene-Caddyfile-Block wird in 30 Sekunden via `nautobot/gc-configplan.py` deployed, mit Diff und Rollback. Backfill-SQL ist dann via `admin/migrate` callbar.
### Abhängigkeiten
- **TP22** (Golden Config Pipeline) ✅ vorhanden
- **TP23** (DNS-Policy + Caddy-Schnittstelle-Voraussetzungen) ✅ Stufe 1
- Hängt an **nichts** außer der Implementierung.
### Status
🔜 Stub. Implementierung in eigenem Runbook, nach terpene-Caddy-Block (Quick-Win).
## Übergangsplan bf-network-r6 → bf-infra
| Schritt | Wer | Wann |
|---|---|---|
| bf-infra lokal Master (dieser Commit) | ich | ✅ |
| bf-network-r6 im Gitea: read-only + Header mit Verweis | du | offen |
| bf-infra bekommt Gitea-Remote (`admin/bf-infra` neu) | offen, „später" | nach terpene-Caddy-Block |
| Caddyfile-Master wandert zu Nautobot/GC (TP34) | nach terpene | nach Quick-Win |
## Offene Punkte (für nächste Session)
- **terpene-Caddy-Block** (zeitkritisch): Quick-Win vor TP34, manueller Eintrag in `bf-infra/caddy/Caddyfile` für `terpene.teilzeitladen.xyz → http://10.40.20.167:8890`. Mit Commit-Kommentar, dass das nicht das Pattern ist.
- **`STATUS.md` Z.47** korrigieren: Streichen oder Realität einarbeiten.
- **`~/.claude.json` `terpene-pg`**: deine Aktion (pg_hba-Erweiterung oder austragen).
- **TP34 Implementierung**: Runbook + Nautobot-Datenmodell-Skizze, sobald terpene-Caddy-Block committed ist.
## Selbstkritik / Lessons Learned für Sessions
- **Bestandsaufnahme vor Plan.** Erst was ist da, wo ist der Schaden — dann Vorschläge. Nicht umgekehrt.
- **Eine große Fragenrunde statt vieler kleiner.** Wenn der Plan von Annahmen abhängt, sammle die Annahmen in einer Runde, nicht in 3–4 Mikrorunden.
- **Master-Frage früh stellen.** Bei jedem Repo, jeder Datei, jedem Tooling: „Was ist die SSoT, wo lebt der Master, was ist Mirror?" — bevor du eine Lösung vorschlägst.
- **Drift zuerst, Lösungen später.** Drift-Tabelle posten + fragen, was richtig ist. Keine Lösungen vor dem Befund.
## Stand
- 2026-08-27
- Inventur-Session mit Christoph
- Commits: `8d2b4a7` (Aufräumen) + dieser Handoff-Commit

11
docs/teilprojekte.md
View File

@@ -204,6 +204,7 @@ nachmessen und dann entscheiden**. Blocker gibt es keine mehr. TP5 ist in der Na
> | TP31 | ✅ | Reverse Proxy Caddy (Schritt 1–4 ✅) | — | > | TP31 | ✅ | Reverse Proxy Caddy (Schritt 1–4 ✅) | — |
> | TP32 | 🟢 | Nummern-Systematik (Konzept) | — | > | TP32 | 🟢 | Nummern-Systematik (Konzept) | — |
> | TP33 | 💡 | Sonos fern (Idee, zurückgestellt) | — | > | TP33 | 💡 | Sonos fern (Idee, zurückgestellt) | — |
> | TP34 | 🔜 | Caddyfile via Nautobot/GC (Stub, Inventur-Handoff 2026-08-27) | — |
> | — | — | **34 archivierte TPs** in `teilprojekte-archiv.md` | — | > | — | — | **34 archivierte TPs** in `teilprojekte-archiv.md` | — |
### TP5.1 — DNS-Visibility & Flow-Observability für Low-Trust-Geräte (Airfryer-Fall) ▸ vorgemerkt ### TP5.1 — DNS-Visibility & Flow-Observability für Low-Trust-Geräte (Airfryer-Fall) ▸ vorgemerkt
@@ -1715,6 +1716,16 @@ kann in Ruhe nachziehen.
--- ---
### TP34 — Caddyfile via Nautobot/GC (generische Reverse-Proxy-Schnittstelle) ▸ 🔜 STUB
> **Konzept + Architektur-Skizze:** [`docs/handoff-20260827-inventur-und-architektur.md`](handoff-20260827-inventur-und-architektur.md) — bitte dort weiterlesen (Architektur-Abschnitt).
- **Scope:** Reverse-Proxy-Hosts werden im **Nautobot-Datenmodell** gepflegt (Site, Host, Backend-Spec). **Golden Config** rendert den Caddyfile aus den Daten, Diff-Check gegen die Live-Version auf `caddy-bf1`, Compliance-Checks + Transaktionen identisch zum bestehenden Workflow für Router-Configs.
- **Auslöser (Inventur 2026-08-27):** der Caddyfile (`bf-infra/caddy/Caddyfile`) ist heute **manuell gepflegt** — kein Drift-Check, keine Transaktionen, andere Projekte können keine Sites anlegen ohne Christoph. Lösung: **Nautobot/GC**, kein Caddy-API-Sidecar (kein zweites SSoT).
- **Erster Anwendungsfall:** `terpene.teilzeitladen.xyz → http://10.40.20.167:8890` (Mac-mini-Backend, dort PostgREST + sync + web via lokalem Caddy `:8890`). Vor TP34: manueller Quick-Win-Caddy-Block.
- **Abh.:** TP22 (GC-Pipeline) ✅ vorhanden · TP23 (DNS-Policy + Caddy-Voraussetzungen) ✅ Stufe 1. Hängt an **nichts**, eigene Implementierung im Runbook nach dem Quick-Win.
- **Status:** 🔜 Stub; Konzept + Architektur-Skizze vollständig in Handoff-Datei. Implementierung in eigenem Runbook nach terpene-Caddy-Quick-Win.
---
--- ---
## Abgeschlossene Teilprojekte ▸ [`teilprojekte-archiv.md`](teilprojekte-archiv.md) ## Abgeschlossene Teilprojekte ▸ [`teilprojekte-archiv.md`](teilprojekte-archiv.md)