62 Commits

Author SHA1 Message Date
e87619e89b TP38: bridge-port comment ungequotet + core place-before->move
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>
2026-09-15 19:33:22 +02:00
177ba100eb TP38: OOB-MGMT-Port (ether23 untagged VLAN99) + Branch-Input-Firewall
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>
2026-09-15 19:23:59 +02:00
bce40d182d TP25: Handoff Steering-Threshold + Terrasse-Verifikation
st-main-5g deployed (140/140), Terrasse am iPhone verifiziert (2.4G statt 5G/-80).
MacBook-Klebrigkeit dokumentiert, transition-time=immediate wird nicht umgesetzt.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2026-09-15 18:40:22 +02:00
1d86983f63 TP25: st-main-5g Parameter-Reihenfolge gefixt + Commands-File
RouterOS exportiert transition-threshold vor wnm; Template-Reihenfolge ans
Export-Format angepasst. Deploy über manuellen Plan (Plan cc8340a8) — 140/140.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2026-09-15 18:30:24 +02:00
27effe937e TP25: AP-Zuordnung definitiv + Doku-Drift geschlossen
ap1=Sideboard/core ether3, ap2=Technik UG/core ether21, ap3=Technik OG/branch
ether24 (live per IP+MAC+Switch-Port). ap2 ether1 = :39. Nautobot Location
gesetzt (vorher None). Kanäle ap1/ap2 mitkorrigiert.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2026-09-15 18:27:19 +02:00
2cf32bde14 TP25: Steering 5G bricht früher ab (st-main-5g, -72/5s)
Terrasse saß am Rundgang 09-15 auf der -80/5G-Kante. transition-threshold
-80→-72, transition-threshold-time 10s→5s — nur für 5G; 2,4G bleibt auf
st-main (unset -80) für Reichweite draußen.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2026-09-15 18:27:16 +02:00
1f19a3b4a9 TP25: AP-Zuordnung definitiv geklärt, ap1-Redundanz gemessen
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2026-09-15 18:06:15 +02:00
3e727f1b3b TP25: AP-Zuordnung per Kabel-Test geklärt, Messrunde Vorher, Tausch ap1↔ap3 begonnen
Handoff der Vor-Ort-Session: ap1=Sideboard, ap2=Technik OG, ap3=Technik UG (per
Kabel-Test eindeutig). Messwerte Vorher (Innenräume + Terrasse) festgehalten;
Terrasse wird ausschließlich marginal von ap2 bedient. Tausch ap1↔ap3 angefangen,
aber Netzzustand unklar (ap2 down, ap3 an ether8). Nächste Schritte dokumentiert.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2026-09-15 17:11:17 +02:00
037d2bd22c TP25: Deckungsfix Variante 3 terminiert -- Umsetzung 2026-09-15/16
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>
2026-09-15 12:17:38 +02:00
0e6742f1d7 TP25: DTU-Verifikation DURCH -- 45000 ms eliminiert den 5:05-Zyklus, Fund F abgeschlossen
- 09-15 12:11: DTU online seit 06:41:49, uptime 5h29m, 0 Disconnects
  (Vergleich 09-14 mit 30,5 s: fuenf Zyklen in 18 min). DTU sitzt heute
  auf ap3-2,4 statt ap2/ch11.
- Fund F damit abgeschlossen: Ursache = DTU-Cloud-Recovery, getriggert
  durch hmsmqtt-Polling-Kollision. Messplan #225 gegenstandslos.
- Issue #17, Kommentar #230.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-09-15 12:12:30 +02:00
b7d82fe300 TP25: Fund-F-5:05-Zyklus geklaert -- Cloud-Recovery der DTU bei Polling-Kollision
- 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>
2026-09-14 22:18:35 +02:00
13a996c6d9 TP25: DTU-Hebel korrigiert -- OpenDTU/AhoyDTU entfaellt fuer HMS-800W-2T
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>
2026-09-14 21:13:27 +02:00
2a21afe74a TP25: Messplan Wechselrichter/DTU (Hoymiles HMS-800W-2T) angelegt; 20:37-Nachtrag
- 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>
2026-09-14 21:04:42 +02:00
9fdcab58ad TP25: ft=yes-Abnahme DURCH — Anruf uebersteht 5 Band-Wechsel in 60 s
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>
2026-09-14 20:37:37 +02:00
441e97ed84 TP25: ft=yes-Durchfuehrung dokumentiert (140/140, 0 Drifts, CAP-Abnahme sauber)
- 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>
2026-09-14 20:34:47 +02:00
89eb9dc3ac TP25: sec-main-Begruendungskommentar im Template auf 09-14-Stand bringen
Kontextkommentar ueber der sec-main-Zeile dokumentierte noch den 09-04-Entscheid
(ft=no); nach der Ruecknahme am 09-14 konsistent gemacht (Entscheid-Historie bleibt
als Zeile erhalten).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-09-14 20:21:47 +02:00
4e80ffac28 TP25: sec-main zurueck auf ft=yes/ft-over-ds=yes (Ruecknahme 09-04, Hebel-A gescheitert)
- Go Christoph 2026-09-14 nach Terrasse-In-situ-Session: mit ft=no ist jeder
  Roam eine Voll-Reassoziation -- darin starben 2 Anrufe.
- Known-Good-Stand vor Hebel-2: Fund-E-Abschlussmessung 09-02 lief auf
  ft=yes/ft-over-ds=yes + 7.24.1 ruhig (4 reauth/8,6 h, 0 Ausfaelle).
- Template [6c]-Kommentar auf Stand 09-14 gebracht: signal-range-Boden
  geprueft und gescheitert (kein band-Property, cap-wifiN-Rejoin-Falle).
- Commands-File docs/transaktionen/TP25-ft-yes-secmain.commands.rsc fuer
  den GC-Deploy via gc-manual-plan.py (Dry-Run gelesen).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-09-14 20:21:13 +02:00
548d73d84a TP25: ap2-In-situ widerlegt (Terrasse), Hebel-A-Machbarkeitspruefung negativ; TP30 #9 GITEA_ACCESS_TOKEN
- 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>
2026-09-14 20:16:20 +02:00
3eb03ae7b4 Plaintext-Secrets entfernt: Portainer-State-Dump gelöscht, n8n-Bearer + AdGuard-Token redaktieren
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2026-09-14 15:14:57 +02:00
3a97bbc41c opencode.jsonc entfernt (durch opencode.json ersetzt, Migration abgeschlossen)
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2026-09-14 15:09:50 +02:00
7d237577e1 MCP: 7 globale Server auf Projektebene (env-Referenzen, keine Tokens im Repo)
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2026-09-14 11:58:09 +02:00
777c4e0984 opencode.json: Projekt-MCP-Konfig mit {env:}-Platzhaltern
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2026-09-14 11:57:28 +02:00
425070ce11 Handoff: CF_API_TOKEN gerollt + Verify-Endpoint-Gotcha (Gitea #69 closed)
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2026-09-13 15:13:23 +02:00
ae87e9f511 TP23 Stufe 5 Redesign: pro-Person Self-Service (agh-exception.py + Bau-Spec)
Stufe 5 reopened — DAU-Requirements (pro Person, "zuletzt geblockt -> 1 Klick",
temp+dauerhaft umschaltbar, scoped HA-Dashboard) nicht erfuellt → Stufe 6 gated.
agh-exception.py: $client-scoped allow/unallow, list-exceptions, recent-blocked
(selftest OK, reine Logik netzunabhaengig getestet). HA-Bau-Spec + Personen-
Client-Modell dokumentiert. Bau/Abnahme on-network offen.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-12 14:32:13 +02:00
f941731ac4 TP35 ✅ abgeschlossen: Header ⏳→✅ (Gitea #25 closed/status:done)
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>
2026-09-12 12:52:52 +02:00
3877c23505 GC-Backup: täglicher Scheduler angelegt (vorher gab es keinen)
Diagnose: die GC-Backups standen seit 2026-09-04, weil NIE ein Scheduler
existierte — Backup/Intended/Compliance liefen nur manuell aus Sessions. Die
"2×/Tag per SSH"-Annahme (CLAUDE.md Bot-Master-Zeile + gc-snapshot.py-Docstring)
war nie real; beide korrigiert.

Fix: Nautobot-Job "Execute All Golden Configuration Jobs - Multiple Device"
enabled + ScheduledJob "GC Backup+Compliance – taeglich" (platform=RouterOS,
täglich 03:30 UTC, Backup→Intended→Compliance). Sofort-Lauf SUCCESS, alle 5
Geräte backup/compliance auf 2026-09-12 10:35, frischer bf-golden-config-Commit.
Announcement-Eintrag ergänzt.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-12 12:36:48 +02:00
123a0fefdf TP35 Schicht 2 ✅ angewandt: claude.json-Secrets auf {env:} geflippt
Flip via ~/dev/.bin/schicht2-claude-json-migrate.py --apply-claude bei beendeter
App (Backup .bak-20260912-*), App neu gestartet, MCP-Server laden sauber. Alle 7
Secrets (mikromcp 5× PASS, hostinger Token, n8n Bearer) jetzt {env:}, verifiziert.
Restcheck: authentifizierter mikromcp-Read on-network (09-12 nur Connect-Timeout
VLAN99:80 = Erreichbarkeit, kein Auth-Fehler).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-12 12:28:23 +02:00
aebf3776ac TP35 Schicht 2 vorbereitet: exports.zsh komplett, claude.json-Flip ausstehend
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>
2026-09-12 12:19:00 +02:00
b6f2129b41 TP35 Schicht 4+5 ✅: /news-Announcements + Backup-Guard abgenommen
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>
2026-09-12 12:14:10 +02:00
82cd8098ef TP36-Live ✅: gc-snapshot.py live — 5 CustomFields auf dcim.Device
Legt die fünf TP36-Live-CustomFields (grouping TP36-Live) auf dcim.device an
und befüllt sie für alle 5 RouterOS-Geräte (ap1/2/3, crs326-branch/core)
ausschließlich aus Nautobot/Golden-Config — kein Geräte-Kontakt:
  ros_version 7.24.1 (flotte), compliance_pct 100, dhcp_server_count
  (core 7, Rest 0), dns_upstream_mode (core doh, Rest plain), mgmt_ip.

Idempotent (get-or-create CF, PATCH Device), Dry-Run default, --commit schreibt.
Token aus gitignored 210-nautobot.yml, Backup-Text nur intern geparst (nie ausgegeben).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-12 12:11:29 +02:00
614025eafb TP43 ✅ umgesetzt: dw-FritzBox-DNS auf FB-Upstream .36/.37 + Rebind-Ausnahme
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>
2026-09-11 14:59:30 +02:00
677dade184 TP43: DHCP-Multi verworfen (FB-DHCP nur 1 DNS-IP) → FB-Upstream .36/.37 + Rebind-Ausnahme
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>
2026-09-11 14:25:53 +02:00
b20edd6b62 TP43 reopened: interne BF-Namen über WG am dw — Entscheidung DHCP-Multi [.36/.37/public]
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>
2026-09-11 13:53:41 +02:00
a38ed0fe1d TP41 (✅) + TP43 (❌) + TP42 (✅) ins Archiv; TP41-Titel entschärft
- 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>
2026-09-11 12:19:51 +02:00
5a29c482bd TP44 abgeschlossen: Prosa ins Archiv verschoben
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>
2026-09-11 11:03:45 +02:00
4eba3673b7 TP44: Überholt-Zeiger auf falsche CF_API_TOKEN-Gotcha (Handoff 09-02)
Die Zeile "Repo-CF_API_TOKEN darf kein Workers-VPC" war falsch (live: liest
14/14). Handoff als Snapshot belassen, aber Korrektur-Hinweis ergänzt. Damit
ist die letzte Wiederholung der stale Gotcha markiert.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-11 10:58:18 +02:00
2b856d3d42 TP44 Teil B durch: Prosa auf ✅ + Handoff (Sync live, täglicher Job)
- teilprojekte.md: TP44-Status ✅ DURCH; Teil-B-Ergebnis (Live-Sync als
  täglicher Nautobot-Job, 4/14, 0 Drift); Drift-Korrektur der falschen
  "CF_API_TOKEN kann kein VPC"-Gotcha (live: liest 14/14).
- handoff-20260910: Root-Cause (Wurzel-__init__.py für walk_packages),
  register_jobs im __init__, has_sensitive_variables, VPC service_id-Fix,
  terpene-db service_id-Reconcile.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-10 11:15:13 +02:00
f1d565bc88 TP44 Teil B: Meta.has_sensitive_variables=False — Job schedulebar machen
Nautobot verweigert das Scheduling von Jobs mit has_sensitive_variables
(Default True): "Job may have sensitive input variables". Der Job nimmt nur
ein Boolean (dryrun); das CF-Token stammt aus dem Nautobot-Secret, nicht aus
einer Job-Variable — daher unbedenklich abschaltbar.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-10 11:12:56 +02:00
43c592e5d4 TP44 Teil B: CF-Sync-Job — VPC service_id-Feld + None-Match-Guard
Dry-Run-Befund: CloudService 'terpene-db' (VPC) wurde faelschlich als stale
markiert und fremde extra_config in 'App Launcher' gemischt. Ursache: VPC-
Directory-Services tragen ihren Identifier in "service_id", der Job las "id"
(=None). Ueber .get(mk)==None matchte der None-Wert das erste Objekt ohne den
Key. Fix: VPC nutzt v["service_id"]; _upsert ueberspringt mv=None generell.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-10 11:09:30 +02:00
33b18a08db TP44 Teil B: __init__.py in Repo-Wurzel — macht bf_infra für Nautobots Job-Loader sichtbar
Root-Cause des "No jobs were registered on loading the bf_infra.jobs submodule":
Nautobot 3.1.7 lädt Git-Repo-Jobs via import_modules_privately() ->
pkgutil.walk_packages([GIT_ROOT]). walk_packages entdeckt nur reguläre Pakete
(mit __init__.py), keine Namespace-Packages. Ohne Wurzel-__init__.py ist der
geklonte Ordner GIT_ROOT/bf_infra/ unsichtbar -> jobs/ wird nie importiert.
Live verifiziert: __init__.py da -> registry["jobs"] enthält CFEstateSync.
bf-infra ist das erste Git-Repo mit extras.job, daher nie zuvor aufgetreten.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-10 11:06:28 +02:00
799b693ffa TP44 Teil B: register_jobs() ins Paket-__init__ (Git-Repo-Job registriert jetzt)
Nautobot importiert von einer Git-Datenquelle nur das Paket bf_infra.jobs und
erwartet register_jobs() im __init__ — der Call im Submodul blieb unsichtbar
(Sync-Log: "No jobs were registered on loading the bf_infra.jobs submodule").
register_jobs(CFEstateSync) daher ins __init__ verschoben, redundanten Call am
Ende von cf_estate_sync.py entfernt.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-10 10:51:02 +02:00
4aeced30b5 CLAUDE.md: terpene-Zeile korrigiert — Terpenfinder = 420.teilzeitladen.xyz
terpene.* existiert nicht (0 DNS in allen Zonen, live 2026-09-10) und soll es
nicht; die öffentliche App ist der CF-Worker 420.teilzeitladen.xyz (blaueblüten).
Alte Zeile nannte terpene.teilzeitladen.xyz:8890 via Tunnel bf-mm — bf-mm ist
gelöscht. Einziger terpene-CF-Gegenstand: interner Tunnel terpene-db (f2d2fc8a).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-10 10:13:00 +02:00
89d94dbd45 TP44 Teil B: jobs/__init__.py — Job-Modul importieren, damit register_jobs greift
Nautobot laedt aus einer Git-Datenquelle nur das jobs-Paket; ohne __init__.py,
das cf_estate_sync importiert, wird kein Job registriert (Sync-Warnung
'No jobs were registered on loading the bf_infra.jobs submodule').

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-09 11:50:33 +02:00
6f60e03679 TP44 Teil B: CF-Estate-Sync als Nautobot-Job (ORM, aus Git-Datenquelle)
jobs/cf_estate_sync.py — kanonische Runtime des CF→Nautobot-Sync als
geplanter Nautobot-Job im vorhandenen nautobot-worker (kein neuer
Container, keine Nautobot-Exposure). Portierung der Reconcile-Logik aus
nautobot/tp44-cf-sync.py von REST auf ORM:
- ID-Matching (tunnel_id/app-id/script/service_id), extra_config-Merge
- Prefix-Assignments live aus teamnet/routes (subsumiert Seeder [7])
- Verwaisung = stale-Markierung statt Loeschen, Scope-sicher uebersprungen
- CF-Token aus Nautobot-Secret 'cf-api-token', dryrun-BooleanVar default True

Import im Worker verifiziert (IMPORT_OK), CF-Egress vom Worker bestaetigt.
Governance: periodische externe→Nautobot-Syncs = Jobs hier, kein per-Task-Container.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-09 11:47:55 +02:00
2f4866ca9a TP44 Teil B: CF-API→Nautobot-Sync (WIP, Dry-Run verifiziert)
nautobot/tp44-cf-sync.py — periodischer Live-Pull der CF-Estate nach
Nautobot (ersetzt den Inline-Snapshot des Seeders). Reuse: api() aus
caddy/cf-sync.py, Nautobot-Helper des Seeders.

- ID-Matching (tunnel_id/app-id/script/service_id) statt Name → rename-fest,
  keine Duplikate
- Merge statt Replace → kuratierte extra_config-Keys bleiben
- Verwaisung: extra_config.stale=true statt Hard-Delete; sicher
  uebersprungen, solange Token-Scope unvollstaendig
- 403-tolerant: deckt die 15 lesbaren Objekte driftfrei ab, zieht
  Hyperdrive/VPC automatisch mit, sobald Token-Scope da ist

Dry-Run: 11 Services unveraendert, 4 Networks Enrichment, 0 Duplikate.
Offen: Token-Scope (Hyperdrive+VPC) erweitern, dann Full-Sync + Cron-Host.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-08 20:43:35 +02:00
8e41268b4b TP44 Etappe 2 Teil A durch: IPAM-Prefixe live, Prosa nachgezogen
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>
2026-09-08 19:50:58 +02:00
b915d02a82 TP44 Etappe 2 Teil A: Seeder für die zwei fehlenden IPAM-Prefixe
nautobot/tp44-ipam-prefixes.py — idempotenter get-or-create für
10.40.0.0/16 (container, Route bf-core-mesh) und 10.101.0.0/24
(network, Route fm.emsenhuber.net). Dry-Run default, --commit schreibt.
Nach dem Anlegen zieht tp44-cf-estate-seed.py Schritt [7] die zwei
cloud-network-prefix-assignments automatisch ein. Muster:
ingest-baseline.py / tp37-substrat-seed.py. Noch nicht gegen Nautobot
ausgeführt (nur Dry-Run verifiziert).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-08 19:48:26 +02:00
efb03979a0 TP34 verworfen: Prosa-Abschnitt ins Archiv verschoben
Caddyfile-via-GC-Ansatz zurückgezogen (Gitea #24 status:dropped, closed).
Caddyfile bleibt manuell in caddy/Caddyfile. Volltext-Abschnitt aus
teilprojekte.md ins Archiv gezogen (fortschreiben-nicht-überschreiben:
datierter Verworfen-Nachtrag oben, Konzepttext unverändert darunter),
plus TOC-Zeile.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-08 16:31:22 +02:00
268fd859ab TP44: cf-tunnel-mapping §0 Live-Kopf + §10-16 als ARCHIV eingeklappt
Doku-Drift behoben: §10-15 beschrieben das 3-Tunnel-HA bf-mm/bf-nas/bf-pve,
das seit dem TP16.3-Cutover (2026-08-27) nicht mehr existiert und eine
Folgesession zu halluzinierten Tunneln/FQDNs verleitet hatte. Neuer §0 mit
dem live gegen die CF-API gemessenen Ist-Stand (bf-public/fm/terpene-db +
warp_connector bf-core-mesh, WARP-Routen); §10-16 in <details> ARCHIV
gekapselt (Inhalt unverändert), §17 (terpene-db, aktuell) bleibt sichtbar;
§14 Mesh-live-Notiz. Deckt sich mit dem Nautobot-Seed (TP44).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-08 15:50:31 +02:00
7a20a1db4f TP37 P2 vervollständigt: +6 live-verifizierte Smart-Home-ipam.Services
Fehlende exponierte Dienste ergänzt (RaspberryMatic 80/443/2001/2010,
iob-master 8081, z2m25 8080). Jeder Port per Socket-Probe belegt (nicht
aus Doku geraten); nc -z lieferte falsch-negativ und wurde verworfen.
iob-exposed/iob_slave bewusst ohne Service (kein Port gefunden).
Nautobot: 20 -> 26 ipam.Services, idempotent. Compliance 140/140.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-08 15:12:33 +02:00
bca8f6e27e TP34 zurückgezogen: Caddyfile via GC verworfen
Session lief auf veralteten Annahmen (Hostname terpene.* statt 420.*, zweiter
CF-Token erfunden) — entgegen dem User-Constraint "raten verboten". 420.teilzeitladen.xyz
ist ein Cloudflare-Worker (Projekt blaueblueten), nicht ein Caddy-Backend; :8890 gehoert
zu terpene.* via Tunnel bf-mm. Caddyfile war netto unveraendert, nur die beiden neuen
Skripte werden entfernt. Live LXC 130 ist bereits Baseline (e96fca5), Nautobot fuer TP34
unberuehrt (nur Dry-Run). Uebergabe: ~/.claude/plans/tp37-p2-seeden-dienste-silly-lerdorf.md

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-08 14:00:02 +02:00
d63dc7bb78 TP34: 420.teilzeitladen.xyz-Caddy-Block wieder entfernt
teilzeitladen.xyz liegt NICHT im emsenhuber.net-CF-Account (live geprueft: der
CF_DNS_API_TOKEN sieht nur die Zone emsenhuber.net, teilzeitladen.xyz count=0).
Damit kann Caddy auf LXC 130 kein DNS-01-Zert fuer den Namen holen -> Dauer-ACME-
Fehlerschleife. 420.teilzeitladen.xyz bleibt beim Cloudflare-Worker (cf-tunnel-mapping §17).

Ein Caddy-Backend fuer 420 braucht einen DNS-Token aus dem teilzeitladen.xyz-CF-Account
(blaueblueten-Projekt) — separat, nicht Teil von bf-infra. Seeder/Renderer bleiben.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-08 13:36:33 +02:00
b200401c5a TP34: 420.teilzeitladen.xyz korrigiert (war terpene.*) + eigener DNS-Token
- caddy/Caddyfile: Hostname 420.teilzeitladen.xyz (nicht terpene.*); eigener
  per-site tls-Block mit CF_DNS_API_TOKEN_TEILZEITLADEN, damit der enge
  emsenhuber.net-ACME-Token unangetastet bleibt (Least-Privilege)
- nautobot/tp34-caddy-cf-seed.py: veraltete terpene.*-Referenz im Kommentar korrigiert

Deploy erst nach Hinterlegen des teilzeitladen.xyz-Tokens in /etc/caddy/caddy.env
(Zone:DNS:Edit nur teilzeitladen.xyz).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-08 13:30:30 +02:00
384f356290 TP34: terpene Quick-Win + Caddy-CF-Seeder + Renderer
- caddy/Caddyfile: terpene.teilzeitladen.xyz → 10.40.20.167:8890 (Quick-Win Schritt 0)
- nautobot/tp34-caddy-cf-seed.py: legt CustomFields caddy_fqdn/caddy_group auf
  ipam.Service an und setzt Werte fuer die 9 Routen mit vorhandenem Service-Objekt
- nautobot/tp34-caddy-render.py: rendert Caddyfile aus Nautobot, Diff gegen
  caddy/Caddyfile, optionaler Deploy via pct push + caddy reload

Deploy-Auflage fuer den terpene-Block:
  pct push 130 caddy/Caddyfile /etc/caddy/Caddyfile
  ssh root@10.40.20.40 "caddy reload --config /etc/caddy/Caddyfile"
(Plus CF-Tunnel-Route fuer terpene.teilzeitladen.xyz pruefen)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-09-08 11:48:18 +02:00
e96fca5a52 Merge branch 'main' of https://gitea.emsenhuber.net/admin/bf-infra 2026-09-07 17:20:38 +02:00
1625c30fd7 Merge tp37-dienste: TP37 P1+P2 durch
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-09-07 17:20:04 +02:00
83fd69ef8d TP37 P1+P2: VirtualMachines + ipam.Service seeden
P1 (tp37-substrat-seed.py): idempotenter Seeder fuer 3 ClusterTypes,
3 Clusters, 28 VirtualMachines mit eth0/IPAddress/primary_ip4.
Schon aus dem Worktree ausgefuehrt -- Skript damit in main nachgezogen.

P2 (tp37-dienste-seed.py): 20 ipam.Service-Eintraege angelegt:
Caddy :80/:443, Caddy-Backends (haos/vaultwarden/gitea/n8n),
Nautobot :8080, AdGuard :53 TCP+UDP (bf1+bf2), platform-pg :5432,
mariadb :3306, influxdb2 :8086, mqtt5 :1883, portainer :9443,
pve-mcp/shelly-mcp/n8n-mcp/gitea-mcp.
Compliance-Gegenprobe: 140/140 unveraendert.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-09-07 17:19:59 +02:00
56746cb24d TP37 P1: Substrat-Seeder — Hosts/Container als native VMs in Nautobot
Idempotenter Seeder: 3 ClusterTypes (Proxmox VE/Synology Docker/Docker
Desktop), 3 Clusters (pve/nas-bf/macmini), 28 VirtualMachines mit
primary_ip4 (24 macvlan-IPs; macmini 4 host-geteilt). Native Modelle,
keine App (konsistent TP44). Live 2026-09-07, Compliance 140/140 / 0 Drift.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-07 14:02:35 +02:00
a0ba87d555 TP36 A4/A5/A6: Index/Status-SSoT-Cutover nach Gitea abgeschlossen
- 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>
2026-09-07 13:30:24 +02:00
674e5fff0d TP36 (reframed): Gitea-TP-Sync — Index/Status als SSoT nach Gitea
- bin/gitea-tp-sync.py: idempotenter Sync teilprojekte.md-Quick-Index +
  Archiv-Header -> Gitea Issues (admin/bf-infra), Labels status:* + thema:*
- Erstlauf: 68 Issues (25 open / 43 closed) + 15 Labels angelegt
- Token aus ~/.hermes/.env (nie ausgegeben); Dry-Run default, --commit schreibt

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-07 11:29:34 +02:00
c024f85579 TP44 nachgezogen + TP37/34/36-Plan (native Modelle, erst planen)
- Seeder tp36-cf-estate-seed.py -> tp44-cf-estate-seed.py (+ Referenzen, Docstring)
- teilprojekte.md: TP44 Quick-Index + Abschnitt (Anker), Ist-Stand 09-06,
  TP34/36/37 auf korrigierten Stand (TP37 P3 via TP44 erledigt; P1+2 offen)
- Plan-Runbook handoff-20260906-tp37-34-36-plan.md (native Modelle, Compliance-Gegenprobe)
- 09-02-Handoff + cf-tunnel-mapping: Referenzen/TODOs nachgezogen
- TP23-Quick-Index-Zeile (fremde, korrekte Aenderung) auf User-Okay mit uebernommen

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-06 22:32:20 +02:00
9caf145341 TP23: Stufe-6-Runbook (DNS-Bypass-Sperre) mit hartem Vor-Ort-Gate
- 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>
2026-09-06 17:20:11 +02:00
40 changed files with 3477 additions and 895 deletions

4
.gitignore vendored
View File

@@ -1,10 +1,6 @@
.DS_Store
.secrets
# Per-Projekt-MCP-Configs: können Tokens/URLs enthalten, projekt-spezifisch, nicht ins Repo
.mcp.json
# Python bytecode
__pycache__/
*.pyc

67
.mcp.json Normal file
View File

@@ -0,0 +1,67 @@
{
"mcpServers": {
"home-assistant": {
"type": "http",
"url": "${MCP_HOME_ASSISTANT_URL}"
},
"mikromcp": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"mikromcp",
"serve"
],
"env": {
"MIKROMCP_CONFIG_PATH": "/Users/christophemsenhuber/dev/bf-infra/mcp/mikromcp/config/routers.yaml",
"MIKROMCP_DEFAULT_ROUTER": "ap1",
"ROUTER_AP1_USER": "admin",
"ROUTER_AP1_PASS": "${MCP_MIKROMCP_ROUTER_AP1_PASS}",
"ROUTER_AP2_USER": "admin",
"ROUTER_AP2_PASS": "${MCP_MIKROMCP_ROUTER_AP2_PASS}",
"CRS326_CORE_USER": "admin",
"CRS326_CORE_PASS": "${MCP_MIKROMCP_CRS326_CORE_PASS}",
"CRS326_BRANCH_USER": "admin",
"CRS326_BRANCH_PASS": "${MCP_MIKROMCP_CRS326_BRANCH_PASS}",
"ROUTER_AP3_USER": "admin",
"ROUTER_AP3_PASS": "${MCP_MIKROMCP_ROUTER_AP3_PASS}"
}
},
"hostinger-api": {
"alwaysLoad": true,
"type": "stdio",
"command": "hostinger-api-mcp",
"args": [],
"env": {
"HOSTINGER_API_TOKEN": "${MCP_HOSTINGER_API_TOKEN}"
}
},
"cloudflare": {
"alwaysLoad": true,
"type": "http",
"url": "https://mcp.cloudflare.com/mcp"
},
"ollama": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"ollama-mcp"
],
"env": {
"OLLAMA_HOST": "http://127.0.0.1:11434"
}
},
"pve-mcp": {
"type": "http",
"url": "http://10.40.20.173:3000/"
},
"n8n-mcp": {
"type": "http",
"url": "http://10.40.20.167:3001/mcp",
"headers": {
"Authorization": "Bearer ${N8N_MCP_BEARER}"
}
}
}
}

View File

