User-Okay 2026-08-30. Auslöser ist der TP16.3-Schnitt: um ihn zu planen,
mussten sechs cloudflared-Container über drei Hosts per SSH und Portainer-API
zusammengesucht werden -- die Zuordnung Tunnel->Connector->Host existierte
nirgends als Datensatz, nur in Prosa.
Befund live gegen die Nautobot-API gelesen:
Devices 8 (4 aktiv, 4 decommissioned), Apps nur golden-config
ipam.Service 0 · CustomField 0 · Relationship 0 · VirtualMachine 0 · Tag 0
Nautobot kennt heute ausschliesslich die vier MikroTik. Weder Caddy noch
AdGuard noch pve/NAS/macmini noch Nautobot selbst sind erfasst.
Konsequenz fuer den Zuschnitt: TP37 ist zuerst eine Datenmodell-Frage
(Substrat + Dienste), erst danach eine Connector-Frage. Damit liefert es das
Fundament, das TP34 (Caddyfile via GC) und TP36 (SSoT fuer teilprojekte.md)
ebenfalls brauchen -- Reihenfolge TP37 vor TP34, festgehalten in beiden.
Abgrenzung explizit: kein Golden Config fuer Nicht-Netzgeraete (das ist TP34),
keine Cloudflare-Writes aus Nautobot heraus.
Einschraenkung benannt: die GC-Pipeline ist heute schlank und 104/104
compliant; Punkt 1-2 daher als eigener abnehmbarer Schritt mit
Compliance-Gegenprobe, nicht als Nebeneffekt.
Alle drei Stellen nachgezogen: Quick-Index, TP-Abschnitt, Ist-Stand-Block.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Dritter Access-Point ap3 (MikroTik cAP ax, cAPGi-5HaxD2HaxD) kommt dazu und loest
mittelfristig ap1 in Technik UG ab. Statt eines neuen TP wandert TP28 aus dem Archiv
zurueck -- neue Regel: ein archiviertes TP ist ein geschlossenes, kein versiegeltes
Ticket (Christoph-Direktive 2026-08-30).
Live am Core:
- ether21 ist AP-Trunk (10/20/30/40/50/90/99 tagged, Muster ether15). ⚠️ Erratum: erst
war ether22 angenommen und getaggt; der Port hat keinen Link. Gegenprobe ueber die
Bridge-Host-Tabelle: auf ether21 sitzt D0:EA:11:FF:16:9D = E01 vom ap3-Label.
ether22 wieder leer.
- Backups vorher: pre-ap3-20260830.backup/.rsc auf core und ap1.
- Compliance vor und nach jeder Aenderung 104/104, 0 Drifts.
Golden Config (2 Pushes: e25d654b, 20472cdb):
- Core-L2-Block traegt ether21.
- AP-Zweig rendert die Bridge-Ports jetzt aus ap.extra_ports statt hartkodiert
ether3/4/5. Das war die stille Annahme "AP == hAP ax2 mit 5 Ports"; der cAP ax hat
zwei. Default in ap-common = hAP-ax2-Bestand, ap3 ueberschreibt mit [].
Dass ap1/ap2 danach zeichengleich rendern, beweist die 0-Drift-Messung.
Kanalplan NICHT neu erfunden: TP25 hat ihn am 2026-08-24 fuer genau dieses Geraet
gerechnet (DFS vom User genehmigt). ap3 = 5180/Ce + 2437 (ch6, nicht ch1 -- ch1 bleibt
fuer ap1, damit 1/6/11 erstmals lueckenlos aufgeht). ap1/ap2 gehen beim Umzug auf
5260/Ce bzw. 5300/Ce, 5220/Ce bleibt Ausweichspur.
MikroMCP-Registry (MCP-Lifecycle, User-Freigabe 2026-08-30) -- zwei Drifts:
- MIKROMCP_CONFIG_PATH zeigte auf ~/dev/bf-network-r6 (Archiv-Repo); die identische
Datei in bf-infra war wirkungslos. Jetzt bf-infra = SSoT.
- In opencode.jsonc fehlte MIKROMCP_CONFIG_PATH ganz, hinterlegt waren nur ap1/ap2 --
opencode kannte core/branch gar nicht. Beide Clients zeigen jetzt auf dieselbe
Registry; ap3 aufgenommen, rosVersion von stale 7.23/7.19.5 auf 7.24 korrigiert.
Neustart des MCP noetig, Registry wird nur beim Start gelesen.
Noch offen: physischer Bring-up (Datei liegt bereit), ap1-Radios aus, CAPsMAN-Objekte
fuer ap3, Nautobot-Adoption, Messrunde -- und die Passwort-Rotation: das gemeinsame
MikroTik-Admin-PW ist in dieser Session durch eine ungefilterte Ausgabe des
mikromcp-env-Blocks ins Transkript geraten und gilt als verbrannt (Posten fuer TP30).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
CLAUDE.md behauptete "lokal, kein Gitea-Remote (Working-Copy). Verloren bei
Festplattencrash." Live geprueft 2026-08-30:
origin = https://gitea.emsenhuber.net/admin/bf-infra.git
origin/main = b917691 (Handoff 2026-08-28)
Das Remote existiert also seit spaetestens 2026-08-28. Die Aussage war bei
der Inventur am 08-27 richtig und ist seither ueberholt -- nicht falsch
erhoben, sondern nicht mitgezogen.
Anlass: eine Session hat die Zeile uebernommen und "lokaler Master ohne
Gitea-Remote" behauptet, statt `git remote -v` zu tippen. Genau der Fall aus
dem Lessons-Block "Kommentar in Code != Verhalten". Merkregel deshalb an der
korrigierten Zeile verankert.
CLAUDE.md: Zeile direkt korrigiert (lebende Anweisungsdatei).
Handoff 2026-08-27: Originalzeile bewusst erhalten, Korrekturvermerk
darunter -- historische Fassungen werden hier nicht umgeschrieben.
Die Backup-Luecke bleibt real, hat aber eine andere Ursache als notiert:
nicht fehlende Struktur, sondern ungepushte Commits (am 08-30 waren es vier).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Public-Strang eingedampft. Entfernt aus Ingress UND DNS:
pve, portainer, pve-mcp, ha-mcp, ds-bf, ccu, iobroker, z2m25, pbs
sowie die drei CF-Access-SSH-Ziele 82unkpb5 / 3k23uow7 / j44d6tua.
Ingress-Bilanz: bf-mm 6->4, bf-nas 6->3, bf-pve 9->2, Catch-all je letzte.
pbs + SSH standen nicht in der Kandidatenliste -- User-Entscheid 2026-08-30
"beide mesh-only".
Abnahme beidseitig gemessen:
- intern traegt weiter: AdGuard loest alle neun Namen auf 10.40.20.40,
Caddy antwortet HTTPS 200 (pve 0,08s / portainer 0,03s / pbs 0,03s)
- oeffentlich weg: NXDOMAIN gegen 1.1.1.1
- Public-Strang unberuehrt: vw/hass/n8n/gitea weiterhin HTTP 200
Nachweis ist das Zuruecklesen der Ingress-Config, nicht die Frontend-Antwort
(Access antwortet vor dem Tunnel -- TP16.3-Regel).
Bewusst NICHT geschnitten: gitea-mcp + n8n-mcp. Die TP16.3-Vorpruefung
schlaegt an -- gitea-mcp.emsenhuber.net steht in 9 Dateien (8 fremde
Projekte + bf-infra/opencode.jsonc), ~/.claude.json nutzt zusaetzlich
n8n-mcp. TP35 Schicht 1 ist nur global vollzogen, nicht auf Projekt-Ebene.
Erst migrieren, dann schneiden -> Follow-up F1.
Blocker fuer den Abbau der drei Alt-Tunnel: bf-public hat 0 Connectoren.
Er gehoert laut Entscheid auf ap1/ap2, dort fehlen aber container-Paket
UND device-mode container=yes (physische Bestaetigung am Geraet, fetch=no).
Vor-Ort-Session noetig -> Follow-up F2. Bis dahin stehen bf-mm/bf-nas/bf-pve
mit sechs Containern (LXC400, macmini, NAS -- alle lokalisiert).
Doku an allen drei Stellen nachgezogen: Quick-Index, TP16.3-Abschnitt,
Ist-Stand-Block. TP37 (CF-Connectoren in Nautobot) als Vorschlag
eingetragen, Okay steht aus.
Rollback: docs/cf-backup/*-20260830-vor-tp16.3-schnitt.json
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Christophs Kontext explodiert am Sessionende. Handoff bündelt:
- CF-Token-Audit-Befund: CF_DNS_API_TOKEN ungültig (Code 1000 'Invalid API Token'),
Christophs Verdacht 'falscher Token extrahiert' bestätigt.
- Globale MCP-Migration FQDN → IP für gitea-mcp + n8n-mcp; cloudflare bleibt
extern (User-Direktive explizit). WARP-Pfad statt Bearer-Header wenn der
Connector intern ohne Token lebt.
- terpene W5: n8n-mcp in blaueblueten-n8n/.mcp.json (User-Zustimmung).
- Domain-Korrektur: 420.teilzeitladen.xyz ist die echte terpene-Domain
(NICHT terpene.teilzeitladen.xyz) — User-Direktive, gilt für alle.
- W1/W6 bleiben User-blocked, W7 wartet auf TP31-Schritt 5/6.
Dringend beim Nachfolger: CF-Token-Validität zuerst klären, dann erst
MCP-Migration. STATUS.md im terpene-Repo ist auf die falsche Domain
korrigieren.
Container shelly-mcp läuft seit dem mcp<2-Pin-Fix auf DS923 (10.40.20.180,
macvlan vlan20). Eintrag in der projekt-spezifischen Config analog zu pve-mcp:
type=remote, kein Bearer (Container nimmt keine Auth entgegen, lebt im
BF-LAN hinter deny-by-default — s. TP5).
Abnahme: mcp list 11/11, shelly-mcp connected, /health antwortet
200 mit psk_configured:true.
Container crashte beim ersten Deploy mit 'No module named mcp.server.fastmcp':
PyPI hat mcp 2.x als aktuellste Version, FastMCP wurde dort zu MCPServer
umbenannt. Repo-Code (server.py) nutzt noch v1-API.
Fix: requirements.txt 'mcp[cli]>=1.0,<2' — hält den Server auf v1-kompatibel.
Deploy-Ergebnis:
- Container shelly-mcp auf DS923, IP 10.40.20.180 (macvlan vlan20)
- Health /health: 200, psk_configured:true, iot_ssid=dirtyvader-iot
- StreamableHTTP /mcp: serverInfo 'shelly-mcp 1.29.1'
- Live-Sweep 10.40.30.180-250: 23 Shellys erreichbar
TP30 Posten #3 (Shelly-Gerätepasswort) hochgestuft: SHELLY_DEVICE_PW ist im
Zuge dieses Deploys erneut in ein Sitzungstranskript geraten (sed-Pattern
'SHELLY_DEVICE_PW=.*' hat den Wert nicht maskiert, weil der Replacement-
String zu wenig greedy war — neuer Lessons-Block-Eintrag). Reihenfolge:
erst Werkzeug-Härtung (Stream-Filter statt cat+sed), dann Posten #3
rotieren. CLAUDE.md hat den Lessons-Eintrag, TP30 Posten #3 hat die
Hochstufungs-Begründung.
Portainer-Server (pve LXC 400): 2.40.0 → 2.42.0 via Image-Swap mit Volume-Erhalt.
Pre-Upgrade-Snapshot: docker commit :2.40.0-preupgrade-20260828 (Rollback 7 d
verfügbar) + Settings/Stacks/Endpoints-JSON-Dump (40 KB, 31 Stacks, 4 Endpoints).
Instance-ID + API-Token nach Bump identisch — kein Re-Auth, kein Settings-Verlust.
portainer-mcp: offizielles PyPI-Paket mcp-portainer~=2.42.0 (193 Tools), nur
in bf-infra/opencode.jsonc, via uvx-stdio. Tool-Gate: get_guidance() einmal pro
Session zwingend vor erstem Read. Andere Projekte unberührt.
Korrekturen ggü. Handoff 2026-08-28 README:
- mcp-portainer PyPI bis 2.42.6, Docker-Hub portainer/portainer-ce nur bis 2.42.0
(unterschiedliche Versionierungspfade).
- mcp/portainer/README.md ist auf 2.42.6 formuliert und sollte nachgezogen werden.
Bestand: mcp/INVENTORY.md portainer-mcp ⛔→🟢 + Header MCP-WARP-Direktive ergänzt.
.mcp.json (war getrackt aus Commit 3426366) entfernt: opencode nutzt opencode.jsonc,
nicht .mcp.json — Claude-Code-Konvention hier irrelevant.
Befund 2026-08-28 nach Skill-Verifikation in opencode:
- Der 'Nächster Schritt (2026-08-26)'-Absatz war zwei Tage veraltet
(drei Sessions waren parallel offen)
- Manuelle Doku mit Live-Daten verliert gegen die Realitaet, sobald
die Datei lang wird (1940 Zeilen, drei Stellen pro Edit)
Reaktion:
1. 'Nächster Schritt' umgeschrieben: drei Folge-Sessions A/B/C aus
dem gestrigen Handoff, klar als 'parallel' markiert. A ist erledigt
(TP35 Schicht 6), B+C offen.
2. TP36 als Folge-TP neu angelegt: SSoT via Nautobot fuer
teilprojekte-Live-Daten + Datei-Aufteilung (Index / Snapshot /
Archiv). Eigene Session, nicht heute.
3. CLAUDE.md: zwei Lessons-Eintraege:
a) opencode-TUI: fuehrendes Leerzeichen vor /command manchmal
noetig (Beobachtung, kein Skill-Bug)
b) Manuell gepflegte Doku verliert gegen Realitaet, Merkregel:
drei Stellen pro Edit mitlesen (Quick-Index, TP-Abschnitt,
Ist-Stand); strukturelle Antwort = TP36
Lessons-Block hat jetzt 7 Eintaege (Stand 2026-08-28).
- CLAUDE.md: zwei Lessons-Eintraege (opencode-Default-Pfad kopieren,
nicht symlinken; Kommentar in Code != Verhalten)
- teilprojekte.md: TP35 Quick-Index auf 'Schicht 6 erledigt, Rest offen',
Schicht-6-Befund im TP-Block, Ist-Stand auf 2026-08-28 mit MCP-Bestand-
Korrektur
- handoff-20260828-session-a-projektstatus.md: Session-A-Bericht mit
Drift, Befund, Entscheid, Lehren fuer Session B
Skill selbst liegt in ~/.config/opencode/skills/projektstatus/SKILL.md
(cp aus ~/.claude/skills/projektstatus/, byte-identisch) - opencode
scannt diesen Default-Pfad, kein skills.paths-Eintrag in der JSONC
noetig.
cloudflared-Konfigurationsmaterialien fuer TP16.3 (BFF-public-Tunnel
auf dem Edge statt cloudflared-QUIC-Workaround). Enthaelt:
- ap-bootstrap.rsc: RouterOS-Script fuer ap1/ap2 (veth, srcnat,
container-mounts, env-Vars). Token kommt aus ~/.secrets, wird per
SFTP auf den Router kopiert — kein Klartext im Script.
- cloudflared-bf-public-config.yml: tunnel-UUID + credentials-Pfad
(KEIN Secret). Ingress wird CF-Dashboard-gemanagt (config_src=cloudflare).
- .gitignore: credentials.json mit dem Tunnel-Secretbase64
(PrivateKey des Tunnels, niemals committen).
Status: vorbereitet, nicht ausgefuehrt. credentials.json bleibt lokal.
Vorbereitetes Runbook für TP31.5 (cloudflared-Container auf hAPs statt
TUN-Device-Workaround, da WARP-Connector auf ROS nicht möglich). Inhalt:
- Image-Build (RouterOS 7.x container, 70 MB Budget je AP)
- Pro AP: veth, interface-list-Mitgliedschaft, container-env
- CNAME-Flip von CF-Tunnel auf ap1/ap2 (DNS-Propagation, Rollback)
- Voraussetzungen: WAN-Healthcheck, Tunnel-Secret aus credentials.json
(siehe routeros/cloudflared/.gitignore im Folge-Commit)
Status: vorbereitet, nicht ausgeführt. Stand 2026-08-27.
Vorbereitung für Session B (Deploy auf DS923). Datei-Set reicht für
Image-Build ohne weitere Quellen aus dem Repo:
- Dockerfile: python:3.12-slim, mountbares /config ohne .env-COPY
- requirements.txt: mcp[cli]>=1.0, starlette>=0.36 (StreamableHTTP)
- BUILD.md: rsync → docker build → Portainer-Container-Deploy
- .gitignore: .env (Schema-Vorlage lokal) + __pycache__ ausklammern
Die Live-Instanz .env und der Container selbst werden in Session B
gebaut, nicht hier. Kein Secret in Git.
Eine Seite, die eine frische Session in 30 Sekunden auf Stand bringt:
TL;DR, Lese-Reihenfolge (Handoff → Anker → TP35), sofort-tun-Liste,
Übergabe-Mechanik, Mid-Action-Checkpoint, Commit-Hinweis-Regel, Was-offen.
Löst das 'Bahnhof'-Problem, das Christoph beim Session-Neustart
beobachtet hat.
TP16.3 existiert seit 2026-08-17 (Quick-Index Z. 194, Body Z. 401,
Runbook tp16.3-nautobot-mesh-only-runbook.md) und deckt 'alle Tools
über Caddy oder CF + Caddy (extern)' + Auth-Sanierung bereits ab.
Mein Fehler: ich habe im Index nicht nachgeschaut und einen Vorab-Punkt
formuliert, der TP16.3 doppelt. Anwender hat das in dieser Session
explizit markiert ('das darf dir kein 2. mal passieren').
Fix:
- Session-Anker: Vorab-Notiz entfernt, ersetzt durch Verweis auf TP16.3.
- TP16.3-Body: technische Notiz 'n8n-mcp Accept-Header-Strike +
Auth-Sanierung' eingepflegt (SSE-Header-Konsequenz für künftiges
Caddy-Fronting, Reihenfolge TP16.3 → TP35 Schicht 2).
Lehre: vor jeder Aussage 'gibt's noch nicht' oder 'neuer TP nötig':
erst grep auf den Quick-Index in teilprojekte.md.
n8n-mcp-Accept-Header-Strike wird mit dem noch kommenden CF-Tunnel-Punkt
gelöst, nicht heute. Bearer-Authentifizierung soll einmal sauber per
Caddy/CF-Access zentralisiert werden — TP35-Schicht-2 Endform hängt davon.
Inhalt: nur Doku, keine Migration, kein neuer TP, keine Config-Änderung.
Diagnose: n8n-mcp verlangt 'Accept: application/json, text/event-stream'
(StreamableHTTP-Modus). opencode mcp list schickt nur 'application/json',
kriegt 406, wertet als failed. Echter Tool-Aufruf nutzt richtigen Header,
deshalb Sidebar grün. Bearer-Token + Server sind gesund (200 OK mit
richtigem Accept-Header, serverInfo: n8n-documentation-mcp 2.57.1).
Konsequenz: 'failed' in mcp list ist nicht 'kaputt' sondern 'Probing-Header
zu strikt'. Sidebar-Status bleibt Wahrheit.
- Neue Handoff-Datei für den konkreten nächsten Schritt (im Gegensatz zur
Inventur-Handoff, die den Master-Plan zeigt).
- Dokumentiert: cannaleo/terpene-pg entfernt, n8n-mcp repariert,
shelly-mcp-Tote entdeckt, CLAUDE.md-Erweiterung.
- Liste der offenen Aktionen für die nächste Session: bf-network-r6
archivieren, terpene-Caddyfile-Block, STATUS.md Z.47 korrigieren,
n8n-mcp auch in ~/.claude.json, gitea-mcp-Init-Problem.
- shelly-mcp läuft auf keinem Host (kein Mac-Prozess, kein Container auf
NAS/pve). INVENTORY-Handoff hatte den Stand nicht aktualisiert.
Config jetzt enabled=false, neuer Punkt im Ist-Stand-Block.
- 3 neue Lessons-for-Sessions-Regeln: MCP-Änderungen aktiv melden,
Host vor Edit verifizieren, tote MCPs ins Projekt-Repo.
- 'Was du sofort wissen musst' um shelly-mcp-Tote ergänzt.
Die Datei war bereits im Working Tree, aber ohne klaren Zweck -- jetzt
umbenannt auf .snapshot.yaml und mit Marker-Kommentar versehen, der sagt:
- das ist KEINE Transaktions-Akte (kein .json)
- das ist auch KEIN Vor-Zustand zum heutigen nas.emsenhuber.net-Edit
- das ist die AGH-Komplett-Config mit bereits angewandtem Standortsuffix
(*.bf.emsenhuber.net), die beim Bau des AGH-Paars (110/111) in der
naechsten Session als Soll-Zustand gilt.
upstream_dns ist auf /bf.emsenhuber.net/ bedingt (Suffix-Form), 26 von
30 Rewrites haben .bf.-Suffix, 4 Public (vw/hass/n8n/gitea) bleiben ohne
Suffix.
Baut auf handoff-20260825 auf (AdGuard-Paar + Split-Horizon) und ergaenzt
den Auftrag um den heute eingefuehrten Standortsuffix-Sweep: alle BF-Hosts
in AGH heissen kuenftig <host>.bf.emsenhuber.net statt ohne Suffix.
nas.emsenhuber.net ist seit 1d569fa weg (Commit direkt vorher).
`nas.emsenhuber.net` war nur als AGH-Rewrite auf 10.40.20.10 vorhanden,
zeigte aber nirgends hin: kein CF-CNAME, kein Caddyfile-Eintrag (der
hatte von Anfang an ds-bf.emsenhuber.net fuer Synology DSM).
Mit dem TP23-Stufe-2-Cutover wandert die DNS-Aufloesung in ein
AdGuard-Paar und der Rewrite-Satz wird neu aufgebaut. Die Regel
ist ab jetzt: Hosts, die es an mehreren Standorten gibt, heissen
immer `<host>.<site>.emsenhuber.net` — kein gemeinsamer Name
ohne Suffix.
Andere namensgleiche Hosts (macmini/mfc/tv/docker/platform-pg/
core/ap1/ap2/branch) bleiben vorerst ohne Suffix in AGH und werden
einzeln in der TP23-Stufe-2-Session bewertet.
- adguard/AdGuardHome.yaml: AGH-Wizard-Setup (27 Rewrites ohne .bf, DoH zum CF-Gateway, conditional emsenhuber.net).
- nautobot/mikrotik_routeros.j2: DHCP dns-server=10.40.20.36,.37, domain=emsenhuber.net.
- docs/transaktionen/TP23-agh-firewall.commands.rsc: TP5-E2 LAN->AGH dns auf .16/.17 ersetzt durch .36/.37.
- docs/transaktionen/TP23-agh-dhcp-cutover.commands.rsc: DHCP-Cutover (dns-server + domain in einem Deploy).
Compliance 104/104, 0 Drifts. Core bleibt als Rückfallebene unangetastet.
[KEIN go fuer den Rest: Persistenz (CLAUDE.md/memory), Host.Naming (.host.emsenhuber.net),
add-dns-entries-Suffix, conditional-Upstream, lease-time-Transaktion, TP31-defer — alles im Plan,
Wartet auf separates go des Users.]
User-Entscheid. minarca, node-red, hms-mqtt-publisher und openproject
zerstoert, 28 PBS-Snapshots geloescht, 0 Fehler. Gegenprobe direkt am
Datastore: keine Spur von ct/103|109|115|201 mehr.
Ergebnis: auf pve laeuft jetzt jeder existierende Gast -- 11 LXC + 2 VMs,
kein einziger stopped. Der Datastore enthaelt nur noch aktuelle Gaeste.
Merkregel mitgeschrieben: die Snapshot-Liste VOR dem pct destroy
einsammeln. pvesm list --vmid liefert danach 0, obwohl die Backups noch
liegen -- der Filter braucht die Gast-Config. Genau deshalb lief der
104er-Loeschversuch vorhin ins Leere.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
User-Entscheid: auch die Grafana-Backups loeschen. Gegenprobe direkt am
Datastore (ct/104 = 0), nicht ueber 'pvesm list --vmid' -- dessen Filter
ist nach dem destroy nicht mehr aussagekraeftig.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Christoph hat 10.40.41.10/32 (alte VLAN1-NAS) entfernt und den Stand als
stable bestaetigt - kein pending offen. Vertraut wird jetzt nur noch, was
tatsaechlich proxyt: 10.40.20.40 (Caddy) plus die drei cloudflared-Origins,
die mit Schritt 6 wegfallen. Abnahme: hass/vw/gitea/n8n je 200 ueber Caddy.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ursache war nicht der fehlende Eintrag, sondern der falsche Ort: HA hat die
http-Konfiguration nach .storage/http migriert ("yaml_migration_done": true,
created_at 2026-08-05). Der YAML-Block wird seither kommentarlos ignoriert -
auch ein absichtlich ungueltiger Schluessel darin erzeugt keinen Fehler.
Die Logzeile fuehrt aktiv in die Irre: "untrusted proxy 10.40.20.40" faellt
laut Quelltext nur bei aktivem use_x_forwarded_for - beide Werte kamen aber
aus .storage, wo .20.10/.126/.167 (die cloudflared-Origins) standen und
Caddy fehlte.
Fix ueber den vorgesehenen Weg: http/config/configure (setzt pending, startet
HA neu) und binnen 5 Minuten http/config/promote. stable enthaelt jetzt
10.40.20.40/32, pending ist leer, hass/vw/gitea/n8n liefern 200 ueber Caddy.
Der wirkungslose Block in configuration.yaml ist durch einen Hinweis ersetzt.
Offen und bewusst vertagt: 10.40.41.10/32 (tote VLAN1-NAS) steht weiter in
der Trusted-Liste.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
SoT: CF und Caddy werden NICHT synchron gehalten - die Doppelpflege faellt
mit Schritt 5/6 weg. Heute stehen 19 Ingress-Regeln und 16 Caddy-Sites
nebeneinander und stimmen fachlich ueberein; im Zielbild haelt CF nur noch
eine Catch-all auf 10.40.20.40. Danach: Caddyfile = Name->Origin,
CF = welcher Name ist oeffentlich (4), AGH = Name->IP intern.
Nebeneffekt: die 12 internen Namen brauchen keinen oeffentlichen DNS mehr.
caddy/cf-sync.py (read-only, Exit 1 bei Drift) findet im ersten Lauf sieben
Abweichungen, alle auf CF-Seite: grafana noch im Ingress, nautobot und
gateway-dw als CNAME ohne Ingress (Quelle der 302), drei *.bf-CNAMEs auf den
zerstoerten NPM, dazu die Wildcard-Access-App, die alles maskiert.
Uebergabe korrigiert nach User-Einwand und Gegenmessung:
- Rewrites sind veraltet, nicht wertlos - Hosts leben auf VLAN20 weiter,
also Ziele umbiegen statt Namen loeschen.
- Die Redundanz existiert doch, reziprok ueber die Standorte: FM antwortet
auf 10.101.0.16/.17 (DS415+) - und beide liefern fuer nas.bf die tote
VLAN1-Adresse. Ein Rewrite-Satz nur im neuen BF-Paar erzeugt
standortabhaengig verschiedene Antworten.
- Vorratsregel auf .16 wird gestrichen statt erweitert (User-Entscheid).
- Cave: emsenhuber.net ist die Domain, bf.lan nur der DHCP-Suffix.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
