Verhaltensabnahme durch echten Login (nicht nur API-Read): Christophs zweiter
GitHub-Account wird abgewiesen, eigener Zugang und Geli funktionieren, uebrige
Auth-Wege wie erwartet. email AND github trennt eigenes von fremdem Konto,
ohne jemanden auszusperren.
Der Fix war bis dahin nur gesetzt und zurueckgelesen — die API sagt nichts
darueber, ob die Regel greift. Mit diesem Test ist sie verhaltensbestaetigt.
TP49 geschlossen, Gitea #76 closed / status:done, kein offener Punkt.
Der Umweg (Fehlschluss -> Schliessung -> Wiedereroeffnung -> Fix -> Abnahme)
bleibt als Aktenhistorie in allen drei Dateien stehen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Christophs zweiter GitHub-Account kam durch — der Ursprungsfund war echt. Die
vormittägliche Schliessung als "Phantom" war ein Fehlschluss (Google-Test
ungeprueft auf GitHub uebertragen) und ist hiermit zurueckgenommen.
Fix: login_method:github aus include raus, in require -> email AND github.
Gesetzt via PUT /accounts/{id}/access/policies/{policy_id} (der App-Pfad gibt
12130 fuer reusable Policies), zurueckgelesen ueber beide Endpunkte.
Sweep ueber alle Apps: login_method nur noch in Terpenfinder v3 — christoph
(github+onetimepin) und geli (nur onetimepin, harmlos). Scope geprueft: die
reusable Policy haengt nur an dieser einen App, kein Kollateral.
Drei neue Gotchas: 12130 (reusable nur unter /access/policies/{id}, der alte
Merkatz meinte das Detach, nicht das Aendern), MCP read-only (1010), 32-Hex-IDs.
Grenze dokumentiert: die Absicht war Kopplung an den GitHub-Username — den
Selector gibt es nicht. Identity-provider-group braucht SCIM (hier disabled,
scim/groups -> 500/12158). email AND github ist das vollstaendige Moegliche.
Aktenhistorie des Umwegs bleibt in allen drei Dateien stehen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Christoph hat die Praemisse am 2026-10-06 selbst widerlegt: testus@emsenhuber.com
wird von CF Access abgelehnt. Die E-Mail-Bindung der Policy gilt, login_method
hebelt sie nicht aus. Es gab nie eine offene Tuer.
Der Fehler war ein Fehlschluss, kein Raten: Doku-Semantik zu login_method
("welche Methode wurde benutzt") wurde so gelesen, als ersetze der Include die
danebenstehende email-Zeile. include ist ein OR — die Zeilen sind Alternativen,
nicht Bedingungen. Aus "GitHub ist eine Alternative zur E-Mail" wurde "GitHub
allein genuegt", und das stand als Tatsache in der Akte (Fund 2026-07-10).
Belegt: kein IdP traegt eine Domain-Bindung (github/google/onetimepin alle nur
client_id + redirect_url, live per GET .../identity_providers). Die Einschraenkung
kann also nur aus der Policy kommen — und sie greift nachweislich.
Grenze der Aussage: der GitHub-Pfad selbst wurde nicht gemessen, nur geschlossen.
Korrigiert: teilprojekte.md TP49 (Herkunft des Fehlers mitgenannt), cf-tunnel-
mapping.md Paragraf 10 (Ursprungsfund widerlegt, nicht geloescht), Startauftrag
als "NICHT AUSFUEHREN" markiert. Kein Schreibzugriff auf die Terpenfinder-Policy;
blauebluethen-Projektgrenze gewahrt.
Erhalten bleiben nur die Gotchas: 32-Hex-App-IDs, cloudflare-MCP ist read-only
(Write-Probe no-op-PUT -> 1010), Reusable Policy nur per App-PUT detachbar.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Christoph-Direktive: zu Sessionbeginn pruefen ob der Cloudflare-MCP laeuft, sonst anhalten.
Der MCP ist als Remote-Server definiert (https://mcp.cloudflare.com/mcp, OAuth) und
laut cf-tunnel-mapping.md:321 read-only — er kann den Fix nicht ausfuehren. Der
Bestandsaufnahme-Teil laeuft ueber den MCP, die Aenderung braucht curl + CF_API_TOKEN.
Co-Authored-By: Claude Code <noreply@anthropic.com>
Live geprueft: interner Wildcard ist durch TP41 sauber (Groups statt login_method).
Offen ist genau ein Eintrag — login_method:github in Policy 'christoph' auf
420.teilzeitladen.xyz (oeffentlich, Projekt blaueblueten).
Enthaelt konkrete IDs, die vier bekannten Gotchas (32-Hex-App-IDs, Schreib-Token,
Reusable-Policy-Detach, Projektgrenze) und den Ablauf inkl. Ruecksprache-Pflicht.
Co-Authored-By: Claude Code <noreply@anthropic.com>
Der Fund vom 2026-07-10 beschrieb login_method-Includes am internen Wildcard
*.emsenhuber.net. Live-Nachpruefung am 2026-10-06: dieser Teil ist durch TP41 behoben —
die Policies binden jetzt an Groups (E-Mail/IP/service_token).
Offen ist genau ein Eintrag: login_method:github in Policy 'christoph' auf
420.teilzeitladen.xyz (oeffentlich, Projekt blaueblueten). Kein Zugriff auf
hass/pve/portainer — die kritische Tuer war schon zu.
Co-Authored-By: Claude Code <noreply@anthropic.com>
Fund vom 2026-07-10, seither unbehoben — stand nur in der Memory project_cf_tunnel_1033,
in keiner TP-Liste. Beim Sichern der Memories wiederentdeckt.
login_method:<idp> als include matcht JEDEN via diesen IdP, nicht den Owner. Betroffen
sind alle Dienste hinter *.emsenhuber.net (hass/grafana/portainer/pve). Gitea #76.
Co-Authored-By: Claude Code <noreply@anthropic.com>
Memories sind seit 2026-10-06 versioniert (Master admin/claude-memories, Arbeitsbaum
~/dev/claude-memories/, Anbindung per Symlink). Dasselbe Muster wie bei den Skills,
aus demselben Befund: reiner Home-Ordner-State, kein Backup.
Festgehalten, weil beides am 2026-10-06 belegt gerissen ist:
- name: muss dem Dateinamen entsprechen — 12 Wikilinks zeigten ins Leere, weil 8
Dateien einen abweichenden Slug trugen. Bricht still, kein Fehler.
- MEMORY.md ist Index, kein Log — nur dieses File wird pro Session geladen. 67
Log-Zeilen trieben den r6-Index auf 16,4 KB (mehr als alle anderen elf zusammen).
Co-Authored-By: Claude Code <noreply@anthropic.com>
Nachmessung vom Core aus (crs326-core via MikroMCP, 15er-Stichproben je Zustand):
Regel AN -> 15/15 200 (168,1 KiB), Regel AUS -> 14/15 403. Der Weg ist
deterministisch; der eine Ausreisser sitzt reproduzierbar am ersten Sample
nach dem Umschalten (Connection-/Cache-Nachlauf), nicht am Pfad.
Merkregel im Archiv festgehalten: nie ein Einzelsample werten, erste Anfrage
nach Routing-Umschalten verwerfen.
Template [10b] in nautobot/mikrotik_routeros.j2 deckungsgleich mit live
(Table egress-cannaleo, Route 0.0.0.0/0 -> cf-mesh, Regel 164.90.191.7/32),
Drift 0. Issue #74 geschlossen, Label status:done.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Anlass aus TP10-Abschluss: DDNS-Updater lebt als /system script auf dem Core, in keinem
Template — Recovery von null haette ihn nicht. Systematische Klasse, nicht Einzelfund.
- Gitea #75: TP48 mit status:todo + thema:nautobot-doku angelegt
- docs/teilprojekte.md: Prosa-Abschnitt TP48 (Inventur + Evaluationsfragen)
- Live gemessener Kernbefund: Nautobot ist heute nur TEILWEISE SSoT — datengetrieben sind
nur Device-Felder, interfaces/IPs und zwei ConfigContexts; 7 VLAN-Defs, 37 bridge-port-
und 19 bridge-vlan-Zeilen, Core-Firewall, NAT/Mangle/Queue/Routen stehen LITERAL im Jinja.
Der Abloese-Vergleich lautet damit 'Ansible vs. Jinja-im-Repo', nicht 'vs. Nautobot-SSoT'.
- Nebenbefund dokumentiert (nicht angefasst): WG-Hub-Privkey im Klartext im Recovery-Skript
tp21-wan-wg-restore auf dem Core
- Korrektur: 'Abloesung durch Komodo' (CLAUDE.md + Archiv) war eine Kategorie-Verwechslung —
Komodo verwaltet Container, nicht RouterOS-Config; es kann diese Luecke nicht schliessen
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Close-Bedingung 1 (DDNS-Updater bf4.emsenhuber.net):
- Global-Scope-Fix (6e2a7cf): /system script environment get statt :global cfDdnsToken
(RouterOS 7.24 trennt CLI- und Skript-Scope)
- Live auf crs326-core: Script tp10-ddns-bf4, Trigger DHCP-Client client1 (Lease-Event),
Token in /system script environment (53 Zeichen)
- Positiv-Test bestanden: A-Record auf 1.2.3.4 gesetzt -> Script-Lauf -> 90.146.33.177,
Comment '2026.10.03-18:08 by crs326-core', Idempotenz-Variable CFWanIP4Cur gesetzt
Close-Bedingung 2 (Mesh-NAT-Regel im taeglichen GC-Lauf konform):
- nautobot_golden_config: ip-firewall-nat = true fuer crs326-core
- Regel in der Intended Config (Z.425), nicht nur im Backup
- Zwei taegliche AllDevicesGoldenConfig-Laeufe nach dem Fix gruen (2026-10-04, 2026-10-05)
Doku: Handoff-Datei entfernt, TP10-Prosa in teilprojekte.md auf abgeschlossen gesetzt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- Standort final: ap1 Sideboard · ap2 Technik UG · ap3 Technik OG, alle drei CAPs am crs326-core
- Kanalplan committed (ap1 5260/5280, ap2 5300/5320, ap3 5180), Template mikrotik_routeros.j2
- wifi-cap-Rest auf dem Core (cap enabled=yes, Manager ohne eigene Radios) auf enabled=no bereinigt
- Compliance 29/29 über 5 Geräte, 0 Drifts (145/145 im GC-Job)
- Transaktionen: TEST-ether3-trunk-ap1-sideboard-2 + TP25-kanalplan-ap1-live committed in SoT
- Prosa: Volltext nach teilprojekte-archiv.md, Pointer bleibt in teilprojekte.md
- Gitea #18: body aktualisiert + Abschluss-Kommentar
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Skript `tp10-ddns-bf4` auf crs326-core angelegt (MIT, Basis bajodel/mikrotik-cloudflare-dns):
- WAN-IP aus DHCP-Lease (client1/vlan100), NICHT von Echo-Diensten
- check-certificate=yes, Public-IPv4-Guard, Idempotenz, Token als globale Variable
CF_DNS_API_TOKEN (eng gescoped: Zone→DNS:Edit nur emsenhuber.net/bf4) liegt
in ~/.secrets/credentials.env und ist als cfDdnsToken auf Core gesetzt.
Offen: Global-Scope-Problem (Variable im Skript nicht sichtbar) — Handlauf 1+2,
Scheduler, Positiv-Test, TP10 #49 schließen stehen aus.
Handoff-Dokumentation in docs/handoff-20261003-tp10-ddns-finalisierung.md.
Co-Authored-By: Claude Code <noreply@anthropic.com>
Der Fix aus 1fddf5d ist live und verifiziert. Dieser Commit traegt die Doku nach und
raeumt eine falsche Diagnose weg, die eine Folge-Session in die Irre gefuehrt haette.
- TP10 (#49) reopened (status:wip), Prosa-Volltext zurueck aus dem Archiv nach
teilprojekte.md; im Archiv bleibt der Zeiger.
- Neuer Befund dokumentiert: WARP-Clients kommen via cf-mesh mit 100.96.0.0/12 an,
ausserhalb der Spoke-AllowedIPs (10.40.0.0/16) -> FritzBox verwirft. Beweis-Tabelle
und Abnahme-Werte im Abschnitt.
- Close-Bedingung ins Issue geschrieben: DDNS-Updater bf4.emsenhuber.net + taeglicher
GC-Lauf konform. Der Mesh-NAT-Teil ist erledigt.
- docs/handoff-20260928-core-wghub-ping-fix.md GELOESCHT: er behauptete, die fehlende
Interface-IP von wg-hub sei ein Defekt, und schlug preferred-source vor. Beides
widerlegt — die fehlende IF-IP ist beabsichtigt (im Archiv dokumentiert), und der
Core-eigene Ping ist kein Betriebsproblem. Die Erkenntnis steht jetzt in TP10.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Spoke-FritzBoxen akzeptieren am WG-Peer nur Quell-IPs aus 10.40.0.0/16; WARP-Clients kommen ueber cf-mesh mit 100.96.0.0/12 und wurden verworfen. src-nat auf wg-hub-Egress legt die Quelle in den AllowedIPs-Raum.
Template (Soll) + idempotenter Job tp10-mesh-nat (manual Plan, nie full-intended). Compliance 145/145, end-to-end verifiziert (Mac/WARP -> 10.95.10.1).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Die `### TPnn`-Header trugen weiterhin Status-Anspruche (▸ ✅ FERTIG …, ▸ ⏳ CUTOVER …),
obwohl Index/Status seit dem TP36-Cutover in Gitea liegt. Das war eine dritte Statusquelle,
die den Labels nachlief — Header-Marker datierten teils Wochen vor dem Issue-Update.
- 75 Header (32 aktiv + 43 Archiv) auf `### TPnn · Gitea #N — <Titel> — <Caveat>` umgestellt.
Caveats, Warnungen, Querverweise und Archiv-Links bleiben erhalten, nur der Status faellt weg.
Status-Marker im Fliesstext (Messchronik, Unterpunkte) bleiben — sie beschreiben Historie.
- TP47 fehlte als Gitea-Issue komplett (nur in der Datei seit 808d3a1) -> als #74 angelegt.
- bin/gitea-tp-sync.py schrieb in die falsche Richtung: der Abgleich leitete den Zielzustand
aus dem Datei-Marker ab (fest ✅) und haette #24 (TP34, bewusst status:dropped) auf status:done
gezogen. Jetzt werden nur noch FEHLENDE Archiv-Issues angelegt, bestehende nie angefasst.
- CLAUDE.md: Header-Form + Werkzeug-Richtung festgehalten.
- Announcement 2026-10-03 für die naechste Session.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die 22 globalen Skills waren reiner Home-Ordner-State - kein Git, kein
Backup. Master ist jetzt das Gitea-Repo admin/claude-skills, ~/.claude/skills
ist dessen Arbeitsbaum. Sync-Ablauf inkl. cp-Schritt nach opencode festgehalten.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Die 3P-Config 8f69f2f1 traegt nur den CCR-Gateway-Token, nicht den
OR-Key. Der OR-Key lebt in config.sqlite live + in der nur gespeicherten
e1219ea4. Rotation muss 8f69f2f1 unangetastet lassen.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Der Key geriet ins Transkript, weil das `sed` auf den geratenen Namen
`apiKey` ankerte statt auf `inferenceGatewayApiKey`. Neue Unterklasse der
bekannten Familie: Quelle war JSON, nicht Env — das geteilte KEY=VALUE-
Snippet kann `"key": "…"` nicht treffen. Merkregel ergaenzt.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Beim Einlesen von ~/.secrets/exports.zsh griffen zwei Feld-Maskierungen nicht:
N8N_MCP_BEARER (Alternation ohne BEARER, Schluessel endet ohne "=") und
TERPENE_RO_URL (Passwort steckt im URL-Userinfo-Teil, keine "="-Ankerstelle).
Beide als neue Zeilen im Sammelbecken, gebuendelt wie die uebrigen Posten.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Drei driftende Wahrheitsquellen (Gitea-Issue, teilprojekte.md, CLAUDE.md),
Standard-vs-Eigenbau, drei Vorschläge. Basis für eine separate Session,
die die Umstellung selbstständig sucht und umsetzt.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
TP25 ist abgeschlossen (Platzierung final, Fund E geschlossen, Gitea #17 closed).
Der aktive Stand (Kondensat, ~507 Zeilen) wandert ins Archiv als neue Sektion
## TP25 — Kondensat (Anchor #tp25); in teilprojekte.md bleibt ein Pointer.
Archiv-Index + "Dazu am Ende"-Notiz + Langfassung-Header ("nicht abgeschlossen"
→ abgeschlossen) nachgezogen.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Die vier "Offen"-Punkte aus dem 09-15-Zuordnungs-Block waren am selben Tag
im Steering-Handoff §6 aufgelöst (ap1 bleibt, Tausch-Korrektur verworfen,
Drei-Räume verworfen, Doku-Drift geschlossen), aber nie zurückgeschrieben.
Header ⏳→✅ FERTIG, Gitea #17 geschlossen.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
- docs/teilprojekte.md: Schicht-C-Zeile auf C1-C3 durch; neuer Abschnitt mit
C1 (27 Core-Statics, Job tp45-c-dns), C2 (AGH entdoppelt), C3 (ds-bf ueber
Caddy), WARP-Abnahme, sowie den zwei offen gelassenen Befunden (AAAA-Leak,
AGH-Doppeladresse) und der dig-Messfalle. ap3.bf-Bullet korrigiert.
- CLAUDE.md: Pflichtlektuere Block 0 beschrieb noch das ungeloeste FQDN-Problem.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
C1 - Der Core haelt jetzt 27 /ip dns static (vorher 10). Die 12 toten Namen
loesen wieder auf: 9 Caddy-Frontends, tv.bf/mfc.bf, das bisher nirgends
existierende ap3.bf, dazu pve.bf und pve-mcp.bf von der Host-IP auf .40 und
die 5 bare Namen. Neuer GC-Job tp45-c-dns; er liest die Zeilen aus dem
Template selbst und macht daraus einen idempotenten Upsert.
C2 - AGH entdoppelt: upstream_dns nur noch 10.40.20.1, alle 26 Rewrites raus.
Der Core ist damit die einzige Quelle. /admin ist lokal wieder erreichbar
(header-frei 200, mit CF-Connecting-IP weiter 404 - der Guard bleibt zu).
C3 - ds-bf-Ingress-Origin auf https://10.40.20.40:443 + SNI (CF-Write).
Oeffentlich 200 in 0,24 s statt 000 nach 20 s.
Abnahme: Geraete-Read (27 Statics), Compliance 145/145 / 0 Drifts, dig vom
Mac fuer alle Namen, /admin lokal 200, ds-bf oeffentlich 200, Filter
(doubleclick -> 0.0.0.0) intakt, vw/hass/n8n/gitea unveraendert.
Offener Befund: der Core reicht AAAA weiter und liefert damit fuer die bare
Namen die CF-IPv6. Heute wirkungslos (kein globales IPv6 im Netz), aber
latent - bewusst dokumentiert statt geaendert.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Commit 3eb03ae (2026-09-14, "Plaintext-Secrets entfernen") hat in beiden
Dateien `private_networks: []` durch `private_<redacted>: []` ersetzt -- ein
Redaktionswerkzeug hat den Schluesselnamen fuer einen Secret-Wert gehalten.
Folge: `adguard/AdGuardHome.yaml` ist die SSoT, die `agh-sync.py push` in beide
Live-Instanzen schreibt -- der naechste Push haette einen unbekannten Schluessel
in die AGH-Config gebracht (private_networks faellt dann auf Default zurueck,
oder der Parser lehnt die Config ab).
Wiederhergestellt in
adguard/AdGuardHome.yaml:74
docs/transaktionen/agh-bf1-AdGuardHome.snapshot.yaml:87
Abnahme: Repo-SSoT vs. live .36 -> 498/498 Zeilen identisch (ohne password-Zeilen).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Zwei Christoph-Direktiven am 2026-09-21, in dieser Reihenfolge:
1. "mach die shellys sofort rueckgaengig" -- HA bindet sie per IP ein.
2. "wir sollten alle vlan30-aenderungen rueckgaengig machen" -- Sperr-Risiko
Nuki: ein Fehlgriff haette aussperren koennen.
Neu in tp45-leases.py: die Tabellen SHELLY/REVERT und das Kommando `revert`
(nur die 26 Shellys) sowie `restore` (alles zurueck auf vor B2, inkl.
NSPanelPro-Reservierung und wiederangelegter CCU-Zeile). In gc-configplan.py
die Jobs tp45-v30-revert und tp45-v30-restore; _lease_move nimmt jetzt ein
tag, damit die :log-Zeilen den Job unterscheidbar machen.
Abnahme: Geraete-Read (alle 36 Adressen zurueck, NSPanelPro ohne Reservierung,
CCU .232 wieder da) und --refresh-compliance 145/145, 0 Drifts.
Zwei Funde, die als Merkregel bleiben: `make-dynamic` gibt es in RouterOS 7.24
nicht (der Rueckweg ist `remove`), und der GC-Plan-Status beweist nichts --
beide Laeufe meldeten Failed, waehrend der Job-:log alle 36 Statements
protokollierte.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Neue IPs .110/.121/.130 werden zuerst am Core generiert (Sekundaer-IP auf
vlan20 + 1:1-NAT aufs Geraet), gemessen wird ab Tag 1 mit zwei Zaehlern
(neue IP = wer ist umgestellt, Alt-IP = ist noch was los). Das Geraet wird
erst angefasst, wenn seine Alt-IP still ist ("siedeln"). Alles ins Soll,
nicht als Transaktion. NAS siedelt zuletzt und gemeinsam.
Warum NAT statt Routing: im selben Subnetz antwortet das Geraet dem Client
direkt per L2 -- er verwirft die Antwort von .10 auf eine Verbindung zu .110.
Vorabcheck: NAS-NFS/iSCSI sind IP-ACL'd, aber ohne lebende Nutzer (pve hat
null NAS-Mounts) -- der src-nat-Umweg bricht nichts. Nebenbefund: die
Exports stehen auf totem 10.40.41.x plus drei 10.0.0.0/8-Freigaben.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Nach dem Streichen der Ausnahme durfte die Wortwahl nicht mehr nach
sofortiger Einzelrotation klingen. Posten #4 ist anlass- aber weiterhin
gebunden; beide Stellen sagen das jetzt explizit.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Die Klausel zog bei einem neuen Leak eine sofortige Einzelrotation vor und
widersprach damit dem Buendelungszweck des TPs (Kostentreiber sind die
Konsumenten, nicht das Setzen) und der gelebten Praxis: auch die
leak-getriebenen Posten #1 und #5-#9 blieben gebuendelt.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Der Posten hing an einem harten Termin ("laeuft am 2027-01-09 ab"), der nicht
mehr existiert: dieses Datum gehoerte zum laengst revokten Alt-Token
9984078812bc..., waehrend das live CF_API_TOKEN (id 493ed8bd...) gar kein
Ablaufdatum hat (expires_on: null, verifiziert ueber /accounts/{id}/tokens/verify).
Damit ist die Rotation anlass- statt termingetrieben — Ausloeser ist jetzt der
Leak vom 2026-09-21 (Wert in einer Session-Ausgabe sichtbar geworden).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
36 DHCP-Reservierungen wandern aus dem Pool-Fenster (.5, .8, .202-.244)
in die Schema-Baender .11-.14 / .151-.176 / .177-.196. Dazu die CCU-Leiche
.232 (status=waiting, last-seen=never; die CCU lebt in VLAN20) entfernt und
SONOFF-NSPanelPro von einer dynamischen Lease auf .249 zu einer statischen
Reservierung auf .12 gepinnt.
Neuer Job `tp45-v30-leases` in gc-configplan.py. Er laedt MOVES/REMOVE/ADDS
per importlib aus tp45-leases.py, statt sie zu kopieren -- die Tabelle dort
ist die SSoT des Umzugs, eine zweite Kopie liefe still auseinander.
Warum der Job zwei Selektor-Formen traegt: die erste Fassung schrieb
ueberall `[/ip dhcp-server lease [find where ...]]`. In `[:len ...]` ist das
Syntaxfehler (`expected command name (line 1 column 55)`, live gemessen) --
Golden Config meldete trotzdem Job SUCCESS und Plan Completed, das Geraet
blieb unveraendert. Aufgefallen ist es an der Zahl der Log-Zeilen: von 38
`:if`-Statements hat kein einziger Zweig geloggt. Richtig ist
`[/ip dhcp-server lease find where ...]` ohne Klammerpaar um `find`;
die Argument-Form `set [find where ...]` bleibt.
Abnahme am Geraet, nicht am Plan-Status: 39 Leases im Soll-Schema, .232 und
.249 geraeumt, NSPanelPro dynamic=false; Compliance 145/145, keine Drifts.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Erster Lauf nach dem Einbau ergab 144/145 -- und die eine Drift war mein Fehler,
nicht der des Geraets: backup_lines() strippte mit l[1:] nur das fuehrende '/',
nicht den ganzen Befehl. Das gerenderte Soll enthielt dadurch
`/ip dhcp-server lease ip dhcp-server lease add ...`.
Gefunden hat das die Compliance-Zahl selbst. Genau deshalb ist der NENNER die
Abnahme und nicht der Zaehler: 140 -> 145 beweist, dass die neue Rule auf allen
fuenf Geraeten auswertet; 145/145 beweist, dass das Soll stimmt.
Ausserdem: seed --force fuer einen bewussten Neuschnitt (der Guard gegen
versehentliches Re-Baseline bleibt).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Die 54 statischen Reservierungen des Cores standen in KEINEM Soll: das Template
rendert kein einziges /ip dhcp-server lease, und die Sektion stand unter keiner
ComplianceRule. Ein GC-Recovery von null haette einen Core ohne Reservierungen
erzeugt, in dem jedes IoT-Geraet in den Pool faellt -- und weil Compliance nur
prueft, was gerendert wird, waere die Zahl dabei gruen geblieben. Dieselbe
Luecke wie die handgelaufene `nautobot`-Adressliste.
- mikrotik_routeros.j2 [5b]: rendert local_config_context_data.dhcp_leases,
gleiches Idiom wie firewall_filter.
- tp45-leases.py: seed/move/check. Zeilen werden verbatim uebernommen und nur
im address=-Token getauscht -- das erhaelt Quoting und die 14 client-id-Felder.
Reihenfolge bleibt die Geraete-Reihenfolge (Einfuege-, nicht numerisch).
- ingest-dhcp-lease-rule.py: Feature+Rule `dhcp-lease` auf RouterOS,
config_ordered=False.
Noch KEIN Geraetewrite -- der Ist-Stand wurde als Soll gesetzt (Re-Baseline).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Die 7 DHCP-Pools starteten alle bei .100 und ueberlappten damit die beiden
Oktett-Baender, die dieses TP gerade belegt: .100-.149 (Server-Hosts) und
.150-.199 (App-Services). In VLAN20 ist das eine echte Kollisionsflaeche --
nautobot .154-.158, gitea .157, pve-mcp .173 und shelly-mcp .180 tragen ihre
IP GERAETELOKAL und stehen in keinem Lease-Eintrag, der Core kann sie also
nicht schuetzen und einem DHCP-Client .154 anbieten.
Entscheid 2026-09-21: nur pool-v20 und pool-v30 werden verengt, v20 zuerst.
VLAN10/40/50/90/99 bleiben bei .100-.200 -- dort gibt es kein Schema-Band,
das etwas gewoenne, und VLAN40/VLAN10 haetten sonst 11 Sonos (.191-.201),
den iPhone (.196) und den Mac (.82) mitgezogen.
VLAN20 kostet die Verengung nichts: eine statische Reservierung (nas-bf
.20.10, in .10x) und 0 dynamische Leases.
pool-v30 bleibt bewusst unangetastet -- dort liegen 35 statische
Reservierungen IM Fenster .200-.249 (26 Shellys .202-.226/.233, SwitchBot
.227, Twinkly .228, Withings .230/.231, lichterketten .236/.237, Nuki
.241/.244, CCU .232). Erst Schicht B zieht die um, dann pool-v30.
Nebenbei faellt damit die .30.250-Kollision: der Sonoff Dongle-M sitzt dort
statisch, der Pool reicht heute bis .250.
Neuer Job `tp45-pool-v20` (gc-configplan.py) mit gezaehltem Selektor: ein
`find where`, das 0 trifft, sieht wie "nicht vorhanden" aus statt wie
"kaputt" -- ein blankes `set [find where name=...]` liefe ins Leere und der
Job meldete Erfolg.
🔴 Lehre aus dem ersten Fehlversuch: jedes config_set-Statement muss auf EINER
Zeile klammer-vollstaendig sein. Mit `:if (...) do={` am Zeilenende geht
RouterOS in den Fortsetzungs-Modus und zeigt einen anderen Prompt, der
netmiko-Treiber verliert sein Muster und der Deploy stirbt mit
`E1015: Pattern not detected: ...@crs326\-core\].*$|#.*$)` -- Plan auf
Failed, ohne etwas geschrieben zu haben.
Abnahme: Gerate-Read pool-v20 = 10.40.20.200-10.40.20.249 (total=50,
used=0); DHCPOFFER-Probe auf vmbr0.20 -> 10.40.20.200 mit
Domain Name Server 10.40.20.30, 10.40.20.31; Probe-Lease wieder entfernt;
Compliance 140/140 ohne Drift.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Die vier Core-Forward-Regeln fuer den Resolver waren nachgezogen, die
DHCP-Antwort an die Clients noch nicht: /ip dhcp-server network trug
weiterhin dns-server=10.40.20.36,10.40.20.37. Ein Client haette nach dem
AGH-Umzug den Resolver unter der alten Adresse gesucht.
Template geaendert, nach bf-golden-config gepusht (Git-DataSource ist die
Wahrheit, nicht die lokale Datei), Git-Sync, am Core gesetzt (alle 7 Netze),
per DHCPOFFER-Probe auf vmbr0.20 bestaetigt (Domain Name Server:
10.40.20.30, 10.40.20.31), Compliance 140/140 ohne Drift.
Randbefund (nicht in diesem Commit): die 7 DHCP-Pools starten live bei .100
und ueberlappen die Schema-Baender .100-.199 — pool-v30 reicht sogar bis
.250, wo statisch der Sonoff Dongle-M sitzt. Entscheid 2026-09-21: nur
pool-v20 und pool-v30 werden auf .200-.249 verengt, v20 zuerst.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- nautobot/tp45-agh-firewall.py (neu): pflegt die vier `TP5-E2: LAN->AGH dns*`-
Regeln im `local_config_context_data.firewall_filter` (add/remove, Dry-Run
default, Unified Diff). Bewusst NICHT `ingest-core-firewall.py` -- das ist ein
RE-BASELINE-Werkzeug und wuerde die Aenderung mit sich selbst absegnen.
- gc-configplan.py: Jobs `tp45-agh-fw` (add + move vor die Log-Regel; `caddy`
dahinter, damit der AGH-Block zusammenbleibt) und `tp45-agh-dhcp`.
Fix in `create_plans`: unter derselben `change_control_id` liegen nach einem
zweiten Lauf zwei Plaene. Die Auswahl folgte der REST-Reihenfolge und traf den
ALTEN -> der config_set-Guard brach ab, obwohl der neue Plan korrekt erzeugt
war. Jetzt gewinnt der juengste; die alten bleiben Historie.
Fund: `find where dst-address=<bare-IP>` matcht in RouterOS nie (nur `~` als
Regex). Die Zeile stand als "Verifikation" in
docs/transaktionen/TP23-agh-firewall.commands.rsc:7 und hat dort seit dem
2026-08-25 immer `0` gemeldet, ohne je etwas zu pruefen. Gleiche Klasse wie
`nc -z` (09-01): eine Pruefung, die 0 meldet, sieht wie "fehlt" aus, nicht wie
"kaputt".
Abnahme: Reihenfolge am Geraet (vier neue Regeln vor dem Drop), Compliance
140/140 / 0 Drifts mit `RouterOS - ip-firewall-filter` (ordered, frisch
bewertet, `actual` traegt die neuen Zeilen), `dig` vom VLAN10-Client gegen
.30/.31/.36/.37 alle beantwortet.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
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>
RouterOS exportiert comment=TP38-OOB-MGMT ohne Quotes (kein Leerzeichen),
das Template hatte sie gesetzt -> bridge-port Drift. Fix: unquoten.
Der Deploy-`place-before=[find ...]` wurde von Netmiko ignoriert (Regel
landete hinter dem drop); im Job jetzt add + move.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Template mikrotik_routeros.j2: ether23 auf core+branch als OOB-Port
(pvid=99, admit-only-untagged-and-priority-tagged) + VLAN99 untagged=ether23.
Branch bekommt einen deny-by-default-Input-Filter (8 Regeln, src-Rahmen
spiegelt /ip service available-from), Core eine Regel "OOB->core mgmt".
Neue Skripte: ingest-tp38-oob.py (seedet firewall_filter in beiden
local_config_context_data) und der gc-configplan.py-Job tp38-oob (Deploy).
ConfigPlans angelegt+approved, Deploy steht noch aus.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
