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>
Die erste Fassung entstand vor der Caddy-Abnahme. Live erhoben, dagegen:
- adguard_bf1 (.20.16) ist ein Archiv, keine Vorlage: 24 Rewrites, davon 8
ins tote VLAN1, 9 auf den heute zerstoerten nginx-proxy-manager (LXC 128)
und 2 FritzBox-Reste. Uebernommen werden Upstreams/Filter, die Rewrites
entstehen neu aus caddy/Caddyfile.
- .20.17 ist nicht "bf2", sondern adguard_fm2 (FM-Standort) und antwortet
fuer gitea mit 10.40.41.123. BF hat heute EINEN AGH.
- Die TP5-Vorratsregeln erlauben LAN->DNS hart auf .20.16. Nach dem
DHCP-Flip wird DNS ein forward-Fluss ueber VLAN-Grenzen; ohne erweiterte
Regeln verlieren IOT/MEDIA/UNTRUSTED/GUEST/MGMT die Aufloesung, waehrend
VLAN20 weiterlaeuft und den Fehler tarnt.
Dazu neu: lease-time=1d macht Flip und Rollback traege (erst zur
Erneuerung wirksam), expliziter Rollback-Abschnitt, .36/.37 als frei
geprueft, und der Core bleibt bewusst Rueckfallebene.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Schritt 3 ist durch: Token liegt, deploy.sh gelaufen, Dienst active+enabled.
Abnahme ueber den Host-Header von einem zweiten Host (pve): 11x 200,
nautobot 302, Antwortzeiten 0,02-0,11 s.
Zwei Funde, die man sonst falsch ablegt:
- pve-mcp 400 / ha-mcp 403 / gitea-mcp 404 sind KEINE Proxy-Fehler - die
Gegenprobe direkt am Origin liefert dieselben Codes. Es sind die Antworten
der MCP-Server auf ein nacktes GET /.
- hass bleibt 400, aber die Logzeile sagt "untrusted proxy 10.40.20.40" und
nicht "not set-up for reverse proxies": use_x_forwarded_for greift also,
nur die Liste zieht nicht. Zwei volle Neustarts, Config-Check valid.
Naechster Schritt notiert; die atime taugt unter relatime nicht als Beweis.
Ist-Stand-Block mitgezogen (Projektregel).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Split-Horizon-Entscheid (AdGuard statt Core) macht aus 'ein paar
Eintraegen' eine Verschiebung der DNS-Aufloesung des ganzen Standorts in
einen Container -- heute liefert der DHCP in allen sieben VLANs den Core.
Das gehoert nicht ans Ende einer langen Sitzung (Lehre aus TP28).
Handoff enthaelt: Ausgangslage (Caddy produktiv, 16 Sites/17 Zertifikate),
den Auftrag in fuenf Schritten inkl. der IP-Kollision .30 (Nautobot) und
der Vorgabe, AGH als Paar 110/111 zu bauen statt als DNS-SPOF, sowie die
Staffelung VLAN fuer VLAN mit VLAN30 zuletzt.
Vier Fallen mitgegeben, alle in dieser Session bezahlt: Statuscode vom
oeffentlichen FQDN beweist nichts (grafana), pvesm free scheitert an
geschuetzten Snapshots stillschweigend, Startreihenfolge haengt nicht an
der VMID, und Core-Config braucht Golden Config.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Caddy in LXC 130 ist produktiv: 17 von 17 Zertifikaten per DNS-01 von
Let's Encrypt, Dienst active+enabled, Proxy gegen Host-Header verifiziert
(nautobot 302, gitea 200, pve 200, portainer 200). deploy.sh laeuft
End-to-End; Token per Fingerprint gegengeprueft -- eigenes Zone:DNS:Edit,
nicht das account-weite.
🔴 Fund beim Durchtesten: grafana war seit Langem tot und Cloudflare
Access hat es maskiert. LXC 104 stopped, konfigurativ noch auf VLAN1
(10.40.41.109), waehrend die Ingress-Zeile auf 10.40.20.109 zeigte -- eine
Adresse die es fuer Grafana nie gab. Der FQDN lieferte trotzdem 302, weil
das der Access-Login war. Exakt die Falle aus TP16.3 Paragraph 8, diesmal
in freier Wildbahn: ein toter Dienst sieht hinter Access monatelang
gesund aus.
=> Caddy-Zeile raus (16 Sites), LXC 104 zerstoert, aus dem Backup-Job.
Die 14 PBS-Snapshots bleiben bewusst stehen -- einzige Kopie etwaiger
Dashboards.
hass liefert 400: bekannter trusted_proxies-Punkt aus TP16, gehoert vor
die CNAME-Umstellung.
Split-Horizon entschieden (User): in AdGuard zusammen mit TP23 Stufe 2.
Dokumentiert, was das bedeutet -- heute liefert der DHCP in allen sieben
VLANs den Core als DNS; AGH bekommt niemand. Der Schritt verschiebt die
Aufloesung des ganzen Hauses in einen Container, deshalb als Paar
110/111 bauen. Die geloeschten Altlasten hiessen nicht zufaellig
adguard-bf1/-bf2.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Nach der Relay-Reparatur lag weiter nichts an. tcpdump auf der VLAN40-Leitung:
jedes SSDP-Paket des MacBooks kam von Chrome (ST dial-multiscreen,
USER-AGENT Chromium), kein einziges von Sonos. Ursache war das
macOS-Local-Network-Gate - es stand auf "an" und griff nicht. Schalter
aus/ein + App-Neustart hat es gerichtet (User-bestaetigt).
Damit faellt auch die tragende Zahl des Vormittags-Handoffs: die "291 Suchen
der App in 12 Minuten" waren Chrome plus eigene Proben.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die macOS-Sonos-App fand ihre Player nicht. Ursache war nicht die Firewall
(MEDIA->MAIN ist offen) und nicht der vermutete Race um den globalen
"last SSDP search source"-Slot, sondern die Flagge --ssdpUnicastAddr selbst:
multicast-relay.py Z. 630 schreibt die Quelle JEDES SSDP-Pakets an
239.255.255.250:1900 auf <addr>:1901 um (auch NOTIFY), Z. 691 verwirft
das Paket dann beim Senden auf eth1, weil 10.40.10.21 nicht im VLAN40-Netz
liegt. Der Hinweg lief damit nie.
Messung vorher: 0 Pakete via eth1 gegen 308 via eth0 in 20 min, 0x
"Received SSDP Unicast" im gesamten Journal seit 2026-08-18. Nachher:
M-SEARCH quellerhaltend in VLAN40, HTTP/1.1 200 OK von 10.40.40.193/.195
an beiden MacBook-Beinen, Drop-Log in:vlan40 out:vlan10 = 0.
- mcast-relay/multicast-relay.service: reparierte Unit jetzt im Repo
(ausgerollt auf LXC 108, Backup /root/multicast-relay.service.bak-20260825)
- CLAUDE.md: Gotcha korrigiert, Richtungsbilanz als Erstmessung, Hinweis auf
die SO_REUSEPORT-Falle auf Port 1900 und das dual-homed MacBook (.183/.82)
- docs/teilprojekte.md: Ist-Stand nachgezogen, TP33 (Fernzugriff) als Stub
- docs/teilprojekte-archiv.md: TP7.1-Aussage "--ssdpUnicastAddr ist noetig"
widerrufen
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die sieben verbliebenen Snapshots waren in PBS als protected markiert.
Auf User-Freigabe entschuetzt (pvesh set .../content/<volid> --protected 0)
und geloescht. Gegenprobe: 0 Snapshots zu allen sechs geloeschten IDs,
72 von 72 weg. VMID 130 gehoert damit ausschliesslich caddy-bf1.
Merkregel mit aufgenommen: pvesm free scheitert an geschuetzten
Snapshots mit 'cannot remove protected snapshot' -- und zwar
stillschweigend, wenn man den Fehler nicht ausliest. Wer nur die
Erfolgszaehler liest, haelt ein halb erledigtes Aufraeumen fuer fertig.
Genau so waeren hier sieben Snapshots stehen geblieben.
TP31-Abschnitt auf den Ist-Stand gezogen: Schritte 1 und 2 erledigt,
Schritt 3 wartet nur noch auf das Zone:DNS:Edit-Token.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Aufgeraeumt (User-Freigabe): LXC 120/121/128/129/130/131 zerstoert --
alle stopped, onboot=0, alle konfigurativ noch auf totem VLAN1
(10.40.41.116/.117, GW .41.254). pct destroy --purge hat 120 und 128
zugleich aus dem Backup-Job entfernt. 65 von 72 PBS-Snapshots geloescht;
sieben sind PROTECTED und stehen noch -- bewusst nicht ueberschrieben.
Neu nach TP32-Systematik:
- LXC 130 caddy-bf1, VLAN20 tag=20, 10.40.20.40/24, GW/DNS .20.1,
onboot=1, startup order=10 (Core), Debian 13, 4 GB / 512 MB
- Caddy v2.11.4 mit dns.providers.cloudflare (Custom-Build)
- caddy/Caddyfile im Repo, 17 Sites: 4 oeffentlich (vw/hass/n8n/gitea),
13 intern inkl. der vier MCP-Endpunkte und drei HTTPS-Backends
- caddy/deploy.sh liest CF_DNS_API_TOKEN aus ~/.secrets und schreibt es
in die Container-Env -- nie auf stdout, nie in einer Kommandozeile
- 130 in denselben Backup-Job aufgenommen
Caddy laeuft noch NICHT: das eng geschnittene Zone:DNS:Edit-Token fehlt.
Ein Token anzulegen und im Klartext zu handhaben ist nichts, was ich
selbst tue -- der Weg ist ~/.secrets plus deploy.sh.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
TP31 -- Caddy als Reverse Proxy fuer innen UND aussen, cloudflared von
sechs Containern auf einen. Anlass war Christophs Einwand, er habe den
Core unter der Praemisse gekauft, dass auch die Public-Apps darueber
laufen. Aktenlage geprueft: eine Zusage gibt es nicht, aber TP16.1
begruendet die Auswahl mit seinem Prinzip 'Router = einziger SPOF' --
und niemand hat je geprueft, ob der oeffentliche Strang ohne sechs
Container auskommt. Keine Taeuschung, eine ungepruefte Annahme.
- dst-nat-Variante geprueft und verworfen (ginge, Free-Tarif reicht),
weil Christophs Tunnel-Variante drei Risiken spart: keine angreifbare
Origin-IP, keine CF-IP-Allowlist, kein DDNS als Voraussetzung
- cloudflared auf ap1/ap2: live gemessen arm64, 95 MB Flash frei,
690 MB RAM frei. Der Core kann es nie (arm 32-bit, 2,9 MB frei)
- Kriterium fuer Infrastruktur-Container: was sich selten aendert und
wenig schreibt. Caddy nein (Config aendert staendig), AGH nein
(Query-Log frisst NAND)
TP32 -- VMID-Systematik (Hunderter = Klasse, gemeinsamer Raum fuer VMs
und LXCs) + letztes Oktett je /24, uebertragbar auf andere Standorte.
🔴 Dabei gefunden und SOFORT REPARIERT: die Startreihenfolge war falsch.
Proxmox startet erst Gaeste mit explizitem startup order=, dann den Rest
nach VMID -- drei Gaeste hatten einen, die DBs nicht. Home Assistant
startete damit vor MariaDB, MQTT und z2m25. Jetzt fuenf Stufen
(Core/Daten/Platform/Broker/Apps). Erkenntnis: VMID = Klassifikation,
startup order = Abhaengigkeit -- die Umnummerierung muss den Startlauf
gar nicht reparieren.
Doku-Korrekturen aus den Messungen:
- CLAUDE.md: 'Container NICHT auf dem Router' war nie nachgemessen
- tp16.1: 'Connector als Container ❌' galt dem TUN-Bedarf des
WARP-Connectors; cloudflared braucht kein TUN
- cf-tunnel-mapping Paragraph 16: die macvlan-Blindheit war mit einem
Shim behebbar -- der Workaround war groesser als der Fix
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Runbook ausgefuehrt. Vorbedingungen alle erfuellt, Testclient hing im
Hotspot-Netz 172.20.10.13 mit aktivem WARP -- also nicht im BF-LAN, der
einzige Aufbau der fuer Vorbedingung 2 etwas beweist.
Schnitt: nautobot.emsenhuber.net aus bf-nas (8 -> 7 Regeln), Catch-all
bleibt letzte. Rollback-Sicherung in docs/cf-backup/. Gegenprobe durch
Zuruecklesen der Config, nicht am Statuscode.
Abnahme vollstaendig, inkl. des uebersehenen Punktes: Golden Config lief
durch (Backup -> Intended -> Compliance, 104/104, 0 Drifts). Die uebrigen
fuenf bf-nas-Hostnames unveraendert.
Befund, der die Abnahmetabelle des Runbooks korrigiert: der oeffentliche
FQDN taugt nicht als Test. Er liefert vor UND nach dem Schnitt 302, weil
der von Cloudflare Access kommt, nicht vom Origin -- Access greift vor
dem Tunnel (JWT: auth_status NONE bei is_warp true). Damit auch eine
ehrlichere Erwartung: nautobot war nie ohne Access-Login oeffentlich
erreichbar, der Schnitt entfernt die zweite Tuer, nicht die erste.
Paragraph 7 des Runbooks ist ueberholt -- die HA-Degradierung ist am
selben Tag repariert, der Fall steht auf dem verbliebenen Argument.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Steht bisher nur in TP30/TP25, also nur beim Oeffnen von
teilprojekte.md sichtbar. Gehoert neben die sshpass-p-Warnung im
Tooling-Abschnitt, weil es dieselbe Klasse ist (Credential geraet
ueber ein Nebenprodukt in ein Transkript) und CLAUDE.md jede Session
gelesen wird.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Kollektor am Manager (15-s-Takt, 29 Samples, 28 Clients). Von den drei
Kandidaten fallen zwei, und beide ohne Wartezeit:
- (b) DHCP-lease-time: tot. dhcp-v30 faehrt lease-time=1d, Renew bei
12h -- kann 5:05 nicht erzeugen. Eine Abfrage, keine Messung.
- (a) periodischer VAP-Re-Apply: tot. Auf genau dem VAP, der angeblich
alle 5:05 abwirft, standen drei Clients bei 16h51m Uptime, 25 von 28
ueber 6h. Dafuer braucht es die vier Zyklen nicht -- ein einziges
Sample mit 16h51m widerlegt einen 5-Minuten-Takt.
- (c) Geraet selbst: bleibt, ist aber nicht pruefbar.
Denn die zwei Fund-F-MACs sind schlicht weg: ARP status=failed, keine
Lease, nicht in der Registration-Table, HA kennt sie nicht. Merkregel
wie beim P750W -- erst pruefen ob das Geraet ueberhaupt da ist, bevor
ein periodisches Trennen als Funk-/Configfehler untersucht wird.
Nebenbefund: einziger Client mit Uptime-Ruecksetzer war der DTU
(54:F2:9F:12:51:F0) auf ap1, 43min Sitzung, bei -52 dBm. Nicht Fund F,
aber echt -- derselbe ESP-Ein-Radio-Mechanismus wie in der Transaktion
TP17.1-dtu-pin-ap2. Gehoert zur Neubewertung des Pins.
Rohdaten: docs/messdaten/tp25-fundf-20260824.log
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