@@ -6,7 +6,7 @@ DNS/DHCP-Ablösung, WLAN via **CAPsMAN auf dem Core** (TP28, 2026-08-17 — der
## Pflichtlektüre pro Sitzung (Reihenfolge)
1. **`docs/teilprojekte.md`** (Quick-Index-Block) — kanonischer Stand, Scope, Abhängigkeiten, **offene** TPs. **1 Read reicht.**
1. **Status/Index = Gitea-Board** (seit TP36-Cutover 2026-09-07): [`admin/bf-infra` · Issues](https://gitea.emsenhuber.net/admin/bf-infra/issues) — TP = Issue, Status = Label `status:*`, Gruppierung = `thema:*`. Für den **Detail/Kontext** eines TP dann den `### TPnn`-Prosa-Abschnitt in **`docs/teilprojekte.md`** (aktiv) bzw. **`docs/teilprojekte-archiv.md`** lesen. *(Die frühere „Quick-Index-Block, 1 Read reicht"-Zeile ist überholt — Index/Status stehen nicht mehr in der Datei.)*
2. **`docs/handoff-*.md`** (neueste) — wo die letzte Session aufgehört hat.
3. Bei Live-Writes oder Inventur: **`docs/cf-tunnel-mapping.md`**, **`docs/teilprojekte-archiv.md`**.
4. ✅ **TP16.3 §5 durch (2026-09-01):** [`docs/handoff-20260901-tp16.3-paragraph5-flip-durch.md`](docs/handoff-20260901-tp16.3-paragraph5-flip-durch.md)
@@ -20,6 +20,12 @@ DNS/DHCP-Ablösung, WLAN via **CAPsMAN auf dem Core** (TP28, 2026-08-17 — der
am 09-01 zurueckgebaut; Hebel 2–4 entfallen, **kein Geraete-Write** (Soll stand: `ft=yes ft-over-ds=yes`,
**Compliance 140/140**). **Am 2026-09-04 hat Christoph `ft=no` auf `sec-main` als Dauerzustand
entschieden** (Hebel 2 doch gezogen: Template + bf-golden-config + Nautobot-Sync, `wifi-security` gruen).
⚠️ **Rueckgenommen am 2026-09-14 (Terrasse-In-situ-Session): `ft=yes ft-over-ds=yes` zurueck** — mit
`ft=no` war jeder Roam eine Voll-Reassoziation, darin starben 2 Anrufe; Rueckkehrstand = Fund-E-Known-Good
von 09-02 (ruhig auf 7.24.1). Weg: Template + `push-gc-template.py` + `gc-configplan.py
--refresh-compliance` + `gc-manual-plan.py --deploy` (Plan `b1135f3e`, Completed) → **140/140, 0 Drifts**;
CAP-Abnahme: **keine** Inline-Overrides auf ap1/ap2/ap3. Commands:
`docs/transaktionen/TP25-ft-yes-secmain.commands.rsc`, s. Handoff 2026-09-14.
🔴 **Nachtrag 09-04: `ft=no` war NICHT uniform.** ap3 trug einen Werks-Inline `security.ft=yes` auf
`wifi1/wifi2` (Bring-up unset `!ft-over-ds`, aber nicht `!ft`; Abnahme zählt nur benannte
security-Objekte → Inline-Wert unsichtbar). Gemischtes FT-ESS → Strong-Signal-Abbrüche (−43/−45 dBm)
@@ -34,15 +40,30 @@ DNS/DHCP-Ablösung, WLAN via **CAPsMAN auf dem Core** (TP28, 2026-08-17 — der
6. ap3-Bring-up 2026-08-30: [`docs/handoff-20260830-ap3.md`](docs/handoff-20260830-ap3.md) — sechs Funde zu Werks-MikroTiks, CAPsMAN und Golden-Config-Lücken.
7. Inventur-Befund 2026-08-27: [`docs/handoff-20260827-inventur-und-architektur.md`](docs/handoff-20260827-inventur-und-architektur.md) — Master-Struktur, Asymmetrie, Drift.
## SSoT & Branch-Konvention (TP36-Cutover 2026-09-07)
- **SSoT-Dreiteilung:** **Index/Status = Gitea-Issues** (`admin/bf-infra`, Labels `status:*`/`thema:*`) ·
**Prosa/Detail = Repo** (`docs/teilprojekte.md` aktiv + `teilprojekte-archiv.md`, `### TPnn`-Abschnitte) ·
**Live-Gerätedaten = Nautobot** (Compliance-Zahl, RouterOS-Version …). Ein Status ändert sich **in Gitea**,
nicht mehr in einer Repo-Datei. Sync-/Abgleich-Werkzeug fürs Archiv: `bin/gitea-tp-sync.py` (Dry-Run default,
Token aus `~/.hermes/.env`, **nie ausgeben**).
- **Branch-Konvention:** Branch `tpNN-kurz` **jederzeit** mitten in der Session möglich (`git switch -c`,
uncommittete Arbeit wandert mit); für Multi-Session-TPs der Normalfall. **Merge nach `main`, sobald der
Code/Config des TP steht.** Weil Steuerungs-Updates nach **Gitea** gehen (nicht in `teilprojekte.md`),
kollidieren TP-Branches nicht mehr auf der Steuerungs-Doku — nur noch der eigene `### TPnn`-Prosa-Abschnitt
wird angefasst.
- **TP anlegen/schließen:** neues aktives TP = **direkt als Gitea-Issue** (Labels setzen), Prosa-Abschnitt
im Repo dazu; abschließen = Issue `closed`, Prosa wandert bei Bedarf ins Archiv. **Keine Handtabelle mehr.**
## Was du sofort wissen musst (Inventur 2026-08-27)
- **`bf-infra`** ist aktiver Master **mit Gitea-Remote**: `origin` = `https://gitea.emsenhuber.net/admin/bf-infra.git` (live verifiziert 2026-08-30). ⚠️ **Die frühere Zeile „lokal, kein Gitea-Remote → verloren bei Festplattencrash" ist überholt** — sie stammt aus der Inventur vom 2026-08-27 und war damals richtig; das Remote existiert seit spätestens 2026-08-28 (`origin/main` = `b917691`). **Die Backup-Lücke ist damit keine Struktur-, sondern eine Disziplinfrage: `git push`.** Am 2026-08-30 lagen vier Commits nur lokal. 🔴 **Das Remote ist nur so viel wert wie der letzte Push** — der Backup-Guard (`~/dev/.bin/backup-guard.sh`, TP35 Schicht 5) bricht Commits ab, solange kein Backup markiert ist; **das ist die Erinnerung ans Pushen, kein Hindernis.** Nicht mit `--no-verify` umgehen. 🔴 **Merkregel:** diese Zeile hat eine Session dazu gebracht, „kein Remote" zu behaupten, statt `git remote -v` zu tippen — vor jeder Aussage über Remotes/Backups **live prüfen**.
- **`admin/bf-network-r6`** (Gitea) ist Archiv, letzte aktive Commits 2026-08-25 → read-only-Header.
- **`admin/bf-golden-config`** (Gitea) ist Bot-Master (Nautobot 2×/Tag), nicht manuell.
- **`admin/bf-golden-config`** (Gitea) ist Bot-Master, nicht manuell. 🔴 **Korrigiert 2026-09-12:** die frühere Angabe „2×/Tag" war nie real — es gab **keinen** Scheduler, Backup/Intended/Compliance liefen nur manuell aus Sessions (zuletzt 09-04, 8 Tage Stillstand). Jetzt **täglich 03:30 UTC** per ScheduledJob **„GC Backup+Compliance – taeglich"** (Nautobot-Job *Execute All Golden Configuration Jobs - Multiple Device*, Scope `platform=RouterOS`, Reihenfolge Backup→Intended→Compliance). Stand prüfen: `backup_last_success_date` am Gerät bzw. `scheduled-jobs` in Nautobot.
- **`admin/blaueblueten-n8n`** (Gitea) ist Master für terpene-Repo.
- **`inventory/` ist tot** (Pipeline seit 2025-06 stale). Live-Daten aus MikroMCP/CF/Portainer.
- **`mcp/INVENTORY.md`** ist BF-Netz-SSoT; `~/.claude.json`/`opencode.jsonc` sind globalere Werkzeugkästen.
- **terpene.teilzeitladen.xyz**: Worker läuft auf Mac mini (`10.40.20.167:8890`), **kein Caddy-Block, kein CF-Tunnel** — Backfill via DB-Migration blockiert (Handoff 2026-08-27).
- **Terpenfinder = `420.teilzeitladen.xyz`** (CF-Worker, Repo `admin/blaueblueten-n8n`, hinter CF Access), **kein Caddy, kein Mac mini im Pfad**. `terpene.*` **existiert nicht und soll es nicht** (live geprüft 2026-09-10). Einziger terpene-benannter CF-Gegenstand: der **interne** Tunnel `terpene-db` (`f2d2fc8a`, ohne öffentlichen Hostname, Hyperdrive→VPC→Postgres, s. `docs/cf-tunnel-mapping.md` §17). ⚠️ **Grenze:** blaueblüten ist ein eigenes Projekt — nicht anfassen. *(Die frühere „terpene.teilzeitladen.xyz:8890 via Tunnel"-Zeile war veraltet — bf-mm ist gelöscht.)*
- **shelly-mcp / portainer-mcp bewusst NICHT als MCP-Client** (User-Direktive 2026-08-28): shelly-mcp-Container auf DS923 wird via **Portainer-API** (Skript-Aufrufe, `mcp/portainer/.env` als Token-Quelle) deployt, nicht via MCP-Protokoll. Inventar-Eintrag spiegelt das. `mcp-host-policy.md` ist SSoT für die Host-/IP-Konvention.
- **Mac mini `10.40.20.167`** ist der **n8n-Host** (n8n `:5678`, n8n-redis `:6379`, n8n-mcp `:3001`) — **NICHT** der zentrale MCP-Host. Performance-Überlegung: MCP-Clients würden auf dem macmini (User-Workstation) laufen und die Box zusätzlich belasten; deshalb liegt der MCP-Host auf der **DS923** (`nas-bf`, Portainer Endpoint 14). gitea-mcp läuft aktuell noch auf dem macmini (historisch, eigene Container-Definition dort) — gehört **bei Gelegenheit** auf die DS923 umgezogen (separater Punkt, **nicht** Teil dieser Session). Container-Definitionen für n8n leben auf dem macmini (Docker Desktop); FQDN→Backend-Mapping im `caddy/Caddyfile`.
@@ -50,12 +71,15 @@ DNS/DHCP-Ablösung, WLAN via **CAPsMAN auf dem Core** (TP28, 2026-08-17 — der
Wenn während einer Session ein neues Teilprojekt, eine Abhängigkeit oder ein Querschnittsthema sichtbar wird, das bisher in keinem TP abgebildet ist:
- Vorschlagen und mit dir abstimmen (nicht eigenmächtig anlegen).
- Auf dein Okay hin anlegen: Quick-Index-Zeile + `### TP<n>`-Abschnitt mit Status `🔜`, Scope,
Abhängigkeiten, Abgrenzung. Nächste freie Nummer vergeben (höchste vergebene + 1; Lücken aus
verworfenen TPs bleiben frei).
- Ist-Stand-Block mitziehen (Datum, betroffene Zeilen).
- Auf dein Okay hin anlegen: **Gitea-Issue** `TPnn — <Kurztitel>` mit Labels `status:🔜`(todo) +
passendem `thema:*` + Body (Anriss + Verweis auf den Prosa-Abschnitt) **und** einen
`### TP<n>`-Prosa-Abschnitt in `docs/teilprojekte.md` (Scope, Abhängigkeiten, Abgrenzung).
Nächste freie Nummer vergeben (höchste vergebene + 1; Lücken aus verworfenen TPs bleiben frei).
- **Status/Reihenfolge/„was lief zuletzt" gehen ins Gitea-Issue** (Label ändern, Kommentar), **nicht**
in eine Quick-Index-Tabelle oder einen Ist-Stand-Block — die gibt es seit dem TP36-Cutover (2026-09-07)
nicht mehr in der Datei.
**Abgeschlossene TPs** stehen seit 2026-08-23 in `docs/teilprojekte-archiv.md` (Volltext, unverändert, mit Inhaltsverzeichnis). **Ein TP wandert erst ins Archiv, wenn nichts mehr daran zu tun ist — und wieder zurück, sobald doch etwas dazukommt.** Ein archiviertes TP ist ein *geschlossenes Ticket, kein versiegeltes*: bei neuer Arbeit an derselben Baustelle wandert der **Volltext zurück** nach `teilprojekte.md` (Zeiger bleibt im Archiv), **kein** Zwillings-TP mit neuer Nummer (Christoph-Direktive 2026-08-30, erster Fall TP28/`ap3`) — und der **Ist-Stand-Block wird bei jeder Änderung mitgezogen**, nicht nur der betroffene TP-Abschnitt.
**Abgeschlossene TPs** stehen seit 2026-08-23 in `docs/teilprojekte-archiv.md` (Volltext, unverändert, mit Inhaltsverzeichnis) und ihr Gitea-Issue ist `closed` (Label `status:✅`/`❌`). **Ein TP wandert erst ins Archiv, wenn nichts mehr daran zu tun ist — und wieder zurück, sobald doch etwas dazukommt** (Issue dann `reopen`). Ein archiviertes TP ist ein *geschlossenes Ticket, kein versiegeltes*: bei neuer Arbeit an derselben Baustelle wandert der **Volltext zurück** nach `teilprojekte.md` (Zeiger bleibt im Archiv), **kein** Zwillings-TP mit neuer Nummer (Christoph-Direktive 2026-08-30, erster Fall TP28/`ap3`) — nur noch der betroffene `### TPnn`-Prosa-Abschnitt wird angefasst.
---
@@ -80,11 +104,11 @@ GW je VLAN = `.1` (crs326-core L3) · Mgmt VLAN99: core `.99.1`, branch `.99.2`,
|---|---|---|
| ~~ALLNET Core-Switch (sw1)~~ | — | ❌ **außer Betrieb (2026-08-08)** — durch `crs326-core` (L3-Router + Core-Switch, Technik UG) ersetzt; physisch abgelöst. (Telnet-Runner `switch/` = nur noch historisch.) |
| ~~Omada Access-Switch (sw2)~~ | — | ❌ **abgebaut 2026-07-23** (TP15 Branch-Tausch) — durch `crs326-branch` in Technik OG ersetzt, physisch entfernt |
| **crs326-branch** (CRS326, Technik OG) | **10.40.99.2** (VLAN99) · Bootstrap Rev4 2026-08-08 | RouterOS **7.24.1** · `admin`/`~/.secrets` (`CRS326_BRANCH_*`) · REST `http://10.40.99.2/rest` · MikroMCP `crs326-branch` ✅ **live** (2026-08-16 verifiziert) · **TP15 ✅: ersetzt sw2** (L2-Switch), volle Portbelegung (ether1 Uplink-Trunk, 2/8 NAS, 3 Drucker, 4 Dock, 5/6 Sonos, 7 macmini, 24 ap2) · sw-id RGZJ-UK0T, MAC 04:F4:1C:B4:15:58 |
| **crs326-branch** (CRS326, Technik OG) | **10.40.99.2** (VLAN99) · Bootstrap Rev4 2026-08-08 | RouterOS **7.24.1** · `admin`/`~/.secrets` (`CRS326_BRANCH_*`) · REST `http://10.40.99.2/rest` · MikroMCP `crs326-branch` ✅ **live** (2026-08-16 verifiziert) · **TP15 ✅: ersetzt sw2** (L2-Switch), volle Portbelegung (ether1 Uplink-Trunk, 2/8 NAS, 3 Drucker, 4 Dock, 5/6 Sonos, 7 macmini, 24 ap3) · sw-id RGZJ-UK0T, MAC 04:F4:1C:B4:15:58 |
| **crs326-core** (CRS326, Technik UG) | **10.40.99.1** (VLAN99-SVI = L3-GW; same-subnet-Fallback `10.40.10.1`) · Identity `crs326-core` | RouterOS **7.24.1** · `admin`/`~/.secrets` (`CRS326_CORE_*`) · MikroMCP routerId `crs326-core` ✅ **live** (2026-08-16 verifiziert) · **TP15/TP21.1 ✅ 2026-08-08: PRODUKTIVER L3-Router** (ersetzt ap1) — Routing/DHCP (7 Server + 54 Leases)/DNS (**DoH zum CF-Gateway mit `verify-doh-cert=yes`**, TP23 Stufe 1 ✅ 2026-08-18; `servers=1.1.1.1` nur noch Bootstrap) · **NTP-Server für den Standort**/NAT/WG-Hub (fm+dw live); WAN `vlan100`=Liwest `90.146.33.177` · sw-id 4W04-URHT, MAC 04:F4:1C:B4:17:76 |
| hAP ax² #1 (ap1) | **10.40.99.11** (VLAN99) · Identity `ap1` | RouterOS **7.24.1** · `admin`/`~/.secrets` (`ROUTER_AP1_*`) · REST `http://10.40.99.11/rest` · MikroMCP `ap1` ✅ live · **TP28 ✅ 2026-08-17: reiner CAP** (Manager = `crs326-core`) · 🔴 **FUNKSTILL seit 2026-08-30**: keine Provisioning-Regel am Manager, weil ap3 daneben steht und denselben Kanal 5180 fährt. Gerät bleibt erreichbar. Beim Umzug ans Sideboard → `5260/Ce` (Band B, DFS) und Uplink auf `core ether3` — Uplink `ether1` (PoE-Port, `poe-out=off`) an crs326-core `ether15`; SSIDs/Kanäle kommen vom Manager, ch36/ch1 · MAC D0:EA:11:4D:40:E0 · Config-Referenz `routeros/.secrets/ap1-prov-base.rsc` |
| hAP ax² #2 (ap2) | **10.40.99.12** (VLAN99) · Identity `ap2` | RouterOS **7.24.1** · `admin`/`~/.secrets` (`ROUTER_AP2_*`) · REST `http://10.40.99.12/rest` · MikroMCP `ap2` · **TP28 ✅ 2026-08-17: reiner CAP** — Uplink `ether1` (PoE) an crs326-branch `ether24`; ch44/ch11 (TP25: ch149 war unter ETSI leistungsbegrenzt) · MAC D0:EA:11:4D:40:3A · Config `routeros/.secrets/ap2-prov-base.rsc` |
| **cAP ax (ap3)** | **10.40.99.13** (VLAN99) · Identity `ap3` | ✅ **LIVE seit 2026-08-30** (TP28-Nachtrag) · `cAPGi-5HaxD2HaxD`, RouterOS **7.24.1** + RouterBOOT 7.24.1 (**seit 2026-08-31 ist die ganze Flotte auf 7.24.1**, TP27-Angleichung erledigt) · reiner CAP, Manager `crs326-core` · Uplink `ether1` → **core `ether21`** (Trunk) · Kanäle **`5180/ax/Ce/I`** (5 GHz) + **`2437/ax`** (ch6) nach TP25-Plan · 🔴 **nur 2 Ethernet-Ports** (`ether1` PoE-in, `ether2` PoE-out, **kein** Bridge-Port) → `ap.extra_ports=[]` · `device-mode=basic` (scheduler/fetch/romon **erlaubt**, anders als ap1/ap2) · Dateien `routeros/tp28-ap3-phase{1,2}-*.rsc` + `-service-accounts.rsc` + `-werksreste.rsc` |
| hAP ax² #1 (ap1) | **10.40.99.11** (VLAN99) · Identity `ap1` | RouterOS **7.24.1** · `admin`/`~/.secrets` (`ROUTER_AP1_*`) · REST `http://10.40.99.11/rest` · MikroMCP `ap1` ✅ live · **TP28 ✅ 2026-08-17: reiner CAP** (Manager = `crs326-core`) · ✅ **aktiv am Sideboard** (Wohnzimmer; Uplink `ether1` → core `ether3`, PoE-Port `poe-out=off`) — Kanäle `5260/Ce` (Band B, DFS, Fallback 5280) + `2412`/ch1, vom Manager · MAC D0:EA:11:4D:40:E0 · Config-Referenz `routeros/.secrets/ap1-prov-base.rsc` |
| hAP ax² #2 (ap2) | **10.40.99.12** (VLAN99) · Identity `ap2` | RouterOS **7.24.1** · `admin`/`~/.secrets` (`ROUTER_AP2_*`) · REST `http://10.40.99.12/rest` · MikroMCP `ap2` · **TP28 ✅ 2026-08-17: reiner CAP** — **Technik UG**, Uplink `ether1` (PoE) an core `ether21`; Kanäle `5300/Ce` (Band B, DFS, Fallback 5320) + `2462`/ch11 · MAC D0:EA:11:4D:40:39 (ether1; Bridge/Mgmt `:3A`) · Config `routeros/.secrets/ap2-prov-base.rsc` |
| **cAP ax (ap3)** | **10.40.99.13** (VLAN99) · Identity `ap3` | ✅ **LIVE seit 2026-08-30** (TP28-Nachtrag) · `cAPGi-5HaxD2HaxD`, RouterOS **7.24.1** + RouterBOOT 7.24.1 (**seit 2026-08-31 ist die ganze Flotte auf 7.24.1**, TP27-Angleichung erledigt) · reiner CAP, Manager `crs326-core` · **Technik OG**, Uplink `ether1` → **branch `ether24`** (Trunk) · Kanäle **`5180/ax`** (Band A, non-DFS, 5 GHz) + **`2437`** (ch6) nach TP25-Plan · 🔴 **nur 2 Ethernet-Ports** (`ether1` PoE-in, `ether2` PoE-out, **kein** Bridge-Port) → `ap.extra_ports=[]` · `device-mode=basic` (scheduler/fetch/romon **erlaubt**, anders als ap1/ap2) · Dateien `routeros/tp28-ap3-phase{1,2}-*.rsc` + `-service-accounts.rsc` + `-werksreste.rsc` |
| **🔑 Einheitliches Admin-PW (2026-08-08)** | alle 4 MikroTik (core/branch/ap1/ap2) | user `admin`, gleiches PW (`~/.secrets/credentials.env` → `ROUTER_*_PASS`/`CRS326_*_PASS`; „Überlebensversicherung", User-Vorgabe). Werks-Defaults ap1/ap2 damit obsolet. |
| NAS (nas-bf, DS923) | 10.40.20.10 | SSH `adm.christoph@10.40.20.10` (kein PW nötig) · Docker (Portainer endpointId=14) |
| platform-pg (LXC 105, pve) | 10.40.20.20 | SSH via pve (`pct exec 105 --`) · **TP20 ✅ 2026-07-16: PG16, DB `nautobot`, Creds `postgres/.secrets`** |
@@ -258,7 +282,7 @@ GW je VLAN = `.1` (crs326-core L3) · Mgmt VLAN99: core `.99.1`, branch `.99.2`,
danach die Ports gegen vorher vergleichen**, sonst verliert man still einen Dienst.
- **VLAN20-Docker-Hosts: Host-DNS nach dem Umzug prüfen (2026-07-10, TP14.2a):** NAS + pve-LXC zeigten `/etc/resolv.conf` noch auf totes `.41.254` → `docker pull` ghcr scheitert (`EAI_AGAIN`, aber Egress ok!). Fix = `.20.1`: LXC `pct set 400 --nameserver 10.40.20.1`; **Synology-Falle: DSM-„Allgemein"-DNS ≠ was `dockerd` liest** — Interface zieht DNS per DHCP → Fix an der *Netzwerkschnittstelle* „DNS manuell". Laufende Container frieren den `127.0.0.11`-Upstream zum Erstellzeitpunkt ein (Recreate nötig). Merkregel: `docker-pull-hängt` + `dns.lookup EAI_AGAIN` aber `TCP zu ghcr-IP:443 ok` = toter Resolver, nicht Egress.
- 📜 **~~ALLNET VLAN-DB (TP1)~~ — historisch.** Die VLAN-Semantik gilt weiter (**40=MEDIA, 50=UNTRUSTED**), die Portangaben (GE1/GE2/GE8) beziehen sich auf ein ausgebautes Gerät.
- **ap2 hängt an `crs326-branch ether24`** (Trunk, native VLAN1 + tagged 10-99); **branch-Uplink `ether1` → `crs326-core ether8`** (korrigiert 2026-08-16 — die frühere Angabe „→ sw1 GE8" stammt aus der Zeit vor dem Core-Tausch; MAC-hart belegt in TP22 Schritt 5).
- **ap3 hängt an `crs326-branch ether24`** (Trunk, native VLAN1 + tagged 10-99); **branch-Uplink `ether1` → `crs326-core ether8`** (korrigiert 2026-08-16 — die frühere Angabe „→ sw1 GE8" stammt aus der Zeit vor dem Core-Tausch; MAC-hart belegt in TP22 Schritt 5). ap2 hängt seit dem TP25-Tausch (2026-09-15) an `core ether21` (Technik UG), ap1 an `core ether3` (Sideboard).
- **Mesh = NEIN** (beide APs haben wired Trunk-Uplink → Loop-Risiko).
- **Beide APs = CAPs, Manager ist `crs326-core` (TP28 ✅ 2026-08-17).** Der Entscheid „kein CAPsMAN" von 2026-07-22 ist **revidiert**: er galt der Konstellation ap1=Manager+AP, in der ein Manager seine eigenen Radios nicht provisionieren kann — mit dem Core als Manager sind beide APs symmetrisch. Der Core braucht dafür **kein** `wifi-qcom`, `capsman` steckt im Basispaket.
- 🔴 **`/interface wifi scan` geht am CAP NICHT — nur am Manager** (Fund 2026-08-23). Das Gerät

18
__init__.py Normal file
View File

@@ -0,0 +1,18 @@
"""Macht die bf-infra-Repo-Wurzel zu einem regulären Python-Paket.
🔴 LOAD-BEARING — NICHT löschen (sonst laden die Nautobot-Jobs nicht mehr).
Nautobot klont dieses Repo nach GIT_ROOT/bf_infra/ und lädt Jobs über
`import_modules_privately()` → `pkgutil.walk_packages([GIT_ROOT])`. walk_packages
entdeckt ausschließlich *reguläre* Pakete (mit __init__.py), niemals
Namespace-Packages (Verzeichnisse ohne __init__.py). Ohne diese Datei ist
`bf_infra` für den Loader unsichtbar und `jobs/` wird nie importiert — Symptom:
Git-Sync SUCCESS, aber Log "No jobs were registered on loading the
`bf_infra.jobs` submodule" und kein Job-DB-Eintrag.
Der module_path-Filter des Loaders (["bf_infra","jobs"]) importiert nur
`bf_infra` + `bf_infra.jobs.*`; die übrigen Verzeichnisse (nautobot/, routeros/,
bin/, …) bleiben unangetastet und laufen weiter als Standalone-Skripte.
Verifiziert 2026-09-10 (Nautobot 3.1.7, Python 3.14) — TP44 Teil B.
"""

View File

@@ -71,7 +71,7 @@ dns:
ipset_file: ""
bootstrap_prefer_ipv6: false
upstream_timeout: 10s
private_networks: []
private_<redacted>: []
use_private_ptr_resolvers: true
local_ptr_upstreams: []
use_dns64: false

View File

@@ -27,6 +27,19 @@ Ein VLAN = eine CIDR-Gruppe. Alle nutzen denselben CF-Upstream-Filter; Divergenz
`filtering aus` bei INFRA/MEDIA/MGMT = bewusste Reduktion (Streaming/Server/Mgmt nicht brechen), per Gruppe rückholbar.
## Personen-Clients (Stufe 5 Redesign 2026-09-12) — SSoT für Person→Gerät
Zusätzlich zu den VLAN-CIDR-Gruppen bekommt **jede Person einen eigenen AGH-Client**
(`/control/clients`): `name` = Personenname, `ids` = **alle** Geräte-IPs der Person. Das ist der
**einzige** Ort, an dem Person→Gerät gepflegt wird (kein zweites Mapping-File). Damit:
- wirken Self-Service-Ausnahmen **pro Person**: `@@||domain^$client='Personenname'` statt global;
- filtert `recent-blocked --client <person>` das Query-Log auf **ihre** Geräte;
- bleiben Ausnahmen stabil bei Gerätewechsel (Name statt IP).
🔴 **On-network verifizieren, bevor Stufe 6 scharf geht:** dass AGH `$client=` auf **Allow**-Regeln
(`@@`) in der laufenden Version greift. Fällt der Test negativ aus → Fallback `$client=<ip>|<ip>`
(die Geräte-IPs); `agh-exception.py scoped_rule()` kann beides. Die CIDR-Gruppen (Policy-Grenze)
bleiben unberührt — Personen-Clients tragen **nur** die Ausnahmen.
## Sync-Invariante
AGH **schreibt die YAML beim Restart um** (normalisiert) → **nicht** gegen die Repo-Datei diffen,
sondern **`.36` == `.37`**. Genau das prüft `agh-sync.py check`.
@@ -42,11 +55,16 @@ Referenz-RMW-Implementierung, die D aufruft (Deploy-Weg auf HAOS in Etappe D zu
| Aktion | CLI | AGH-API (RMW) |
|---|---|---|
| Domain global entsperren | `allow-domain <d>` | `GET /control/filtering/status` → +`@@\|\|<d>^` → `POST /control/filtering/set_rules` |
| Entsperrung zurück | `unallow-domain <d>` | dito, Regel entfernen |
| Client entfiltern | `unfilter <ip>` | `GET /control/clients` → Objekt, `filtering_enabled=false` → `POST /control/clients/update` |
| Domain **pro Person** entsperren | `allow-domain <d> --client <person>` | `GET /control/filtering/status` → +`@@\|\|<d>^$client='<person>'` → `POST /control/filtering/set_rules` |
| Domain global entsperren (Admin) | `allow-domain <d>` | dito, ohne `$client` |
| Entsperrung zurück | `unallow-domain <d> [--client <person>]` | dito, exakt dieselbe Regel entfernen |
| „meine Ausnahmen" | `list-exceptions --client <person> --json` | `GET /control/filtering/status`, `@@`-Regeln parsen/filtern |
| „zuletzt geblockt" | `recent-blocked --client <person> --json` | `GET /control/querylog?response_status=blocked`, client-seitig auf Geräte-IPs gefiltert |
| Client entfiltern (grob) | `unfilter <ip>` | `GET /control/clients` → Objekt, `filtering_enabled=false` → `POST /control/clients/update` |
| Client wieder filtern | `refilter <ip>` | dito, zurück auf global |
Reine Regel-/Filter-Logik ist netzunabhängig getestet: `python3 agh-exception.py selftest`.
**Kein Timing in der CLI** — Ablauf/Revert macht der Aufrufer (HA-Timer) und, ab Stufe 6, der
RouterOS-Backstop.

View File

@@ -2,22 +2,37 @@
"""
agh-exception.py — TP23 Stufe 5 Exception-Primitive gegen das AGH-Paar (.36 + .37).
Von der HA-Self-Service-Schicht (rest_command) ODER von Hand aufrufbar. Wirkt IMMER auf
Von der HA-Self-Service-Schicht (shell_command) ODER von Hand aufrufbar. Wirkt IMMER auf
BEIDE Instanzen (kein Sync im Datenpfad). KEIN eigenes Timing — Ablauf/Revert macht der
Aufrufer (HA-Timer) bzw. der RouterOS-Backstop (Stufe 6). Diese CLI ist reines add/remove.
Aufrufer (HA-Timer) bzw. der RouterOS-Backstop (Stufe 6). Diese CLI ist reines add/remove/read.
allow-domain <domain> → user_rules += @@||domain^ (Domain für ALLE entsperren)
unallow-domain <domain> → user_rules -= @@||domain^
unfilter <ip> → Client (dessen ids <ip> enthält) filtering_enabled=false
allow-domain <domain> [--client <name|ip[,ip]>] → user_rules += @@||domain^[$client=…]
unallow-domain <domain> [--client <name|ip[,ip]>] → dieselbe Regel wieder entfernen
list-exceptions [--client <name>] [--json] → alle @@-Regeln, nach Client gruppiert
recent-blocked --client <name|ip[,ip]> [--limit N] [--json]
→ zuletzt geblockte Domains DIESER Person
unfilter <ip> → Client (dessen ids <ip> enthält) filtering_enabled=false (grob!)
refilter <ip> → denselben Client wieder filtern (use_global_settings=true)
status → user_rules + Client-Policy beider Instanzen
--client:
* ein AGH-Client-NAME (empfohlen, stabil bei Gerätewechsel) → Regel bekommt $client='Name',
IPs werden für recent-blocked aus /control/clients (ids) aufgelöst.
* ODER eine/mehrere IP/CIDR, komma-getrennt → $client=<ip>|<ip>, recent-blocked filtert darauf.
ohne --client bei allow/unallow = GLOBAL (für alle) — nur für Admin-Zwecke.
🔴 ANNAHME, on-network zu verifizieren, BEVOR Stufe 6 scharf geht: dass AGH $client= auf
ALLOW-Regeln (@@) in der laufenden Version wirkt. Die Regelkonstruktion steht isoliert in
scoped_rule()/parse_allow_rule() — falls die Syntax abweicht, nur dort anpassen.
Auth: AGH_AUTOMATION_USER/_PASS aus ~/.secrets/credentials.env (nie in argv).
"""
import sys, os, json, base64, urllib.request, urllib.error, pathlib, re
import sys, os, json, base64, urllib.request, urllib.error, urllib.parse, pathlib, re, ipaddress, argparse
DOMAIN_RE = re.compile(r"^(?=.{1,253}$)([a-z0-9](-?[a-z0-9]+)*\.)+[a-z]{2,}$", re.I)
IP_RE = re.compile(r"^\d{1,3}(\.\d{1,3}){3}$")
CIDR_RE = re.compile(r"^\d{1,3}(\.\d{1,3}){3}/\d{1,2}$")
# Ein Client-„spec" ist IP-artig, wenn JEDES komma-Glied IP oder CIDR ist; sonst = Name.
INST = ["10.40.20.36", "10.40.20.37"]
# Creds-Quellen in Reihenfolge: erste, die User+Pass liefert, gewinnt.
@@ -50,14 +65,20 @@ def creds():
sys.exit("AGH_AUTOMATION_USER/_PASS: weder Env noch eine Creds-Datei gefunden")
AUTH = "Basic " + base64.b64encode(":".join(creds()).encode()).decode()
_AUTH = None
def auth_header():
# lazy: erst beim ersten echten API-Call — so bleibt das Modul ohne Creds importier-/testbar.
global _AUTH
if _AUTH is None:
_AUTH = "Basic " + base64.b64encode(":".join(creds()).encode()).decode()
return _AUTH
def api(ip, path, method="GET", body=None):
url = f"http://{ip}{path}"
data = json.dumps(body).encode() if body is not None else None
req = urllib.request.Request(url, data=data, method=method,
headers={"Authorization": AUTH,
headers={"Authorization": auth_header(),
"Content-Type": "application/json"})
try:
with urllib.request.urlopen(req, timeout=8) as r:
@@ -69,26 +90,129 @@ def api(ip, path, method="GET", body=None):
sys.exit(f"{ip} {path} → {e}")
def rule(domain):
return f"@@||{domain}^"
# ---------------------------------------------------------------------------
# Reine Regel-Logik (netzunabhängig, self-testbar). Bei AGH-Syntax-Drift NUR hier anfassen.
# ---------------------------------------------------------------------------
def is_ip_spec(spec):
"""True, wenn spec eine (Komma-)Liste aus lauter IPs/CIDRs ist (→ IP-spec), sonst Name."""
parts = [s.strip() for s in spec.split(",") if s.strip()]
return bool(parts) and all(IP_RE.match(p) or CIDR_RE.match(p) for p in parts)
def allow(domain, remove=False):
def client_modifier(spec):
"""$client-Modifier-Wert für eine Regel. IP-spec → ip|ip ; Name → 'Name' (quoted)."""
if is_ip_spec(spec):
return "|".join(s.strip() for s in spec.split(",") if s.strip())
return "'" + spec.replace("'", "") + "'"
def scoped_rule(domain, client=None):
"""@@||domain^ bzw. @@||domain^$client=… (client = Name oder ip[,ip])."""
base = f"@@||{domain}^"
return base if not client else f"{base}$client={client_modifier(client)}"
_ALLOW_RE = re.compile(r"^@@\|\|(?P<domain>[^\^]+)\^(?:\$client=(?P<client>.+))?$")
def parse_allow_rule(rule):
"""@@-Regel → {'domain':…, 'client': <str oder None>, 'raw': rule} oder None."""
m = _ALLOW_RE.match(rule.strip())
if not m:
return None
return {"domain": m.group("domain"), "client": m.group("client"), "raw": rule.strip()}
def ip_in_specs(ip, specs):
"""Ist ip (aus dem Query-Log) von einer der specs (IP oder CIDR) erfasst?"""
try:
addr = ipaddress.ip_address(ip)
except ValueError:
return False
for s in specs:
s = s.strip()
try:
if "/" in s:
if addr in ipaddress.ip_network(s, strict=False):
return True
elif ip == s:
return True
except ValueError:
continue
return False
# ---------------------------------------------------------------------------
def resolve_client_ips(spec):
"""spec → Liste von IP/CIDR-strings. IP-spec direkt; Name → ids des AGH-Clients (von .36)."""
if is_ip_spec(spec):
return [s.strip() for s in spec.split(",") if s.strip()]
data = api(INST[0], "/control/clients")
for c in data.get("clients", []):
if c.get("name") == spec:
return list(c.get("ids", []))
sys.exit(f"kein AGH-Client mit name={spec!r} (für IP-spec Komma-Liste aus IP/CIDR angeben)")
def allow(domain, client=None, remove=False):
domain = domain.strip().lower()
if not DOMAIN_RE.match(domain):
sys.exit(f"ungültige Domain: {domain!r}")
r = rule(domain)
r = scoped_rule(domain, client)
for ip in INST:
st = api(ip, "/control/filtering/status")
rules = st.get("user_rules", [])
if remove:
rules = [x for x in rules if x != r]
rules = [x for x in rules if x.strip() != r]
elif r not in rules:
rules = rules + [r]
api(ip, "/control/filtering/set_rules", "POST", {"rules": rules})
print(f"{ip}: {'entfernt' if remove else 'gesetzt'} {r} (user_rules={len(rules)})")
def list_exceptions(client=None, as_json=False):
st = api(INST[0], "/control/filtering/status") # .36 == .37 (Invariante, via agh-sync geprüft)
items = []
for raw in st.get("user_rules", []):
p = parse_allow_rule(raw)
if not p:
continue
if client is not None and (p["client"] or "") != client_modifier(client):
continue
items.append(p)
if as_json:
print(json.dumps(items, ensure_ascii=False))
return
if not items:
print("— keine Ausnahmen —"); return
for p in items:
who = p["client"] or "GLOBAL"
print(f" {p['domain']:40} client={who}")
def recent_blocked(client, limit=20, as_json=False):
specs = resolve_client_ips(client)
q = urllib.parse.urlencode({"response_status": "blocked", "limit": max(limit * 8, 100)})
data = api(INST[0], f"/control/querylog?{q}")
seen = {} # domain -> {count, last}
for e in data.get("data", []):
c = e.get("client", "")
if not ip_in_specs(c, specs):
continue
dom = (e.get("question", {}) or {}).get("name", "").rstrip(".").lower()
if not dom:
continue
rec = seen.setdefault(dom, {"domain": dom, "count": 0, "last": e.get("time", "")})
rec["count"] += 1
if e.get("time", "") > rec["last"]:
rec["last"] = e.get("time", "")
out = sorted(seen.values(), key=lambda r: r["last"], reverse=True)[:limit]
if as_json:
print(json.dumps(out, ensure_ascii=False)); return
if not out:
print("— nichts geblockt —"); return
for r in out:
print(f" {r['domain']:40} x{r['count']:<4} {r['last']}")
def set_filter(ip_addr, enabled):
if not IP_RE.match(ip_addr):
sys.exit(f"ungültige IP: {ip_addr!r}")
@@ -117,13 +241,47 @@ def status():
print(f" {c['name']:16} ids={c['ids']} global={c['use_global_settings']} filt={c['filtering_enabled']}")
def _selftest():
"""Netzunabhängiger Test der reinen Regel-Logik."""
assert is_ip_spec("10.40.10.82") and is_ip_spec("10.40.10.82,10.40.10.183")
assert is_ip_spec("10.40.10.0/24") and not is_ip_spec("christoph")
assert scoped_rule("x.com") == "@@||x.com^"
assert scoped_rule("x.com", "10.40.10.82,10.40.10.183") == "@@||x.com^$client=10.40.10.82|10.40.10.183"
assert scoped_rule("x.com", "christoph") == "@@||x.com^$client='christoph'"
p = parse_allow_rule("@@||x.com^$client='christoph'")
assert p and p["domain"] == "x.com" and p["client"] == "'christoph'"
p2 = parse_allow_rule("@@||y.com^")
assert p2 and p2["client"] is None
assert parse_allow_rule("||block.com^") is None
assert ip_in_specs("10.40.10.82", ["10.40.10.82"]) is True
assert ip_in_specs("10.40.10.5", ["10.40.10.0/24"]) is True
assert ip_in_specs("10.40.20.5", ["10.40.10.0/24"]) is False
# round-trip: eine scoped Regel wird von list-exceptions --client wieder getroffen
assert (parse_allow_rule(scoped_rule("z.com", "christoph"))["client"]
== client_modifier("christoph"))
print("selftest OK")
if __name__ == "__main__":
a = sys.argv[1:]
if not a: sys.exit(__doc__)
cmd = a[0]
if cmd == "allow-domain": allow(a[1])
elif cmd == "unallow-domain": allow(a[1], remove=True)
elif cmd == "unfilter": set_filter(a[1], False)
elif cmd == "refilter": set_filter(a[1], True)
elif cmd == "status": status()
else: sys.exit(f"unbekannt: {cmd}\n{__doc__}")
ap = argparse.ArgumentParser(add_help=False)
ap.add_argument("cmd", nargs="?")
ap.add_argument("arg", nargs="?")
ap.add_argument("--client")
ap.add_argument("--permanent", action="store_true") # semantisch = kein Timer; wirkt in HA, nicht hier
ap.add_argument("--limit", type=int, default=20)
ap.add_argument("--json", action="store_true")
a = ap.parse_args()
if not a.cmd:
sys.exit(__doc__)
if a.cmd == "allow-domain": allow(a.arg, a.client)
elif a.cmd == "unallow-domain": allow(a.arg, a.client, remove=True)
elif a.cmd == "list-exceptions": list_exceptions(a.client, a.json)
elif a.cmd == "recent-blocked":
if not a.client: sys.exit("recent-blocked braucht --client <name|ip[,ip]>")
recent_blocked(a.client, a.limit, a.json)
elif a.cmd == "unfilter": set_filter(a.arg, False)
elif a.cmd == "refilter": set_filter(a.arg, True)
elif a.cmd == "status": status()
elif a.cmd == "selftest": _selftest()
else: sys.exit(f"unbekannt: {a.cmd}\n{__doc__}")

View File

@@ -1,63 +1,98 @@
# TP23 Stufe 5 — HA-Self-Service für DNS-Ausnahmen
# TP23 Stufe 5 (Redesign 2026-09-12) — DAU-tauglicher, personenbezogener DNS-Self-Service
Home Assistant (HAOS-VM 100, `10.40.20.105`) gibt eine Ein-Klick-Oberfläche, um eine Domain
temporär (JIT) über das AGH-Paar `.36`/`.37` zu entsperren. Ablauf/Revert nativ per `timer`.
> 🔴 **Status: Bau-Spec, noch nicht deployt.** Die alte Fassung (single-domain, temp-only,
> HA-Neustart bei neuer Domain) war „funktional ein kastriertes Pi-hole" (User-Befund 2026-09-12)
> und ist ersetzt. Bau + Abnahme laufen **on-network** (HAOS `10.40.20.105`, AGH `.36/.37`) — beim
> Anlegen den **home-assistant-best-practices-Skill** konsultieren und via **ha-mcp** in `.storage`
> anlegen (native Helper, `entity_id` statt `device_id`). Diese Datei ist die Repro-/SSoT-Quelle.
**Warum kein `rest_command`:** die AGH-Endpunkte sind read-modify-write (`set_rules` ersetzt die
ganze Liste). HA ruft deshalb die deployte RMW-CLI `agh-exception.py` per `shell_command`.
## Ziel (User-Requirements 2026-09-12)
Ein **einfaches, klar verständliches** End-User-UI zum Entsperren:
- **alles was den Nutzer betrifft, nichts** von anderen / Admin / Power-User;
- Policy nur sichtbar, wo sie für den einfachen Nutzer Relevanz hat.
## Bausteine (alle in HA .storage, via ha-mcp angelegt — keine YAML außer shell_command)
| Typ | entity_id | Zweck |
| # | Requirement | Umsetzung |
|---|---|---|
| input_text | `input_text.dns_ausnahme_domain` | einzugebende Domain |
| input_text | `input_text.dns_ausnahme_aktiv` | aktuell aktive Ausnahme (für leak-freien Revert; init `""`) |
| input_select | `input_select.dns_ausnahme_dauer` | 15 Minuten / 1 Stunde / 4 Stunden |
| timer | `timer.dns_ausnahme` | JIT-Countdown (restore=false) |
| input_button | `input_button.dns_ausnahme_starten` | Auslöser |
| automation | `automation.dns_ausnahme_starten` | Button → validieren, alte Ausnahme aufräumen, `agh_allow_domain`, Timer starten |
| automation | `automation.dns_ausnahme_ablauf` | `timer.finished`/`timer.cancelled` → `agh_unallow_domain`, `_aktiv` leeren |
| 1 | **Pro Person** (Login), Sicht über alle Geräte | HA-User = Person; Person → AGH-Client (Name), dessen `ids` = ihre Geräte-IPs |
| 2 | **„zuletzt geblockt" → 1 Klick** | `recent-blocked --client <person>` aus dem AGH-Query-Log, auf die Geräte der Person gefiltert |
| 3 | **temporär UND dauerhaft**, Modus umschaltbar | Dauer-Select inkl. „dauerhaft"; `input_boolean` self-permanent ⇄ Anfrage. **Start: self-permanent** |
| 4 | **HA-Dashboard, scoped** pro Person | ein View je Person, nur für ihre HA-User-ID sichtbar |
## `configuration.yaml` (der einzige YAML-Teil, Backup `.bak-tp23-*`)
## Identitätsmodell — AGH-Client je Person ist die SSoT
- Pro Person **ein AGH-Client** (`/control/clients`), `name` = Personenname, `ids` = **alle** Geräte-IPs
der Person (die per DHCP faktisch statisch sind). Damit ist Person→Gerät **an einem Ort** gepflegt
(kein zweites Mapping-File), und Ausnahmen sind stabil bei Gerätewechsel.
- Ausnahme-Regel = `@@||domain^$client='Personenname'` (statt globalem `@@||domain^`).
🔴 **Vor Scharfschalten on-network verifizieren, dass AGH `$client=` auf `@@`-Regeln wirkt**
(s. `agh-exception.py` Kopf). Fällt der Test negativ aus: Fallback = `$client=<ip>|<ip>` mit den
Geräte-IPs statt dem Namen (Code kann beides, `scoped_rule()`).
- Die bestehenden **VLAN-CIDR-Gruppen** bleiben die Policy-Grenze (Filter an/aus je VLAN);
Personen-Clients sind spezifischer und tragen nur die *Ausnahmen*.
## CLI (deployt nach `/config/agh-exception.py`, wirkt auf `.36`+`.37`)
```
allow-domain <domain> --client <person> # Ausnahme setzen (temp: HA revertiert; perm: kein Timer)
unallow-domain <domain> --client <person> # dieselbe Ausnahme entfernen
list-exceptions --client <person> --json # „meine Ausnahmen" (für Übersicht + Entfernen)
recent-blocked --client <person> --json # „zuletzt geblockt" (nur Geräte der Person)
```
`--client` nimmt einen AGH-Client-Namen (→ IPs via `/control/clients`) ODER eine Komma-IP/CIDR-Liste.
## `configuration.yaml` — `shell_command` (einziger YAML-Teil, Backup `.bak-tp23-*`)
Domain **und** Client sind Parameter → **kein HA-Neustart mehr** bei neuer Domain (das war der alte
DAU-Killer: pro Domain ein eigener `shell_command`).
```yaml
shell_command:
agh_allow_domain: "python3 /config/agh-exception.py allow-domain '{{ domain }}'"
agh_unallow_domain: "python3 /config/agh-exception.py unallow-domain '{{ domain }}'"
agh_unfilter_client: "python3 /config/agh-exception.py unfilter '{{ ip }}'"
agh_refilter_client: "python3 /config/agh-exception.py refilter '{{ ip }}'"
agh_allow: "python3 /config/agh-exception.py allow-domain '{{ domain }}' --client '{{ client }}'"
agh_unallow: "python3 /config/agh-exception.py unallow-domain '{{ domain }}' --client '{{ client }}'"
```
Neue Domain → **HA-Neustart** nötig (reload_all lädt eine erstmals hinzugefügte Domain nicht).
## Deploy auf HAOS (Zugang `ssh admin@10.40.20.105`, sudo passwortlos)
- `/config/agh-exception.py` — Kopie von `adguard/agh-exception.py` (liest Creds via `/config/agh-exception.secrets`).
- `/config/agh-exception.secrets` (chmod 600, root) — `AGH_AUTOMATION_USER`/`_PASS`.
- Redeploy nach Script-Änderung: `base64 < adguard/agh-exception.py | ssh admin@10.40.20.105 "base64 -d | sudo tee /config/agh-exception.py >/dev/null"`.
## Helfer / Entities (via ha-mcp in .storage)
Pro Person (Beispiel `christoph`) — bei mehreren Personen je einmal, Suffix = Personen-Slug:
| Typ | entity_id | Zweck |
|---|---|---|
| command_line sensor | `sensor.dns_recent_blocked_<slug>` | `recent-blocked --client <person> --json` → `json_attributes: items` (Liste {domain,count,last}); Scan-Intervall ~60 s |
| command_line sensor | `sensor.dns_exceptions_<slug>` | `list-exceptions --client <person> --json` → aktive Ausnahmen der Person |
| input_select | `input_select.dns_dauer_<slug>` | 1 Stunde / 4 Stunden / **dauerhaft** |
| timer | `timer.dns_ausnahme_<slug>` | JIT-Countdown je temporärer Freigabe (restore=false) |
| input_boolean | `input_boolean.dns_permanent_ohne_anfrage` | **global**: an = „dauerhaft" wirkt sofort (Start); aus = erzeugt Admin-Genehmigung |
| script | `script.dns_freigeben_<slug>` | nimmt `domain` als Feld → `agh_allow`; bei „dauerhaft"+Switch-aus → `todo`/Notification statt Freigabe; sonst Timer starten |
| automation | `automation.dns_ablauf_<slug>` | `timer.finished`/`.cancelled` → `agh_unallow`, Aufräumen |
## Bedienung
Domain eintragen → Dauer wählen → **DNS-Ausnahme starten**. Bei Ablauf/Abbruch wird die Regel auf
beiden AGH automatisch zurückgenommen. Ungültige Domains werden HA- **und** CLI-seitig abgelehnt.
## Dashboard — ein scoped View je Person
- Eigener storage-Dashboard-View, **nur für die HA-User-ID der Person sichtbar** (`visible:` mit
der user-id; `require_admin:false`). Kleiner Haushalt → ein View je Person ist praktikabel und
umgeht das „Template kennt den aktuellen Betrachter nicht"-Problem.
- **Karte 1 „Zuletzt geblockt (antippen zum Freigeben)":** rendert `sensor.dns_recent_blocked_<slug>`
Attribut `items`; jede Zeile hat eine `tap_action` → `script.dns_freigeben_<slug>` mit `domain`
der Zeile + aktueller `input_select`-Dauer. (Dynamische Per-Zeilen-tap_action braucht i.d.R.
`auto-entities` + `template`/`button-card` **oder** ein kleines Custom-List-Template — **beim Bau
on-network entscheiden**, das ist der Teil, der Live-Verifikation braucht.)
- **Karte 2 „Meine Ausnahmen":** `sensor.dns_exceptions_<slug>` als Liste, je Eintrag Entfernen
(`agh_unallow`).
- **Karte 3 „Dauer":** `input_select.dns_dauer_<slug>` (inkl. „dauerhaft").
- **Kein** globaler Status, keine fremden Clients, keine Policy-Interna. Nur wenn relevant ein
kurzer Hinweis („durch den Familien-Filter blockiert").
## Dashboard (1. Draft, 2026-09-06)
Eigenes storage-mode Dashboard `url_path: dns-ausnahmen` (Sidebar, `require_admin: false`),
angelegt via `ha_config_set_dashboard`. Da es in HA-`.storage` lebt, hier die Repro-Quelle:
```json
{"views":[{"title":"DNS-Ausnahmen","path":"dns","type":"sections","icon":"mdi:dns","max_columns":2,"sections":[
{"type":"grid","cards":[
{"type":"heading","heading":"Domain temporaer freigeben","icon":"mdi:lock-open-variant"},
{"type":"entities","entities":[{"entity":"input_text.dns_ausnahme_domain","name":"Domain"},{"entity":"input_select.dns_ausnahme_dauer","name":"Dauer"}]},
{"type":"button","name":"DNS-Ausnahme starten","icon":"mdi:lock-open-check","tap_action":{"action":"perform-action","perform_action":"input_button.press","target":{"entity_id":"input_button.dns_ausnahme_starten"}},"grid_options":{"columns":"full"}}]},
{"type":"grid","cards":[
{"type":"heading","heading":"Status","icon":"mdi:information-outline"},
{"type":"tile","entity":"timer.dns_ausnahme","name":"Restlaufzeit"},
{"type":"tile","entity":"input_text.dns_ausnahme_aktiv","name":"Aktive Ausnahme"},
{"type":"markdown","content":"**AGH-Resolver-Paar** — .36: {{ states('binary_sensor.adguard_bf1_status') }} / .37: {{ states('binary_sensor.adguard_bf2_status') }}"}]},
{"type":"grid","cards":[
{"type":"heading","heading":"VLAN-Filter-Policy (AGH-Gruppen)","heading_style":"subtitle"},
{"type":"markdown","content":"MAIN/IOT/UNTRUSTED=an · INFRA/MEDIA/MGMT=aus · GUEST=an+SafeSearch/Parental · dns-bypass-exempt=aus"}]}
]}]}
```
⚠️ Draft-Notiz: `binary_sensor.adguard_bf1_status` ist stale (hing am alten `.16`-Container, TP42) —
zeigt evtl. `unavailable`, obwohl `.36` läuft. Sensor-Quelle gehört bei Gelegenheit auf `.36` gefixt.
## Genehmigungs-Variante (Modus-Switch aus)
`input_boolean.dns_permanent_ohne_anfrage = off` → „dauerhaft"-Klick legt statt der Freigabe einen
Eintrag in einer **`todo`-Liste** „DNS-Freigaben zu prüfen" an (+ Notification an Christoph). Beim
Abhaken führt eine Admin-Automation `agh_allow` ohne Timer aus. Beide Varianten sind gebaut; der
Switch entscheidet zur Laufzeit.
## Verifiziert (2026-09-04)
Button → `@@||doubleclick.net^` auf `.36`+`.37`, Timer 15:00, `_aktiv` gesetzt; Timer-Abbruch →
Regel auf beiden entfernt, `_aktiv` geleert, `.36==.37`.
## Alt-Reste, die beim Bau wegfallen/fixen
- Single-domain-Flow (`input_text.dns_ausnahme_domain/_aktiv`, `input_button…_starten`,
`automation…_starten/_ablauf`) und der `agh_allow_domain`/`_unallow_domain`-**pro-Domain**-Zwang.
- Statuskachel-Sensor `binary_sensor.adguard_bf1_status` hing am toten `.16` → auf `.36`/`.37` neu.
## Abnahme (on-network, = neue echte Stufe-6-Vorbedingung)
Mit einem **echten Nicht-Admin-Login**: geblockte Seite → erscheint in *ihrer* Fläche → 1 Klick
temporär (revertiert nach Ablauf) **und** 1 Klick dauerhaft (bleibt) → wirkt **nur** für diese
Person (Gegentest: anderer Client sieht die Domain weiter geblockt). `.36 == .37`
(`agh-sync.py check`). Modus-Switch beide Wege einmal durchgespielt.
## Verweise
- CLI: `adguard/agh-exception.py` (Subcommands + `selftest`). Deploy-Weg unverändert (base64→scp,
s. unten). Creds `/config/agh-exception.secrets` (chmod 600).
- Redeploy: `base64 < adguard/agh-exception.py | ssh admin@10.40.20.105 "base64 -d | sudo tee /config/agh-exception.py >/dev/null"`.
- Personen-Client-Modell: `adguard/README.md`. Kontext/Reihenfolge: TP23 in `docs/teilprojekte.md`.

218
bin/gitea-tp-sync.py Normal file
View File

@@ -0,0 +1,218 @@
#!/usr/bin/env python3
"""
TP36 (reframed) — teilprojekte.md Index/Status → Gitea Issues (admin/bf-infra).
Idempotenter Sync (get-or-create, Match ueber "TPnn" im Titel):
- Archiv-Header in docs/teilprojekte-archiv.md -> closed Issues (nur TPs, die in Gitea
NICHT offen sind; ein reopentes TP mit Archiv-Zeiger bleibt offen).
- Labels status:* (Marker) + thema:* (Gruppierung) werden vorab get-or-create.
SSoT-Modell (seit TP36-Cutover 2026-09-07): Gitea fuehrt Index+Status — aktive TPs werden
DIREKT als Gitea-Issue angelegt/gepflegt, NICHT mehr aus einer Datei-Tabelle abgeleitet
(die Quick-Index-Tabelle wurde aus teilprojekte.md entfernt). Dieses Werkzeug haelt nur noch
die ARCHIVIERTEN (closed) TPs mit teilprojekte-archiv.md idempotent abgeglichen und fasst
offene Issues nie an. Die per-TP-Prosa bleibt in docs/teilprojekte.md / teilprojekte-archiv.md.
Token: ~/.hermes/.env (GITEA_ACCESS_TOKEN, GITEA_HOST) — wird NIE ausgegeben.
Aufruf:
python3 bin/gitea-tp-sync.py # Dry-Run (default) — zeigt, was passieren wuerde
python3 bin/gitea-tp-sync.py --commit # legt Labels + Issues an / gleicht sie ab
"""
import json
import os
import re
import sys
import urllib.request
import urllib.error
from pathlib import Path
REPO = Path(__file__).resolve().parent.parent
ACTIVE = REPO / "docs" / "teilprojekte.md"
ARCHIV = REPO / "docs" / "teilprojekte-archiv.md"
HERMES = Path.home() / ".hermes" / ".env"
OWNER_REPO = "admin/bf-infra"
COMMIT = "--commit" in sys.argv
# Marker -> (status-label, gitea-state)
MARKER = {
"🔜": ("status:todo", "open"),
"⏳": ("status:wip", "open"),
"⏸️": ("status:paused", "open"),
"💡": ("status:idea", "open"),
"🟢": ("status:concept", "open"),
"✅": ("status:done", "closed"),
"❌": ("status:dropped", "closed"),
}
LABEL_COLORS = {
"status:todo": "#ededed", "status:wip": "#fbca04", "status:paused": "#c5def5",
"status:idea": "#d4c5f9", "status:concept": "#bfdadc", "status:done": "#0e8a16",
"status:dropped": "#e11d21",
"thema:firewall-dns": "#b60205", "thema:wlan": "#1d76db", "thema:cloudflare-proxy": "#f9a825",
"thema:nautobot-doku": "#5319e7", "thema:infra": "#0e8a16", "thema:ipv6-matter": "#006b75",
"thema:identity": "#e99695", "thema:backlog": "#cccccc",
}
# TP-Nummer -> Themen-Label (aus dem Statusbaum-Gruppierung; nur aktive TPs brauchen ein Board-Thema)
THEME = {
"5.1": "firewall-dns", "23": "firewall-dns",
"25": "wlan", "28": "wlan", "13": "wlan", "17.1": "wlan", "17.3": "wlan",
"16": "cloudflare-proxy", "16.2": "cloudflare-proxy", "16.3": "cloudflare-proxy",
"31": "cloudflare-proxy", "41": "cloudflare-proxy", "14.4": "cloudflare-proxy",
"42": "cloudflare-proxy", "43": "cloudflare-proxy", "44": "cloudflare-proxy",
"32": "nautobot-doku", "34": "nautobot-doku", "35": "nautobot-doku",
"36": "nautobot-doku", "37": "nautobot-doku",
"30": "infra", "40": "infra", "20.1": "infra", "18": "infra",
"24": "infra", "38": "infra", "11": "infra",
"12": "ipv6-matter", "12.1": "ipv6-matter",
"8": "identity",
"29": "backlog", "33": "backlog",
}
def hermes_env():
tok = host = None
for line in HERMES.read_text().splitlines():
m = re.match(r"\s*(GITEA_ACCESS_TOKEN|GITEA_HOST)\s*=\s*(.+?)\s*$", line)
if not m:
continue
if m.group(1) == "GITEA_ACCESS_TOKEN":
tok = m.group(2).strip().strip('"').strip("'")
else:
host = m.group(2).strip().strip('"').strip("'")
if not tok:
sys.exit("GITEA_ACCESS_TOKEN nicht in %s gefunden." % HERMES)
host = (host or "https://gitea.emsenhuber.net").rstrip("/")
if not host.startswith("http"):
host = "https://" + host
return tok, host
TOKEN, HOST = hermes_env()
API = HOST + "/api/v1"
def api(method, path, body=None):
url = API + path
data = json.dumps(body).encode() if body is not None else None
req = urllib.request.Request(url, data=data, method=method, headers={
"Authorization": "token " + TOKEN,
"Accept": "application/json", "Content-Type": "application/json"})
try:
with urllib.request.urlopen(req, timeout=30) as r:
return r.status, json.load(r)
except urllib.error.HTTPError as e:
return e.code, (json.load(e) if e.headers.get("content-type", "").startswith("application/json") else {})
# --------------------------------------------------------------------------- parse
def parse_archiv(exclude_nums):
"""Archiv-Header -> archivierte TPs. exclude_nums = TP-Nummern, die in Gitea OFFEN sind
(reopente TPs mit Archiv-Zeiger) -> die bleiben offen, nicht als closed abgleichen."""
out = []
hdr = re.compile(r"^#{2,4}\s*(TP[\d.\-A-Za-z]+)\s*—\s*(.+?)\s*▸", )
seen = set()
for line in ARCHIV.read_text().splitlines():
m = hdr.match(line)
if not m:
continue
tp, title = m.groups()
num = tp[2:]
if num in exclude_nums or num in seen:
continue
seen.add(num)
short = re.sub(r"\*\*|`", "", title).strip()[:80]
out.append({"tp": tp, "num": num, "marker": "✅",
"title": short, "date": "", "src": "archiv"})
return out
# --------------------------------------------------------------------------- gitea sync
def ensure_labels(existing):
by_name = {l["name"]: l for l in existing}
for name, color in LABEL_COLORS.items():
if name in by_name:
continue
if COMMIT:
api("POST", f"/repos/{OWNER_REPO}/labels",
{"name": name, "color": color.lstrip("#")})
print(f" [{'+' if COMMIT else 'DRY'}] label {name}")
st, cur = api("GET", f"/repos/{OWNER_REPO}/labels?limit=100")
return {l["name"]: l["id"] for l in (cur if isinstance(cur, list) else [])}
def all_issues():
out, page = [], 1
while True:
st, d = api("GET", f"/repos/{OWNER_REPO}/issues?state=all&type=issues&limit=50&page={page}")
if not isinstance(d, list) or not d:
break
out += d
page += 1
return out
def main():
print(f"Gitea {HOST} repo {OWNER_REPO} mode={'COMMIT' if COMMIT else 'DRY-RUN'}")
st, existing_labels = api("GET", f"/repos/{OWNER_REPO}/labels?limit=100")
label_id = ensure_labels(existing_labels if isinstance(existing_labels, list) else [])
issues = all_issues()
by_tp = {}
open_nums = set()
for iss in issues:
# Titel ist "TPxx — …"; volle ID inkl. Buchstaben/Bindestrich (TP14.2a, TP-R) bis zum " — "
m = re.match(r"^(TP[\w.\-]*?)\s+—", iss["title"])
if m:
by_tp[m.group(1)] = iss
if iss.get("state") == "open":
open_nums.add(m.group(1)[2:])
# Aktive TPs sind seit dem TP36-Cutover SSoT direkt in Gitea -> nur das Archiv abgleichen,
# und offene (reopente) TPs davon ausschliessen, damit sie nicht faelschlich geschlossen werden.
items = parse_archiv(open_nums)
print(f"Geparst: {len(items)} archivierte TP (aktive TPs = SSoT in Gitea: "
f"{len(open_nums)} offen, nicht angetastet)\n")
created = updated = 0
for it in items:
status_label, state = MARKER.get(it["marker"], ("status:todo", "open"))
labels = [status_label]
th = THEME.get(it["num"])
if th:
labels.append(f"thema:{th}")
title = f"{it['tp']} — {it['title']}"
body = (f"Steuerungs-SSoT: Index/Status hier in Gitea; **Prosa/Detail** im Repo unter "
f"`docs/{'teilprojekte-archiv.md' if it['src']=='archiv' else 'teilprojekte.md'}` "
f"(Abschnitt `{it['tp']}`).\n\n"
f"- Status: {it['marker']} ({status_label})\n"
+ (f"- Abschluss: {it['date']}\n" if it["date"] else ""))
want_ids = [label_id[l] for l in labels if l in label_id]
cur = by_tp.get(it["tp"])
if cur is None:
print(f" [{'+' if COMMIT else 'DRY'}] NEW {title} {labels} state={state}")
if COMMIT:
sc, res = api("POST", f"/repos/{OWNER_REPO}/issues",
{"title": title, "body": body, "labels": want_ids})
if state == "closed" and isinstance(res, dict) and res.get("number"):
api("PATCH", f"/repos/{OWNER_REPO}/issues/{res['number']}", {"state": "closed"})
created += 1
else:
have = {l["name"] for l in cur.get("labels", [])}
drift = (have != set(labels)) or (cur.get("state") != state)
if drift:
print(f" [{'~' if COMMIT else 'DRY'}] UPD #{cur['number']} {title} "
f"{sorted(have)}->{labels} state {cur.get('state')}->{state}")
if COMMIT:
api("PATCH", f"/repos/{OWNER_REPO}/issues/{cur['number']}",
{"labels": want_ids, "state": state})
updated += 1
print(f"\n{'Angelegt' if COMMIT else 'Wuerde anlegen'}: {created} · "
f"{'Abgeglichen' if COMMIT else 'Wuerde abgleichen'}: {updated}")
if not COMMIT:
print("Dry-Run — nichts geschrieben. Mit --commit ausfuehren.")
if __name__ == "__main__":
main()

47
docs/announcements.md Normal file
View File

@@ -0,0 +1,47 @@
# Announcements — bf-infra
Breaking News / Querschnitts-Änderungen, die **jede** folgende Session kennen muss, bevor sie
losarbeitet — Dinge, die man sonst erst nach dem ersten Fehlschlag merkt. Kein Ersatz für die
TP-Prosa (`docs/teilprojekte.md`) oder das Gitea-Board; hier steht nur, was *quer* zu den TPs gilt.
**Format je Eintrag:** Überschrift `## YYYY-MM-DD — <Titel>`, dann die Zeilen
**Betrifft:** (wer/was) und **Aktion:** (was eine Session konkret anders machen muss),
optional ein, zwei Sätze Kontext. **Neueste oben.** Der Skill `/news` liest diese Datei und
zeigt die Einträge, die seit dem letzten `/news`-Lauf dazugekommen sind (Rest auf Wunsch).
<!-- TP35 Schicht 4. Eintrag hinzufügen = neuen ##-Block ganz oben unter dieser Zeile einfügen. -->
---
## 2026-09-12 — Golden-Config-Backups laufen jetzt täglich (vorher KEIN Scheduler)
**Betrifft:** alle, die sich auf GC-Backups/Compliance oder `gc-snapshot.py`-Werte verlassen.
**Aktion:** Es gab **nie** einen automatischen GC-Backup-Zeitplan — Backup/Intended/Compliance liefen
nur manuell aus Sessions (zuletzt 09-04 → 8 Tage Stillstand). Jetzt ScheduledJob **„GC Backup+Compliance
– taeglich"** (Nautobot, *Execute All GC Jobs - Multiple Device*, `platform=RouterOS`, täglich 03:30 UTC,
Reihenfolge Backup→Intended→Compliance). Wenn `backup_last_success_date` eines Geräts alt ist: zuerst
prüfen, ob der ScheduledJob noch `enabled` ist (`/api/extras/scheduled-jobs/`), nicht das Gerät verdächtigen.
## 2026-09-12 — claude.json-Secrets laufen über `{env:}` (TP35 Schicht 2 ✅)
**Betrifft:** alle, die `~/.claude.json` oder `~/.secrets/exports.zsh` anfassen.
**Aktion:** Keine Klartext-Secrets mehr in `~/.claude.json` — MCP-Credentials referenzieren jetzt
`{env:MCP_*}` (dieselben Namen wie `opencode.jsonc`, bidirektional kompatibel). SSoT ist
`~/.secrets/exports.zsh` (25 Vars). Nach jeder Änderung dort: `~/dev/.bin/gui-env-sync.sh`
**und App-Neustart** (laufender Prozess erbt die launchd-Umgebung nicht). ⚠ `~/.claude.json` nie aus
einer **laufenden** Session editieren — Claude Code schreibt dort State, der Edit würde überschrieben;
der Flip läuft bei beendeter App über `~/dev/.bin/schicht2-claude-json-migrate.py --apply-claude`.
## 2026-09-12 — TP36-Live: Gerätedaten stehen als CustomFields in Nautobot
**Betrifft:** alle, die Geräte-Ist-Werte (RouterOS-Version, Compliance %, DHCP-Server-Zahl,
DNS-Modus, Mgmt-IP) brauchen.
**Aktion:** Nicht mehr aus der Prosa ablesen und nicht raten — die fünf Felder (`grouping: TP36-Live`)
hängen an den 5 RouterOS-`dcim.Device` in Nautobot. Aktualisieren: `python3 nautobot/gc-snapshot.py
--commit` (liest nur aus Nautobot/GC, kontaktiert kein Gerät). Die Werte sind so aktuell wie das
letzte Golden-Config-Backup (`backup_last_success_date` am Gerät).
## 2026-09-07 — SSoT-Cutover: Index/Status = Gitea, NICHT mehr teilprojekte.md
**Betrifft:** jede Session, die einen TP-Status ändert, anlegt oder abschließt.
**Aktion:** Status/Reihenfolge/„was lief zuletzt" gehen ins **Gitea-Issue**
([`admin/bf-infra`](https://gitea.emsenhuber.net/admin/bf-infra/issues), Labels `status:*`/`thema:*`),
**nicht** in eine Tabelle in `docs/teilprojekte.md`. Die Datei trägt nur noch die `### TPnn`-Prosa.
`/projektstatus` liest Baum + Status aus der Gitea-API. Branch `tpNN-kurz` jederzeit möglich, Merge
nach `main`, sobald Code/Config steht.

View File

@@ -3,14 +3,38 @@
> 🆕 **SSoT-Wechsel im Aufbau (TP44, seit 2026-09-02):** Die CF-Estate (Tunnel, WARP-Connector,
> VPC-Services, Hyperdrive, Workers, Access-Apps) wird als **native `nautobot.cloud`-Objekte** in
> Nautobot (`10.40.20.30`) geführt — Etappe 1 (manuelle Erstbefüllung) ✅. Seeder:
> `nautobot/tp36-cf-estate-seed.py`, Detail: `docs/handoff-20260902-cf-estate-nautobot-ssot.md`.
> `nautobot/tp44-cf-estate-seed.py`, Detail: `docs/handoff-20260902-cf-estate-nautobot-ssot.md`.
> **CF bleibt operativer Master, Nautobot = Dokumentations-SSoT.** Dieses File bleibt gültige Historie
> und As-Built-Log; die *strukturierte* Estate liest man ab jetzt in Nautobot. Etappe 2 (CF-API→Nautobot-Sync)
> ist offen.
> **Aktueller Stand: → §10 (2026-07-10, TP16 UMGESETZT ✅).** §9 = Analyse/Zielbild, §10 = As-Built.
> Abschnitte 1–8 sind Historie (Track A, 2026-06-30); die „3 Connectors gut/Zielbild"-Aussagen dort sind
> durch §9/§10 **überholt** (Round-Robin = macvlan-Host-Isolation → 1/N-Ausfälle). Track A aus `docs/handoff-cf-tunnel-1033.md`.
> **Aktueller Stand: → §0 (unten).** §1–16 sind Historie/As-Built-Log früherer Sessions und beschreiben
> Topologien, die **nicht mehr live** sind (v.a. das 3-Tunnel-HA `bf-mm`/`bf-nas`/`bf-pve`). §9 = Analyse,
> §10–15 = As-Built des inzwischen abgelösten 3-Tunnel-Designs. Track A aus `docs/handoff-cf-tunnel-1033.md`.
## §0 — Live-Ist-Stand (2026-09-08, maßgeblich)
> Der einzige aktuelle Topologie-Stand. **§1–16 nicht als aktuelle Konfiguration lesen** — insbesondere das
> 3-Tunnel-HA `bf-mm`/`bf-nas`/`bf-pve` (§10–15) existiert seit dem TP16.3-Cutover (bf-public/Caddy,
> 2026-08-27) **nicht mehr**. Strukturierte Estate = Nautobot (TP44, deckt sich mit diesem Stand);
> operativer Master = Cloudflare. Read-only gemessen gegen die CF-API (`cfd_tunnel`, `warp_connector`,
> `teamnet/routes`) am 2026-09-08.
**cloudflared-Tunnel (live) — es gibt genau drei:**
| Tunnel | ID | Conns | Zweck |
|---|---|---|---|
| **bf-public** | `48d3b0b6-7233-4781-a76a-1de4a5e957ce` | 2, healthy | **einziger öffentlicher BF-Tunnel** (TP31/TP16.3), erstellt 2026-08-27 |
| **fm.emsenhuber.net** | `b697d124-53bf-4a33-8fcf-384cced4db1a` | 1, healthy | Standort FM (`ds-fm`, `gateway-fm`), separat |
| **terpene-db** | `f2d2fc8a-54ae-41df-b09a-97312cdb9fe2` | 1, healthy | DB-Pfad (Hyperdrive→VPC-Service), Rebuild 2026-09-01 — s. §17 |
**bf-public-Ingress** → alle vier auf **Caddy `10.40.20.40:443`** (Caddy macht das Fan-out), catch-all 404:
`vw` · `hass` · `n8n` · `gitea` (`.emsenhuber.net`).
**WARP / Private Access — nativer Mesh, KEIN cloudflared:**
- warp_connector **bf-core-mesh** `d1da7c8a-2736-4cbb-8af1-32db5393fb9c`, healthy — nativer
WireGuard-Mesh-Node auf dem Core (TP16.1). **Live und produktiv** (nicht mehr „gated/Konzept" wie in §14).
- Routen: `10.40.0.0/16` → **bf-core-mesh** · `10.101.0.0/24` → **fm**. Ein vnet `vnetemsenhuber` (default).
## 1. Alle Tunnel im Account (`393c…66c36`)
| Tunnel | ID | Status | Conns | Verwendung |
@@ -234,6 +258,9 @@ Der macmini ist vollwertiger dritter Knoten (nicht „vergessen").
---
<details>
<summary>🗄️ <b>ARCHIV (§10–16)</b> — überholtes 3-Tunnel-HA <code>bf-mm</code>/<code>bf-nas</code>/<code>bf-pve</code>. Seit dem TP16.3-Cutover (2026-08-27) nicht mehr live — siehe §0. Aufklappen nur für die Historie.</summary>
## 10. AS-BUILT 2026-07-10 (TP16 umgesetzt) — reziprokes 3-Tunnel-HA ✅
> Gebaut & verifiziert in eigener Session. Round-Robin-#1033 **strukturell weg** (Loop-Gegentest 0×530 über alle 19 Live-FQDNs, HA per Host-Ausfall-Sim bewiesen). Schritte 1–4+HA durch; **Schritt 5 (Access/WARP + `vw`) offen** (user-gated).
@@ -337,6 +364,10 @@ Letzte in §9.2/§8 als „bleibt `.41`" geführte Origin-Klasse (`pve .41.100`,
## 14. Richtungsentscheid 2026-07-16 — Private Access via native Cloudflare Mesh (WARP Connector) auf dem CRS326 Core-Switch (TP16.1)
> ✅ **Nachtrag 2026-09-08 (live):** umgesetzt. warp_connector **bf-core-mesh** (`d1da7c8a-…`) ist healthy
> und trägt die Route `10.40.0.0/16` — der „Scharfschalten = eigene Session, gated"-Status unten ist
> überholt. Siehe §0.
> ✅ **Update 2026-07-22 (User-Entscheid):** Ziel-Device retargeted von **ap1** auf den **CRS326 Core-Switch** — konsistent mit TP15-Endstand (kein RB5009, Router bleibt ap1/ap2) und TP21s Kabel-Fabric-Modell. Reine Ziel-Doku-Änderung, Scharfschalten bleibt gated bis TP21 den CRS326 abdeckt. Der Rest dieser Sektion ist entsprechend auf den neuen Zielhost umgeschrieben; CRS326 ist aktuell noch Werkszustand, Management-IP/Interface TBD.
**Trennung der Concerns (wichtig):**
@@ -452,6 +483,8 @@ Netzwerk-Namespace, sieht ohnehin alles), und die cloudflared-Connectoren laufen
eigene Maschinen, auf denen die Blindheit prinzipiell nicht auftreten kann. Der Shim bleibt als Option
für den Fall, dass später doch ein Dienst neben macvlan-Nachbarn einziehen soll.
</details>
## 17. Terpenfinder-DB-Pfad neu aufgebaut 2026-09-02 (Fremdprojekt-Handout blaueblüten)
**Auslöser:** Handout `blaueblueten-n8n/docs/handout-bf-infra-db-pfad-20260902.md` — der Cloudflare-Worker

View File

@@ -82,7 +82,7 @@ terpene.teilzeitladen.xyz {
"type": "http",
"url": "https://n8n-mcp.emsenhuber.net/mcp",
"headers": {
"Authorization": "Bearer 47a34f5589388d37d8b7503abac07b930df264c469ef0674aaeeea9b71dde847"
"Authorization": "Bearer <redacted>"
}
}
```

View File

@@ -41,10 +41,10 @@ Manufacturer "Cloudflare"
## Werkzeug
`nautobot/tp36-cf-estate-seed.py` — **idempotenter** Seeder (get-or-create), Datenstand als Inline-Struktur.
`nautobot/tp44-cf-estate-seed.py` — **idempotenter** Seeder (get-or-create), Datenstand als Inline-Struktur.
Token aus `docs/nas-vlan20/stacks/210-nautobot.yml` (gitignored). Aufruf: Dry-Run default,
`--commit` schreibt. Re-Run = 26/26 „existiert".
*(Dateiname trägt noch `tp36`-Präfix aus dem ersten Arbeitsstand; inhaltlich TP44. Umbenennen bei Gelegenheit.)*
*(Datei am 2026-09-06 von `tp36-…` auf `tp44-cf-estate-seed.py` umbenannt — Präfix jetzt korrekt.)*
## Gotchas (für Etappe 2 / Folgesessions)
@@ -54,15 +54,17 @@ Token aus `docs/nas-vlan20/stacks/210-nautobot.yml` (gitignored). Aufruf: Dry-Ru
- VPC-Service-API liegt unter `connectivity/directory/services` (Update = **PUT**, voller Body), nicht `/vpc/`.
- Der Repo-`CF_API_TOKEN` darf `cfd_tunnel`, aber **nicht** Workers-VPC (`connectivity/directory`) — dort
über den `cloudflare`-MCP-Credential gehen.
> ⚠️ **ÜBERHOLT (2026-09-11):** falsch. Live getestet liest der `CF_API_TOKEN` aus
> `~/.secrets/credentials.env` Hyperdrive/VPC/Workers (alle 200) — der schmale ist `CF_DNS_API_TOKEN`.
> Der Teil-B-Sync deckt damit 14/14 ab. Details: `handoff-20260910-tp44-teilb-sync-live.md`.
## Offen (Etappe 2, eigene Session)
1. **CF-API→Nautobot-Sync** (Python/n8n): Inline-Daten im Seeder durch Live-Pull ersetzen, periodisch
(analog golden-config-bot). Dann ist Nautobot driftfrei.
2. **TP44 in `teilprojekte.md`** eintragen (Quick-Index + Abschnitt + Ist-Stand), sobald die dortigen
fremden Änderungen committet/geklärt sind.
2. ✅ **TP44 in `teilprojekte.md`** eingetragen (Quick-Index + Abschnitt + Ist-Stand) — 2026-09-06.
3. IPAM-Prefixe `10.40.0.0/16` + `10.101.0.0/24` anlegen → dann greifen die Prefix-Assignments automatisch.
4. Seeder-Datei nach `tp44-…` umbenennen.
4. ✅ Seeder-Datei nach `tp44-cf-estate-seed.py` umbenannt — 2026-09-06.
## Verifikation (2026-09-02)

View File

@@ -0,0 +1,127 @@
# Handoff 2026-09-06 — Plan TP37 (P1+2) → TP34, TP36 parallel
> **Sessiontyp:** „erst planen, nichts bauen" (User-Entscheid 2026-09-06). **Kein Nautobot-Write.**
> Dieses Dokument ist der verzahnte Runbook für die drei nachfolgenden Build-Sessions.
> Datenmodell-Entscheid: **native Nautobot-Modelle, keine eigene App** (konsistent zu TP44).
## 1. Ausgangslage — live gegen die API gelesen (2026-09-06)
| | Wert | Bedeutung |
|---|---|---|
| Nautobot | `http://10.40.20.30:8080`, v3.1.7 | Apps: **Golden Config 3.0.7 + Nornir** (cloud-Modelle sind Core) |
| Devices | 9 | 4 aktive MikroTik + decommissioned/Rest — in Build-Schritt 0 verifizieren |
| **VirtualMachines** | **0** | TP37 P1 offen |
| **Clusters** | **0** | TP37 P1 offen |
| **ipam.Service** | **0** | TP37 P2 offen |
| **CustomFields** | **0** | TP36 offen |
| Relationships / Tags | 0 / 0 | — |
| `cloud.*` (Account/ResType/Network/Service) | 1 / 6 / 4 / 14 | ✅ **TP44 Etappe 1** — CF-Estate steht |
**Kernbefund:** TP37 **Punkt 3 (CF-Connectoren) ist durch TP44 erledigt** (native cloud-Modelle). Echt
offen bleibt das **Substrat** (P1) und die **Dienste** (P2) — und genau darauf sitzt TP34.
## 2. Entscheidungen (User, 2026-09-06)
1. **Erst planen, nichts bauen** — diese Session schreibt nichts nach Nautobot.
2. **Native Modelle** — `virtualization.Cluster/VirtualMachine` + `ipam.Service`, **keine eigene App**.
3. **TP44-Doku aufgeräumt** — Quick-Index-Zeile + Abschnitt in `teilprojekte.md`, Seeder
`nautobot/tp36-…` → `tp44-cf-estate-seed.py` umbenannt.
## 3. Reihenfolge / Abhängigkeit (korrigiert)
```
TP37 P3 (CF-Connectoren) ─── ✅ ERLEDIGT via TP44 ───┐
│ gleiche native-Modell-Linie
TP37 P1 (Hosts/Container → VirtualMachine) │
└─► TP37 P2 (Dienste → ipam.Service) ─► TP34 (Caddyfile via GC)
TP36 (CustomFields auf den 4 Devices + Datei-Split) ── ∥ unabhängig, jederzeit parallel
```
**Grund für die Unabhängigkeit von TP36:** seine Live-Daten-CustomFields hängen an den **bestehenden
`dcim.Device`**, nicht an neuen VM/Service-Objekten. TP34 dagegen kann ohne die Backend-`ipam.Service`
aus P2 nichts rendern → **TP37 vor TP34** bleibt zwingend.
---
## 4. TP37 Punkt 1 — Substrat: Hosts + Container als VMs
**Modell-Mapping (nativ):**
- `virtualization.ClusterType`: `Proxmox VE`, `Synology Docker`, `Docker Desktop`.
- `virtualization.Cluster`: `pve`, `nas-bf`, `macmini` (je einer, passender ClusterType).
*(Die physischen Hosts als eigene `dcim.Device` sind **optional** und kommen frühestens in einer
Etappe 2 — für den Doku-SSoT reicht der Cluster als Gruppierung. Empfehlung: Etappe 1 ohne Host-Devices.)*
- `virtualization.VirtualMachine` je Workload, mit `cluster` + `primary_ip4`:
- **pve:** alle LXCs (u.a. `platform-pg` 105/`.20.20`, Docker-LXC 400/`.20.126`, `mcast-relay` 108,
influxdb, MariaDB 302/`.20.23`, …).
- **nas-bf (DS923, Portainer ep14):** Nautobot-Stack-Container, ggf. Caddy/weitere.
- **macmini (Docker Desktop):** `n8n`/`n8n-redis`/`n8n-mcp`/`gitea-mcp` + terpene-Worker `:8890`.
**Build-Schritt 0 (read-only Inventur, BEVOR geseedet wird):** je Host die Workloads mit Name, Rolle,
primärer IP enumerieren — `pct list` + `pct config <id>` über **pve-mcp**, Portainer-API (ep14) für die
NAS, `docker ps` auf dem macmini. Ergebnis in eine **Inline-Datenstruktur** (Muster: `tp44-cf-estate-seed.py`)
→ idempotenter Seeder `nautobot/tp37-substrat-seed.py` (get-or-create, Dry-Run default, `--commit`).
## 5. TP37 Punkt 2 — Dienste als `ipam.Service`
- Je exponiertem Port ein `ipam.Service`, an die VM (bzw. später das Device) gebunden, das ihn betreibt:
Caddy `:80/:443`, AdGuard `:53` (bf1/bf2), Nautobot `:8080`, n8n `:5678`, HA `:8123`, Portainer `:9443`,
`pve-mcp :3000`, gitea, Vaultwarden, …
- **Quelle ohne Raten:** die Ports stehen in `CLAUDE.md` (Hardware/Tooling) **und** in den
`extra_config.origin/port`-Feldern der TP44-`CloudService`-Objekte — gegeneinander abgleichen.
- Idempotenter Seeder `nautobot/tp37-dienste-seed.py`.
## 6. 🔴 Auflage: Compliance-Gegenprobe (aus TP37 selbst)
Nach P1+2 **muss** `python3 nautobot/gc-transaktion.py status` bzw. `gc-configplan.py --refresh-compliance`
zeigen, dass die Geräte-Compliance **unverändert 140/140** ist. VMs/Services hinzuzufügen darf die
Golden-Config-Pipeline der 4 MikroTik **nicht** berühren. P1 und P2 sind je ein **abnehmbarer** Schritt
mit dieser Gegenprobe danach — nicht als Nebeneffekt von etwas anderem.
---
## 7. TP34 — Caddyfile via Golden Config (nach P2)
- **Vorbedingung:** Backend-Dienste existieren als `ipam.Service` (P2).
- **Modell (nativ):** Proxy-Route = **Relationship** (oder CustomField) Frontend `caddy`-Service ↔ Backend-
Service, plus den öffentlichen Hostname am Backend. GC-Job + Jinja rendert den Caddyfile, Diff gegen
live `caddy-bf1`, neue ComplianceRule `caddyfile`.
- **Schritt 0 / Quick-Win (sobald gebaut wird):** `terpene.teilzeitladen.xyz → http://10.40.20.167:8890`
als **manueller** Caddy-Block, damit terpene läuft, bevor die GC-Pipeline steht.
- ⚠️ **Offener Design-Punkt:** Caddy ist **kein RouterOS-Gerät** — GC an ein Nicht-Netzgerät zu deployen
(Caddy-Reload) ist neu (die „nicht in TP37"-Grenze). Deploy-Pfad in der TP34-Build-Session entscheiden.
## 8. TP36 — Live-Daten-CustomFields + Datei-Split (parallel)
- **CustomFields auf `dcim.Device`:** `ros_version`, `compliance_pct`, `dhcp_server_count`, `mgmt_ip`,
`dns_upstream_mode`. Compliance-Zahl kommt aus **GC selbst**, der Rest aus MikroMCP/REST.
- **Skript `nautobot/gc-snapshot.py`** (neu — existiert noch nicht): liest live, setzt die CFs, rendert
`docs/teilprojekte-aktuell.md` als **read-only Snapshot**.
- **Datei-Split:** `teilprojekte-index.md` (nur aktive TPs, eine Zeile) · `teilprojekte-aktuell.md`
(Live-Snapshot) · `teilprojekte-archiv.md` (unverändert). `/projektstatus` liest **Index + Archiv**.
- **Unabhängig von TP37** → kann sofort/parallel starten.
---
## 9. Empfohlene Reihenfolge der Build-Sessions
1. **TP37 P1** (Substrat) — Inventur → Seeder → Compliance-Gegenprobe.
2. **TP37 P2** (Dienste) — schließt an P1 an, gleiche Gegenprobe.
3. **TP34** — nach P2 (Quick-Win terpene als Schritt 0).
4. **TP36** — jederzeit parallel zu 1–3.
## 10. Offene Entscheidungen je Build-Session (nicht heute)
- **TP34:** Proxy-Route-Modell (Relationship vs. CustomField) + Caddy-Deploy-Pfad (GC an Nicht-Netzgerät).
- **TP37:** Hosts als eigene `dcim.Device` anlegen oder nur Cluster? (Empfehlung: Etappe 1 nur Cluster.)
- **TP36:** genaues Feld-Set + wie oft `gc-snapshot.py` läuft (Bot analog golden-config vs. on-demand).
## 11. Was diese Session geändert hat (nur Doku)
- `nautobot/tp36-cf-estate-seed.py` → **`nautobot/tp44-cf-estate-seed.py`** umbenannt (+ 4 Referenzen,
+ Docstring-Titel TP36→TP44).
- `teilprojekte.md`: Quick-Index-Zeile TP44; Ist-Stand-Bullet 2026-09-06; TP34/TP36/TP37-Abschnitte auf
den korrigierten Stand gezogen; **neuer TP44-Abschnitt** mit Anker.
- `handoff-20260902-cf-estate-nautobot-ssot.md` + `cf-tunnel-mapping.md`: Dateiname-Referenzen + erledigte
TODOs nachgezogen.
- **TP23-Quick-Index-Zeile** (fremde, korrekte Fremd-Änderung ✅→⏳) auf User-Okay mit übernommen.

View File

@@ -0,0 +1,57 @@
# Handoff 2026-09-10 — TP44 Teil B: CF-Estate-Sync als Nautobot-Job LIVE
> **Ergebnis:** Der Cloudflare-Estate→Nautobot-Sync läuft als **täglicher Nautobot-Job**
> (`CFEstateSync`, grouping `TP44 / Cloudflare`). Dry-Run + Commit-Run sauber: **4 CloudNetworks /
> 14 CloudServices, alle CF-Endpoints lesbar, 0 Drift.** CF bleibt operativer Master, Nautobot ist
> read-only Dokumentations-SSoT. **TP44 ist damit vollständig durch.**
## Governance (User, 2026-09-09)
Periodische externe→Nautobot-Syncs leben als **Nautobot-Jobs** in `bf-infra/jobs/` und werden **in
Nautobot geplant** — kein per-Task-Container, kein Cron. Künftige Syncs = weitere Jobs in `jobs/`.
## Was live ist
- **Runtime:** `jobs/cf_estate_sync.py` (`CFEstateSync`, ORM). Pull der CF-API (urllib+Bearer),
Upsert per `extra_config`-Match (`tunnel_id`/`script`/`id`/`service_id`), Verwaisung = `stale`-Flag
statt Löschen. 403-tolerant (fehlender Scope kippt den Sync nicht; Verwaisung wird dann übersprungen).
- **Registrierung:** `jobs/__init__.py` ruft `register_jobs(CFEstateSync)`; **Repo-Wurzel-`__init__.py`**
macht `bf_infra` als reguläres Paket sichtbar.
- **Token:** Nautobot-Secret `cf-api-token` (Provider `environment-variable`) → `CF_API_TOKEN` am
`nautobot-worker`, verdrahtet im Anchor-`environment` von `docs/nas-vlan20/stacks/210-nautobot.yml`
(gitignored). Wert = der breite `CF_API_TOKEN` aus `~/.secrets/credentials.env` (liest 14/14).
- **Schedule:** `ScheduledJob "CF Estate Sync – taeglich"`, `interval=daily`, `start_time=2026-09-11T03:00:00Z`
(= 05:00 Europe/Vienna, vor den Golden-Config-Läufen), `enabled=True`, `dryrun=False`.
- **GitRepository:** `bf-infra` (`provided_contents=['extras.job']`) — war schon verdrahtet.
## Drei load-bearing Funde (sonst lädt/plant der Job nicht)
1. **Repo-Wurzel `__init__.py` ist Pflicht.** Nautobot 3.1.7 lädt Git-Repo-Jobs über
`import_modules_privately()` → `pkgutil.walk_packages([GIT_ROOT])`. walk_packages entdeckt **nur**
reguläre Pakete (mit `__init__.py`), **keine** Namespace-Packages. Ohne die Datei ist der geklonte
`GIT_ROOT/bf_infra/` unsichtbar → `jobs/` wird nie importiert. Symptom: Git-Sync **SUCCESS**, aber
Log „No jobs were registered on loading the `bf_infra.jobs` submodule" und **kein** Job-DB-Eintrag.
bf-infra ist das **erste** Git-Repo mit `extras.job` — daher nie zuvor aufgetreten. Der `module_path`-
Filter des Loaders importiert nur `bf_infra` + `bf_infra.jobs.*`; `nautobot/`, `routeros/` etc. bleiben
unberührt.
2. **`register_jobs()` gehört ins Paket-`__init__`**, nicht nur ins Submodul (Doku bestätigt).
3. **`Meta.has_sensitive_variables = False`** nötig — Default `True` ⇒ Nautobot verweigert das Scheduling
(„Job may have sensitive input variables"). Der Job nimmt nur `dryrun` (Boolean); das Token kommt aus
dem Secret, nicht aus einer Job-Variable.
## Zwei Daten-/Code-Funde beim Dry-Run
- **VPC-Bug:** VPC-Directory-Services tragen ihren Identifier in **`service_id`**, nicht `id`. Der Job las
`id` (=None) → per `.get(mk)==None` matchte er ein Fremdobjekt (App Launcher) und ließ den echten
`terpene-db` auf stale laufen. Fix: VPC nutzt `service_id`; `_upsert` überspringt `mv=None` generell.
- **Seed-Artefakt:** der geseedete CloudService `terpene-db` hatte `extra_config.service_id: null`
(der echte `019fa3d5-…` stand beim Seed nur in den Hyperdrive-Einträgen als `vpc_service_id`).
**Einmalig reconciled** (PATCH `service_id=019fa3d5-…`) → seither matcht der Sync sauber, 0 Drift.
## Drift-Korrektur (nicht stillschweigend)
Die frühere Notiz „Repo-`CF_API_TOKEN` darf kein Workers-VPC → über den `cloudflare`-MCP-Credential"
(TP44-Prosa + `handoff-20260902-…`) war **falsch**. Live getestet liest der `CF_API_TOKEN` aus
`~/.secrets/credentials.env` Hyperdrive/VPC/Workers (alle 200). Der schmale Token ist `CF_DNS_API_TOKEN`
(403). Der `cloudflare`-MCP ist der **remote OAuth-MCP** (kein API-Token) und für einen serverseitigen
Job ohnehin nicht nutzbar.
## Nächster CF-Sync = neuer Job im selben Muster
Modul in `jobs/` anlegen, Klasse importieren + `register_jobs(...)` im `jobs/__init__.py` ergänzen,
`Meta.has_sensitive_variables=False` setzen, Git-Sync, enablen, Dry-Run, dann Schedule. Die Wurzel-
`__init__.py` gilt schon.

View File

@@ -0,0 +1,28 @@
# Handoff 2026-09-13 — CF_API_TOKEN gerollt (Gitea bf-infra #69)
## Was passiert ist
`CF_API_TOKEN` (id `493ed8bd…`, konsolidiert) war nach TP41 tot (Fehler `1000` an allen drei
Fundorten). Statt eines separaten railplanner-Tokens wurde das konsolidierte Token am 2026-09-13
im CF-Dashboard **gerollt** (neuer Wert, gleicher Scope). Workers-Scope verifiziert:
`GET /accounts/{id}/workers/scripts` listet `railplanner` / `blaueblueten-n8n` / `terpene`.
## Drift behoben
Der neue Wert lag zunächst nur in `credentials.env`. Realignt auf identischen Wert in:
- `~/.secrets/exports.zsh` (SSoT) — vorher gar kein `CF_API_TOKEN`
- `~/.secrets/credentials.env`
- `bf-infra/mcp/cloudflare/.env` (vorher `…4148`)
- `bf-network-r6/mcp/cloudflare/.env` (vorher `…2174`)
## Gotcha (hat die Session zweimal „Token kaputt" fehldeuten lassen)
Account-owned Tokens verifizieren an `GET /accounts/{account_id}/tokens/verify` — am alten
`/user/tokens/verify` liefern sie `1000 "Invalid API Token"`, **obwohl gültig**. Siehe
`docs/tp16.1-warp-mesh-native-crs326.md:164` und `docs/teilprojekte-archiv.md:830`.
Ins Memory notiert (`reference_cf_account_token_verify.md`).
## Status
Gitea #69 `closed` (`status:done`). Kein Repo-Code geändert — alles Secret-Store + Gitea-Status.

View File

@@ -0,0 +1,111 @@
# Handoff 2026-09-14 — TP25: ap2-In-situ-Messung (Terrasse), Hebel-A-Machbarkeitsprüfung
**Anlass:** Christoph beobachtete 19:18 auf der Terrasse springende WLAN-Balken (1→2→3 binnen
Sekunden) und zwei Anruf-Aussetzer; danach Umstellung des Telefons auf 5G-Zellular. Verdacht:
Das Telefon probe die APs ab und falle dabei hinaus.
**Beteiligte:** iPhone `F2:62:4C:E1:AF:09` (das bekannte Fund-E-Gerät), Manager `crs326-core`.
Alle Reads am Manager; **kein einziger Geräte-Write** in dieser Session.
## cap-wifi-Karte (verifiziert live 19:22, vor jeder Auswertung gelesen)
`cap-wifi1` = ap2 5G (5300/ax/Ce/DI, tx-power 18) · `cap-wifi6` = ap2 2,4G (2462, tx-power 15) ·
`cap-wifi2` = ap3 5G (5180) · `cap-wifi4` = ap3 2,4G · `cap-wifi3`/`cap-wifi5` = ap1 (5G 5280/2,4G).
⚠️ Das CLAUDE.md sagt „ap1 FUNKSTILL seit 08-30" — **überholt**: seit dem 09-04-Kanalplan-Commit
hat ap1 wieder eine Provisioning-Zeile und dient live (heute 16:51:53 sogar ein Radar-Event auf
5280 mit sauberem Kanalwechsel auf 5260/5280-Liste). Doku-Drift, hier vermerkt.
## Befund 1 — das Flapping ist echt und überwiegend band-intern an ap2
Kollektor-Log 18:53–19:18: **~30 Roams**, fast alle `cap-wifi1 ↔ cap-wifi6` = **ap2 5G ↔ ap2 2,4G**
(derselbe AP), Feldstärke −68…−81 dBm. Drei echte Abwürfe `disconnected, not responding`
(19:01:29, 19:12:10, 19:47:51 — der letzte tötete den Anruf). Ein Ausflug zu ap1-5G (19:35:45,
**−64**) und ap3 (−78…−82).
## Befund 2 — In-situ vor ap2: Hardware-Verdacht WIDERLEGT
Christoph stellte sich 1–2 m vor ap2. Registration-Table live (3 Stichproben + Log):
| Position | Interface | Signal | Verhalten |
|---|---|---|---|
| 1–2 m vor ap2 | cap-wifi1 (5G) | **−49…−51** | **>2 min stabil, 0 Roams** |
| Rückweg (Weg) | cap-wifi1 → cap-wifi6 | −76…−78 | 2 Roams binnen 26 s |
| Terrassenplatz | cap-wifi6 (2,4G) | **−65…−73** | 36 s im 1-s-Takt, 0 Roams, ±4 dB |
⇒ Der offene TP25-Unterpunkt „**ap2 unterperformt (2 m/−80, 23:02-Befund)**" ist **in situ
widerlegt**: ap2 sendet auf 2 m mit −49…−51 dBm und bleibt dort stabil. Der 23:02-Befund
reproduziert sich nicht — plausibel, weil seitdem der 09-04-Kanalplan (5220→5300/5320,
Band-B-Liste) committed ist; alternativ war die damalige Position/Attribution anders.
**ap2 RF/Antenne/HW: sauber. Kein Hardware-Tausch begründet.**
## Befund 3 — Ursache-Modell Terrasse: 5-GHz-Zellkante + client-getriebene Band-Aggressivität
- Terrassenplatz: 5 GHz **−76…−81** (Zellkante), 2,4 GHz **−65…−73** — die ~7 dB sind normale
Bandspreizung plus Wand. Link-Budget, kein Defekt.
- Das iPhone **bleibt**, sobald ein Band klar gewinnt (am Platz: 2,4 GHz, minutenlang ruhig).
Das Thrash passiert ausschließlich in der **Überlappungszone −70…−77**, wo beide Bänder
gleichauf liegen und 5 GHz ständig um die iOS-Aufgabeschwelle (~−75) pendelt.
- Client-Aggressivität als Second Layer: 19:44:21 stand das Telefon bei **−52 auf ap2-5G** und
floh 13 s später auf 2,4 (−77) — dasselbe Muster wie im Archiv-Fund E („Abbruch bei −47").
Steering-Objekte `st-main`/`st-guest` haben **keine Schwellen** (nur rrm/wnm) — der AP
drängt nichts aktiv per BTM, die Entscheidungen trifft das iPhone.
- Mit `ft=no` (Dauerzustand seit 09-04) ist jeder Roam eine Voll-Reassoziation in Sekundenhöhe
⇒ genau darin sterben Anrufe.
## Hebel-A-Machbarkeitsprüfung (Dry-Run, kein Write)
**Ziel:** 5-GHz-Boden für `dirtyvader-main` (reject unter ~−76), damit das Telefon an der
Zellkante sofort endgültig auf 2,4 GHz committet statt zu thrashen.
Live + MikroTik-Doku verifiziert:
- `signal-range` wird **kontinuierlich** geprüft (Grace über `allow-signal-out-of-range`,
Default 0s) — der Mechanismus trägt grundsätzlich.
- ABER: `/interface/wifi/access-list` hat **kein `band`-Property**. Band-Scoping nur über
`interface=` möglich — und die `cap-wifiN`-Namen wechseln bei jedem CAP-Rejoin (Gotcha
2026-08-31): die Regel würde stillschweigend auf ein falsches Radio zeigen (im Worst Case
ein 2,4-Master ⇒ Lockout-Schatten). Alternativen fallen alle durch:
- **Nur SSID scope** (ohne Band): trifft auch 2,4 GHz — Schlafzimmer-Gegenmessung 08-22
(−84 dBm am Counter-AP) ⇒ Lockout, exakt das 08-22-Gegenargument.
- **Nur MAC scope** (iPhone): trifft beide Bänder — das iPhone saß heute selbst bei −89 auf
2,4 GHz (19:01) ⇒ WiFi-Verlust in schwachen Räumen.
- **Fazit: Der Band-Boden ist in der aktuellen wifi-qcom-Access-List nicht sauber ausdrückbar.
Nicht umgesetzt; Dry-Run-Preview des Kandidaten gefahren, kein Apply.**
Kandidat (NICHT angewendet, nur als Referenz wie er *heute* aussehen würde):
```
/interface wifi access-list add interface=cap-wifi1 ssid-regexp=dirtyvader-main \
signal-range=-120..-76 action=reject comment="TP25-hebel-a-5g-boden"
```
(× cap-wifi1/2/3 — die drei 5G-Master — bricht bei jedem CAP-Rejoin)
**Verbleibende Hebel:**
1. **`ft=yes` uniform auf `sec-main`** — macht Roams nahtlos ⇒ Anrufe überleben das (verbleibende)
Springen. Bewusste Aufweichung der 09-04-Entscheidung (`ft=no`), Fund-E-Ursache (7.24.1) ist
längst behoben, FT-Flotte uniform. Ein Config-Weg: Template + Compliance + Transaktion.
2. **Deckungsfix (TP25 Variante 3)** — der eigentliche Hebel: ein AP muss an der Terrasse
eindeutig stärker sein als alle anderen. Bemerkenswert: ap1-5G erreichte die Terrasse heute
mit −64 (besser als ap2-5G mit −78) — ap1 sitzt bereits auf der Band-B-Liste 5260/5280.
3. Monitoring: wireless-Logging läuft persistent; das Flapping ist damit künftig rückwirkend
diagnostizierbar.
## Nachweise
- Live-Log am Manager: 43 + 18 + 8 Zeilen `wireless,info` zu `F2:62:4C:E1:AF:09`, 18:53–19:56.
- 1-s-Sampling: zwei 18-Sekunden-Loops (`:for` am Manager, Registration-Table), 20:01:44–20:02:26.
- Monitor-Reads: `cap-wifi1` → `5300/ax/Ce/DI tx-power 18`; `cap-wifi6` → `2462/ax tx-power 15`.
- Doku-Verifikation Access-List: help.mikrotik.com/docs/display/ROS/Wifi (signal-range kontinuierlich,
kein band-Property, first-match-wins, kein impliziter Reject).
## Offen / nächste Schritte
1. Entscheidung Christoph: `ft=yes` ja/nein (Hebel 1 oben) — ich lege dazu auf Go den
GC-ConfigPlan als Dry-Run vor.
2. Deckungsfix-Terminierung (Variante 3 / ap1-Endausbau) — TP25 bleibt offen.
3. CLAUDE.md-Drift „ap1 FUNKSTILL" beim nächsten CLAUDE.md-Edit korrigieren (nur Vermerk hier,
kein stiller Fix).
4. Gitea-TP25-Issue **#17** hat einen Kommentar mit diesem Befund erhalten.
5. 🔴 **Sicherheitsvorfall dieser Session:** durch einen Env-Parse-Fehler stand der
`GITEA_ACCESS_TOKEN` in einer URL im Traceback — **Token ist als kompromittiert zu
betrachten und zu rotieren** (neues Token erzeugen, `~/.hermes/.env` aktualisieren, altes
widerrufen). Siehe Merkregel-Klasse „Werte nie suchen, um sie zu sehen".

View File

@@ -0,0 +1,72 @@
# Handoff 2026-09-15 — TP25: Steering-Threshold 5G deployed, Terrasse verifiziert, MacBook-Klebrigkeit „wird nicht umgesetzt"
**Anlass:** Folgesession zum TP25-Handoff „zuordnung-und-redundanz" ([[handoff-20260915-tp25-zuordnung-und-redundanz]]). Ziele: (1) Doku-Drift schließen, (2) Roaming-Threshold für die Terrasse (5G bricht früher zur 2,4G ab), (3) Terrasse-Nachmessung nach dem Deploy.
## 1. Steering-Threshold 5G — DEPLOYED, 140/140
**Problem:** Am Rundgang 09-15 saß der Terrasse-Client auf der **−80/5G-Kante** (genau der Default
`transition-threshold`); auf 2,4 GHz wäre das nicht passiert.
**Umsetzung (nur 5G):** neues Steering-Profil `st-main-5g` mit `transition-threshold=-72`
(statt Default −80) und `transition-threshold-time=5s` (statt 10s). Die drei 5G-Configs
(`cfg-main-5g-ap1/ap2/ap3`) zeigen darauf; die drei 2G-Configs bleiben auf `st-main` (unset −80),
weil 2,4 GHz draußen (Terrasse/außerhalb) Reichweite behalten soll. **8 dB Abstand = kleine Hysterese.**
Weg: Template-Edit (`nautobot/mikrotik_routeros.j2`) → `push-gc-template.py` (GC-Commits `6a4b504f`,
`242ed108`) → manueller Plan (`gc-manual-plan.py`, Plan `cc8340a8`, Completed) → Refresh:
**140/140, 0 Drifts.** Commands-File:
[`docs/transaktionen/TP25-steering-5g-threshold.commands.rsc`](transaktionen/TP25-steering-5g-threshold.commands.rsc).
## 2. Gotcha: Parameter-Reihenfolge im Template
Nach dem ersten Push meldete Compliance **139/140** mit einem `wifi-steering`-Drift: `extra`/`missing`
derselben Zeile, aber mit unterschiedlicher Feld-Reihenfolge. **RouterOS exportiert `transition-threshold`
vor `wnm` (alphabetisch)** — mein Template hatte `wnm` davor. Fix = Template-Zeile auf die Export-Reihenfolge
gebracht (`… rrm=yes transition-threshold=-72 transition-threshold-time=5s wnm=yes`). Kein Re-Deploy nötig
(das Gerät war schon korrekt, nur das Template war es nicht). **Merkregel: bei neuen Parametern im
`/interface wifi steering add` die RouterOS-Export-Reihenfolge (alphabetisch) verwenden, sonst Drift ohne
Fehlfunktion.**
## 3. Terrasse-Nachmessung — Threshold wirkt am iPhone, nicht am MacBook
Zwei Apple-Geräte 20 cm auseinander auf der Terrasse, beide auf `dirtyvader-main`, beide physisch
rein/raus bewegt (A/B):
| Gerät | Band | Signal | Roam-Verhalten |
|---|---|---|---|
| iPhone `F2:62:4C:E1:AF:09` | **2,4 GHz** | −55…−66 | ✅ roamt sauber (rein→5G, raus→2,4G) |
| MacBook `56:71:6C:22:E6:A9` | **5 GHz** | −73…−75 | ❌ kein Roam (uptime 1h15m unverändert) |
**Befund:** gleiche Bewegung, gegensätzliches Verhalten. iOS folgt dem Band-Wechsel; **macOS hält 5 GHz
klebrig fest** und ignoriert die 802.11v-Transition-Request — selbst unter der −72-Schwelle und beim
physischen Umhertragen. Christoph: das MacBook hatte an diesem Ort nie Probleme (−73/5G reicht ihm).
## 4. Entscheidung: MacBook-Klebrigkeit = ❌ WIRD NICHT UMGESETZT
Der einzige Hebel dagegen wäre `transition-time=immediate` (deauth-Erzwingung nach der
Transition-Request statt bloßem Vorschlag) — ein schärferer Eingriff mit Abbruch-Risiko für aktive
Sitzungen. **Christoph-Entscheid 2026-09-15: nicht umsetzen.** Kein Handlungsbedarf, da das MacBook
dort funktioniert. Nur dokumentiert, falls es später doch wieder aufkommt.
## 5. Doku-Drift geschlossen (diese Session)
- **CLAUDE.md:** ap1 „FUNKSTILL"→aktiv am Sideboard (`core ether3`), ap2→Technik UG (`core ether21`,
ether1-MAC `:39`), ap3→Technik OG (`branch ether24`), Branch-Portliste `24 ap3`, Gotcha-Zeile
ap2/ap3-Uplink. Kanäle mitkorrigiert (ap1 `5260/Ce`, ap2 `5300/Ce`).
- **teilprojekte.md:** neuer Stand-Block 2026-09-15 (definitive Zuordnung + Tausch-Befund ap2↔ap3).
- **Nautobot Location** (war `None`): ap1→`Wohnzimmer Sideboard`, ap2→`Technik UG`, ap3→`Technik OG`.
## 6. Handoff-Punkte (aus dem Vorgänger) — aufgelöst
1. **ap1 behalten/abbauen** → **behalten** (Christoph). APs bleiben an ihren jetzigen Orten.
2. **Tausch korrigieren** (cAP ax → Sideboard) → **verworfen**; aktueller Zustand bleibt.
3. **Drei-Räume-Schatten** nachmessen → **verworfen**; Signal war beim letzten Rundgang gut.
4. **Doku-Drift** → ✅ geschlossen (s. §5).
## Übergabeprompt (nächste Session)
> TP25: Steering-Threshold 5G deployed (st-main-5g, −72/5s, 140/140), Terrasse am iPhone verifiziert
> (2,4G statt 5G/−80). MacBook-Klebrigkeit auf 5G dokumentiert und per Christoph-Entscheid
> „wird nicht umgesetzt" (transition-time=immediate). Doku-Drift geschlossen, Handoff-Punkte aufgelöst
> (ap1 bleibt, APs bleiben, Drei-Räume verworfen). Siehe
> [[handoff-20260915-tp25-steering-threshold-und-terrasse]].

View File

@@ -0,0 +1,105 @@
# Handoff 2026-09-15 — TP25: AP-Zuordnung geklärt, Messrunde (Vorher), Tausch ap1↔ap3 begonnen
**Anlass:** Christoph wieder on site in Linz. Zurückgestellter Job = TP25 Deckungsfix Variante 3
(„Deckenstrahler an den guten Platz, hAP in den Schatten"). Session lief als große Messrunde
(Vorher) + physischer Tausch ap1↔ap3. **Tausch ist physisch angefangen, aber der Netzzustand ist
zum Sitzungsende unklar — ap2 ist down.**
## 🔑 AP-Zuordnung — EINDEUTIG per physischem Test geklärt
Die Session lief lange mit vertauschter Zuordnung (auch Christoph hat sie zwischenzeitlich falsch
„korrigiert"). Der **Kabel-Test** hat sie eindeutig festgelegt:
| Gerät | IP | Position | Uplink |
|---|---|---|---|
| **ap1** | 10.40.99.11 | **Sideboard / Wohnzimmer** | core `ether3` |
| **ap2** | 10.40.99.12 | **Technik OG** | core `ether8` → branch `ether24` |
| **ap3** | 10.40.99.13 | Technik UG | core `ether21` |
**Beweis:** Christoph zog das Kabel in Technik OG → `cap-wifi1`/`cap-wifi6` (= ap2,
Radio-MAC `D0:EA:11:4D:40:3E/3F`) verschwanden aus der cap-wifi-Karte, ap1/ap3 blieben.
⇒ ap2 = Technik OG, ap1 = Sideboard. Die ARP zeigt ap2 noch ~30 s „reachable" (Cache), die
CAPWAP-Karte ist die Wahrheit.
⚠️ **CLAUDE.md-Drift:** die Hardware-Tabelle sagt für ap1 „core ether15" — überholt, ap1 hängt an
`ether3`. Und die Doku-Aussage „ap1 FUNKSTILL seit 08-30" ist überholt (ap1 dient live).
## Messrunde (Vorher) — Methode
iPhone `F2:62:4C:E1:AF:09` (Fund-E-Gerät) wurde per **Access-List-Reject** gezielt auf je einen AP
gelenkt (die anderen zwei APs ablehnen), dann Registration-Table am Manager gelesen. Reject-Regeln
nur auf `ssid-regexp=dirtyvader-main`, am Ende immer `remove [find where comment~"TP25-messung"]`.
⚠️ **Zwei Methodik-Gotchas (neu):**
1. `interface=` in der Access-List nimmt **nur EINEN Wert** (keine Komma-Liste) — pro AP zwei
Regeln (5G- + 2,4G-Radio). Eine Komma-Liste wirft `input does not match any value of interface`.
2. **MAC-Tippfehler** `F2:62:4C:E1:41:AF:09` (ein „41" zu viel) ist mir **zweimal** passiert und
hat stille Fehl-Reads (leere Registration-Table) erzeugt. Korrekt ist `F2:62:4C:E1:AF:09`.
**Methodischer Vorbehalt:** die wiederholten Rejects + Disconnects drosseln die iOS-Wiederverbindung.
Ein „✗ tot"-Wert direkt nach mehreren Disconnects kann teils Artefakt sein — Christoph hat den
ap1-tot-Befund auf der Terrasse aber selbst per manuellen Verbindungsversuchen bestätigt.
## Messwerte (Vorher)
**Innenräume** (Durchschaltung, je Station alle 3 APs):
| Ort | ap1 (Sideboard) | ap2 (OG) | ap3 (UG) |
|---|---|---|---|
| Küche | 5G −52 | — | — |
| Schlafzimmer | 5G −52 | ✗ tot | 2,4G −57 / 5G −73 |
| Bad | 2,4G −71…−76 | ✗ tot | 5G −73 / 2,4G −72 |
| Klo | ✗ tot | 2,4G −75…−81 | 5G −69 |
| Technik OG | (−52 erst, dann ✗)† | 5G −47…−57 | 5G −68…−71 |
**Terrasse** (3 Runden je AP: sitzend → Rundgang entlang der Mauern → wieder sitzen):
| | ap1 (Sideboard) | ap2 (OG) | ap3 (UG) |
|---|---|---|---|
| Sitzend | ✗ tot | 5G −78…−85 / 2,4G −67 (Thrash) | ✗ tot |
| Rundgang | ✗ überall | 2,4G −63…−74 / 5G −73…−75 | ✗ (nur 1 Mauerdurchlass −70…−82) |
† Vorbehalt s.o.
**Kernbefunde:**
1. **Die Terrasse wird ausschließlich von ap2 (Technik OG) bedient — marginal** (Band-Thrash
5G −78…−85 / 2,4G −67). ap1 (Sideboard) erreicht die Terrasse **nicht**, ap3 nur an einem
Mauerdurchlass kurz (−70…−82). Die Prämisse „Sideboard-AP deckt die Terrasse" ist **widerlegt**.
2. **ap1 (Sideboard) ist der Innenraum-König:** Küche −52, Schlafzimmer −52, Bad −71…−76.
3. **ap3 (cAP ax, UG) hält als einziger beide Geschoße** (UG: Schlafzimmer/Bad/Klo −69…−73,
OG: Technik OG −68…−71 über die Decke).
## Tausch ap1↔ap3 — Status UNKLAR (Sitzungsende)
Christoph hat ap1 und ap3 physisch getauscht: **ap3 (cAP ax) liegt jetzt „am Kasten auf
ap1-Position"**, bewusst „oben/unten ausgerichtet wie Deckenmontage" (Abstrahlwinkel). Ports/VLAN
sollten laut Vorgabe gleich bleiben.
**Live-Befund direkt nach dem Tausch (Vorsicht, Zustand kann sich noch setzen):**
- ap2 = **down** (10.40.99.12 ARP `incomplete`, fehlt in cap-wifi-Karte). Vermutlich Kabel beim
Tausch abgezogen.
- ap1 = reachable, noch an `ether3` (Sideboard).
- ap3 = reachable, aber Bridge-Host zeigt es an **`ether8` (branch)**, nicht an `ether21`.
- `ether21` ist **leer**.
⇒ Der Tausch ist im Netz noch nicht so angekommen, wie physisch beabsichtigt. **Bevor irgendetwas
weitergemessen wird: ap2 wieder einstecken und die tatsächliche Verkabelung (welches Kabel an
welchem Gerät) klären.**
## Offen / nächste Schritte
1. **ap2 (Technik OG) wieder versorgen** — Kabel prüfen, ARP `10.40.99.12` wieder `reachable`.
2. **Verkabelung nach dem Tausch verifizieren:** Bridge-Host-Tabelle (`mac-address~"D0:EA:11"`)
gegen Soll (ap1=`ether3`, ap2=`ether8`/branch, ap3=`ether21`) stellen. ap3 hängt aktuell an
`ether8` — klären, ob das Absicht ist oder Verwechslung.
3. **Nachher-Messung** derselben Stationen (Terrasse + Innenräume), erst wenn 1+2 sauber sind.
4. **Nautobot hat keine Location/Position** für ap1/ap2/ap3 hinterlegt (`location: None`). Nach dem
abgeschlossenen Tausch die korrekten Positionen dort nachtragen (SSoT-Drift schließen).
5. Gitea-TP25-Issue #17 bekommt den Befund als Kommentar (Zitat auf Messwerte + Zuordnung).
## Messwerte-Kurzform (für Folgesession)
`cap-wifi`-Karte war am Sitzungsende nach ap2-Rejoin: `cap-wifi1`=ap3-5G, `cap-wifi2`=ap3-2,4G,
`cap-wifi3`=ap1-5G, `cap-wifi5`=ap1-2,4G, ap2 fehlte (down). **Die cap-wifiN-Nummern verschieben
sich bei jedem CAP-Rejoin — vor jeder Messung neu lesen** (`/interface wifi radio print terse
proplist=cap,radio-mac,interface` am Manager).

View File

@@ -0,0 +1,96 @@
# Handoff 2026-09-15 — TP25: AP-Zuordnung fixiert, Tausch-Befund, ap1-Redundanz gemessen
**Anlass:** Folgesession zur unklaren Tausch-Lage vom Vormittag ([[handoff-20260915-tp25-tausch-und-zuordnung]]).
Ziele: (1) AP-Positionen definitiv per IP/MAC/Switch-Port klären, (2) ob die Messwerte den richtigen
Geräten zugeordnet sind, (3) Rundgang-Messung im natürlichen Zustand, (4) ap1-Redundanz-Test (ap1 aus).
## 🔑 AP-Zuordnung — DEFINITIV (IP + MAC + Switch-Port)
| Gerät | IP | ether1-MAC | Bridge/Mgmt-MAC | Radios (5G/2,4G) | Port | Position |
|---|---|---|---|---|---|---|
| **ap1** | .11 | `D0:EA:11:4D:40:E0` | `:E1` | `:E5` / `:E6` | core **ether3** | Sideboard (Wohnzimmer) |
| **ap2** | .12 | `D0:EA:11:4D:40:39` | `:3A` | `:3E` / `:3F` | core **ether21** | Technik **UG** |
| **ap3** | .13 | `D0:EA:11:FF:16:9D` | `:9E` | `:9F` / `:A0` | branch **ether24** | Technik **OG** |
Beweis: Neighbor-Tabelle (MNDP, L2) + Bridge-Host-Tabelle + Port-Link-Status am Core, live gelesen.
⚠️ **MAC-Korrektur:** ap2s `ether1` ist **`:39`**, nicht `:3A`. `:3A` ist die Bridge-/Mgmt-MAC
(die CLAUDE.md als „ap2" führt). ap2s Radios sind **`:3E`/`:3F`** — das Handoff-09-15 hatte damit
recht; meine frühere „um eins versetzt"-Korrektur war falsch (ich hatte `:3A` fälschlich als
ether1-Basis angenommen).
## Tausch-Befund — ap2↔ap3 statt ap1↔ap3
Geplant (Deckungsfix Variante 3): **ap1↔ap3** (cAP ax → Sideboard, hAP → UG-Schatten).
Tatsächlich getauscht: **ap2↔ap3**:
- **ap1** blieb Sideboard (ether3)
- **ap2** ging von OG → UG (ether21)
- **ap3** (cAP ax) ging von UG → OG (branch ether24)
⇒ Drei-Wege-Drehung mit dem **falschen Paar**. Der „Deckenstrahler" (cAP ax) steht jetzt in **OG**,
nicht am guten Platz (Sideboard). Ursache war die ap1/ap2-Verwechslung während der Session.
## Rundgang 1 — alle APs an, natürlicher Zustand (ohne Fixierung)
Methode: Registration-Table am Manager im 1-s-Takt, iPhone `F2:62:4C:E1:AF:09` auf `dirtyvader-main`.
- **0 Disconnects**, Signal **−45…−77 dBm** (alles brauchbar, meist deutlich besser).
- Roaming natürlich über **alle 3 APs** (ap3→ap2→ap1→ap2→ap3) — funktioniert.
- **Terrasse** (das Sorgenkind): **−58 dBm stabil** an OG-Position (jetzt cAP ax), 2,4G.
- **ap1 (Sideboard)** wurde nur **kurz gestreift** (−52…−60); den Rest dominieren ap3 (OG) + ap2 (UG).
- Kein Band-Thrash: nur ein sinnvoller 2,4G-Ausflug bei 5G-Zellkante (−77), sonst sauber 5G.
## Rundgang 2 — ap1 komplett aus (Redundanz-Test)
**Methode (neues CAPsMAN-Wissen):** ap1-Radios lassen sich **nicht** über `cap-wifiN` abschalten
(`failure: can not change dynamic interface`). Richtig: Provisioning-Regeln auf `action=none`, dann
re-provisionieren:
```
/interface wifi provisioning set [find where radio-mac=D0:EA:11:4D:40:E5 or radio-mac=D0:EA:11:4D:40:E6] action=none
/interface wifi capsman remote-cap provision [find where identity="ap1"]
```
Rückbau = `action=create-dynamic-enabled` + dieselbe re-provision. (Merkregel: `cap-wifiN` sind
dynamische Interfaces; Abschalten geht nur über die Provisioning-Regel + re-provision.)
**Ergebnis:**
- **Main-Client (iPhone):** ohne ap1 voll abgedeckt (ap2+ap3), tiefster Wert **−80 dBm** (ap3/OG 5G,
an der Terrasse — dieselbe bekannte Zellkante, nur diesmal auf 5G statt 2,4G erwischt), kein Disconnect.
- **IOT:** vorher 27 Geräte (19 ap1 + 8 ap2). Nach Abschalten **alle 27 zurück** — 23 auf ap2, 4 auf ap3.
MAC-gegengeprüft, keiner verloren. **Aber ~4 Geräte sitzen marginal bei −77…−80 dBm** (Wohnzimmer-Geräte,
vorher nah am Sideboard-AP, jetzt an der ap2/UG-2,4G-Zellkante).
- **ap1 wieder eingeschaltet** (Revert) — Zustand vor dem Test wiederhergestellt.
## Befund: ap1 technisch redundant, aber 4 IOT-Geräte an der Kante
| Aspekt | Ergebnis |
|---|---|
| Main-Client | ✅ ohne ap1 voll abgedeckt, tiefster Wert −80, kein Disconnect |
| IOT (27) | ✅ alle verbunden, **aber ~4 marginal −77…−80 dBm** |
ap1 ist **technisch redundant** — nichts fällt aus, wenn es weg ist. Aber die ~4 Wohnzimmer-IOT-Geräte
verlieren ihre Signal-Reserve (verbunden ja, Aussetzer-Risiko erhöht). „ap1 abbauen" ist eine echte
Option, aber kein Selbstläufer.
## Offen / nächste Schritte
1. **Entscheidung ap1:** behalten (Status quo) oder Richtung Abbau? Nur sinnvoll, wenn die ~4 marginalen
IOT-Geräte akzeptiert werden (oder deren Platzierung/ap2-Abdeckung verbessert wird).
2. **Tausch korrigieren?** Aktuell cAP ax @ OG, hAP @ UG, hAP @ Sideboard — misst gut, ist aber nicht der
geplante Zustand (cAP ax → Sideboard). Der **Drei-Räume-Schatten** (Schlafzimmer/Bad/Küche, 08-22:
−82…−84) ist mit dem jetzigen Arrangement **noch nicht verifiziert** — der Rundgang lief ohne
Raumnamen/Fixierung. Nächste Messung sollte die drei Räume gezielt prüfen.
3. **Doku-Drift schließen** (nicht in dieser Session angefasst): CLAUDE.md-Hardware-Tabelle (ap2-MAC
`:3A`→`:39` ether1, ap2 Position OG→UG, ap3 UG→OG, ap1 „FUNKSTILL" überholt), teilprojekte.md TP25-Abschnitt,
Nautobot Location (nach wie vor `None`).
4. Gitea-Issue #17 trägt den Befund als Kommentar.
## Übergabeprompt (nächste Session)
> TP25 weiter: Die AP-Zuordnung ist jetzt definitiv geklärt (Handoff 2026-09-15 „zuordnung-und-redundanz").
> ap1=Sideboard (core ether3), ap2=Technik UG (core ether21), ap3=Technik OG (branch ether24) — der Tausch
> hat ap2↔ap3 vertauscht statt ap1↔ap3, ap1 blieb stehen. Rundgang ergab: Coverage überall gut (0 Disconnects,
> −45…−77 dBm), Terrasse −58 stabil an OG, ap1 nur kurz gestreift. ap1-Aus-Test: Main-Client voll abgedeckt,
> alle 27 IOT-Geräte kehren zurück, aber ~4 Wohnzimmer-IOT sitzen marginal −77…−80 dBm. ap1 ist wieder an.
> Offen: (1) ap1 behalten oder abbauen? (2) Tausch auf Plan korrigieren (cAP ax → Sideboard)? (3) Drei-Räume-
> Schatten (Schlafzimmer/Bad/Küche) gezielt nachmessen. (4) Doku-Drift (CLAUDE.md MAC/Positionen, Nautobot
> Location) schließen.

File diff suppressed because one or more lines are too long

View File

@@ -63,6 +63,11 @@ teuerste Eigenschaft der Datei zerstört, um ihr billigstes Problem zu lösen. B
| [TP28](#tp28) | WLAN über CAPsMAN auf `crs326-core` | ↩️ **wieder geöffnet 2026-08-30** (ap3) — Volltext in [teilprojekte.md](teilprojekte.md#tp28) |
| [TP-R](#tp-r) | Router-Capabilities-Sweep | FERTIG (docs/research/routeros-capabilities.md) |
| [TP39](#tp39) | LXC-Hygiene pve: Resolver-Altlasten, `networking.service`, DB-Reverse-Lookup | ✅ ABGESCHLOSSEN (2026-09-01) — pve+NAS-Sweep grün |
| [TP34](#tp34) | Caddyfile via Nautobot/GC (generische Reverse-Proxy-Schnittstelle) | ❌ VERWORFEN (2026-09-08) — Caddyfile bleibt manuell |
| [TP44](#tp44) | Cloudflare-Estate als Dokumentations-SSoT in Nautobot | ✅ DURCH (2026-09-10) |
| [TP41](#tp41) | CF-Access-Reparatur + Zero-Trust-Konsolidierung | ✅ ABGESCHLOSSEN (2026-09-10) — Gelis WARP via Android eingerichtet, letzter Blocker weg |
| [TP43](#tp43) | dw-Standort-DNS-Uplink (site-spezifische Overrides) | ♻️ REOPENED (2026-09-11) — Volltext zurück in teilprojekte.md; interne BF-Namen über WG am dw offen |
| [TP42](#tp42) | Namens-Vereinheitlichung: ein interner Suffix bf.emsenhuber.net | ✅ DURCH (2026-09-02) — `.bf.lan` raus, `.16` abgebaut, Compliance 140/140 |
Dazu am Ende: **[TP25 (Langfassung)](#tp25-lang)** — die Messchronik und die Funde A–E im Volltext.
TP25 selbst ist **nicht** abgeschlossen und steht weiter in `teilprojekte.md`; nur seine 394 Zeilen
@@ -1777,3 +1782,198 @@ gemessen hat. Beim Beheben kam eine zweite, unabhängige Altlast zum Vorschein.
- **Nicht** TP31/TP34 (Caddy) und nicht TP11 (Monitoring) — obwohl gilt: ein Monitoring, das
DB-Verbindungszeiten kennt, hätte diesen Fall Monate früher gezeigt.
- **Nicht** TP40: der HA-Recorder-Wildwuchs (Punkt 3) ist HA-seitig und ein eigenes TP.
---
### TP34 — Caddyfile via Nautobot/GC (generische Reverse-Proxy-Schnittstelle) ▸ ❌ **VERWORFEN (2026-09-08)**
> 🔴 **Nachtrag 2026-09-08 (verworfen):** Der Ansatz „Caddyfile via Golden Config rendern" ist
> zurückgezogen (Commits `d63dc7b`, `bca8f6e`; Gitea-Issue #24 → `status:dropped`, closed). Der
> `420.teilzeitladen.xyz`-Block wurde wieder aus dem GC-gerenderten Caddyfile entfernt; **der
> Caddyfile bleibt manuell** in `caddy/Caddyfile`. Gründe: kein zweites SSoT-Modell für Proxy-Routen
> nötig, TP37 deckt die Dienst-Doku als `ipam.Service` bereits ab, und der einzige akute Anwendungsfall
> ließ sich mit einem manuellen Block lösen. Text unten unverändert als Konzept-Historie.
> **Konzept + Architektur-Skizze:** [`docs/handoff-20260827-inventur-und-architektur.md`](handoff-20260827-inventur-und-architektur.md) — bitte dort weiterlesen (Architektur-Abschnitt).
- **Scope:** Reverse-Proxy-Hosts werden im **Nautobot-Datenmodell** gepflegt (Site, Host, Backend-Spec). **Golden Config** rendert den Caddyfile aus den Daten, Diff-Check gegen die Live-Version auf `caddy-bf1`, Compliance-Checks + Transaktionen identisch zum bestehenden Workflow für Router-Configs.
- **Auslöser (Inventur 2026-08-27):** der Caddyfile (`bf-infra/caddy/Caddyfile`) ist heute **manuell gepflegt** — kein Drift-Check, keine Transaktionen, andere Projekte können keine Sites anlegen ohne Christoph. Lösung: **Nautobot/GC**, kein Caddy-API-Sidecar (kein zweites SSoT).
- **Erster Anwendungsfall:** `terpene.teilzeitladen.xyz → http://10.40.20.167:8890` (Mac-mini-Backend, dort PostgREST + sync + web via lokalem Caddy `:8890`). Vor TP34: manueller Quick-Win-Caddy-Block.
- **Abh.:** TP22 (GC-Pipeline) ✅ · TP23 (DNS/Caddy-Voraussetzungen) ✅ Stufe 1 · 🔴 **NEU 2026-09-06: TP37 Punkt 1+2** — Caddy rendert *Config aus Daten*, die Backend-Dienste müssen als `ipam.Service` in Nautobot existieren, sonst gibt es nichts zu rendern. **TP37 vor TP34.**
- **Datenmodell (entschieden 2026-09-06):** native Modelle — Backend = `ipam.Service`, Proxy-Route = Relationship/CustomField Frontend↔Backend, GC-Job rendert den Caddyfile. Keine eigene App (konsistent zu TP44).
- **Status:** 🔜 Stub; wartet auf TP37 P1+2. Quick-Win `terpene.teilzeitladen.xyz → 10.40.20.167:8890` als manueller Caddy-Block ist **Schritt 0** des Runbooks. Plan: [`handoff-20260906-tp37-34-36-plan.md`](handoff-20260906-tp37-34-36-plan.md).
---
<a id="tp44"></a>
### TP44 — Cloudflare-Estate als Dokumentations-SSoT in Nautobot ▸ ✅ **DURCH (2026-09-10): Etappe 1 + Etappe 2 (Teil A IPAM-Prefixe, Teil B Live-Sync als täglicher Nautobot-Job)**
> **Entscheid (User, 2026-09-02):** die volle CF-Estate (Tunnel + WARP-Connector + VPC-Service +
> Hyperdrive + Workers + alle Access-Apps) als strukturierte, abfragbare SSoT in Nautobot abbilden —
> **etappenweise: manuell jetzt, Sync später.** Nautobot kann CF nicht steuern → „SSoT" heißt
> **Dokumentations-SSoT; CF bleibt operativer Master.** Detail-Handoff:
> [`handoff-20260902-cf-estate-nautobot-ssot.md`](handoff-20260902-cf-estate-nautobot-ssot.md).
- **Warum eigenes TP, nicht TP36:** TP36 ist eng auf `teilprojekte.md`-Live-Daten geschnitten; gleiche
Idee (Nautobot als Doku-SSoT), andere Dimension. TP44 = nächste freie Nummer nach TP43.
- **Modell (native `nautobot.cloud`, Nautobot 3.1.7 — keine eigene App):** `Manufacturer "Cloudflare"` →
`CloudAccount` (`393c051f…`) → `CloudResourceType ×6` → `CloudNetwork ×4` (`bf-public`/`fm`/`terpene-db`/
`bf-core-mesh`) + `CloudService ×14`; Service↔Tunnel über das Through-Modell
`cloud-service-network-assignments` (3 Rows). IDs/Ports/Hostnames/Origins je Objekt in `extra_config`.
- **Werkzeug:** `nautobot/tp44-cf-estate-seed.py` — idempotenter Seeder (Re-Run = 26/26 „existiert"),
Datenstand inline (Live-CF-Inventur 2026-09-02). Token aus `docs/nas-vlan20/stacks/210-nautobot.yml`.
- ✅ **Verifikation 2026-09-06 (live gegen die API):** CloudAccount 1 · ResourceType 6 · CloudNetwork 4 ·
CloudService 14 — unverändert seit 09-02.
- 🔴 **Gotchas:** `CloudService.cloud_networks` ist `read_only` (nur Through-Rows schreiben/lesen) ·
VPC-Service-API unter `connectivity/directory/services` (PUT, voller Body) · **VPC-Objekte tragen ihren
Identifier in `service_id`, NICHT `id`** (kostete im Sync einen Fehl-Match) · ⚠️ **DRIFT-KORREKTUR
2026-09-10:** die frühere Zeile „Repo-`CF_API_TOKEN` darf kein Workers-VPC → über den `cloudflare`-MCP"
war **falsch**. Live getestet liest der `CF_API_TOKEN` aus `~/.secrets/credentials.env` Hyperdrive **und**
VPC **und** Workers (alle 200). Der schmale Token ist `CF_DNS_API_TOKEN` (403). Der `cloudflare`-MCP ist
der **remote OAuth-MCP** (kein API-Token) und für einen serverseitigen Job ohnehin nicht nutzbar.
- ✅ **Etappe 2 Teil A (2026-09-08): IPAM-Prefixe live.** `10.40.0.0/16` (container, Route `bf-core-mesh`) +
`10.101.0.0/24` (network, Route `fm`) angelegt via `nautobot/tp44-ipam-prefixes.py`; der Seeder-Re-Run
hat die zwei `cloud-network-prefix-assignments` eingehängt (count=2, Idempotenz-Gegenprobe grün).
- ✅ **Etappe 2 Teil B (2026-09-10): Live-Sync als Nautobot-Job — DURCH.** Governance (User 2026-09-09):
periodische externe→Nautobot-Syncs leben als **Nautobot-Jobs** in `bf-infra/jobs/`, in Nautobot geplant —
**kein per-Task-Container/-Cron.** Runtime `jobs/cf_estate_sync.py` (`CFEstateSync`, ORM, read-only Pull,
403-tolerant, Verwaisung = `extra_config.stale` statt Löschen). Token = Nautobot-Secret `cf-api-token`
(Provider env → `CF_API_TOKEN` am Worker, in `210-nautobot.yml` verdrahtet). **Schedule: täglich 03:00Z**
(`ScheduledJob "CF Estate Sync – taeglich"`). Verifiziert: Dry-Run + Commit-Run sauber, **4 Networks /
14 Services, alle Endpoints lesbar, 0 Drift**. Der REST-Einmalproof `nautobot/tp44-cf-sync.py` bleibt als
workstation-seitiges Diagnose-Werkzeug liegen (nicht die kanonische Runtime).
- 🔴 **Drei load-bearing Funde (Detail-Handoff `handoff-20260910-tp44-teilb-sync-live.md`):**
(1) **Wurzel-`__init__.py` im Repo ist Pflicht** — Nautobot lädt Git-Repo-Jobs via
`pkgutil.walk_packages([GIT_ROOT])`, das Namespace-Packages (ohne `__init__.py`) NICHT entdeckt; ohne die
Datei bleibt `bf_infra.jobs` unsichtbar (Symptom: Sync SUCCESS + „No jobs were registered"). bf-infra ist
das erste Git-Repo mit `extras.job`. (2) `register_jobs()` gehört ins **Paket-`__init__`**, nicht nur ins
Submodul. (3) `Meta.has_sensitive_variables=False` nötig, sonst verweigert Nautobot das Scheduling.
- **Beziehung zu TP37:** TP44 hat **TP37 Punkt 3** (CF-Connectoren) vorweggenommen — dieselbe native-Modell-
Linie, die TP37 P1+2 (Substrat/Dienste) fortsetzt.
### TP41 — CF-Access-Reparatur + Zero-Trust-Konsolidierung ▸ ✅ **ABGESCHLOSSEN (2026-09-10)** — Auth-Kern seit 2026-09-01 komplett; **Gelis WARP-Client am 2026-09-10 via Android erfolgreich eingerichtet** (letzter Blocker weg, User-Bestätigung). Optionale Restpunkte (T6 Rate-Limit, geli-CGNAT-Policy-Cleanup) bewusst nicht gezogen; Keystore-Rotation läuft unter TP30 #7.
**Auslöser:** CF-Access zwang Christoph **und Geli** täglich zum OTP-Login (soll: 30 Tage); GitHub/Google
„funktionieren nicht". Root-Causes: Team-Domain-Rename `bf4`→`emsenhuber` (Provider-Callback veraltet),
App-Session 24h, diverse Ordnungs-/Sicherheitslecks. Vollständiger Verlauf + offene Schritte:
**[`docs/handoff-20260901-tp41.md`](handoff-20260901-tp41.md)**. Branch `tp41-cf-access-repair`.
**✅ Live erledigt:** Session 720h (Wildcard/vw/Warp-Login) · login_method-Loch zu (reusable Policy
`bf-users` = nur `email:christoph`+`email:geli`) · `8e44f5d1` von 4 Apps auf **nur Terpenfinder**
entkoppelt · Access-**Gruppen** `zt-humans`/`zt-home`/`zt-automation`, Policies zeigen darauf · **vw voll
Bypass** (Lebensader offen) + **`vw/admin` per WAF-Regel öffentlich geblockt** (CF-Edge + Mobilfunk
verifiziert) · API-Token auf das vollständige `…4148` konsolidiert (User hat Service-Tokens- + Zero-Trust-
Write ergänzt), altes `…2174` revoken.
**✅ T4 DURCH (2026-09-01, Variante B):** ein Access-Service-Token **`zt-svc`** (`65f1821a`, rotiert) über
Gruppe `zt-automation`; Terpene-Worker per `wrangler secret put TERPENE_SVC_CLIENT_ID` auf zt-svc
umgestellt (Worker-Pin `index.js:44`); `terpene-verify`+`-v2` **gelöscht**; `test_whoami` grün.
**Token-Altlast geklärt:** `b00722` = LIVE Caddy-DNS-Token (LXC130 caddy.env, SSoT), `d47435` = stale
Kopie (kein Consumer) → **User revoket `d47435`**; `credentials.env`-Kopie auf b00722 realignt.
**✅ T3 APPLIED (2026-09-01):** Default-Profil (`0197d1b3`; das custom „Cloudflare Mesh" matcht nur den
`warp_connector`) `fallback_domains += emsenhuber.net → [10.40.20.36, 10.40.20.37]`; Tunnel-Route
`10.40.0.0/16` (`d1da7c8a`) da, kein `10/8`-Exclude → routbar. ⏳ Client-Verify: WARP neu verbinden.
**✅ T2 DURCH (2026-09-01):** WAF-Regel `f26744eb` gelöscht; Caddy `vw`-Block `respond @cf_admin 404` bei
Header `CF-Connecting-IP` (LXC130). Verify: Edge `/admin`=404, lokal/WARP `/admin`=200. ✅
**✅ T5 DURCH (2026-09-01, User-bestätigt):** GitHub-Login läuft; Google-Login läuft nach dem
Consent-Screen-Fix (§A des Follow-up-Handoffs: User Type *Internal*→*External*/veröffentlicht).
Callback für beide `https://emsenhuber.cloudflareaccess.com/cdn-cgi/access/callback`.
**❌ Facebook/Meta für TP41 abgesagt (2026-09-01, User-Entscheid):** optional, kein Bedarf — Geli ist
über OTP `angelikahy@outlook.de` + Google `pillepalle670@gmail.com` voll gedeckt. **Keine Facebook-App,
kein CF-Facebook-IdP angelegt → nichts aufzuräumen.** Instagram hat ohnehin keinen CF-IdP.
**✅ App-Launcher (D1):** je eine Bookmark-Kachel vw/hass/terpenfinder, Wildcard-Kachel raus, Launcher
gestylt (Follow-up-Handoff §D, Policies unverändert).
**✅ Geli in WARP — CF-seitig nichts zu tun (2026-09-01 live geprüft):** Device-Enrollment läuft über
die App **„Warp Login App"** (`6c32fe23…`, type `warp`) → Policy `bf-users` → Gruppe **`zt-humans`**, die
Gelis beide Mails **schon enthält** → sie **darf bereits enrollen** (deshalb war „Device enrollment
permissions" nicht als fehlendes Setting zu finden). Terpenfinder-`geli`-Policy lässt sie per E-Mail durch.
✅ **Client am 2026-09-10 via Android erfolgreich eingerichtet** (WARP installiert, Team `emsenhuber`,
Login OTP `angelikahy@outlook.de` — User-Bestätigung); damit ist der einzige verbliebene Handgriff erledigt.
🔑 **Permission-Frage beantwortet:** CF-seitig **keine** nötig. Für generelle WARP/Enrollment/User-Verwaltung
per Account-Token: *Access: Apps and Policies → Edit* + *Access: Organizations, IdPs, and Groups → Edit*
(User erteilt 2026-09-01). **Seat-Verwaltung (`/access/seats`) bleibt per MCP gesperrt** — `10405 Method
not allowed for this authentication scheme` (Endpoint will User-Token, nicht Account-Token; kein Scope-Fix,
für Enroll irrelevant).
**🔻 Optionale Restpunkte (bewusst nicht gezogen, kein Blocker):** **T6** optional Rate-Limit ·
🔴 `TERPENE_ANDROID_KEYSTORE_PW`-Rotation (→ **TP30 Posten #7**, Transkript-Leak) · **Security-Cleanup:**
die `geli`-Terpenfinder-Policy hat **OR-Semantik** und enthält den breiten CGNAT-Bereich
`94.154.138.0/24` als IP-Include → jeder aus dieser geteilten Range käme **ohne Login** rein. Über WARP ist
der Egress ohnehin Cloudflare (nicht diese IP) → der IP-Include wäre dann überflüssig und entfernbar.
**d47435-Revoke ✅ · T3-WARP-Client-Verify ✅** (User, 2026-09-01).
**Abgrenzung:** hass/gitea bleiben (diese Runde) öffentlich; Terpenfinder-Human-Policies nicht angefasst;
**Gitea-Least-Privilege** = eigener künftiger TP (jedes Projekt repo-scoped Login, Admin nur Claude/Christoph).
- Bezug **TP11** (Monitoring): eine Plattenfüllstand-Warnung hätte das Wochen früher gezeigt.
### TP43 — dw-Standort-DNS-Uplink (site-spezifische Overrides) ▸ ♻️ **REOPENED 2026-09-11 → Volltext zurück in [`teilprojekte.md`](teilprojekte.md) (Abschnitt TP43)**
Kurz zwischen 2026-09-11 verworfen und am selben Tag reopened: die 420-Prämisse war gegenstandslos
(public CF-Worker, via WARP/TP41 gelöst), aber die **interne** BF-Namensauflösung über WG am dw blieb
dabei offen (`portainer.bf.emsenhuber.net` am dw nicht erreichbar). Korrigierter Scope + verworfene
420-Historie stehen jetzt aktiv in `teilprojekte.md`. Gitea-Issue #32 = `status:todo` · `thema:firewall-dns`.
### TP42 — Namens-Vereinheitlichung: ein interner Suffix bf.emsenhuber.net ▸ ✅ **DURCH (2026-09-02)** — ein interner Suffix `bf.emsenhuber.net`, `.bf.lan` raus, `.16` (adguard_bf1) abgebaut, Compliance 140/140. Offen nur der an **TP37** gekoppelte Nautobot-Doku-Teil.
**Auslöser (2026-09-01, TP41-Randbefund):** live gemessen liefern die realen Client-Resolver
`10.40.20.36`/`.37` `*.emsenhuber.net → 10.40.20.40` (Caddy) — korrekt. Daneben existiert aber ein
zweiter, gedrifteter interner Namensraum: der **Core** trägt in `/ip dns static` 11 Einträge auf
`*.bf.lan`, der **Caddyfile** doppelt jeden internen Namen als `*.bf.emsenhuber.net`, und die alten
AdGuard `.16`/`.17` antworten noch mit `nginx*.bf.emsenhuber.net` bzw. totem VLAN1 `10.40.41.123`.
Christoph: „aus emsenhuber.net wurde schon wieder bf.lan — das müssen wir ein für alle mal aus allen
Geräten rausprügeln und in Nautobot festhalten."
**Ziel:** genau **ein** interner Namensraum `emsenhuber.net` (Split-Horizon `.36/.37 → .40`). `.bf.lan`
und `.bf.emsenhuber.net` werden entfernt; Sollzustand in Nautobot dokumentiert.
**Scope (Reihenfolge = eigene Session):**
1. **Bestandsaufnahme** aller Fundstellen: Core `/ip dns static` (`*.bf.lan`), DHCP-Option
`domain`/Search-Domain je Netz, Caddyfile-Aliase (`*.bf.emsenhuber.net`), AdGuard-Rewrites `.36/.37`,
stale `.16/.17`, Geräte-`identity`.
2. **Entscheidung Zielschema** (nur `emsenhuber.net`, ggf. `bf.emsenhuber.net` als *einzige* interne
Zone — Christoph-Entscheid) und Migrationsreihenfolge ohne DNS-Loch.
3. **Umsetzen:** Core-DNS + DHCP + Caddyfile angleichen; stale `.16/.17` klären/abbauen.
4. **Nautobot:** interne Namen/Records als Sollzustand erfassen (Bezug TP37 Datenmodell).
**Abgrenzung:** kein CF-Public-DNS-Umbau (Zone `emsenhuber.net` öffentlich bleibt); kein Resolver-Swap
(`.36/.37` bleiben); `.1`-als-DNS-Reste auf Clients sind separat/tolerierbar (User: „bis jetzt kein
Problem"). **Abh.:** TP37 (Nautobot-Datenmodell) für Punkt 4; sonst nichts Offenes.
#### ✅ Bestandsaufnahme LIVE (2026-09-02) — Drift hat 80 % schon erledigt
Gegen die Geräte gemessen (MikroMCP + dig), nicht aus dem Handoff:
| Fundstelle | Handoff 09-01 | Live 09-02 |
|---|---|---|
| Core `/ip dns static` | 11× `*.bf.lan` | ✅ **0× `.bf.lan`** — 10× `*.bf.emsenhuber.net` (deckt sich mit GC-Template Z.284–293) |
| DHCP `domain` (7 Netze) | „prüfen" | `emsenhuber.net` (GC-Template Z.133 = gleich ⇒ **keine Drift**), DNS `.36/.37` |
| `.36/.37` (Soll) | aktiv | `vw.emsenhuber.net→.40` ✅ · `macmini.bf.emsenhuber.net→.20.167` ✅ · **`macmini.emsenhuber.net→leer`** ❌ |
| Caddyfile | `*.bf.emsenhuber.net`-Aliase | unverändert, **konsistent** mit Core-Static |
| `.16`/`.17` | tot | laufen (:53), liefern totes VLAN1; **kein Core-Objekt** (Firewall/NAT/DNS-Upstream/Addr-List) hängt an `.16` |
**Kernkonflikt:** DHCP verteilt `emsenhuber.net` (bare), Records leben unter `bf.emsenhuber.net` ⇒ bare `macmini` löst nicht.
#### ✅ Entscheidungen (User, 2026-09-02)
1. **Zielschema = `bf.emsenhuber.net`** (der wenig-Arbeit-Weg): DHCP-domain → `bf.emsenhuber.net`, dann
löst `macmini` bare korrekt; Core-Static + Caddyfile bleiben (tragen schon `.bf.`). Öffentliche Zone
`emsenhuber.net` bleibt getrennt.
2. **`.16` (adguard_bf1) abbauen**, **`.17` (adguard_fm2 = Standort FM) NICHT anfassen.**
#### ✅ Umsetzung DURCH (2026-09-02)
- **(A) DHCP-domain `emsenhuber.net → bf.emsenhuber.net` über GC ✅** — kein Direkt-Write:
`mikrotik_routeros.j2` Z.133 gehoben → `push-gc-template.py` (Commit `7a4068c4`, **Nebenbefund:** das
Remote-Template hing dem lokalen hinterher — es trug noch `*.bf.lan`+`router.lan`, obwohl Gerät+lokal
längst `.bf.emsenhuber.net` fuhren; der Push hat das GC-Repo an den Live-Stand angeglichen) →
GitRepo-Sync (SUCCESS) → manueller ConfigPlan **`tp42-dhcp-domain`** (`set [find] domain=…`, weil
`add` das Netz doppelt anlegen würde) → Deploy an **crs326-core** → Live **7/7 = bf.emsenhuber.net**,
Compliance **140/140, keine Drifts**. Der Job steht dauerhaft in `nautobot/gc-configplan.py`.
- **(B) `.16`-Teardown ✅** — `adguard_bf1` lag im geteilten Portainer-Stack **195 `adguard`** (Docker-LXC
`.126`, **ep2** — *nicht* ep14) **zusammen mit `adguard_fm2` (`.17`, Standort FM!)**. Deshalb **nicht**
Stack löschen, sondern compose auf nur `.17` getrimmt + Stack redeployt (Prune): `.16`-Container weg,
`.16:53` tot; **`.17` läuft** (⚠️ ~40 s mit-neugestartet durch den Redeploy — kurzer FM-DNS-Blip,
danach sauber). Rollback-compose gesichert. 🧹 Daten-Dirs `/opt/docker/adguard_bf1/*` bleiben als
harmlose Leichen auf dem LXC.
- **(C) Nautobot-Soll** (Scope-Punkt 4) bleibt an **TP37** gekoppelt (Datenmodell), separat — kein Blocker.
**Status:** ✅ **Namensraum vereinheitlicht (2026-09-02)** — ein interner Suffix `bf.emsenhuber.net`,
`.bf.lan` raus, `.16` abgebaut, Compliance 140/140. Offen nur der TP37-gekoppelte Nautobot-Doku-Teil.
Handoff: [`docs/handoff-20260901-tp42-naming.md`](handoff-20260901-tp42-naming.md).

File diff suppressed because it is too large Load Diff

View File

@@ -0,0 +1,76 @@
# TP23 Stufe 6 — DNS-Bypass-Sperre (Runbook für eine SEPARATE, VOR-ORT-Session)
> 🔴🔴 **HARTES GATE: NUR VOR ORT ausführen. NICHT aus der Ferne, nicht während Christoph
> abwesend ist.** (Notiert 2026-09-06: Christoph ist ~1 Woche nicht vor Ort → in diesem Fenster
> **gar nicht anfangen**, auch nicht die log-only-Vorstufe scharf lassen.)
>
> Grund: Die Sperre macht das AGH-Paar `.36`/`.37` zum **harten DNS-SPOF**. Bis heute kann jeder
> Client bei einem AGH-Ausfall auf einen externen Resolver ausweichen; **nach** der Sperre nicht
> mehr — ein AGH-Ausfall = **hausweiter DNS-Ausfall** (betrifft die Familie), und ohne physischen
> Zugriff gibt es keinen schnellen Rollback. Eine falsch platzierte Drop-Regel kann außerdem den
> **Fernzugang selbst** (WG/cf-mesh) aussperren, mit dem man den Fehler zurücknehmen wollte.
## Ziel
Clients dürfen plain **DNS (udp/tcp 53)** und **DoT (853)** nur noch zu den erlaubten Resolvern
(`10.40.20.36`, `10.40.20.37`, Core `10.40.X.1`) schicken. Externe DNS-Server (Smart-TV mit
`8.8.8.8` hartkodiert, App-eigene Resolver) werden geblockt → **kein Umgehen des Filters**.
Das ist der letzte Baustein von TP23 und lebt in der **TP5-Firewall** (`forward`-Kette).
## Voraussetzungen
**Erfüllt (Stand 2026-09-06):**
- Self-Service-Oberfläche steht und ist getestet (HA-Dashboard `dns-ausnahmen`, Stufe 5) → ein
geblockter Dienst kann **ohne Admin** temporär freigegeben werden. Das war die harte
Reihenfolge-Regel („erst der Ersatz, dann die Sperre").
- `dns-bypass-exempt`-Gruppe existiert auf dem Resolver-Paar (AGH-Client-Seite).
**Noch zu bauen (Teil dieser Session, VOR dem Drop):**
- **Firewall-Exempt** ist noch NICHT da: eine Address-List `dns-bypass-exempt` (permanent) mit dem
dev-MacBook (`10.40.10.183` **und** `10.40.10.82`, dual-homed) + Agent-Toolchain, plus eine
`accept`-Regel **vor** dem Drop. Ohne die verliert der Entwicklungsrechner seinen Ausweg.
- Ad-hoc-JIT: Address-List `jit-dns-bypass` mit `timeout` nach dem Muster `jit-admin`
(`routeros/tp5-etappe4-input-mgmt.rsc`) — selbstverfallende Freigabe.
## Bekannte Grenze (offen benennen, nicht „lösen")
Die Sperre greift auf **Port** (53/853). **DoH läuft über 443** und ist damit portgleich zu HTTPS —
ein Gerät, das DoH gegen `8.8.8.8:443` fährt, umgeht die Sperre. Das per SNI/IP zu schließen ist
ein eigenes, größeres Thema (nicht Teil von TP23). Für den Alltag (TVs/IoT mit Plain-DNS) reicht die
Port-Sperre.
## Sichere Methodik — log-only zuerst, Drop zuletzt
1. **Exempt + JIT bauen** (via Nautobot GC, `ip-firewall-filter` steht unter Drift-Kontrolle → **kein
Direkt-Write**): `accept` für `dns-bypass-exempt`/`jit-dns-bypass` → 53/853, platziert **vor** der
künftigen Drop-Regel. Erst hier abnehmen, dass die Exempts wirklich durchkommen.
2. **Log-only-Vorstufe**: eine Regel `TP5-WOULD-DROP-DNS`, die LAN→extern auf `dst-port 53,853`
(udp+tcp), **nicht** zu `.36/.37/Core`, **nur loggt** (in den Kollektor `10.40.20.18:514`, wie die
bestehende `TP5-WOULD-DROP`). **Mehrere Tage laufen lassen** und den Drop-Log lesen: *welche*
Geräte reden mit *welchen* externen Resolvern? Jedes davon ist ein Kandidat, der nach dem Drop
bricht — vorab entscheiden (Reservierung auf AGH, Exempt, oder bewusst brechen lassen).
🔑 Merkregel aus dem E5-Drop-Log: Geräte fallen oft mit **udp/161/andere** nebenbei auf — nur die
53/853-Zeilen zählen hier.
3. **Erst nach ruhigem/verstandenem Log**: die Log-only-Regel auf `action=drop` (oder `reject` mit
`icmp-port-unreachable`, damit Clients schneller auf den nächsten Resolver fallen) heben —
**mit Auto-Revert-Absicherung** (Scheduler/Netwatch, der die Regel nach X Minuten deaktiviert,
falls nicht bestätigt), analog zum TP5-E3/E4-Vorgehen. **Vor Ort**, mit offener Konsole.
## Was NICHT gesperrt werden darf (sonst Selbst-Aussperrung)
- `.36`/`.37` → CF-DoH-Upstream (443) und Core-Resolver-Egress: die Resolver müssen raus.
- Core `10.40.X.1` DoH-Egress.
- **cf-mesh / WG-Pfad** (Fernzugang) — die Drop-Regel matcht nur `dst-port 53,853`; trotzdem vor dem
Scharfschalten gegenprüfen, dass Management-Input (`cf-mesh`, HA `8728`, Nautobot `22`) unberührt
bleibt.
## Rollback
- GC-Deploy der vorherigen Version (Regel zurück auf `disabled`/entfernt) — bzw. der Auto-Revert.
- Fällt das AGH-Paar bei aktiver Sperre aus: Drop-Regel deaktivieren (Vor-Ort-Konsole) → Clients
können sofort wieder externe Resolver nutzen.
## Abnahme
- Exempt-Host (dev-MacBook) löst extern weiter auf; ein Test-Gerät mit hartkodiertem `8.8.8.8` löst
**nicht** mehr (aber über AGH schon).
- Self-Service: eine geblockte Domain per HA-Button freigeben → wirkt; nach Ablauf wieder gefiltert.
- Compliance nach dem GC-Deploy grün (`python3 nautobot/gc-transaktion.py status`, GC 140/140).
## Verweise
- Stufe 4/5 (fertig): `adguard/README.md`, `adguard/ha-self-service.md`, `adguard/agh-exception.py`.
- JIT-/Firewall-Muster: `routeros/tp5-etappe4-input-mgmt.rsc`; GC-Pipeline: `nautobot/gc-configplan.py`.
- Kontext/Reihenfolge-Regel: TP23-Abschnitt in `docs/teilprojekte.md`.

View File

@@ -0,0 +1,8 @@
# TP25 — sec-main zurueck auf ft=yes / ft-over-ds=yes (Ruecknahme der 09-04-Entscheidung "ft=no als Dauerzustand")
# Go: Christoph 2026-09-14 ("go fuer ft=yes, dry-run vorlegen"), Terrasse-In-situ-Session
# Anlass: 2 Call-Aussetzer + ~30 Roams in 25 min — mit ft=no ist jeder Roam (Band- und AP-Wechsel)
# eine Voll-Reassoziation in Sekundenhoehe; genau darin sterben Anrufe.
# Nachweis, dass ft-over-ds=yes + 7.24.1 ruhig ist: Fund-E-Abschlussmessung 09-02 (4 reauth/8,6 h, 0 Ausfaelle).
# Nur am Manager noetig: sec-main wird per CAPsMAN an alle CAPs verteilt (Uniformitaet per Konstruktion);
# Inline-Overrides je CAP gibt es seit dem ap3-Fix 09-04 nicht mehr — Abnahme prueft sie trotzdem (Merkregel).
/interface wifi security set sec-main ft=yes ft-over-ds=yes

View File

@@ -0,0 +1,10 @@
# TP25 — 5G bricht frueher zur 2.4G ab (Terrasse sass am Rundgang 09-15 auf der -80/5G-Kante)
# Go: Christoph 2026-09-15 ("committen und threshold deployen")
# Nur 5G: neues Steering-Profil st-main-5g mit transition-threshold=-72 (statt Default -80) und
# transition-threshold-time=5s (statt 10s). 2G bleibt auf st-main (unset -80) — Reichweite draussen.
# Nur am Manager noetig: steering/config werden per CAPsMAN an die CAPs verteilt.
# Rollback = steering der drei Configs zurueck auf st-main + st-main-5g loeschen.
/interface wifi steering add name=st-main-5g neighbor-group=bf-main rrm=yes wnm=yes transition-threshold=-72 transition-threshold-time=5s
/interface wifi configuration set [find name=cfg-main-5g-ap1] steering=st-main-5g
/interface wifi configuration set [find name=cfg-main-5g-ap2] steering=st-main-5g
/interface wifi configuration set [find name=cfg-main-5g-ap3] steering=st-main-5g

View File

@@ -84,7 +84,7 @@ dns:
ipset_file: ""
bootstrap_prefer_ipv6: false
upstream_timeout: 10s
private_networks: []
private_<redacted>: []
use_private_ptr_resolvers: false
local_ptr_upstreams: []
use_dns64: false

14
jobs/__init__.py Normal file
View File

@@ -0,0 +1,14 @@
"""bf-infra Nautobot-Jobs (Git-Datenquelle).
Nautobot importiert nur dieses Paket; damit die enthaltenen Jobs sich
registrieren, muss jedes Job-Modul hier importiert werden. Neue periodische
externe->Nautobot-Syncs kommen als weiteres Modul dazu (kein per-Task-Container).
"""
from nautobot.apps.jobs import register_jobs
from .cf_estate_sync import CFEstateSync
# Nautobot importiert nur dieses Paket (bf_infra.jobs) und erwartet register_jobs()
# HIER im __init__ (nicht im Submodul) — sonst: "No jobs were registered on loading
# the bf_infra.jobs submodule". Neue Jobs: Klasse importieren + hier mitregistrieren.
register_jobs(CFEstateSync)

267
jobs/cf_estate_sync.py Normal file
View File

@@ -0,0 +1,267 @@
"""
TP44 Teil B — CF-Estate → Nautobot, als geplanter Nautobot-Job (ORM).
Kanonische Runtime des CF→Nautobot-Sync. Laeuft im nautobot-worker (kein extra
Container), schreibt per ORM (keine Nautobot-Exposure), zieht die CF-API outbound.
Portierung der Reconcile-Logik aus nautobot/tp44-cf-sync.py (REST) auf das ORM.
Governance (User 2026-09-09): periodische externe->Nautobot-Syncs leben als
Nautobot-Jobs in bf-infra/jobs/ und werden in Nautobot geplant — KEIN per-Task-
Container/-Cron. Kuenftige Syncs = weitere Jobs hier.
Deckung: CloudNetwork (cfd_tunnel + warp_connector), CloudService (workers,
access-apps, hyperdrive, VPC), Prefix-Assignments (teamnet/routes), Verwaisung
(stale-Markierung statt Loeschen). ID-Matching + extra_config-Merge wie im Skript.
Token: Nautobot-Secret "cf-api-token" (Provider environment-variable -> CF_API_TOKEN
am Worker). CF-Account-ID: Secret "cf-account-id" ODER Konstante unten.
CF bleibt operativer Master; Nautobot ist Dokumentations-SSoT (read-only Pull).
"""
import json
import urllib.request
import urllib.parse
import urllib.error
from django.contrib.contenttypes.models import ContentType
from nautobot.apps.jobs import BooleanVar, Job
from nautobot.cloud.models import (
CloudAccount,
CloudNetwork,
CloudNetworkPrefixAssignment,
CloudResourceType,
CloudService,
)
from nautobot.dcim.models import Manufacturer
from nautobot.extras.models import Secret
from nautobot.ipam.models import Prefix
CF_API = "https://api.cloudflare.com/client/v4"
CF_ACCOUNT_ID = "393c051f3accf51881d6c98fc5b66c36"
RESOURCE_TYPES = [
("Cloudflare cloudflared Tunnel", "cloud", "cloudnetwork"),
("Cloudflare WARP Connector", "cloud", "cloudnetwork"),
("Cloudflare VPC Service", "cloud", "cloudservice"),
("Cloudflare Hyperdrive", "cloud", "cloudservice"),
("Cloudflare Worker", "cloud", "cloudservice"),
("Cloudflare Access Application", "cloud", "cloudservice"),
]
class CFEstateSync(Job):
dryrun = BooleanVar(
default=True,
description="Nur berichten, nichts schreiben (empfohlen fuer den ersten Lauf).",
)
class Meta:
name = "CF Estate Sync"
description = "Cloudflare-Estate (Tunnel/Worker/Access/Hyperdrive/VPC) nach Nautobot syncen (Doku-SSoT)."
grouping = "TP44 / Cloudflare"
# Nur ein Boolean (dryrun) als Eingabe; das CF-Token kommt aus dem Nautobot-Secret,
# nicht aus einer Job-Variable. Ohne diese Zeile (Default True) verweigert Nautobot
# das Scheduling: "Job may have sensitive input variables".
has_sensitive_variables = False
# ---------------------------------------------------------------- CF-Pull
def _cf_get(self, path):
"""(ok, result) — 403/404 werden abgefangen, damit fehlende Scopes den Sync nicht kippen."""
req = urllib.request.Request(CF_API + path, headers={"Authorization": "Bearer " + self._tok})
try:
with urllib.request.urlopen(req, timeout=30) as r:
return True, json.load(r).get("result")
except urllib.error.HTTPError as e:
if e.code in (403, 404):
return False, None
raise
def _ingress(self, tunnel_id):
ok, res = self._cf_get(f"/accounts/{CF_ACCOUNT_ID}/cfd_tunnel/{tunnel_id}/configurations")
rules = ((res or {}).get("config") or {}).get("ingress") or [] if ok else []
return [r["hostname"] for r in rules if r.get("hostname")]
def _load_cf(self):
"""networks/services: (name, rt_name, desc, extra, match_key, match_val).
routes: {tunnel_id: cidr}. skipped: Liste nicht lesbarer Endpoints."""
A = CF_ACCOUNT_ID
networks, services, routes, skipped = [], [], {}, []
_, tuns = self._cf_get(f"/accounts/{A}/cfd_tunnel?is_deleted=false&per_page=50")
for t in (tuns or []):
networks.append((t["name"], "Cloudflare cloudflared Tunnel",
f"cloudflared-Tunnel ({len(t.get('connections') or [])} Connectoren)",
{"tunnel_id": t["id"], "kind": "cloudflared",
"connector_count": len(t.get("connections") or []),
"ingress_hostnames": self._ingress(t["id"])},
"tunnel_id", t["id"]))
_, warps = self._cf_get(f"/accounts/{A}/warp_connector?per_page=50")
for w in (warps or []):
networks.append((w["name"], "Cloudflare WARP Connector",
f"WARP-Connector ({len(w.get('connections') or [])} Connectoren)",
{"tunnel_id": w["id"], "kind": "warp_connector",
"connector_count": len(w.get("connections") or [])},
"tunnel_id", w["id"]))
_, scripts = self._cf_get(f"/accounts/{A}/workers/scripts")
for s in (scripts or []):
services.append((s["id"], "Cloudflare Worker", "Cloudflare Worker",
{"script": s["id"]}, "script", s["id"]))
ok, apps = self._cf_get(f"/accounts/{A}/access/apps?per_page=100")
if not ok:
skipped.append("access/apps")
for a in (apps or []):
services.append((a.get("name") or a.get("id"), "Cloudflare Access Application",
f"Access-App ({a.get('type')})",
{"id": a.get("id"), "type": a.get("type"), "domain": a.get("domain")},
"id", a.get("id")))
ok, hyper = self._cf_get(f"/accounts/{A}/hyperdrive/configs")
if not ok:
skipped.append("hyperdrive/configs")
for h in (hyper or []):
origin = h.get("origin") or {}
services.append((h.get("name") or h.get("id"), "Cloudflare Hyperdrive", "Hyperdrive-Config",
{"id": h.get("id"), "database": origin.get("database"),
"user": origin.get("user")}, "id", h.get("id")))
ok, vpc = self._cf_get(f"/accounts/{A}/connectivity/directory/services")
if not ok:
skipped.append("connectivity/directory/services")
for v in (vpc or []):
# VPC-Directory-Services tragen ihren Identifier in "service_id" (NICHT "id").
sid = v.get("service_id") or v.get("id")
services.append((v.get("name") or sid, "Cloudflare VPC Service", "VPC-Service",
{"service_id": sid, "type": v.get("type")}, "service_id", sid))
ok, rts = self._cf_get(f"/accounts/{A}/teamnet/routes?per_page=50")
if not ok:
skipped.append("teamnet/routes")
for r in (rts or []):
if r.get("network") and r.get("tunnel_id"):
routes[r["tunnel_id"]] = r["network"]
return networks, services, routes, skipped
# ---------------------------------------------------------------- ORM-Upsert
def _upsert(self, model, cache, name, rt, acct, desc, extra, mk, mv, label, seen, dryrun):
# mv=None nie matchen: sonst greift .get(mk)==None auf das erste Objekt OHNE mk
# und mischt fremde extra_config zusammen (z.B. VPC ohne id -> App-Launcher).
if mv is None:
self.logger.warning("~ %s '%s' ohne Match-Wert (%s) — uebersprungen", label, name, mk)
return None
ex = next((o for o in cache if (o.extra_config or {}).get(mk) == mv), None)
if ex:
seen.add(ex.id)
merged = dict(ex.extra_config or {})
merged.update(extra)
if merged == (ex.extra_config or {}):
return ex
if dryrun:
self.logger.info("~ %s '%s': extra_config-Update [DRY-RUN]", label, ex.name)
return ex
ex.extra_config = merged
ex.validated_save()
self.logger.info("~ %s '%s' aktualisiert", label, ex.name)
return ex
if dryrun:
self.logger.info("+ %s '%s' [DRY-RUN]", label, name)
return None
obj = model(name=name, cloud_resource_type=rt, cloud_account=acct,
description=desc, extra_config=extra)
obj.validated_save()
cache.append(obj)
seen.add(obj.id)
self.logger.info("+ %s '%s' angelegt", label, name)
return obj
def _mark_stale(self, cache, seen, label, dryrun):
for o in cache:
extra = o.extra_config or {}
if o.id in seen:
if extra.get("stale") and not dryrun:
o.extra_config = {k: v for k, v in extra.items() if k != "stale"}
o.validated_save()
self.logger.info("↩ %s '%s': stale entfernt (wieder da)", label, o.name)
continue
if extra.get("stale"):
continue
if dryrun:
self.logger.warning("⚠ %s '%s' fehlt im Live-Pull → wuerde stale markiert [DRY-RUN]", label, o.name)
continue
o.extra_config = dict(extra, stale=True)
o.validated_save()
self.logger.warning("⚠ %s '%s' als stale markiert (nicht mehr in CF)", label, o.name)
# ---------------------------------------------------------------- run
def run(self, dryrun=True):
try:
self._tok = Secret.objects.get(name="cf-api-token").get_value()
except Secret.DoesNotExist:
raise RuntimeError("Nautobot-Secret 'cf-api-token' fehlt — bitte anlegen (Provider env, CF_API_TOKEN).")
networks, services, routes, skipped = self._load_cf()
self.logger.info("Live-Pull: %d CloudNetworks · %d CloudServices%s",
len(networks), len(services),
f" · SKIP: {', '.join(skipped)}" if skipped else " · alle Endpoints lesbar")
mfr, _ = Manufacturer.objects.get_or_create(name="Cloudflare")
acct, created = CloudAccount.objects.get_or_create(
name="Cloudflare", defaults={"account_number": CF_ACCOUNT_ID, "provider": mfr})
if created and dryrun:
pass
rt_by_name = {}
for name, app, model_name in RESOURCE_TYPES:
ct = ContentType.objects.get(app_label=app, model=model_name)
rt, _ = CloudResourceType.objects.get_or_create(name=name, defaults={"provider": mfr})
rt.content_types.add(ct)
rt_by_name[name] = rt
net_cache = list(CloudNetwork.objects.filter(cloud_account=acct))
svc_cache = list(CloudService.objects.filter(cloud_account=acct))
seen_net, seen_svc = set(), set()
self.logger.info("[CloudNetworks]")
for name, rt_name, desc, extra, mk, mv in networks:
self._upsert(CloudNetwork, net_cache, name, rt_by_name.get(rt_name), acct,
desc, extra, mk, mv, "CloudNetwork", seen_net, dryrun)
self.logger.info("[CloudServices]")
for name, rt_name, desc, extra, mk, mv in services:
self._upsert(CloudService, svc_cache, name, rt_by_name.get(rt_name), acct,
desc, extra, mk, mv, "CloudService", seen_svc, dryrun)
self.logger.info("[Prefix-Assignments]")
for tunnel_id, cidr in routes.items():
net = next((n for n in net_cache if (n.extra_config or {}).get("tunnel_id") == tunnel_id), None)
if not net or getattr(net, "id", None) is None:
continue
pfx = Prefix.objects.filter(prefix=cidr).first()
if not pfx:
self.logger.info(" ~ Route %s: Prefix nicht in IPAM → uebersprungen", cidr)
continue
if CloudNetworkPrefixAssignment.objects.filter(cloud_network=net, prefix=pfx).exists():
continue
if dryrun:
self.logger.info(" + %s ↔ %s [DRY-RUN]", net.name, cidr)
continue
CloudNetworkPrefixAssignment(cloud_network=net, prefix=pfx).validated_save()
self.logger.info(" + %s ↔ %s angelegt", net.name, cidr)
self.logger.info("[Verwaisung]")
# CloudServices nur markieren, wenn ALLE Service-Endpoints lesbar waren — sonst
# wuerde ein fehlender Scope echte Objekte faelschlich als verwaist markieren.
svc_safe = not ({"access/apps", "hyperdrive/configs", "connectivity/directory/services"} & set(skipped))
if svc_safe:
self._mark_stale(svc_cache, seen_svc, "CloudService", dryrun)
else:
self.logger.info(" · CloudService-Verwaisung uebersprungen (Token-Scope unvollstaendig)")
self._mark_stale(net_cache, seen_net, "CloudNetwork", dryrun)
self.logger.info("Fertig (%s).", "DRY-RUN — nichts geschrieben" if dryrun else "COMMIT")
# Registrierung zentral in jobs/__init__.py (Nautobot importiert nur das Paket).

View File

@@ -353,10 +353,76 @@ def job_tp42_dhcp_domain():
return [(["crs326-core"], core_set, "TP42-dhcp-domain-bf")]
def job_tp38_oob():
"""TP38 (2026-09-15): OOB-MGMT-Port (ether23 untagged VLAN99) + Branch-Input-Firewall.
Zwei Geraete, zwei config_sets:
* branch: ether23 untaggen, VLAN99 um untagged=ether23 erweitern, 8 Input-Regeln
(deny-by-default). Die Regeln werden in der Reihenfolge angelegt, in der das
Template sie rendert — established zuerst, drop zuletzt — damit kein LOCKOUT:
die laufende Nautobot-SSH-Session (10.40.20.30) matcht auf Regel 1 (established),
bevor Regel 8 (drop) greift.
* core: ether23 untaggen, VLAN99 untagged=ether23, EINE Regel "OOB->core mgmt" mit
place-before vor die Log-Regel (sonst landet sie hinter dem finalen drop und
waere wirkungslos + non-compliant).
KEIN LOCKOUT-RISIKO: ether23 ist auf beiden Geraeten frei (running=false); der
VLAN99-Umbau aendert nur `untagged`, nicht `tagged`; der Deploy laeuft von Nautobot
(10.40.20.30), das in jeder gesetzten Firewall-Freigabe enthalten bleibt.
"""
bridge_set = (
':do { /interface bridge port set [find interface=ether23] pvid=99 '
'frame-types=admit-only-untagged-and-priority-tagged comment="TP38-OOB-MGMT" } '
'on-error={ :log info "tp38: ether23 set geworfen" }'
)
vlan_set = (
':do { /interface bridge vlan set [find vlan-ids=99] untagged=ether23 } '
'on-error={ :log info "tp38: vlan99 untagged geworfen" }'
)
branch_fw = "\n".join([
'add action=accept chain=input comment="TP38: established" connection-state=established,related,untracked',
'add action=drop chain=input comment="TP38: invalid" connection-state=invalid',
'add action=accept chain=input comment="TP38: icmp" protocol=icmp',
'add action=accept chain=input comment="TP38: mndp" dst-port=5678 protocol=udp',
'add action=accept chain=input comment="TP38: mgmt LAN" dst-port=22,80,8291,8728 protocol=tcp src-address=10.40.0.0/16',
'add action=accept chain=input comment="TP38: mgmt mesh" dst-port=22,80,8291,8728 protocol=tcp src-address=100.96.0.0/12',
'add action=log chain=input comment="TP38: input log-only" log-prefix=TP38-BRANCH-WOULD-DROP',
'add action=drop chain=input comment="TP38: input deny-by-default"',
])
branch_set = "\n".join([
bridge_set,
vlan_set,
*[f"/ip firewall filter {ln}" for ln in branch_fw.splitlines()],
':log info ("tp38: branch pvid=" . [:tostr [/interface bridge port get [find interface=ether23] pvid]]'
' . " fw=" . [:tostr [:len [/ip firewall filter find where comment~"TP38"]]] . "/8")',
])
# ⚠️ `add ... place-before=[find ...]` wird ueber Netmiko IGNORIERT (Regel landet am
# Ketten-Ende, also HINTER dem finalen drop = wirkungslos; beim Deploy 2026-09-15 so
# aufgeschlagen). Deshalb: erst add (appends), dann `move` vor die Log-Regel.
core_set = "\n".join([
bridge_set,
vlan_set,
'/ip firewall filter add action=accept chain=input comment="TP38: OOB->core mgmt" '
'dst-port=22,80,8291,8728 in-interface=vlan99 protocol=tcp',
'/ip firewall filter move [find where comment="TP38: OOB->core mgmt"] '
'destination=[find where comment="TP5: input log-only"]',
':log info ("tp38: core pvid=" . [:tostr [/interface bridge port get [find interface=ether23] pvid]]'
' . " oob=" . [:tostr [:len [/ip firewall filter find where comment="TP38: OOB->core mgmt"]]])',
])
return [
(["crs326-branch"], branch_set, "TP38-oob-branch"),
(["crs326-core"], core_set, "TP38-oob-core"),
]
JOBS = {
"drift-cleanup": job_drift_cleanup,
"mgmt-acl": job_mgmt_acl,
"tp42-dhcp-domain": job_tp42_dhcp_domain,
"tp38-oob": job_tp38_oob,
}

199
nautobot/gc-snapshot.py Normal file
View File

@@ -0,0 +1,199 @@
#!/usr/bin/env python3
"""
TP36-Live — Live-Gerätedaten als CustomFields auf den RouterOS-dcim.Device.
Legt (idempotent, get-or-create) fünf CustomFields auf `dcim.device` an und
befüllt sie für jedes RouterOS-Gerät. Die Werte kommen AUSSCHLIESSLICH aus
Nautobot selbst — es wird KEIN Gerät kontaktiert:
ros_version aus der GoldenConfig-`backup_config` ("by RouterOS X.Y.Z")
dhcp_server_count gezählte Einträge der Sektion "/ip dhcp-server" im Backup
dns_upstream_mode aus der "/ip dns"-Sektion des Backups: doh | plain | none
compliance_pct GC config-compliance: compliant / total * 100 (gerundet)
mgmt_ip device.primary_ip4 (ohne /prefix)
Warum aus Nautobot statt live vom Gerät: der MGMT-/REST-Weg (VLAN99:80) ist
nicht aus jedem Vantage erreichbar; die GC-Backups werden täglich (03:30 UTC,
ScheduledJob "GC Backup+Compliance – taeglich") per SSH gezogen und sind die
Doku-SSoT. Damit braucht der Snapshot keine Geräte-Credentials. Aktualität steht
in `backup_last_success_date` — ist die alt, steht der Backup-Schedule (2026-09-12
war er 8 Tage aus, weil es vorher gar keinen gab).
Der Backup-Config-Text wird nur INTERN geparst (Zähler/Modus abgeleitet) und
NIE ausgegeben — er kann gescrubte Reste enthalten (PSK-Leak-Regel).
Token-Quelle: docs/nas-vlan20/stacks/210-nautobot.yml (gitignored),
Schlüssel NAUTOBOT_SUPERUSER_API_TOKEN.
Aufruf:
python3 nautobot/gc-snapshot.py # Dry-Run (default) — zeigt nur an
python3 nautobot/gc-snapshot.py --commit # legt CustomFields an + patcht Devices
"""
import json
import os
import re
import sys
import urllib.request
import urllib.parse
import urllib.error
from pathlib import Path
NB = os.environ.get("NAUTOBOT_URL", "http://10.40.20.30:8080")
REPO = Path(__file__).resolve().parent.parent
YML = REPO / "docs" / "nas-vlan20" / "stacks" / "210-nautobot.yml"
COMMIT = "--commit" in sys.argv
def load_token() -> str:
for line in YML.read_text().splitlines():
m = re.search(r"NAUTOBOT_SUPERUSER_API_TOKEN[=:]\s*([^\s\"']+)", line)
if m:
return m.group(1)
sys.exit(f"NAUTOBOT_SUPERUSER_API_TOKEN nicht in {YML} gefunden")
TOKEN = load_token()
HDRS = {"Authorization": f"Token {TOKEN}", "Accept": "application/json",
"Content-Type": "application/json"}
def req(method: str, path: str, body=None):
data = json.dumps(body).encode() if body is not None else None
r = urllib.request.Request(f"{NB}{path}", data=data, headers=HDRS, method=method)
try:
with urllib.request.urlopen(r, timeout=20) as resp:
return resp.status, json.loads(resp.read().decode() or "{}")
except urllib.error.HTTPError as e:
return e.code, json.loads(e.read().decode() or "{}")
# --------------------------------------------------------------- CustomFields
# (key, label, type, description). content_types wird ergänzt.
CUSTOM_FIELDS = [
("ros_version", "RouterOS-Version", "text",
"RouterOS-Version aus der GC-backup_config (by RouterOS …)."),
("compliance_pct", "GC-Compliance %", "integer",
"Golden-Config config-compliance: compliant/total in Prozent."),
("dhcp_server_count", "DHCP-Server", "integer",
"Anzahl Einträge der Sektion /ip dhcp-server im GC-Backup."),
("mgmt_ip", "Mgmt-IP", "text",
"device.primary_ip4 ohne Prefix (VLAN99-Management)."),
("dns_upstream_mode", "DNS-Upstream-Modus", "text",
"Aus /ip dns des GC-Backups: doh | plain | none."),
]
CF_KEYS = [c[0] for c in CUSTOM_FIELDS]
def ensure_custom_fields():
"""get-or-create die fünf CFs; bei Bestand: content_type dcim.device sicherstellen."""
st, d = req("GET", "/api/extras/custom-fields/?limit=0")
have = {r["key"]: r for r in d.get("results", [])}
for key, label, typ, desc in CUSTOM_FIELDS:
ex = have.get(key)
if ex:
cts = ex.get("content_types", [])
ok = "dcim.device" in cts
print(f" = CF '{key}' existiert ({ex['id']}){'' if ok else ' ⚠ ohne dcim.device!'}")
if not ok and COMMIT:
req("PATCH", f"/api/extras/custom-fields/{ex['id']}/",
{"content_types": sorted(set(cts) | {"dcim.device"})})
print(f" + dcim.device ergänzt")
continue
payload = {"key": key, "label": label, "type": typ, "description": desc,
"content_types": ["dcim.device"], "grouping": "TP36-Live",
"required": False}
if not COMMIT:
print(f" + CF '{key}' ({typ}) [DRY-RUN]")
continue
st, r = req("POST", "/api/extras/custom-fields/", payload)
print(f" {'+' if st in (200,201) else '!'} CF '{key}'"
+ (f" angelegt ({r.get('id')})" if st in (200, 201)
else f" FEHLER {st}: {json.dumps(r)[:200]}"))
# --------------------------------------------------------------- Backup-Parser
def parse_backup(cfg: str):
"""Werte aus dem flachen RouterOS-Export (eine '/…'-Zeile pro Kommando)."""
ver = ""
m = re.search(r"by RouterOS ([0-9][0-9A-Za-z.\-]*)", cfg)
if m:
ver = m.group(1)
# DHCP-Server = Zeilen '/ip dhcp-server add …' (NICHT lease/network/option)
dhcp = len(re.findall(r"(?m)^\s*/ip dhcp-server add\b", cfg))
# DNS-Modus aus der '/ip dns set …'-Zeile
mode = "none"
md = re.search(r"(?m)^\s*/ip dns set\b.*", cfg)
if md:
line = md.group(0)
doh = re.search(r"use-doh-server=([^\s]+)", line)
srv = re.search(r"\bservers=([^\s]+)", line)
if doh and doh.group(1) not in ("", '""'):
mode = "doh"
elif srv and srv.group(1) not in ("", '""'):
mode = "plain"
return ver, dhcp, mode
def compliance_pct(device_name: str):
q = urllib.parse.urlencode({"device": device_name, "limit": 0, "depth": 0})
st, d = req("GET", f"/api/plugins/golden-config/config-compliance/?{q}")
rows = d.get("results", [])
if not rows:
return None
ok = sum(1 for r in rows if r.get("compliance"))
return round(ok / len(rows) * 100)
# ---------------------------------------------------------------------- main
def routeros_devices():
q = urllib.parse.urlencode({"limit": 0, "depth": 1, "platform": "RouterOS"})
st, d = req("GET", f"/api/dcim/devices/?{q}")
devs = []
for r in d.get("results", []):
ip = r.get("primary_ip4")
ip = ip.get("address") if isinstance(ip, dict) else ip
if not ip:
continue # tote Altgeräte (cudy/sw) ohne IP überspringen
devs.append((r["id"], r["name"], ip.split("/")[0]))
return sorted(devs, key=lambda x: x[1])
def main():
print(f"== TP36-Live gc-snapshot ({'COMMIT' if COMMIT else 'DRY-RUN'}) @ {NB} ==")
print("\n[1] CustomFields sicherstellen")
ensure_custom_fields()
print("\n[2] Golden-Config-Backups laden")
st, gc = req("GET", "/api/plugins/golden-config/golden-config/?depth=1&limit=0")
backups = {}
for r in gc.get("results", []):
dev = r.get("device")
dev = dev.get("name") if isinstance(dev, dict) else dev
backups[dev] = (r.get("backup_config") or "", r.get("backup_last_success_date") or "?")
print("\n[3] Snapshot je Gerät")
print(f" {'Gerät':16} {'ros':9} {'cmpl%':>5} {'dhcp':>4} {'dns':6} {'mgmt-ip':15} backup")
for dev_id, name, mgmt in routeros_devices():
cfg, when = backups.get(name, ("", "—"))
ver, dhcp, dns = parse_backup(cfg) if cfg else ("?", 0, "?")
pct = compliance_pct(name)
vals = {
"ros_version": ver or None,
"compliance_pct": pct,
"dhcp_server_count": dhcp,
"mgmt_ip": mgmt,
"dns_upstream_mode": dns,
}
pct_s = "—" if pct is None else str(pct)
print(f" {name:16} {ver or '?':9} {pct_s:>5} {dhcp:>4} {dns:6} {mgmt:15} {when[:10]}")
if COMMIT:
st, r = req("PATCH", f"/api/dcim/devices/{dev_id}/", {"custom_fields": vals})
if st not in (200, 201):
print(f" ! PATCH FEHLER {st}: {json.dumps(r)[:200]}")
print(f"\n== fertig ({'COMMIT — geschrieben' if COMMIT else 'DRY-RUN — nichts geschrieben'}) ==")
if __name__ == "__main__":
main()

105
nautobot/ingest-tp38-oob.py Normal file
View File

@@ -0,0 +1,105 @@
#!/usr/bin/env python3
r"""TP38: OOB-Port + Input-Firewall als Daten nach Nautobot schreiben.
Zwei getrennte Aenderungen, ein Skript:
1. BRANCH (crs326-branch): `firewall_filter` im local_config_context_data ANLEGEN
(8 Input-Regeln, deny-by-default). Der src-Rahmen 10.40.0.0/16 + 100.96.0.0/12
spiegelt bewusst das `available-from` der /ip service-Zeilen — kein neues
Fenster, nur stateful + deny-by-default + WOULD-DROP-Log.
2. CORE (crs326-core): EINE Regel "TP38: OOB->core mgmt" in die bestehende
firewall_filter-Liste EINFUEGEN (vor log/drop), damit der OOB-Port (untagged
ether23, VLAN99) auch den Core selbst verwalten kann.
Attributreihenfolge = alphabetisch, exakt wie RouterOS `/export` sie schreibt
(gleiche Konvention wie ingest-core-firewall.py).
python3 nautobot/ingest-tp38-oob.py # Dry-Run
python3 nautobot/ingest-tp38-oob.py --apply
"""
import json
import os
import sys
import urllib.request
NB = os.environ.get("NAUTOBOT_URL", "http://10.40.20.30:8080")
BRANCH_RULES = [
'add action=accept chain=input comment="TP38: established" connection-state=established,related,untracked',
'add action=drop chain=input comment="TP38: invalid" connection-state=invalid',
'add action=accept chain=input comment="TP38: icmp" protocol=icmp',
'add action=accept chain=input comment="TP38: mndp" dst-port=5678 protocol=udp',
'add action=accept chain=input comment="TP38: mgmt LAN" dst-port=22,80,8291,8728 protocol=tcp src-address=10.40.0.0/16',
'add action=accept chain=input comment="TP38: mgmt mesh" dst-port=22,80,8291,8728 protocol=tcp src-address=100.96.0.0/12',
'add action=log chain=input comment="TP38: input log-only" log-prefix=TP38-BRANCH-WOULD-DROP',
'add action=drop chain=input comment="TP38: input deny-by-default"',
]
CORE_NEW_RULE = 'add action=accept chain=input comment="TP38: OOB->core mgmt" dst-port=22,80,8291,8728 in-interface=vlan99 protocol=tcp'
def nb(path, method="GET", payload=None):
tok = os.environ.get("NAUTOBOT_TOKEN") or sys.exit("NAUTOBOT_TOKEN nicht gesetzt")
req = urllib.request.Request(
f"{NB}{path}", method=method,
data=json.dumps(payload).encode() if payload is not None else None,
headers={"Authorization": f"Token {tok}", "Content-Type": "application/json",
"Accept": "application/json"})
with urllib.request.urlopen(req, timeout=60) as r:
raw = r.read()
return json.loads(raw) if raw else {}
def get_device(name):
return nb(f"/api/dcim/devices/?name={name}&depth=1")["results"][0]
def patch_device(dev, ctx, label):
dev_id = dev["id"]
nb(f"/api/dcim/devices/{dev_id}/", "PATCH", {"local_config_context_data": ctx})
print(f" ~ {label} geschrieben.")
def main():
apply_ = "--apply" in sys.argv
# --- BRANCH ---
branch = get_device("crs326-branch")
bctx = dict(branch.get("local_config_context_data") or {})
if bctx.get("firewall_filter") == BRANCH_RULES:
print("== branch: firewall_filter unveraendert ==")
else:
bctx["firewall_filter"] = BRANCH_RULES
print(f"== branch: {len(BRANCH_RULES)} Input-Regeln ==")
for ln in BRANCH_RULES:
print(" " + ln)
if apply_:
patch_device(branch, bctx, "branch firewall_filter")
# --- CORE ---
core = get_device("crs326-core")
cctx = dict(core.get("local_config_context_data") or {})
ff = list(cctx.get("firewall_filter") or [])
if CORE_NEW_RULE in ff:
print("\n== core: Regel schon vorhanden ==")
else:
# vor der Log-Regel einsortieren (die sitzt direkt vor dem finalen drop).
insert_at = len(ff)
for i, ln in enumerate(ff):
if "log-prefix=TP5-INPUT-WOULD-DROP" in ln:
insert_at = i
break
ff.insert(insert_at, CORE_NEW_RULE)
cctx["firewall_filter"] = ff
print(f"\n== core: fuege OOB-Regel an Position {insert_at} ein ==")
print(" " + CORE_NEW_RULE)
if apply_:
patch_device(core, cctx, "core firewall_filter")
if not apply_:
print("\nDRY-RUN — mit --apply schreiben. Danach: "
"push-gc-template.py + gc-configplan.py --refresh-compliance")
if __name__ == "__main__":
main()

View File

@@ -73,9 +73,11 @@
/interface bridge port add bridge=bridge comment=defconf interface=ether14 pvid=30
/interface bridge port add bridge=bridge comment=defconf interface=ether15
/interface bridge port add bridge=bridge comment=defconf interface=ether16 pvid=100
{% for n in range(17, 25) %}
{% for n in range(17, 23) %}
/interface bridge port add bridge=bridge comment=defconf interface=ether{{ n }}
{% endfor %}
/interface bridge port add bridge=bridge comment=TP38-OOB-MGMT frame-types=admit-only-untagged-and-priority-tagged interface=ether23 pvid=99
/interface bridge port add bridge=bridge comment=defconf interface=ether24
/interface bridge port add bridge=bridge comment=defconf interface=sfp-sfpplus1
/interface bridge port add bridge=bridge comment=defconf interface=sfp-sfpplus2
# ether4 = Wohnzimmer-Sideboard: 2026-08-13 von Trunk auf untagged VLAN40 gezogen (TP21.1/4).
@@ -94,7 +96,7 @@
/interface bridge vlan add bridge=bridge tagged=ether1,ether3,ether8,ether13,ether15,ether21 untagged=ether2,ether4,ether5 vlan-ids=40
/interface bridge vlan add bridge=bridge tagged=ether1,ether3,ether8,ether15,ether21 vlan-ids=50
/interface bridge vlan add bridge=bridge tagged=ether1,ether3,ether8,ether15,ether21 vlan-ids=90
/interface bridge vlan add bridge=bridge tagged=ether3,ether8,ether15,ether21,bridge vlan-ids=99
/interface bridge vlan add bridge=bridge tagged=ether3,ether8,ether15,ether21,bridge untagged=ether23 vlan-ids=99
/interface bridge vlan add bridge=bridge tagged=ether1 untagged=ether16 vlan-ids=100
# [1] INTERFACE-LISTS
@@ -222,10 +224,12 @@
/interface wifi datapath add bridge=bridge name=dp-media vlan-id=40
/interface wifi datapath add bridge=bridge name=dp-untrusted vlan-id=50
/interface wifi datapath add bridge=bridge name=dp-guest vlan-id=90
# sec-main: ft=no seit 2026-09-04 (User-Entscheid nach TP25-Messung). Fast-Transition
# komplett aus; ft-over-ds ist damit gegenstandslos (gilt nur bei ft=yes) und steht auf no.
# Fund E hatte ft-over-ds=no BEI ft=yes widerlegt -- das hier ist ein anderer Hebel (FT aus).
/interface wifi security add authentication-types=wpa3-psk ft=no ft-over-ds=no name=sec-main passphrase="<<REDACTED>>"
# sec-main: ft=yes/ft-over-ds=yes zurueckgesetzt am 2026-09-14 (Ruecknahme des 09-04-Entscheids
# "ft=no als Dauerzustand"; Go nach Terrasse-In-situ-Session: mit ft=no war jeder Roam eine
# Voll-Reassoziation -- darin starben Anrufe). Known-Good: genau dieser Stand lief in der
# Fund-E-Abschlussmessung 09-02 ruhig (4 reauth/8,6 h, 0 Ausfaelle) auf 7.24.1.
# 2026-09-04 stand hier: ft=no ft-over-ds=no (User-Entscheid nach TP25-Messung).
/interface wifi security add authentication-types=wpa3-psk ft=yes ft-over-ds=yes name=sec-main passphrase="<<REDACTED>>"
/interface wifi security add authentication-types=wpa2-psk,wpa3-psk disabled=no ft=no name=sec-infra passphrase="<<REDACTED>>"
/interface wifi security add authentication-types=wpa2-psk,wpa3-psk disabled=no ft=no name=sec-iot passphrase="<<REDACTED>>"
/interface wifi security add authentication-types=wpa2-psk,wpa3-psk ft=no name=sec-media passphrase="<<REDACTED>>"
@@ -239,11 +243,16 @@
# BSSIDs einer SSID melden, auf die sie gar nicht assoziieren koennen (TP28).
/interface wifi steering add name=st-main neighbor-group=bf-main rrm=yes wnm=yes
/interface wifi steering add name=st-guest neighbor-group=bf-guest rrm=yes wnm=yes
/interface wifi configuration add channel=ch-5g-ap1 country=Austria datapath=dp-main mode=ap name=cfg-main-5g-ap1 security=sec-main ssid=dirtyvader-main steering=st-main
/interface wifi configuration add channel=ch-5g-ap2 country=Austria datapath=dp-main mode=ap name=cfg-main-5g-ap2 security=sec-main ssid=dirtyvader-main steering=st-main
# st-main-5g (TP25, 2026-09-15): transition-threshold=-72 statt Default -80 -- 5G bricht frueher
# zur 2.4G ab (Terrasse sass am Rundgang 09-15 auf der -80/5G-Kante). transition-threshold-time=5s
# statt 10s. NUR 5G: die drei 2G-Configs bleiben auf st-main (unset=-80), weil 2.4G draussen
# (Terrasse/ausserhalb der Wohnung) Reichweite behalten soll. 8 dB Abstand = kleine Hysterese.
/interface wifi steering add name=st-main-5g neighbor-group=bf-main rrm=yes transition-threshold=-72 transition-threshold-time=5s wnm=yes
/interface wifi configuration add channel=ch-5g-ap1 country=Austria datapath=dp-main mode=ap name=cfg-main-5g-ap1 security=sec-main ssid=dirtyvader-main steering=st-main-5g
/interface wifi configuration add channel=ch-5g-ap2 country=Austria datapath=dp-main mode=ap name=cfg-main-5g-ap2 security=sec-main ssid=dirtyvader-main steering=st-main-5g
/interface wifi configuration add channel=ch-2g-ap1 country=Austria datapath=dp-main mode=ap name=cfg-main-2g-ap1 security=sec-main ssid=dirtyvader-main steering=st-main
/interface wifi configuration add channel=ch-2g-ap2 country=Austria datapath=dp-main mode=ap name=cfg-main-2g-ap2 security=sec-main ssid=dirtyvader-main steering=st-main
/interface wifi configuration add channel=ch-5g-ap3 country=Austria datapath=dp-main mode=ap name=cfg-main-5g-ap3 security=sec-main ssid=dirtyvader-main steering=st-main
/interface wifi configuration add channel=ch-5g-ap3 country=Austria datapath=dp-main mode=ap name=cfg-main-5g-ap3 security=sec-main ssid=dirtyvader-main steering=st-main-5g
/interface wifi configuration add channel=ch-2g-ap3 country=Austria datapath=dp-main mode=ap name=cfg-main-2g-ap3 security=sec-main ssid=dirtyvader-main steering=st-main
/interface wifi configuration add country=Austria datapath=dp-guest mode=ap name=cfg-guest security=sec-guest ssid=dirtyvader-guest steering=st-guest
/interface wifi capsman set ca-certificate=auto certificate=auto enabled=yes interfaces=vlan99 upgrade-policy=none
@@ -273,17 +282,16 @@
# python3 nautobot/gc-transaktion.py begin --device crs326-core \
# --scope wifi-access-list --change-id TEST-... --expires JJJJ-MM-TT
#
# 🔴 Hier landet TP25 **Fund E** (`signal-range`-Boden gegen klebende Clients),
# sobald er entschieden ist. Die alte Auflage lautete "vor dem Eintragen den
# Sticky-Fall erneut messen" -- das ist am 2026-08-30 passiert: dasselbe iPhone
# machte 16 Bandwechsel in 20 Minuten bei -53..-81 dBm, erst an ap3, dann an ap2.
# Fund E ist damit WIEDER OFFEN.
# Eingetragen wird hier trotzdem NICHTS, und zwar bewusst: ein signal-range-Boden
# ist der invasivste der drei Hebel und kann Clients AUSSPERREN -- genau das war
# 08-22 das Gegenargument (in den schwachen Raeumen gibt es keinen besseren AP,
# auf den ein Boden steuern koennte). Erst kommen (1) `2g-probe-delay=yes` und
# (2) `ft-over-ds=no`, jeder einzeln und als Transaktion, mit dem seit 2026-08-30
# laufenden wireless-Logging als Messgrundlage. Siehe teilprojekte.md TP25 Fund E.
# 🔴 Stand 2026-09-14 (Terrasse-In-situ-Session): der `signal-range`-Boden gegen
# klebende Clients ist GEPRUEFT und GESCHEITERT -- `/interface wifi access-list`
# hat kein `band`-Property (Band-Scoping ginge nur ueber cap-wifiN-Interface-Namen,
# die bei jedem CAP-Rejoin wechseln), SSID-/MAC-Scope ohne Band träfe 2,4 GHz mit
# (Lockout-Risiko, Schlafzimmer -84). Der Boden ist damit NICHT umsetzbar; der
# Ersatz gegen die Call-Aussetzer ist `ft=yes ft-over-ds=yes` auf sec-main
# (2026-09-14 zurueckgesetzt, s. docs/transaktionen/TP25-ft-yes-secmain.commands.rsc
# und handoff-20260914-tp25-ap2-insitu-terrassse.md): Roams laufen als nahtlose
# FT-Transition statt Voll-Reassoziation. Das Band-Springen selbst endet erst
# mit dem Deckungsfix (TP25 Variante 3). Siehe teilprojekte.md TP25 (Stand 09-14).
# Kanonischer Mgmt-Nummernplan (User-Bestaetigung 2026-08-13, verbindlich):
# core .99.1 | branch .99.2 | ap1 .99.11 | ap2 .99.12
@@ -416,9 +424,20 @@
/system ntp client servers add address=10.40.99.1
/ip route add comment=TP21-default dst-address=0.0.0.0/0 gateway=10.40.99.1
# INPUT-FIREWALL (TP38, 2026-09-15) — deny-by-default fuer die Mgmt-Ebene (10.40.99.2).
# Der Branch ist L2-only: ALLE Mgmt-Anfragen kommen auf der einen vlan99-SVI an, egal ob
# VLAN10 (ueber den Core geroutet), cf-mesh (100.96.0.0/12) oder der OOB-Port (untagged
# ether23, 10.40.99.x). Deshalb matcht die Quelle per src-address, nicht per in-interface.
# Der src-Rahmen 10.40.0.0/16 + 100.96.0.0/12 spiegelt bewusst das `available-from` der
# /ip service-Zeilen — kein neues Fenster, nur stateful + deny-by-default + WOULD-DROP-Log.
{% for line in obj.get_config_context().get("firewall_filter", []) %}
/ip firewall filter {{ line }}
{% endfor %}
# L2-FABRIC — wie beim Core ein Literal-Block (Begruendung dort).
# ether9-23 tragen pvid=20 OHNE VLAN-Membership (Bootstrap-Rev4-Rest, funktionslos) —
# ether9-22 tragen pvid=20 OHNE VLAN-Membership (Bootstrap-Rev4-Rest, funktionslos) —
# bewusst so abgebildet, damit eine spaetere Bereinigung als Drift sichtbar wird.
# ether23 ist seit TP38 der OOB-MGMT-Port (untagged VLAN99), s. unten.
/interface bridge port add bridge=bridge comment=defconf interface=ether1
/interface bridge port add bridge=bridge comment=defconf interface=ether2
/interface bridge port add bridge=bridge comment=defconf interface=ether3 pvid=10
@@ -427,9 +446,10 @@
/interface bridge port add bridge=bridge comment=defconf interface=ether6 pvid=40
/interface bridge port add bridge=bridge comment=defconf interface=ether7 pvid=20
/interface bridge port add bridge=bridge comment=defconf interface=ether8
{% for n in range(9, 24) %}
{% for n in range(9, 23) %}
/interface bridge port add bridge=bridge comment=defconf interface=ether{{ n }} pvid=20
{% endfor %}
/interface bridge port add bridge=bridge comment=TP38-OOB-MGMT frame-types=admit-only-untagged-and-priority-tagged interface=ether23 pvid=99
/interface bridge port add bridge=bridge comment=defconf interface=ether24
/interface bridge port add bridge=bridge comment=defconf disabled=yes interface=sfp-sfpplus1
/interface bridge port add bridge=bridge comment=defconf disabled=yes interface=sfp-sfpplus2
@@ -439,7 +459,7 @@
/interface bridge vlan add bridge=bridge comment=MEDIA tagged=ether1,ether24,bridge untagged=ether5,ether6 vlan-ids=40
/interface bridge vlan add bridge=bridge comment=UNTRUSTED tagged=ether1,ether24,bridge vlan-ids=50
/interface bridge vlan add bridge=bridge comment=GUEST tagged=ether1,ether24,bridge vlan-ids=90
/interface bridge vlan add bridge=bridge comment=MGMT tagged=ether1,ether24,bridge vlan-ids=99
/interface bridge vlan add bridge=bridge comment=MGMT tagged=ether1,ether24,bridge untagged=ether23 vlan-ids=99
{% elif obj.role.name == "Wireless AP" %}
{% set ap = obj.get_config_context()["ap"] %}
{% set mgmt_host = obj.primary_ip4.host %}

View File

@@ -0,0 +1,178 @@
#!/usr/bin/env python3
"""
TP37 Punkt 2 (Dienste) — exponierte Ports als native ipam.Service-Objekte.
Idempotenter Seeder (get-or-create) fuer ipam.Service:
je VM-Name + Port + Protokoll ein Service-Eintrag.
Vorbedingung: TP37 P1 (tp37-substrat-seed.py --commit) muss vorher gelaufen sein,
da die VirtualMachine-Objekte existieren muessen.
Datenmodell-Entscheid (User 2026-09-06): native Modelle, KEINE eigene App.
Muster: nautobot/tp37-substrat-seed.py.
Umfang (User-Default 2026-09-07):
Caddy (:80/:443), Caddy-Backends (haos:8123, vaultwarden:80, gitea:3000, n8n:5678),
Nautobot:8080, AdGuard:53 (bf1+bf2, tcp+udp), platform-pg:5432, mariadb:3306,
influxdb2:8086, mqtt5:1883, portainer:9443,
MCP-Dienste (pve-mcp:3000, shelly-mcp:3030, n8n-mcp:3001, gitea-mcp:3000).
+ Smart-Home (vervollstaendigt 2026-09-08, Ports per Socket-Probe verifiziert):
RaspberryMatic/CCU (80/443/2001/2010), iob-master:8081, z2m25:8080.
iob-exposed/iob_slave BEWUSST ohne Service (kein exponierter Port gefunden).
Token-Quelle: docs/nas-vlan20/stacks/210-nautobot.yml (gitignored),
Schluessel NAUTOBOT_SUPERUSER_API_TOKEN.
Aufruf:
python3 nautobot/tp37-dienste-seed.py # Dry-Run (default)
python3 nautobot/tp37-dienste-seed.py --commit # legt an
"""
import json
import os
import re
import sys
import urllib.request
import urllib.parse
import urllib.error
from pathlib import Path
NB = os.environ.get("NAUTOBOT_URL", "http://10.40.20.30:8080")
REPO = Path(__file__).resolve().parent.parent
YML = REPO / "docs" / "nas-vlan20" / "stacks" / "210-nautobot.yml"
COMMIT = "--commit" in sys.argv
def load_token() -> str:
for line in YML.read_text().splitlines():
m = re.search(r"NAUTOBOT_SUPERUSER_API_TOKEN[=:]\s*([^\s\"']+)", line)
if m:
return m.group(1)
sys.exit(f"NAUTOBOT_SUPERUSER_API_TOKEN nicht in {YML} gefunden")
TOKEN = load_token()
HDRS = {"Authorization": f"Token {TOKEN}", "Accept": "application/json",
"Content-Type": "application/json"}
def req(method: str, path: str, body=None):
url = f"{NB}{path}"
data = json.dumps(body).encode() if body is not None else None
r = urllib.request.Request(url, data=data, headers=HDRS, method=method)
try:
with urllib.request.urlopen(r, timeout=20) as resp:
return resp.status, json.loads(resp.read().decode() or "{}")
except urllib.error.HTTPError as e:
return e.code, json.loads(e.read().decode() or "{}")
def find(endpoint: str, params: dict, match_key: str, match_val: str):
q = urllib.parse.urlencode(dict(params, depth=0))
st, d = req("GET", f"/api/{endpoint}/?{q}")
for row in d.get("results", []):
if row.get(match_key) == match_val:
return row
return None
def get_or_create(endpoint: str, find_params: dict, match_key: str,
match_val: str, payload: dict, label: str):
existing = find(endpoint, find_params, match_key, match_val)
if existing:
print(f" = {label}: '{match_val}' existiert ({existing['id']})")
return existing
if not COMMIT:
print(f" + {label}: '{match_val}' [DRY-RUN]")
return {"id": f"<dry:{match_val}>"}
st, d = req("POST", f"/api/{endpoint}/", payload)
if st in (200, 201):
print(f" + {label}: '{match_val}' angelegt ({d.get('id')})")
return d
print(f" ! {label}: '{match_val}' FEHLER {st}: {json.dumps(d)[:300]}")
return None
# ---------------------------------------------------------------- Inventar
# (vm_name, svc_name, ports, protocol, description)
SERVICES = [
# Caddy Reverse-Proxy (TP34 critical)
("caddy-bf1", "caddy-http", [80], "tcp", "Caddy HTTP"),
("caddy-bf1", "caddy-https", [443], "tcp", "Caddy HTTPS Reverse Proxy"),
# Caddy-Backends via bf-public Tunnel
("haos", "home-assistant", [8123], "tcp", "Home Assistant Web"),
("vaultwarden", "vaultwarden-http", [80], "tcp", "Vaultwarden (HTTP, TLS via Caddy)"),
("gitea", "gitea-http", [3000], "tcp", "Gitea Web"),
("n8n", "n8n-web", [5678], "tcp", "n8n Workflow Engine"),
# Nautobot
("nautobot", "nautobot-web", [8080], "tcp", "Nautobot API/Web"),
# DNS (TCP + UDP je Resolver)
("agh-bf1", "adguard-dns-tcp", [53], "tcp", "AdGuard Home DNS/TCP"),
("agh-bf1", "adguard-dns-udp", [53], "udp", "AdGuard Home DNS/UDP"),
("agh-bf2", "adguard-dns-tcp", [53], "tcp", "AdGuard Home DNS/TCP"),
("agh-bf2", "adguard-dns-udp", [53], "udp", "AdGuard Home DNS/UDP"),
# Infrastruktur
("platform-pg", "postgresql", [5432], "tcp", "PostgreSQL 16 (Nautobot-DB)"),
("mariadb", "mariadb", [3306], "tcp", "MariaDB (vw/hass/gitea)"),
("influxdb2", "influxdb", [8086], "tcp", "InfluxDB 2"),
("mqtt5", "mqtt", [1883], "tcp", "MQTT Broker (Mosquitto)"),
("docker", "portainer", [9443], "tcp", "Portainer CE"),
# MCP-Dienste
("pve-mcp", "pve-mcp", [3000], "tcp", "Proxmox MCP (StreamableHTTP)"),
("shelly-mcp", "shelly-mcp", [3030], "tcp", "Shelly MCP"),
("n8n-mcp", "n8n-mcp", [3001], "tcp", "n8n MCP"),
("gitea-mcp", "gitea-mcp", [3000], "tcp", "Gitea MCP"),
# Smart-Home / IoT — Ports live per Socket-Probe verifiziert 2026-09-08 (NICHT raten!)
("RaspberryMatic","ccu-http", [80], "tcp", "Homematic CCU Web (HTTP)"),
("RaspberryMatic","ccu-https", [443], "tcp", "Homematic CCU Web (HTTPS)"),
("RaspberryMatic","ccu-rpc-bidcos", [2001], "tcp", "Homematic BidCos-RF XML-RPC"),
("RaspberryMatic","ccu-rpc-hmip", [2010], "tcp", "Homematic-IP XML-RPC"),
("iob-master", "iobroker-admin", [8081], "tcp", "ioBroker Admin"),
("z2m25", "zigbee2mqtt", [8080], "tcp", "Zigbee2MQTT Frontend"),
# iob-exposed (.19) + iob_slave (.33): kein exponierter Port gefunden (13 Ports, alle Timeout)
# -> BEWUSST kein Service, bis ein Port live belegt ist. Nicht "hilfreich" einen erfinden.
]
def main():
print(f"== TP37 Dienste-Seed ({'COMMIT' if COMMIT else 'DRY-RUN'}) @ {NB} ==")
# VM-IDs vorab holen (unique Namen, Batch)
vm_names = sorted({vm for vm, *_ in SERVICES})
print(f"\n[0] VM-IDs holen ({len(vm_names)} unique VMs)")
vm_ids = {}
for name in vm_names:
row = find("virtualization/virtual-machines", {"name": name}, "name", name)
if row:
vm_ids[name] = row["id"]
print(f" = {name}: {row['id']}")
else:
vm_ids[name] = None
print(f" ! {name}: NICHT gefunden — Service-Eintraege werden uebersprungen")
print(f"\n[1] ipam.Services ({len(SERVICES)} Eintraege)")
n_ok = n_skip = 0
for vm_name, svc_name, ports, protocol, desc in SERVICES:
vm_id = vm_ids.get(vm_name)
if not vm_id and COMMIT:
print(f" ~ {vm_name}/{svc_name}: VM fehlt, uebersprungen")
n_skip += 1
continue
svc = get_or_create(
"ipam/services",
{"name": svc_name, "virtual_machine": vm_name},
"name", svc_name,
{"virtual_machine": vm_id, "name": svc_name,
"ports": ports, "protocol": protocol, "description": desc},
f"{vm_name}/{protocol}/{ports[0]}",
)
if svc:
n_ok += 1
else:
n_skip += 1
print(f"\n== fertig ({'COMMIT' if COMMIT else 'DRY-RUN — nichts geschrieben'}) "
f"| Services={n_ok} uebersprungen={n_skip} ==")
if __name__ == "__main__":
main()

View File

@@ -0,0 +1,256 @@
#!/usr/bin/env python3
"""
TP37 Punkt 1 (Substrat) — Hosts/Container als native Nautobot-Objekte.
Idempotenter Seeder (get-or-create) fuer die native virtualization-Modellwelt:
ClusterType (3x: Proxmox VE / Synology Docker / Docker Desktop)
-> Cluster (pve / nas-bf / macmini)
-> VirtualMachine je Workload (Status Active)
+ VMInterface "eth0" + ipam.IPAddress (Namespace Global) + primary_ip4
Datenmodell-Entscheid (User 2026-09-06): native Modelle, KEINE eigene App
(konsistent zu TP44). Muster: nautobot/tp44-cf-estate-seed.py.
Umfang Etappe 1 (User-Default 2026-09-07):
- komplettes Substrat: alle 15 pve-Gaeste (inkl. Smart-Home) + alle running
Container auf nas-bf (Portainer ep14) und macmini (ep20).
- macmini-Container teilen sich die Host-IP 10.40.20.167 (Bridge/Port-Mapping)
-> KEIN primary_ip4; Port kommt in TP37 P2 (ipam.Service).
- portainer_agent (Bridge 172.17.0.2, kein Workload) weggelassen.
- gestoppte (exited) NAS-Container weggelassen (nur running).
Datenstand: Live-Inventur 2026-09-07 (pve-mcp pct config, Portainer ep14,
ssh macmini docker ps, ARP fuer die 2 QEMU-IPs).
Token-Quelle: docs/nas-vlan20/stacks/210-nautobot.yml (gitignored),
Schluessel NAUTOBOT_SUPERUSER_API_TOKEN.
Aufruf:
python3 nautobot/tp37-substrat-seed.py # Dry-Run (default)
python3 nautobot/tp37-substrat-seed.py --commit # legt an
"""
import json
import os
import re
import sys
import urllib.request
import urllib.parse
import urllib.error
from pathlib import Path
NB = os.environ.get("NAUTOBOT_URL", "http://10.40.20.30:8080")
REPO = Path(__file__).resolve().parent.parent
YML = REPO / "docs" / "nas-vlan20" / "stacks" / "210-nautobot.yml"
COMMIT = "--commit" in sys.argv
def load_token() -> str:
for line in YML.read_text().splitlines():
m = re.search(r"NAUTOBOT_SUPERUSER_API_TOKEN[=:]\s*([^\s\"']+)", line)
if m:
return m.group(1)
sys.exit(f"NAUTOBOT_SUPERUSER_API_TOKEN nicht in {YML} gefunden")
TOKEN = load_token()
HDRS = {"Authorization": f"Token {TOKEN}", "Accept": "application/json",
"Content-Type": "application/json"}
def req(method: str, path: str, body=None):
url = f"{NB}{path}"
data = json.dumps(body).encode() if body is not None else None
r = urllib.request.Request(url, data=data, headers=HDRS, method=method)
try:
with urllib.request.urlopen(r, timeout=20) as resp:
return resp.status, json.loads(resp.read().decode() or "{}")
except urllib.error.HTTPError as e:
return e.code, json.loads(e.read().decode() or "{}")
def is_dry(v) -> bool:
return isinstance(v, str) and v.startswith("<dry:")
def find(endpoint: str, params: dict, match_key: str, match_val: str):
q = urllib.parse.urlencode(dict(params, depth=0))
st, d = req("GET", f"/api/{endpoint}/?{q}")
for row in d.get("results", []):
if row.get(match_key) == match_val:
return row
return None
def get_or_create(endpoint: str, find_params: dict, match_key: str,
match_val: str, payload: dict, label: str):
existing = find(endpoint, find_params, match_key, match_val)
if existing:
print(f" = {label}: '{match_val}' existiert ({existing['id']})")
return existing
if not COMMIT:
print(f" + {label}: '{match_val}' [DRY-RUN]")
return {"id": f"<dry:{match_val}>"}
st, d = req("POST", f"/api/{endpoint}/", payload)
if st in (200, 201):
print(f" + {label}: '{match_val}' angelegt ({d.get('id')})")
return d
print(f" ! {label}: '{match_val}' FEHLER {st}: {json.dumps(d)[:300]}")
return None
def status_id(name: str):
return find("extras/statuses", {"name": name}, "name", name)["id"]
def namespace_id(name: str):
return find("ipam/namespaces", {"name": name}, "name", name)["id"]
# ---------------------------------------------------------------- Inventar
CLUSTER_TYPES = ["Proxmox VE", "Synology Docker", "Docker Desktop"]
# cluster -> clustertype
CLUSTERS = [("pve", "Proxmox VE"),
("nas-bf", "Synology Docker"),
("macmini", "Docker Desktop")]
# cluster -> [ (vm_name, primary_ip_with_mask_or_None, comment) ]
VMS = {
"pve": [
("haos", "10.40.20.105/24", "Home Assistant OS (QEMU 100)"),
("iob-master", "10.40.20.107/24", "ioBroker Master (LXC 101)"),
("mqtt5", "10.40.20.108/24", "MQTT-Broker Mosquitto (LXC 102)"),
("platform-pg", "10.40.20.20/24", "PostgreSQL 16 - Nautobot-DB (LXC 105, TP20)"),
("influxdb2", "10.40.20.8/24", "InfluxDB 2 (LXC 106)"),
("redis", "10.40.20.111/24", "Redis (LXC 107)"),
("mcast-relay", "10.40.10.21/24", "SSDP-Relay VLAN10<->40 (LXC 108); 2. Bein 10.40.40.21"),
("agh-bf1", "10.40.20.36/24", "AdGuard Home Resolver (LXC 110, TP23)"),
("agh-bf2", "10.40.20.37/24", "AdGuard Home Resolver (LXC 111, TP23)"),
("z2m25", "10.40.20.106/24", "Zigbee2MQTT (LXC 112)"),
("caddy-bf1", "10.40.20.40/24", "Caddy Reverse-Proxy (LXC 130, TP31)"),
("iob-exposed", "10.40.20.19/24", "ioBroker exposed (LXC 150)"),
("mariadb", "10.40.20.23/24", "MariaDB - vw/hass/gitea (LXC 302)"),
("RaspberryMatic","10.40.20.232/24", "Homematic CCU (QEMU 330)"),
("docker", "10.40.20.126/24", "Docker-Host nested (LXC 400)"),
],
"nas-bf": [
("nautobot", "10.40.20.30/24", "Nautobot Web (DS923 ep14)"),
("nautobot-worker", "10.40.20.31/24", "Nautobot Golden-Config Worker"),
("nautobot-scheduler", "10.40.20.32/24", "Nautobot Scheduler"),
("nautobot-redis", "10.40.20.34/24", "Nautobot Redis"),
("gitea", "10.40.20.157/24", "Gitea (git-SSoT)"),
("vaultwarden", "10.40.20.127/24", "Vaultwarden (DB=mariadb LXC302)"),
("shelly-mcp", "10.40.20.180/24", "Shelly-MCP"),
("pve-mcp", "10.40.20.173/24", "Proxmox-MCP (mcp-pve)"),
("iob_slave", "10.40.20.33/24", "ioBroker Slave"),
],
"macmini": [
# Bridge/Port-Mapping auf Host 10.40.20.167 -> kein eigenes primary_ip4
("n8n", None, "n8n (Docker Desktop, Host 10.40.20.167:5678)"),
("n8n-redis", None, "n8n Redis (intern, kein Host-Port)"),
("n8n-mcp", None, "n8n-MCP (Host 10.40.20.167:3001)"),
("gitea-mcp", None, "Gitea-MCP (Host 10.40.20.167:3000)"),
],
}
def main():
print(f"== TP37 Substrat-Seed ({'COMMIT' if COMMIT else 'DRY-RUN'}) @ {NB} ==")
st_active = status_id("Active")
ns_global = namespace_id("Global")
print(f" (Status Active={st_active} Namespace Global={ns_global})")
print("\n[1] ClusterTypes")
for ct in CLUSTER_TYPES:
get_or_create("virtualization/cluster-types", {"name": ct}, "name", ct,
{"name": ct}, "ClusterType")
print("\n[2] Clusters")
ct_lookup = {ct: find("virtualization/cluster-types", {"name": ct}, "name", ct)
for ct in CLUSTER_TYPES}
cluster_ids = {}
for cname, ctname in CLUSTERS:
ctrow = ct_lookup.get(ctname)
ct_id = ctrow["id"] if ctrow else None
cl = get_or_create("virtualization/clusters", {"name": cname}, "name", cname,
{"name": cname, "cluster_type": ct_id}, "Cluster")
cluster_ids[cname] = cl["id"] if cl else None
print("\n[3] VirtualMachines (+ eth0 + IPAddress + primary_ip4)")
n_vm = n_ip = 0
for cname, _ in CLUSTERS:
cl_id = cluster_ids.get(cname)
print(f" -- Cluster {cname} --")
for name, ip, comment in VMS[cname]:
vm = get_or_create(
"virtualization/virtual-machines", {"name": name}, "name", name,
{"name": name, "cluster": cl_id, "status": st_active,
"comments": comment}, "VM")
if not vm:
continue
n_vm += 1
if not ip:
print(f" (ohne primary_ip4 - Host-geteilt)")
continue
# VMInterface eth0
vmif = None
if is_dry(vm["id"]):
print(f" + eth0 @ {name} [DRY-RUN]")
vmif = {"id": f"<dry:{name}/eth0>"}
else:
vmif = find("virtualization/interfaces",
{"virtual_machine": name, "name": "eth0"}, "name", "eth0")
if vmif:
print(f" = eth0 @ {name} ({vmif['id']})")
else:
s, d = req("POST", "/api/virtualization/interfaces/",
{"virtual_machine": vm["id"], "name": "eth0",
"status": st_active})
if s in (200, 201):
vmif = d
print(f" + eth0 @ {name} ({d.get('id')})")
else:
print(f" ! eth0 @ {name} FEHLER {s}: {json.dumps(d)[:200]}")
continue
# IPAddress
ipobj = get_or_create("ipam/ip-addresses", {"address": ip}, "address", ip,
{"address": ip, "status": st_active,
"namespace": ns_global, "dns_name": ""},
"IP")
if not ipobj:
continue
n_ip += 1
if is_dry(vm["id"]) or is_dry(ipobj["id"]) or is_dry(vmif["id"]):
print(f" + assign {ip} -> {name}/eth0 + primary_ip4 [DRY-RUN]")
continue
# assign IP <-> interface (idempotent)
q = urllib.parse.urlencode({"vm_interface": vmif["id"], "depth": 0})
s, d = req("GET", f"/api/ipam/ip-address-to-interface/?{q}")
have = any((r.get("ip_address") or {}).get("id") == ipobj["id"]
for r in d.get("results", []))
if have:
print(f" = assign {ip} -> {name}/eth0")
else:
s, d = req("POST", "/api/ipam/ip-address-to-interface/",
{"ip_address": ipobj["id"], "vm_interface": vmif["id"]})
print(f" {'+' if s in (200,201) else '!'} assign {ip} -> {name}/eth0"
+ ("" if s in (200, 201) else f" FEHLER {s}: {json.dumps(d)[:150]}"))
# primary_ip4 (idempotent)
s, vmnow = req("GET", f"/api/virtualization/virtual-machines/{vm['id']}/?depth=0")
cur = vmnow.get("primary_ip4")
cur = cur.get("id") if isinstance(cur, dict) else cur
if cur == ipobj["id"]:
print(f" = primary_ip4 {ip} @ {name}")
else:
s, d = req("PATCH", f"/api/virtualization/virtual-machines/{vm['id']}/",
{"primary_ip4": ipobj["id"]})
print(f" {'+' if s == 200 else '!'} primary_ip4 {ip} @ {name}"
+ ("" if s == 200 else f" FEHLER {s}: {json.dumps(d)[:150]}"))
print(f"\n== fertig ({'COMMIT' if COMMIT else 'DRY-RUN - nichts geschrieben'}) "
f"| VMs={n_vm} IPs={n_ip} ==")
if __name__ == "__main__":
main()

View File

@@ -1,6 +1,6 @@
#!/usr/bin/env python3
"""
TP36 — Cloudflare-Estate als SSoT in Nautobot (Etappe 1: manuelle Erstbefuellung).
TP44 — Cloudflare-Estate als SSoT in Nautobot (Etappe 1: manuelle Erstbefuellung).
Idempotenter Seeder (get-or-create) fuer die native nautobot.cloud-Modellwelt:
Manufacturer "Cloudflare"
@@ -18,8 +18,8 @@ Token-Quelle: docs/nas-vlan20/stacks/210-nautobot.yml (gitignored),
Schluessel NAUTOBOT_SUPERUSER_API_TOKEN.
Aufruf:
python3 nautobot/tp36-cf-estate-seed.py # Dry-Run (default)
python3 nautobot/tp36-cf-estate-seed.py --commit # legt an
python3 nautobot/tp44-cf-estate-seed.py # Dry-Run (default)
python3 nautobot/tp44-cf-estate-seed.py --commit # legt an
"""
import json
import os

315
nautobot/tp44-cf-sync.py Normal file
View File

@@ -0,0 +1,315 @@
#!/usr/bin/env python3
"""
TP44 Etappe 2 Teil B — CF-Estate LIVE aus der Cloudflare-API nach Nautobot syncen.
Ersetzt den Inline-Snapshot von tp44-cf-estate-seed.py durch einen periodischen
Live-Pull (get-or-create + Merge). Idempotent, Dry-Run default. Kein Push nach CF —
read-only Pull, Nautobot bleibt Dokumentations-SSoT, CF operativer Master.
Deckung (Live-Pull, je Endpoint 403-tolerant):
CloudNetwork cfd_tunnel + warp_connector (4)
CloudService workers/scripts + access/apps (11) [Repo-Token OK]
CloudService hyperdrive/configs + VPC directory (3) [braucht Token-Scope]
Verwaisung: ein CF-Objekt, das in Nautobot steht, aber im Live-Pull fehlt, wird
NICHT geloescht, sondern extra_config.stale=true gesetzt (Doku-SSoT bewahrt Historie).
Ein Objekt, das wieder auftaucht, verliert die Markierung.
Tokens:
CF : CF_API_TOKEN + CF_ACCOUNT_ID aus ~/.secrets/credentials.env (nie im Output)
Nautobot: NAUTOBOT_SUPERUSER_API_TOKEN aus docs/nas-vlan20/stacks/210-nautobot.yml (gitignored)
Aufruf:
python3 nautobot/tp44-cf-sync.py # Dry-Run (default) — zeigt Diff
python3 nautobot/tp44-cf-sync.py --commit # schreibt
"""
import json
import os
import re
import sys
import urllib.request
import urllib.parse
import urllib.error
from pathlib import Path
NB = os.environ.get("NAUTOBOT_URL", "http://10.40.20.30:8080")
REPO = Path(__file__).resolve().parent.parent
YML = REPO / "docs" / "nas-vlan20" / "stacks" / "210-nautobot.yml"
COMMIT = "--commit" in sys.argv
# ------------------------------------------------------------ Cloudflare-Seite
def cf_secrets():
env = {}
with open(os.path.expanduser("~/.secrets/credentials.env")) as fh:
for line in fh:
line = line.strip()
if line.startswith("#") or "=" not in line:
continue
k, v = line.split("=", 1)
env[k.strip()] = v.strip().strip("'\"")
return env
_CF = cf_secrets()
CF_TOK, CF_ACCT = _CF.get("CF_API_TOKEN"), _CF.get("CF_ACCOUNT_ID")
if not CF_TOK or not CF_ACCT:
sys.exit("CF_API_TOKEN/CF_ACCOUNT_ID fehlen in ~/.secrets/credentials.env")
def cf_get(path):
"""(ok, result) — faengt 403/404 ab, damit fehlende Token-Scopes den Sync nicht kippen."""
req = urllib.request.Request("https://api.cloudflare.com/client/v4" + path,
headers={"Authorization": "Bearer " + CF_TOK})
try:
with urllib.request.urlopen(req, timeout=30) as r:
return True, json.load(r).get("result")
except urllib.error.HTTPError as e:
if e.code in (403, 404):
return False, None
raise
def cf_ingress(tunnel_id):
ok, res = cf_get(f"/accounts/{CF_ACCT}/cfd_tunnel/{tunnel_id}/configurations")
rules = ((res or {}).get("config") or {}).get("ingress") or [] if ok else []
return [r["hostname"] for r in rules if r.get("hostname")]
def load_cf_estate():
"""Baut (networks, services) aus dem Live-Pull. Jedes Objekt:
(name, resource_type, description, extra_config, match_key, match_val).
match_key/-val = stabile CF-ID → idempotentes Matching trotz kuratierter Namen.
Live-Zaehl-/Statusfelder liegen unter eigenen Keys (connector_count, ingress_hostnames),
damit der Merge kuratierte Strings (z.B. connectors='3x @ ap1/ap2/ap3') nicht ueberschreibt."""
networks, services = [], []
skipped = []
# --- CloudNetworks: cloudflared-Tunnel (+ Connector-Zahl, Ingress-Hostnames)
ok, tuns = cf_get(f"/accounts/{CF_ACCT}/cfd_tunnel?is_deleted=false&per_page=50")
for t in (tuns or []):
networks.append((t["name"], "Cloudflare cloudflared Tunnel",
f"cloudflared-Tunnel ({len(t.get('connections') or [])} Connectoren)",
{"tunnel_id": t["id"], "kind": "cloudflared",
"connector_count": len(t.get("connections") or []),
"ingress_hostnames": cf_ingress(t["id"])},
"tunnel_id", t["id"]))
# --- CloudNetworks: WARP-Connector
ok, warps = cf_get(f"/accounts/{CF_ACCT}/warp_connector?per_page=50")
for w in (warps or []):
networks.append((w["name"], "Cloudflare WARP Connector",
f"WARP-Connector ({len(w.get('connections') or [])} Connectoren)",
{"tunnel_id": w["id"], "kind": "warp_connector",
"connector_count": len(w.get("connections") or [])},
"tunnel_id", w["id"]))
# --- CloudServices: Workers
ok, scripts = cf_get(f"/accounts/{CF_ACCT}/workers/scripts")
for s in (scripts or []):
services.append((s["id"], "Cloudflare Worker", "Cloudflare Worker",
{"script": s["id"]}, "script", s["id"]))
# --- CloudServices: Access-Apps
ok, apps = cf_get(f"/accounts/{CF_ACCT}/access/apps?per_page=100")
if not ok:
skipped.append("access/apps")
for a in (apps or []):
services.append((a.get("name") or a.get("id"), "Cloudflare Access Application",
f"Access-App ({a.get('type')})",
{"id": a.get("id"), "type": a.get("type"), "domain": a.get("domain")},
"id", a.get("id")))
# --- CloudServices: Hyperdrive (braucht Scope)
ok, hyper = cf_get(f"/accounts/{CF_ACCT}/hyperdrive/configs")
if not ok:
skipped.append("hyperdrive/configs")
for h in (hyper or []):
origin = h.get("origin") or {}
services.append((h.get("name") or h.get("id"), "Cloudflare Hyperdrive",
"Hyperdrive-Config",
{"id": h.get("id"), "database": origin.get("database"),
"user": origin.get("user")}, "id", h.get("id")))
# --- CloudServices: VPC-Service (braucht Scope)
ok, vpc = cf_get(f"/accounts/{CF_ACCT}/connectivity/directory/services")
if not ok:
skipped.append("connectivity/directory/services")
for v in (vpc or []):
services.append((v.get("name") or v.get("id"), "Cloudflare VPC Service",
"VPC-Service",
{"service_id": v.get("id"), "type": v.get("type")},
"service_id", v.get("id")))
return networks, services, skipped
# ------------------------------------------------------------ Nautobot-Seite
def nb_token():
for line in YML.read_text().splitlines():
m = re.search(r"NAUTOBOT_SUPERUSER_API_TOKEN[=:]\s*([^\s\"']+)", line)
if m:
return m.group(1)
sys.exit(f"NAUTOBOT_SUPERUSER_API_TOKEN nicht in {YML} gefunden")
NB_HDRS = {"Authorization": f"Token {nb_token()}", "Accept": "application/json",
"Content-Type": "application/json"}
def nb(method, path, body=None):
data = json.dumps(body).encode() if body is not None else None
r = urllib.request.Request(f"{NB}{path}", data=data, headers=NB_HDRS, method=method)
try:
with urllib.request.urlopen(r, timeout=20) as resp:
return resp.status, json.loads(resp.read().decode() or "{}")
except urllib.error.HTTPError as e:
return e.code, json.loads(e.read().decode() or "{}")
def nb_all(endpoint, params):
"""Alle Rows eines Endpoints (paginiert)."""
out, url = [], f"/api/{endpoint}/?{urllib.parse.urlencode(dict(params, depth=0, limit=200))}"
while url:
st, d = nb("GET", url)
out += d.get("results", [])
nxt = d.get("next")
url = nxt.replace(NB, "") if nxt else None
return out
_INDEX = {} # endpoint -> [rows] (einmal je Account geladen)
def index(endpoint, acct_id):
if endpoint not in _INDEX:
_INDEX[endpoint] = nb_all(endpoint, {"cloud_account": acct_id})
return _INDEX[endpoint]
def upsert(endpoint, name, payload, label, seen, acct_id=None,
match_key=None, match_val=None):
"""get-or-create + Merge von extra_config.
Matching: bei (match_key,match_val) nach der stabilen CF-ID in extra_config
(Rename-fest), sonst nach Name. Trackt die getroffene id in seen[endpoint]."""
ex = None
if match_val is not None:
for row in index(endpoint, acct_id):
if (row.get("extra_config") or {}).get(match_key) == match_val:
ex = row
break
else:
for row in (index(endpoint, acct_id) if acct_id else
nb_all(endpoint, {"name": name})):
if row.get("name") == name:
ex = row
break
if ex:
seen.setdefault(endpoint, set()).add(ex["id"])
merged = dict(ex.get("extra_config") or {})
merged.update(payload.get("extra_config") or {})
if merged == (ex.get("extra_config") or {}):
print(f" = {label}: '{name}' unveraendert")
return ex
if not COMMIT:
print(f" ~ {label}: '{name}' extra_config-Update [DRY-RUN]")
return ex
st, d = nb("PATCH", f"/api/{endpoint}/{ex['id']}/", {"extra_config": merged})
print(f" ~ {label}: '{name}' aktualisiert" if st == 200
else f" ! {label}: '{name}' PATCH {st}: {json.dumps(d)[:200]}")
return d if st == 200 else ex
if not COMMIT:
print(f" + {label}: '{name}' [DRY-RUN]")
return {"id": f"<dry:{name}>"}
st, d = nb("POST", f"/api/{endpoint}/", payload)
if st in (200, 201):
seen.setdefault(endpoint, set()).add(d["id"])
print(f" + {label}: '{name}' angelegt")
return d
print(f" ! {label}: '{name}' FEHLER {st}: {json.dumps(d)[:200]}")
return None
def mark_stale(endpoint, acct_id, seen_ids, label):
"""CF-Objekte in Nautobot (per id), die im Live-Pull fehlen → extra_config.stale=true.
Ein wieder aufgetauchtes Objekt verliert die Markierung."""
for row in index(endpoint, acct_id):
extra = row.get("extra_config") or {}
nm = row.get("name")
if row["id"] in seen_ids:
if extra.get("stale") and COMMIT:
nb("PATCH", f"/api/{endpoint}/{row['id']}/",
{"extra_config": {k: v for k, v in extra.items() if k != "stale"}})
print(f" ↩ {label}: '{nm}' stale-Markierung entfernt (wieder da)")
continue
if extra.get("stale"):
continue
if not COMMIT:
print(f" ⚠ {label}: '{nm}' fehlt im Live-Pull → wuerde stale markiert [DRY-RUN]")
continue
nb("PATCH", f"/api/{endpoint}/{row['id']}/", {"extra_config": dict(extra, stale=True)})
print(f" ⚠ {label}: '{nm}' als stale markiert (nicht mehr in CF)")
RESOURCE_TYPES = [
("Cloudflare cloudflared Tunnel", "cloud.cloudnetwork"),
("Cloudflare WARP Connector", "cloud.cloudnetwork"),
("Cloudflare VPC Service", "cloud.cloudservice"),
("Cloudflare Hyperdrive", "cloud.cloudservice"),
("Cloudflare Worker", "cloud.cloudservice"),
("Cloudflare Access Application", "cloud.cloudservice"),
]
def main():
print(f"== TP44 CF-Sync ({'COMMIT' if COMMIT else 'DRY-RUN'}) CF→{NB} ==")
networks, services, skipped = load_cf_estate()
print(f"Live-Pull: {len(networks)} CloudNetworks · {len(services)} CloudServices"
+ (f" · SKIP (Token-Scope): {', '.join(skipped)}" if skipped else " · alle Endpoints lesbar"))
print("\n[1] Manufacturer + CloudAccount")
mfr = upsert("dcim/manufacturers", "Cloudflare", {"name": "Cloudflare"}, "Manufacturer", {})
mfr_id = mfr["id"]
acct = upsert("cloud/cloud-accounts", "Cloudflare",
{"name": "Cloudflare", "account_number": CF_ACCT, "provider": mfr_id},
"CloudAccount", {})
acct_id = acct["id"]
print("\n[2] CloudResourceTypes")
rt_ids = {}
for name, ct in RESOURCE_TYPES:
rt = upsert("cloud/cloud-resource-types", name,
{"name": name, "provider": mfr_id, "content_types": [ct]}, "ResourceType", {})
rt_ids[name] = rt["id"]
seen = {}
print("\n[3] CloudNetworks")
for name, rt_name, desc, extra, mk, mv in networks:
upsert("cloud/cloud-networks", name,
{"name": name, "cloud_resource_type": rt_ids.get(rt_name), "cloud_account": acct_id,
"description": desc, "extra_config": extra}, "CloudNetwork", seen,
acct_id=acct_id, match_key=mk, match_val=mv)
print("\n[4] CloudServices")
for name, rt_name, desc, extra, mk, mv in services:
upsert("cloud/cloud-services", name,
{"name": name, "cloud_resource_type": rt_ids.get(rt_name), "cloud_account": acct_id,
"description": desc, "extra_config": extra}, "CloudService", seen,
acct_id=acct_id, match_key=mk, match_val=mv)
print("\n[5] Verwaisung (stale-Markierung; nur Endpoints, die gelesen wurden)")
# Nur markieren, wenn der zugehoerige Endpoint erreichbar war — sonst wuerde ein
# fehlender Token-Scope echte Objekte faelschlich als verwaist markieren.
if "access/apps" not in skipped and "hyperdrive/configs" not in skipped \
and "connectivity/directory/services" not in skipped:
mark_stale("cloud/cloud-services", acct_id, seen.get("cloud/cloud-services", set()), "CloudService")
else:
print(" · CloudService-Verwaisung uebersprungen (Token-Scope unvollstaendig — kein sicherer Vergleich)")
mark_stale("cloud/cloud-networks", acct_id, seen.get("cloud/cloud-networks", set()), "CloudNetwork")
print(f"\n== fertig ({'COMMIT' if COMMIT else 'DRY-RUN — nichts geschrieben'}) ==")
if skipped:
print(f"Hinweis: {', '.join(skipped)} nicht lesbar → Token-Scope erweitern, dann syncen sie mit.")
if __name__ == "__main__":
main()

View File

@@ -0,0 +1,119 @@
#!/usr/bin/env python3
"""
TP44 Etappe 2 Teil A — die zwei fehlenden IPAM-Prefixe der CF-CloudNetworks anlegen.
Zwei CloudNetworks (tp44-cf-estate-seed.py) tragen eine Route, die der Seeder als
cloud-network-prefix-assignment verknuepfen wuerde -- aber nur, wenn der Prefix in
IPAM existiert (dort Schritt [7], sonst "~ Prefix ... nicht in IPAM"):
10.40.0.0/16 -> bf-core-mesh (WARP-Connector auf crs326-core, TP16.1) [container]
10.101.0.0/24 -> fm.emsenhuber.net (Standort FM, cloudflared-Tunnel) [network]
Idempotenter get-or-create (Dry-Run default). Nach dem --commit den Seeder erneut
laufen lassen -- er haengt die zwei Assignments dann automatisch ein.
10.40.0.0/16 als 'container', weil die VLAN-/24 (10.40.10/20/30/...) aus
ingest-baseline.py bereits als Prefixe existieren; Nautobot nistet sie
automatisch darunter (rein hierarchisch, nicht-destruktiv).
Token-Quelle: docs/nas-vlan20/stacks/210-nautobot.yml (gitignored),
Schluessel NAUTOBOT_SUPERUSER_API_TOKEN.
Aufruf:
python3 nautobot/tp44-ipam-prefixes.py # Dry-Run (default)
python3 nautobot/tp44-ipam-prefixes.py --commit # legt an
"""
import json
import os
import re
import sys
import urllib.request
import urllib.parse
import urllib.error
from pathlib import Path
NB = os.environ.get("NAUTOBOT_URL", "http://10.40.20.30:8080")
REPO = Path(__file__).resolve().parent.parent
YML = REPO / "docs" / "nas-vlan20" / "stacks" / "210-nautobot.yml"
COMMIT = "--commit" in sys.argv
def load_token() -> str:
for line in YML.read_text().splitlines():
m = re.search(r"NAUTOBOT_SUPERUSER_API_TOKEN[=:]\s*([^\s\"']+)", line)
if m:
return m.group(1)
sys.exit(f"NAUTOBOT_SUPERUSER_API_TOKEN nicht in {YML} gefunden")
TOKEN = load_token()
HDRS = {"Authorization": f"Token {TOKEN}", "Accept": "application/json",
"Content-Type": "application/json"}
def req(method: str, path: str, body=None):
url = f"{NB}{path}"
data = json.dumps(body).encode() if body is not None else None
r = urllib.request.Request(url, data=data, headers=HDRS, method=method)
try:
with urllib.request.urlopen(r, timeout=20) as resp:
return resp.status, json.loads(resp.read().decode() or "{}")
except urllib.error.HTTPError as e:
return e.code, json.loads(e.read().decode() or "{}")
def find(endpoint: str, params: dict, match_key: str, match_val: str):
q = urllib.parse.urlencode(dict(params, depth=0))
st, d = req("GET", f"/api/{endpoint}/?{q}")
for row in d.get("results", []):
if row.get(match_key) == match_val:
return row
return None
def status_id(name: str):
return find("extras/statuses", {"name": name}, "name", name)["id"]
def namespace_id(name: str):
return find("ipam/namespaces", {"name": name}, "name", name)["id"]
# ---------------------------------------------------------------- Inventar
# (prefix, type, description)
PREFIXES = [
("10.40.0.0/16", "container",
"BF-Supernet; Route des CF WARP-Connectors bf-core-mesh (crs326-core, TP16.1)"),
("10.101.0.0/24", "network",
"Standort FM; Route des CF cloudflared-Tunnels fm.emsenhuber.net"),
]
def main():
print(f"== TP44 IPAM-Prefixe ({'COMMIT' if COMMIT else 'DRY-RUN'}) @ {NB} ==")
st_active = status_id("Active")
ns_global = namespace_id("Global")
for prefix, ptype, desc in PREFIXES:
existing = find("ipam/prefixes", {"prefix": prefix}, "prefix", prefix)
if existing:
print(f" = Prefix: '{prefix}' existiert ({existing['id']})")
continue
if not COMMIT:
print(f" + Prefix: '{prefix}' [{ptype}] [DRY-RUN]")
continue
payload = {"prefix": prefix, "status": st_active, "namespace": ns_global,
"type": ptype, "description": desc}
st, d = req("POST", "/api/ipam/prefixes/", payload)
if st in (200, 201):
print(f" + Prefix: '{prefix}' [{ptype}] angelegt ({d.get('id')})")
else:
print(f" ! Prefix: '{prefix}' FEHLER {st}: {json.dumps(d)[:300]}")
print(f"\n== fertig ({'COMMIT' if COMMIT else 'DRY-RUN — nichts geschrieben'}) ==")
if not COMMIT:
print("Danach: python3 nautobot/tp44-cf-estate-seed.py --commit (haengt die 2 Assignments ein)")
if __name__ == "__main__":
main()

75
opencode.json Normal file
View File

@@ -0,0 +1,75 @@
{
"mcp": {
"home-assistant": {
"type": "remote",
"url": "{env:MCP_HOME_ASSISTANT_URL}",
"enabled": false
},
"hostinger-api": {
"type": "local",
"command": [
"npx",
"-y",
"hostinger-api-mcp"
],
"environment": {
"HOSTINGER_API_TOKEN": "{env:MCP_HOSTINGER_API_TOKEN}"
},
"enabled": false
},
"mikromcp": {
"type": "local",
"command": [
"npx",
"-y",
"mikromcp",
"serve"
],
"environment": {
"MIKROMCP_CONFIG_PATH": "/Users/christophemsenhuber/dev/bf-infra/mcp/mikromcp/config/routers.yaml",
"MIKROMCP_DEFAULT_ROUTER": "crs326-core",
"ROUTER_AP1_USER": "admin",
"ROUTER_AP2_USER": "admin",
"ROUTER_AP3_USER": "admin",
"CRS326_CORE_USER": "admin",
"CRS326_BRANCH_USER": "admin",
"ROUTER_AP1_PASS": "{env:MCP_MIKROMCP_ROUTER_AP1_PASS}",
"ROUTER_AP2_PASS": "{env:MCP_MIKROMCP_ROUTER_AP2_PASS}",
"ROUTER_AP3_PASS": "{env:MCP_MIKROMCP_ROUTER_AP3_PASS}",
"CRS326_CORE_PASS": "{env:MCP_MIKROMCP_CRS326_CORE_PASS}",
"CRS326_BRANCH_PASS": "{env:MCP_MIKROMCP_CRS326_BRANCH_PASS}"
},
"enabled": false
},
"cloudflare": {
"type": "remote",
"url": "https://mcp.cloudflare.com/mcp",
"enabled": true
},
"ollama": {
"type": "local",
"command": [
"npx",
"-y",
"ollama-mcp"
],
"environment": {
"OLLAMA_HOST": "http://127.0.0.1:11434"
},
"enabled": false
},
"pve-mcp": {
"type": "remote",
"url": "http://10.40.20.173:3000/",
"enabled": true
},
"n8n-mcp": {
"type": "remote",
"url": "http://10.40.20.167:3001/mcp",
"headers": {
"Authorization": "Bearer {env:N8N_MCP_BEARER}"
},
"enabled": true
}
}
}

View File

@@ -1,65 +0,0 @@
{
"$schema": "https://opencode.ai/config.json",
"instructions": ["CLAUDE.md"],
"permission": "allow",
"mcp": {
"gitea-mcp": {
"type": "remote",
"url": "http://10.40.20.167:3000/mcp",
"enabled": true
},
"mikromcp": {
"type": "local",
"command": ["npx", "-y", "mikromcp", "serve"],
"environment": {
"MIKROMCP_CONFIG_PATH": "/Users/christophemsenhuber/dev/bf-infra/mcp/mikromcp/config/routers.yaml",
"MIKROMCP_DEFAULT_ROUTER": "ap1"
},
"enabled": true,
"timeout": 30000
},
"pve-mcp": {
"type": "remote",
"url": "http://10.40.20.173:3000/",
"enabled": true,
"timeout": 15000
},
"home-assistant": {
"type": "remote",
"url": "http://10.40.20.105:9583/private_29X8x73taoNEq6gzmbVdyg",
"enabled": true,
"timeout": 15000
},
"cloudflare": {
"type": "remote",
"url": "https://mcp.cloudflare.com/mcp",
"enabled": true,
"timeout": 15000,
"oauth": {}
},
"portainer": {
"type": "local",
"command": ["uvx", "--from", "mcp-portainer~=2.42.0", "mcp-portainer"],
"environment": {
"PORTAINER_URL": "https://10.40.20.126:9443",
"PORTAINER_API_KEY": "{env:PORTAINER_API_KEY}",
"PORTAINER_TLS_VERIFY": "0"
},
"enabled": true,
"timeout": 15000
},
"shelly-mcp": {
"type": "remote",
"url": "http://10.40.20.180:3030/mcp",
"headers": {},
"enabled": true,
"timeout": 15000
}
},
"command": {
"handoff": {
"description": "Session-Übergabe generieren oder laden",
"template": "Du bist das Handoff-Tool für das BF-Infra-Projekt.\n\n1. Ermittle, was zu tun ist:\n - Lese `docs/handoff-*.md` und finde die neueste Datei (nach Datum).\n - Wenn `$ARGUMENTS` \"resume\" oder einen Dateinamen enthält: lade die genannte oder neueste Handoff-Datei.\n - Wenn `$ARGUMENTS` leer ist oder \"generate\" enthält: generiere eine neue Handoff-Datei.\n\n2. Generieren (`/handoff`):\n - Lese `docs/teilprojekte.md` (Quick-Index-Block, Zeilen ~174-200) für den aktuellen TP-Status.\n - Prüfe offene Config-Transaktionen: `bash` mit `python3 nautobot/gc-transaktion.py status`.\n - Schreibe `docs/handoff-YYYYMMDD-thema.md` mit: Titel, Ausgangslage (was erledigt, was läuft), offene Schritte, Fallen/Gotchas, Einstieg für die nächste Session.\n - Sag dem User, welche Datei erstellt wurde.\n\n3. Laden (`/handoff resume`):\n - Lese die neueste Handoff-Datei vollständig.\n - Gib Zusammenfassung: Thema, Stand, offene Schritte.\n - Frage: \"Soll ich die Arbeit aus dieser Handoff-Datei fortsetzen?\"\n\nWichtig: Keine Secrets in die Handoff-Datei schreiben. Verweise auf existierende Doku statt zu duplizieren. Ziel < 200 Zeilen."
}
}
}