3ea8d050d2f3397f59de4fb0f1ab4b14dc987f75
101 iob-master, 102 mqtt5, 106 influxdb2, 107 redis meldeten networking.service und ifupdown-wait-online.service dauerhaft als failed, bei funktionierendem Netz. Folge: alles mit After=network-online.target startet nach einem Reboot nicht -- influxdb2 kam gestern Nacht nicht hoch (Unit enabled, kein Startversuch im Journal). URSACHE, und es ist dieselbe Altlast wie beim toten Resolver: in /etc/network/interfaces standen noch auto-Stanzas aus dem alten VLAN1-Schema (eth0 -> 10.40.41.x, teils mit gateway 10.40.41.254) sowie aus frueheren Versuchen (veth16, veth24, ein Tippfehler eth01) -- alle auf Interfaces, die es im Container gar nicht gibt. ifup -a scheitert daran, waehrend das echte veth20 sauber hochkommt. Der VLAN-Umzug hat die Container umgehaengt, aber die alten Stanzas nie entfernt. FIX: nur Stanzas entfernt, deren Interface in ip -br link fehlt; lo, veth20 und veth20.2 unangetastet. Backup je Container: /etc/network/interfaces.bak-20260901. ABNAHME war ein echter Reboot, nicht systemctl is-active: 106 neu gestartet, influxdb kam nach 5 s VON SELBST hoch, networking active, null failed units. Endstand ueber alle 13 LXC: dns=10.40.20.1 durchgehend, networking ueberall sauber. Ohne Netzbezug bleiben run-rpc_pipefs.mount (101, 150) und proxmox-regenerate-snakeoil.service (108), beide vorbestehend. MESSFALLE, mit in CLAUDE.md aufgenommen: nc -z meldete waehrenddessen neun Dienste gleichzeitig als "Port zu" -- inklusive des SSH-Ports, ueber den diese Session gerade arbeitete, waehrend curl vom selben Host HTTP 200 in 24 ms bekam. Bei "alles gleichzeitig kaputt" zuerst das eigene Werkzeug verdaechtigen. Es waere um ein Haar die zweite falsche Ausfallmeldung dieser Nacht geworden. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
docs 🧭 Governance „Config nur via Nautobot" + TP19.1-Stand (ap1-DNS ✅, ap2 vertagt), sw2-IP-Korrektur .41.181, VLAN99-Cutover-Guides sw1/sw2, TP15-Lieferung 17.07., TP20 an Komodo gebunden
bf-infra
BF-Netzwerk-Infrastruktur (Caddy, AGH, MikroTik-Konfig, Dokumentation, MCPs).
Aktiver Fork von bf-network-r6 (Claude-Code-Architektur, 2025-2026), ab August 2026
unter OpenCode und anderem LLM weitergepflegt.
Master-Struktur
| Repo | Rolle | Stand |
|---|---|---|
~/dev/bf-infra/ + admin/bf-infra (Gitea) |
Aktiver Master | Remote seit 2026-08-30, main synchron — Backup-Lücke geschlossen |
admin/bf-network-r6 (Gitea) |
Archiv, historischer Master | read-only-Header, letzte aktive Commits 2026-08-25 |
admin/bf-golden-config (Gitea) |
Bot-Master (Nautobot 2×/Tag) | intended/ + backups/, nicht manuell |
admin/blaueblueten-n8n (Gitea) |
Master für terpene-Repo | aktiv, lokal synchron |
Was hier lebt
docs/teilprojekte.md— kanonische Steuerung (Ist-Stand, offene TPs, kritischer Pffad)docs/teilprojekte-archiv.md— abgeschlossene TPs (Volltext)docs/handoff-*.md— Session-Übergabencaddy/Caddyfile— Reverse-Proxy BF (siehe TP34 für Migration zu Nautobot/GC)nautobot/— Skripte + Jinja-Template für Golden Configmcp/— MCP-Server-Inventar (SSoT gegen „1000 MCP-Leichen")inventory/— entfernt 2026-08-27 (Pipeline seit 2025-06 stale; Live-Daten via MikroMCP/CF/Portainer)
Status (2026-08-27)
- L3 + WAN-Edge =
crs326-core, alle 4 MikroTik auf RouterOS 7.24 (TP27) - Firewall deny-by-default seit 2026-08-18 (TP5)
- WLAN via CAPsMAN auf dem Core seit 2026-08-17 (TP28)
- Compliance 104/104 grün, 0 Drifts (Golden Config, TP22)
- AdGuard-Paar
agh-bf1/agh-bf2aufgebaut, DHCP noch nicht umgestellt (TP23 Stufe 2 / TP31 Schritt 4) - Caddyfile Reverse-Proxy seit 2026-08-25 (TP31), 16 Sites BF-intern
- terpene.teilzeitladen.xyz: Worker läuft auf Mac mini (10.40.20.167:8890), kein Caddy-Block, kein CF-Tunnel — Backfill via DB-Migration blockiert (Handoff 2026-08-27)
Übergangspfad von bf-network-r6 → bf-infra
- README + Strukturen aktualisiert (dieses File)
- bf-network-r6 im Gitea auf read-only, Header mit Verweis (deine Aktion)
- Inventar-Pipeline gelöscht (XLSX stale, MikroMCP/CF/Portainer liefern Live)
- Caddyfile-Master wandert zu Nautobot/GC (TP34, siehe Handoff 2026-08-27)
- bf-infra bekommt Gitea-Remote (offen, „später")
Werkzeuge (Stand 2026-08-27)
- MikroMCP (RouterOS, 4 Geräte) —
~/.claude.json+opencode.jsonc - pve-mcp (Proxmox, 10.40.20.173) —
opencode.jsonc - home-assistant (HA, 10.40.20.105) —
opencode.jsonc - cloudflare (CF-API, OAuth) —
opencode.jsonc - gitea-mcp (FQDN) —
opencode.jsonc - komodo-mcp (geplant, Migration von Portainer) —
~/dev/bf-infra/mcp/komodo/ - shelly-mcp (Client-lokal Interim, 127.0.0.1:3030) — vor Migration auf zentralen Container
Description
BF-Infrastruktur (Fork von bf-network-r6): MikroTik, Caddy, AGH, Nautobot/GC, MCPs. Master seit 2026-08-27.
Languages
Python
57.9%
RouterOS Script
33.8%
Jinja
6.6%
Shell
1.7%