Oktett-Klasse .150-.199 (App-Services). Nautobot gibt damit .30/.31 an
AGH frei. .157 ist gitea, deshalb nimmt redis .158.
- Datenmigration ueber neues nautobot/tp45-ip-move.py: Nautobot verbietet
das Aendern einer IP nach dem Anlegen -> anlegen/primary_ip4 umhaengen/
Altobjekt loeschen, in dieser Reihenfolge
- Stack-Redeploy (PUT /api/stacks/203), Caddy-Backend, Core-Literal *24
ueber GC deployt (Plan 51a90e25) mit Wirksamkeitspruefung am Geraet
- caddy/deploy.sh: push_verified() ersetzt den push||push-Fallback.
`pct push` meldet Exit 0 AUCH wenn es die Quelle nicht lesen kann, der
Fallback griff deshalb nie und `caddy validate` pruefte die ALTE Datei
-> gruene Abnahme bei unveraendertem Zustand (Symptom: 502 bei
gesundem Backend)
- 39 Referenzen in 28 Dateien mitgezogen; lebende Doku nachgezogen
(CLAUDE.md, ip-plan.md, cf-tunnel-mapping §0-Kopf, TP16.3/TP31-Prosa)
- GC-Compliance 140/140, 0 Drifts
Neue Funde (TP45-Prosa + CLAUDE.md):
- Die Core-Adressliste `nautobot` wird von GC nirgends gerendert -> ein
Recovery von null erzeugt einen Core, in den Nautobot nicht mehr per
SSH kommt. Gleiche Klasse wie die fehlenden DHCP-Reservierungen.
- Regel *24 (Literal) und *28 (Liste) sind Dubletten; der Literal steht
bei 0 Paketen. Zusammenlegung bleibt offen.
- gc-manual-plan.py: /api/extras/job-log-entries/ liefert 404 (Nautobot
3.x) -> bei gescheitertem Deploy fehlt die Fehlermeldung.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Bestandsaufnahme 2026-09-21 ergab: die FQDNs sind nicht in Caddy/CF
verschwunden, sondern (a) AGH wertet DNS-Rewrites im Filter-Pfad aus und
ueberspringt sie fuer unfiltrierte Clients -> Fallback auf den Core, der
nur 10 von 26 Namen haelt; (b) ds-bf ist der einzige Ingress-Eintrag, der
Caddy umgeht, und faellt damit unter TP5 deny-by-default.
- TP32-Oktett-Tabelle: .10-.19/.20-.29-Split, Server-Block .100-.149,
Broker/Funk .9x, Platform .8x, Alt-IP-Reservierung dokumentiert
- TP32-Ordnungsgruppe 40 auf 102/112 reduziert (CCU gehoert zu haos)
- TP37-Status: P1+2 waren als "offen" notiert, live sind 28 VMs/26 Services
- TP45 (VLAN20/30 ins Schema + DNS/FQDN) + TP46 (CF-SSoT/Recovery) als
Prosa-Abschnitt, Zeiger in der Pflichtlektuere
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Letzter offener TP25-Posten: Terrasse ein eindeutig dominantes Signal
geben (Ende von Band-Thrash und -89-Kollaps-Roams). Plan gemess Variante 3
(Deckenstrahler an den guten Platz, hAP in den Drei-Raeume-Schatten),
Vorher/Nachher-Terrassenmessung + Anruf-Abnahme, Kanalplan unberuehrt,
Config nur ueber GC-Weg. Issue #17, Kommentar #232.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Wireshark-Analyse (hms-mqtt-publisher PR #110, HMS-800W-2T): Poll <30 s
resettet den Countdown, Cloud-Updates fallen aus; nach 4-5 min startet
die DTU eine neue TCP-Session -- und dabei (Log-Beweis 09-14) eine
vollstaendige WiFi-Disassoziation inkl. DHCP-Churn. Zyklus-Abstaende
decken sich aufs Minutenkomma. Fund F damit neu interpretiert.
- Ursache: hmsmqtt 30500 ms (Grenzzone). Hebel = Poll-Rate, nicht
DNS-Hoheit: Christoph hat 45000 ms gesetzt (09-14 abends).
- Verifikation ab 09-15 frueh (Log-Lauf ohne 4-5-min-Zyklen = Fund-F-
Abschlussbeweis); Fallback: DTU-Firmware klaeren (ha-hoymiles-wifi#134).
- Issue #17, Kommentar #228.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Recherche 09-14 abends: HMS-XXXXW-2T (W = eingebaute DTU, protobuf-
Protokoll) wird von AhoyDTU/OpenDTU nicht unterstuetzt (lumapu/ahoy#1189
seit 09-2023 offen; Christophs eigene AhoyDTU inkompatibel). Lokale Tools
(hmsmqtt, dtuGateway, ha-hoymiles-wifi) nehmen die DTU nicht von der Luft.
Einziger Airtime-Heibel bleibt DNS-Hoheit ueber die Cloud -- von Christoph
bewusst zurueckgestellt (Cloud-Aufzeichnungen bis hmsmqtt + WLAN stabil).
Korrektur auch als Issue-17-Kommentar #227; Messplan #225 bleibt gueltig.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- DTU geht mit der Sonne an/ab (09-14: 07:09-19:35) -- nachts unbetelligt,
20:37-Verlust passierte ohne sie. Tagsueber ~5:05-Zyklus auf ch11 bei -53.
- Messplan (Issue #17, Kommentar #225): Referenz-Client auf ch11 pinnen,
30-60 min Ping, Korrelation gegen die 5:05-Taktmarken.
- Hebel falls messbar: OpenDTU/AhoyDTU-Dongle statt Cloud-DTU (5-Min-Takt
ist S-Miles-Telemetrie per Design, kein Ethernet an der DTU-WLite,
Pin auf anderen AP kontraindiziert).
- 20:37-Nachtrag zur Abnahme: Totalverlust eigener Klasse (-89-Roam +
iOS-Aufgeben, identisch 19:01 mit ft=no) -- keine ft=yes-Regression.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Live-Beleg 2026-09-14 20:33-20:34, Terrasse: nur roamed-to-Events, keine
disconnected-Zeile mehr im Fenster (davor 20:29/20:31 noch zwei volle
Trennungen). Hebel (1) damit komplett abgenommen; offen bleibt nur noch
der Deckungsfix Variante 3.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- CLAUDE.md: 09-04-Entscheid (ft=no) mit Ruecknahme 09-14 konsistent gemacht —
Weg, Plan-ID, Compliance-Stand und CAP-Abnahme vermerkt, damit keine
Folgesession einen ft=no-Zustand liest, der nicht mehr existiert.
- teilprojekte.md TP25: Hebel (1) auf DURCH gesetzt (Sequenz, Plan b1135f3e,
Asserts, Polling-Timeout-Folgenlosigkeit), offene Abnahme = Terrassen-Anruf.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Handoff 2026-09-14: iPhone-Flapping auf der Terrasse = 5-GHz-Zellkante
(-76..-81) plus client-getriebene Band-Wechsel in der Uberlappungszone
-70..-77; vor ap2 (1-2 m) -49..-51 dBm, >2 min stabil => HW-Verdacht
(23:02-Befund 2 m/-80) in situ widerlegt, kein Tausch begruendet.
- Hebel "Access-List-Band-Boden < -76 auf 5G" nicht sauber ausdrueckbar:
kein band-Property, Interface-Scoping bricht am cap-wifiN-Rejoin,
SSID-/MAC-Scope trae fen 2,4 GHz mit (Lockout-Risiko). Nicht umgesetzt.
- TP30: Posten #9 vorgemerkt -- GITEA_ACCESS_TOKEN am 09-14 ueber einen
Fehlerpfad (URL-Konstruktion -> ValueError-Traceback) ins Transkript
geraten; sechster Vorfall der Leak-Familie, neue Unterklasse.
- Gitea: TP25-Issue #17 Kommentar 217, TP30-Issue #20 Kommentar 218.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
5/6 Schichten durch; Schicht-3-pro-Projekt-Rollout laut Abgrenzung eigene
Sessions; On-Network-mikromcp-Smoketest als Merkposten → TP30 #20.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
exports.zsh um die 3 von opencode bereits referenzierten, aber fehlenden
MCP_MIKROMCP_{ROUTER_AP3,CRS326_CORE,CRS326_BRANCH}_PASS ergänzt (25 Vars,
gui-env-sync 25/25 in launchd-Env). claude.json hält noch 7 Klartext-Secrets;
DRY-RUN bestätigt alle Ziel-Vars MATCH. Flip läuft bei BEENDETER App über
~/dev/.bin/schicht2-claude-json-migrate.py --apply-claude (nicht aus laufender
Session — Claude Code schreibt State in die Datei). Announcement-Eintrag ergänzt.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Schicht 4 (Announcement): docs/announcements.md angelegt (Format
## YYYY-MM-DD — Titel + Betrifft/Aktion, neueste oben) + globaler Skill /news
(liegt in ~/.claude/skills/news/ UND ~/.config/opencode/skills/news/, cp kein
Symlink). /news zeigt Einträge seit dem letzten Lauf (Seen-State ~/.news-seen/).
Erste Einträge: SSoT-Cutover + TP36-Live.
Schicht 5 (Backup-Guard): abgenommen — Guard + pre-commit-Hook live verdrahtet,
hat beim TP36-Live-Commit real gegriffen. Grenze dokumentiert (check prüft nur
Existenz der Guard-Datei, nicht deren Alter).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Christoph on-site: Upstream 10.40.20.36 + .37, DNS-Rebind-Schutz-Ausnahme
bf.emsenhuber.net, Fallback-Haken "öffentliche NS bei Unreachbarkeit der
primären" gesetzt (existiert auf diesem FRITZ!OS-Stand) → Ideal-Variante,
.37-Redundanz bleibt, BF-down fällt auf public. Gitea #32 closed (status:done).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
dw-FritzBox kann per DHCP nur eine DNS-IP ausliefern → "mehrere NS an die
Clients" scheidet aus. Neue Richtung: Clients → 10.95.10.1 (FB), die FB
forwardet an Upstream 10.40.20.36 + .37 (beide BF, Voll-Resolver).
- Zwingend: DNS-Rebind-Schutz-Ausnahme bf.emsenhuber.net (sonst filtert die FB
die Privat-IP-Antworten 10.40.x als Rebind weg).
- BF-down-Fallback: FRITZ!OS-"öffentliche NS bei Unreachbarkeit"-Setting, sonst
public im Alternativ-Slot (kostet .37, dann strikt-primär verifizieren).
- Sauberer als DHCP-Multi: FB ist einziger Client-Resolver, .36 löst
intern+public → public nie "zuerst" gefragt, kein NXDOMAIN-Leak.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Auslöser: portainer.bf.emsenhuber.net vom dw-Standort (WG-Tunnel up) nicht
auflösbar — dw-FritzBox kennt die interne Zone bf.emsenhuber.net nicht.
- Gitea #32 reopened (status:todo, thema:firewall-dns), Prosa aus dem Archiv
zurück nach teilprojekte.md (Archiv = ♻️-Zeiger).
- fm-Einwand live entkräftet (dig @.36): bf-Namen → 10.40.0.0/16 (über WG
erreichbar), fm-Namen → Cloudflare-Anycast, nie 10.101.x.
- Entscheidung: FritzBox verteilt per DHCP die DNS-Liste .36/.37/9.9.9.9;
.37-Redundanz bleibt, FB entlastet. NXDOMAIN-Failover-Haken + zwei
On-site-Verifikationen dokumentiert. Umsetzung = eigene On-site-Session.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- TP41 abgeschlossen: Gelis WARP via Android eingerichtet (letzter Blocker weg)
- TP43 verworfen: 420 = public CF-Worker, kein BF-Split-Horizon nötig; keine Altlasten
- TP42-Prosa nachgezogen (war closed in Gitea, Prosa stand noch in teilprojekte.md)
- Status-SSoT-Änderungen in Gitea gesetzt (#30 done, #32 dropped, #31 title-Fix)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Volltext TP44 (✅ DURCH) nach teilprojekte-archiv.md (Anker #tp44 + TOC-Zeile),
aus teilprojekte.md entfernt, Control-Plane-Themenzeile + gebrochenen intra-file
Link auf teilprojekte-archiv.md#tp44 gefixt. Gitea #33 war bereits closed/status:done.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
10.40.0.0/16 (container, Route bf-core-mesh) + 10.101.0.0/24 (network,
Route fm) in Nautobot IPAM angelegt; Seeder-Re-Run hat die zwei
cloud-network-prefix-assignments eingehängt (count=2, idempotent).
Gitea #33 kommentiert, bleibt WIP (Teil B CF-Sync offen).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- teilprojekte.md: Quick-Index-Tabelle + "Ist-Stand (Kurz)"-Block entfernt (-493 Z.),
Kopf zeigt aufs Gitea-Board (Labels status:*/thema:*); Governance/Genehmigte Ausnahmen
unter eigenem Header behalten; TP36 reframed (Nautobot->Gitea, Scope = Index/Status,
Nautobot nur noch Live-Geraetedaten). Alle 33 ### TPnn-Prosa-Abschnitte intakt.
- gitea-tp-sync.py: an das neue SSoT-Modell angepasst - aktive TPs sind SSoT direkt in
Gitea, das Tool gleicht nur noch das Archiv ab und fasst offene Issues nie an. Dry-Run 0/0.
- CLAUDE.md: Pflichtlektuere #1 = Gitea-Board (Status) + Prosa-Datei (Detail); neue Sektion
"SSoT & Branch-Konvention"; TP-Management-Sektion nachgezogen.
/projektstatus-Skill (beide globalen Kopien ~/.claude + ~/.config/opencode) auf die
Gitea-API umgestellt (Modus A Board / Modus B Markdown-Fallback) - liegt ausserhalb des Repos.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- docs/tp23-stufe6-bypass-sperre-runbook.md: separate Vor-Ort-Session; AGH-SPOF-Warnung
(nicht aus der Ferne / nicht waehrend Abwesenheit), log-only-Vorstufe -> Drop mit Auto-Revert,
Exempt/JIT-Bau, DoH-443-Grenze, Rollback + Abnahme
- teilprojekte.md: TP23-Zeiger auf den Runbook + Vor-Ort-Gate
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
ap3 trug auf wifi1/wifi2 einen Werks-Inline security.ft=yes (Bring-up-Skript
tp28-ap3-phase2-cap.rsc unset !ft-over-ds, aber nicht !ft; Abnahme zaehlt nur
benannte security-Objekte -> Inline-Wert unsichtbar). Gemischtes FT-ESS =
Strong-Signal-Abbrueche (-43/-45 dBm) NUR auf ap3 bei 3/3 Strichen. Live per
!security.ft geradegezogen (uniform ft=no), Bring-up-Quelle korrigiert.
Kanalplan committed: Template auf DFS-Frequenzlisten (ch-5g-ap1=5260,5280,
ch-5g-ap2=5300,5320) + ap1-Provisioning-Zeilen (radio-mac ...E5/...E6) wieder
aufgenommen. Push nach bf-golden-config + GitRepo-Sync + refresh-compliance ->
140/140, 0 Drifts; Transaktion TP25-kanalplan-ap1-live committed.
Doku: Ist-Stand, Fund-E-Block, CLAUDE.md Punkt 5 (Merkregel: nach jeder
sec-main-FT-Aenderung jeden CAP einzeln auf security.ft pruefen).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Hebel 2 (ft=no) doch gezogen: sec-main von ft=yes ft-over-ds=yes auf
ft=no ft-over-ds=no. Template (nautobot/mikrotik_routeros.j2) + Push nach
bf-golden-config + Nautobot-Sync; wifi-security damit gruen (Live stand
schon auf ft=no, das Template war der Drift).
Doku nachgezogen (CLAUDE.md Punkt 5, teilprojekte.md Ist-Stand/Quick-Index/
Fund-E-Block): Soll ft=yes ft-over-ds=yes -> ft=no ft-over-ds=no, 802.11r aus.
Co-Authored-By: Claude Code <noreply@anthropic.com>
Die Konsole (docs/tp6-marker/server.py) war beim Multi-Pin-Umbau nicht
mitgezogen worden: hartkodiert auf 2 Clients, pinnte ueber die alte
Gegen-AP-Automatik. Jetzt:
- Client-Liste aus geraete.txt (schreibt tp25-walk-messung.sh), Fallback
auf die zwei alten MACs fuer Alt-Laeufe.
- Kein eigenes SSH mehr: je Client letzte Zeile von sampler-<name>.csv
(AP/Signal) + Ping-Verlust aus walk-ping-<name>.csv.
- N Client-Karten; Alarm, wenn ein gepinnter Client nirgends haengt.
- Pin-UI: je Client AP/Band waehlen, set/off/verify via tp25-pin-multi.sh
(POST /pinmulti). Alte 2-Client-Automatik (entscheide/pin_setzen/auto)
entfernt; tp25-pin-s22.sh liefert nur noch die map.
- tp25-runde.sh loest beim Aufraeumen den Multi-Pin statt des S22-Pins.
Doku: Ist-Stand-Block + Quick-Index + Messwerkzeug-Bullets nachgezogen,
neuer Handoff 2026-09-04.
Co-Authored-By: Claude Code <noreply@anthropic.com>
(A) DHCP-Search-Domain der 7 Netze emsenhuber.net -> bf.emsenhuber.net ueber
die GC-Pipeline (kein Direkt-Write): Template Z.133 gehoben, per
push-gc-template.py ins bf-golden-config-Repo (7a4068c4), GitRepo-Sync,
neuer manueller Job tp42-dhcp-domain in gc-configplan.py (set [find], weil
add das existierende Netz doppeln wuerde), Deploy an crs326-core.
Live 7/7 = bf.emsenhuber.net, Compliance 140/140 keine Drifts.
Nebenbefund: Remote-GC-Template hing dem lokalen hinterher (noch *.bf.lan +
router.lan) -> mit an den Live-Stand angeglichen.
Loest den Kernkonflikt: DHCP verteilte bare emsenhuber.net, Records leben
unter bf.emsenhuber.net -> bare macmini loest jetzt beim Lease-Renew.
(B) .16 (adguard_bf1) abgebaut: lag im mit FM geteilten Portainer-Stack 195
zusammen mit adguard_fm2 (.17, Standort FM). Statt Stack-Delete die compose
auf nur .17 getrimmt + redeployt (Prune). .16 weg, .17 laeuft (kurzer Blip).
Nautobot-Soll (Scope 4) an TP37 gekoppelt, separat.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Gegen die Geraete gemessen: .bf.lan ist ueberall weg, DHCP-domain auf
emsenhuber.net vereinheitlicht, Core-Static + Caddyfile konsistent auf
.bf.emsenhuber.net (deckt sich mit GC-Template). Drift hat ~80% erledigt.
Kernkonflikt: DHCP verteilt bare emsenhuber.net, Records leben unter
bf.emsenhuber.net -> bare macmini loest nicht. Entscheidung (User):
Zielschema = bf.emsenhuber.net (wenig-Arbeit-Weg); .16 (adguard_bf1)
abbauen, .17 (=FM) bleibt.
Netto-Rest = 2 Infra-Eingriffe: DHCP-domain ->bf.emsenhuber.net ueber die
GC-Pipeline (Template Z.133 + push-gc-template.py + Deploy) und .16-Teardown.
Kein Core-Objekt haengt an .16 (Firewall/NAT/DNS/Addr-List live geprueft).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Kern von TP31 (Caddy als Host->Origin-SoT, cloudflared 6->1 Knoten) lief
über den Piloten TP16.3 durch: bf-public 12 conns, vier öffentliche Namen
über Caddy (https://10.40.20.40:443), Alttunnel bf-nas/bf-pve/bf-mm weg.
cf-sync.py:107 akzeptierte nur http://<caddy>; der Flip legte die Namen auf
https://...:443 -> Abnahme-Tool meldete vier Fehlalarme. Fix: auch https://
als "zeigt auf Caddy". Drift-Check jetzt grün (nur ds-bf als bewusst intern).
Schritt-6-Teil "MCP-Clients auf FQDN" durch TP35 Schicht 1 umgekehrt (LAN-IP),
damit gegenstandslos. Quick-Index/TP-Abschnitt/Ist-Stand-Block nachgezogen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Kein eigenständiger claude-mcp-Token mehr: in TP41 T4 (2026-09-01) zu
zt-svc umbenannt+rotiert, mcp/cloudflare/.env trägt jetzt
CF_ACCESS_CLIENT_ID/_SECRET. Quick-Index (🔜→✅), TP-Abschnitt und
Ist-Stand-Block nachgezogen; alte ".env leer"-Notiz als überholt erhalten.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Zwei Sessions haben denselben Fall bewertet und kamen zu entgegengesetzten
Schluessen. Aufgeloest zugunsten der Kollektor-Messung.
Der Widerspruch und sein Beleg:
- Die Nacht-Session las `get_log ... sinceMinutes=1440` -> total 0 und schloss
auf "Fund E geheilt, Hebel 1 committen". Das ist der FLUECHTIGE Ringpuffer des
Routers: live nachgemessen 1000 Zeilen, aeltester Eintrag 01.09. 00:38:58 --
keine 9 h Tiefe. Der Core-Reboot 14:36 hatte ihn geleert, der 31.08. Vormittag
war darin nicht enthalten. "total 0" hiess "im Puffer nichts", nicht "in 24 h
nichts" -- genau die Falle, wegen der am 30.08. der Kollektor gebaut wurde.
- Im Kollektor stehen fuer 08:09-14:36 (Hebel 1 ALLEIN, vor dem Upgrade) 124x
reauthenticating: 09h=1, 11h=2, 12h=20, 13h=31, 14h=70 -- alle vom iPhone
allein, also Client-Befund nach der eigenen Merkregel. Dazu Christophs zwei
erlebte Ausfaelle 13:16 und 14:23. Zwischen 09:00 und 14:36 lag kein Reboot.
Daraus gehandelt (User-Entscheid: symmetrisch am Geraet, jetzt):
- Backup pre-tp25-funde-rollback, dann ft-over-ds=yes + remote-cap provision
- Rueckbau-Diff zeigte genau eine Abweichung, kein Kollateral
- Abnahme: CAPs durchgehend Ok, ap2 9/9 und ap3 9/9 running, frische DHCP-Lease
(~1 min alt), Transaktion "zurueckgebaut", Compliance 140/140
- Der Rueckbau IST das Experiment: bleibt es ruhig, war 7.24.1 die Ursache;
kehrt das Haemmern zurueck, hatte die Nacht-Session recht. Bis zur Messung
am 2026-09-02 frueh committet niemand.
Zwei Nebenbefunde:
- gc-configplan.py --refresh-compliance scheitert STILL ohne NAUTOBOT_TOKEN:
Meldung ausgegeben, aber Exit-Code 0. Gehoert gefixt.
- Compliance ist 140/140, nicht 135/135: es gibt eine 28. ComplianceRule
`interface-veth`, angelegt 31.08. 20:04, Urheber offen.
Der ap2-Befund der Nacht-Session (2 m Abstand, -80 dBm, 0 Clients auf ap2)
bleibt unberuehrt gueltig und ist weiter der beste Hinweis auf die
23:02-Stoerung. CLAUDE.md enthaelt in diesem Commit auch deren TP16.3-Zeile
(gemeinsame Datei, Hunks nicht trennbar).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Diese Aenderungen stammen NICHT aus dieser Session. Sie lagen seit 01:41 uncommittet
im gemeinsamen Working Tree, in dem parallel mehrere Sessions schreiben -- jedes
read-modify-write haette sie stillschweigend ueberschreiben koennen. Daher hier
unveraendert gesichert, bevor irgendetwas anderes passiert.
Inhalt:
- TP39 (LXC-Hygiene pve) abgeschlossen und nach teilprojekte-archiv.md verschoben
- TP41-Cloudflare-Backup unter docs/cf-backup/tp41-20260901/
- handoff-20260901-tp25-ap2-verdacht.md: Befund, dass ap2 unterperformt
(iPhone 2 m entfernt, aber -80 dBm; 0 Clients auf ap2 gegen 29 auf ap3).
Dieser Teil ist wertvoll und unabhaengig -- er erklaert Christophs
23:02-Stoerung vom 31.08.
WARNUNG zum TP25-Teil: der hier eingesammelte Stand wertet Fund E als "Hebel 1
wirkt DOCH, commit-bereit". Diese Wertung ist ueberholt -- sie beruht auf einer
Messung im fluechtigen Router-Ringpuffer. Korrektur folgt im naechsten Commit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die 7-Tage-Frist wurde auf User-Entscheid aufgehoben ("es wird nichts mehr
sein"). Reihenfolge Container -> Tunnel eingehalten (umgekehrt gaebe es 530er).
Vorbedingung geprueft: alle vier Namen auf bf-public, kein Name mehr an den
Alttunneln -> Abbau gefahrlos.
7 Container entfernt, per exakter Namensliste (nicht per Filter):
LXC 400 (pve): cloudflared-bfmm, cloudflared-bfnas
macmini: cloudflared-bfpve, cloudflared-bfnas
NAS ep14: cloudflared-bfpve, cloudflared-bfmm
plus terpene-cloudflared -- auf zusaetzlichen User-Entscheid, weil
420.teilzeitladen.xyz jetzt ueber Caddy/CF laeuft. Kein Stack dahinter, also
kein Wiederauferstehen.
Beweis VOR der Tunnel-Loeschung: 420.teilzeitladen.xyz lieferte mit bereits
entferntem terpene-cloudflared echten Origin-Inhalt (assetlinks-JSON, 200) --
der Dienst haengt also nicht mehr am Tunnel.
4 Tunnel geloescht: bf-mm, bf-nas, bf-pve, terpene-db -- jede ID gegen die
Behalten-Liste (bf-public, fm) geprueft.
Schlusskontrolle: nur noch bf-public (12) + fm (4) healthy; alle vier BF-Namen
und 420 weiterhin 200.
Der terpene-db-Tunnel-Token stand kurz im docker-inspect-Output; mit der
Tunnel-Loeschung ungueltig, kein Rotationsbedarf.
TP16.3 damit vollstaendig abgeschlossen (Status ✅ 2026-09-01). Quick-Index,
Abschnittsheader, §6-Record, Ist-Stand, Runbook §6 und Handoff nachgezogen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
SKIP-NAME-RESOLVE (letzter offener TP39-Punkt, jetzt zu)
mysql.user gelesen (User gab DB-Zugang per /root/.my.cnf): KEIN Grant lautet auf
einen DNS-Hostnamen -- alle % / IP-Literal / localhost. skip-name-resolve kann
also niemanden aussperren; der Reverse-Lookup war reiner Ballast. Gesetzt als
eigenes Drop-in /etc/mysql/mariadb.conf.d/90-skip-name-resolve.cnf (nicht die
#-Zeile in 50-server.cnf, Paket-Update-stabil), @@skip_name_resolve=1 nach
Neustart verifiziert. Wirkung: gitea/vw/hass je 0 von 12 frischen Anfragen
langsam, max 0,25 s -- die Ursache ist damit beseitigt, nicht nur entschaerft.
RESIZE (im selben Fenster aufgetaucht)
LXC 302 war zu 100% voll (62/65 GB). Rootfs +30G online gewachsen -> 95 GB / 69%,
MariaDB lief durch. Puffer, kein Fix: 59 GB davon sind die homeassistant-DB.
TP40 ANGELEGT (User-Okay): HA-Recorder-Retention
states.ibd = 41 GB, unbegrenzt gewachsen (kein purge_keep_days wirksam). Scope:
purge_keep_days setzen (Christophs Policy-Zahl), rauschende Entities excluden,
purge mit repack -- danach TP39-Resize neu bewerten. Kein eigenmaechtiges
Loeschen: purge wirft echte Historie weg.
TP30 um zwei Posten erweitert
#5 Nautobot-Tokens (Leak 08-31, in der Liste bisher nur im Fliesstext).
#6 MariaDB root-Passwort: heute ins Transkript geraten -- die .my.cnf trug
"password <wert>" OHNE =, die Feld-Maskierung ankerte auf = und griff nicht.
Dritte Panne derselben Klasse nach SHELLY_DEVICE_PW und den Nautobot-Tokens;
Merkregel (Schluesselnamen ankern, nie ein evtl. fehlendes Trennzeichen) im
TP30-Text nachgeschaerft. #6 ist zugleich der billigste Posten -- kein externer
Konsument, die Dienste nutzen eigene DB-User.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
Fasst die zwei Restpunkte aus dem Wartungsfenster der Nacht zusammen, statt sie
auf zwei TPs zu verteilen -- beides betrifft dieselben pve-LXCs und wird in einem
Fenster erledigt:
1. skip-name-resolve auf der MariaDB. Der Reverse-Lookup ist heute nur schnell
(21-24 ms statt 10.010 ms), nicht abgeschafft. Vorher mysql.user lesen:
Hostname-basierte Grants brechen sonst und sperren vw/HA/gitea aus.
Blocker: DB-Credentials noch nicht lokalisiert (Bezug TP30).
2. networking.service + ifupdown-wait-online.service sind in 101/102/106/107
dauerhaft failed, bei vorhandenem Netz. Folge: alles mit
After=network-online.target startet nach einem Reboot nicht -- belegt an
influxdb2, das nach dem Neustart nicht hochkam (Unit enabled, kein
Startversuch im Journal). 101 wurde nie angefasst und zeigt dasselbe, es ist
also vorbestehend.
Dazu der Resolver-Sweep als wiederkehrende Kontrolle statt Einmalaktion: derselbe
Fehlertyp wurde 2026-07-10 (TP14.2a) an NAS und LXC 400 behoben, aber nie im
Bestand gesucht -- deshalb lag er hier noch. Die NAS-Container gehoeren mit
geprueft (DSM-Fallstrick: Interface-DNS != was dockerd liest).
Quick-Index, TP-Abschnitt und Ist-Stand-Block mitgezogen; Handoff verlinkt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
FLIP (User-Freigabe, vorgezogen)
n8n / gitea / hass / vw laufen jetzt ueber bf-public, der oeffentliche Verkehr
geht damit erstmals ueber Caddy statt an ihm vorbei. Je Name einzeln geflippt und
dazwischen gemessen; Antwortzeiten vorher/nachher unveraendert. Nachweise:
gitea echte Gitea-Antwort, hass WebSocket 101 Switching Protocols (der
Companion-App-Pfad, den das Runbook als "nur vom User pruefbar" fuehrte),
vw /alive + /api/config 200 und WS-Hub 401 von Vaultwarden selbst, n8n vom User
im Browser bestaetigt (von aussen nicht bis zum Origin pruefbar, s. TP14.4).
Die drei Alttunnel bleiben als Rueckfallebene stehen -- §6 ist NICHT Teil davon.
10-SEKUNDEN-ZOLL AUF gitea/vw/hass -- Ursache gefunden und behoben
gitea hing bei ~10% der Anfragen exakt 10,1 s, quer ueber Web-UI, /api/healthz
und den Git-Pfad. MariaDB (LXC 302) hatte skip-name-resolve auskommentiert und
machte bei JEDER NEUEN Verbindung einen Reverse-Lookup, waehrend ihr resolv.conf
auf den toten 10.40.41.254 zeigte: 10.010 ms je Lookup, Pool-Verbindungen
schnell -- daher wirkte es sporadisch. An derselben DB haengen Vaultwarden, Home
Assistant und gitea (per Verbindungstabelle belegt, nicht vermutet; die erste
Annahme "vaultwarden nutzt SQLite" war falsch und wurde vom User korrigiert).
Fix: nameserver 10.40.20.1 + Reboot fuer fuenf LXCs (302, 102, 106, 107, 150).
Nachher 21-24 ms und 0 von 25 Proben langsam.
Offen: skip-name-resolve selbst -- bricht Hostname-basierte Grants, vorher
mysql.user lesen (DB-Zugang fehlt).
LATENT, NICHT VON DIESER SESSION VERURSACHT
networking.service + ifupdown-wait-online.service sind in 101/102/106/107
failed; influxdb2 kam nach dem Reboot nicht hoch (Unit enabled, kein
Startversuch im Journal). 101 wurde nie angefasst und zeigt dasselbe -- die
Container liefen nur 13+ Tage ohne Neustart.
RUNBOOK-KORREKTUREN
§5.3 "Caddy sieht den Request" konnte nie funktionieren: im Caddyfile steht keine
log-Direktive, ein erfolgreicher Request hinterlaesst nichts. Ersetzt durch die
Werkzeuge, die tatsaechlich etwas beweisen -- erzwungener oeffentlicher Weg per
curl --resolve (Pflicht wegen Split-Horizon), Verbindungstabelle am Core statt
Firewall-Zaehler (cloudflared haelt die Origin-Verbindung offen, der Zaehler
steht still obwohl alles laeuft), Antwort-Fingerabdruck, WebSocket mit --http1.1.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
