admin/bf-infra
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
bb2c87c68e74f8835c293779f1b121dac3314666
bf-infra/docs/doku-cleanup-session.md
Christoph Emsenhuber bb2c87c68e Compliance 68/68 + TP24 (USV) ausgeloest + Doku auf den Stand nach dem Core-Cutover 
Zwei Straenge, die sich dieselben Dateien teilen — deshalb ein Commit.

1) COMPLIANCE-DRIFTS BESEITIGT (User: "beseitige autonom alle") -> 68/68, 0 Drifts

Entfernt wurden die 4 verbliebenen `extra`-Drifts (der fuenfte, core 10.40.41.211,
war schon ueber TP19-vlan1-core-address gefallen):
- ap1 + ap2: Werks-defconf `/ip dns static router.lan -> 192.168.88.1`. Auf beiden
  APs der einzige statische Eintrag, die IP existiert im Netz nicht. Der Core hat
  sein eigenes, korrektes router.lan -> 10.40.99.1 (im Template, compliant).
- crs326-branch: Bring-up-Rest SVI vlan10 + 10.40.10.2, Adresse zuerst.

Richtung bewusst "am Geraet entfernen" statt "ins Template aufnehmen" — genau so
steht es seit 2026-08-13 im Switch-Zweig des Templates. Der frueher notierte
Vorbehalt "potenzielle Rettungspfade" ist per User-Entscheid aufgehoben; der
Mgmt-Fallback aus VLAN10 auf dem branch entfaellt damit (Rueckweg = MAC-Winbox am
selben Draht).

Weg: 3 manuelle GC-ConfigPlans, kein Direkt-Write. Vorher /system backup je Geraet.
Deploy gestaffelt — erst die APs, am Geraet gegengeprueft, dann branch.

Verifikation am GERAET, nicht am Job: DNS-Statics total=0 bei unveraenderten 28
bzw. 3 WLAN-Clients; branch nur noch vlan99 + 10.40.99.2/24; Ping vom Core 4/4.
Entscheidende Gegenprobe: /interface bridge vlan/export byte-identisch — `bridge`
steht dort statisch als tagged-Member von VLAN10, das Entfernen des SVI hat also
weder Traffic-Wirkung noch neuen Drift. Danach Backup -> Intended -> Compliance,
alle 4 Geraete mit frischem Success-Datum.

Neue API-Falle, die erklaert warum es bisher kein Skript gab:
POST /plugins/golden-config/config-plan/ ist 405 — das ViewSet ist read-only.
ConfigPlans entstehen nur ueber den Job "Generate Config Plans" (plan_type=manual
+ commands-TextVar). plan_type=missing erzeugt ausserdem nur add-Zeilen, also muss
alles Entfernende zwangslaeufig ein manueller Plan sein.

Neu: nautobot/gc-configplan.py — loest Device-UUIDs einzeln per Name auf und
assertet plan.device UND config_set gegen das Ziel (die alphabetische
Sortier-Falle aus TP21.1 kann damit nicht wiederkommen), verweigert config_sets
mit <<REDACTED>> (Regel 1) und print-Zeilen, kann gestaffelt deployen
(--deploy-ids) und kapselt Backup -> Intended -> Compliance (--refresh-compliance).
Dry-Run ist Default.

2) TP16.1: GATE OFFEN, Runbook ausfuehrungsreif, Governance-Ausnahme #4

Die Bedingung "gated bis TP21 den CRS326 abdeckt" ist seit der Adoption am
2026-08-13 erfuellt. §3 neu gemessen, §4.3 von Platzhalter auf echte Werte.
Die letzte inhaltliche Unbekannte hat sich erledigt: "Rueckweg-Routing TBD" —
der Core IST L3-Gateway aller VLANs, es braucht keine Zusatzroute. wg-hub liegt
auf demselben Geraet und ist damit direktes Vorbild statt fernes Muster.

Klarstellung, weil leicht zu verwechseln: das Mesh ersetzt die Tunnel NICHT. Es
loest nur den privaten Zugang (10.40.0.0/16 per IP, inkl. ICMP); die oeffentlichen
FQDNs bleiben auf cloudflared. Relevant dabei: die Route 10.40.0.0/16 zeigt auf
bf-pve — und der faehrt derzeit nur einen Connector.

Ausnahme #4 (User 2026-08-16): die WG-Zeilen des Mesh-Bring-ups auf crs326-core
duerfen direkt gesetzt werden. Grund ist strukturell, nicht bequem — TP22-Regel 1
schliesst jede <<REDACTED>>-Sektion vom Push aus, ein Privkey ist ueber Golden
Config gar nicht deploybar. Auflage: Backup vorher, intended config danach zurueck
nach Nautobot. Scope: nur dieser Bring-up.

Damit das ein einmaliger Bootstrap bleibt, ist das Secret-Handling-Design
dokumentiert: ein privater Schluessel ist Geraete-Identitaet, keine Konfiguration
(wie ein SSH-Hostkey). Der private Teil entsteht am Geraet und geht nie weg, nur
der oeffentliche kommt in die SoT und wird in die Peer-Configs gerendert.
Stufe 2 (nautobot-secrets-providers + Vault) lohnt bei 4 Geraeten und einem Key
nicht. Nebenbefund: die WG-Peers fm/dw stehen mit hartkodierten public-keys im
Jinja-Template — Public Keys sind Daten, keine Templatezeilen.

3) TP24 — USV aus TP15 herausgeloest (User-Entscheid)

Die DC-USV war der letzte offene Rest in TP15 und hat mit Switching/Routing
sachlich nichts zu tun (eigene Einkaufs-, Verkabelungs- und Elektrik-Logik).
TP15 ist damit inhaltlich zu. TP24 traegt jetzt 48V-Bus, MeanWell/LiFePO4,
Laufzeiten, DC-Eingangs-Tabelle und die 5 offenen Entscheidungen — darunter neu
die Standortfrage, die sich durch den Core-Umzug ins UG neu stellt.

4) DOKU-AUFRAEUM-SESSION A-E abgearbeitet

- Ist-Stand-Block neu geschrieben, live gegen die Geraete geprueft. Alte Fassung
  als ausklappbare Historie, ⚠️-Provisorium entfernt.
- Reihenfolge-Abschnitt auf den echten Rest-Pfad TP5 -> TP6 eingedampft (Punkt 3
  sagte noch "Jetzt: Omada-PVID-Fix").
- Stale ap1-als-Router-Aussagen in TP3/TP4/TP15/TP16.1/TP21/TP-R korrigiert —
  fortgeschrieben, nicht ueberschrieben.
- CLAUDE.md: Mac mini .41.167 -> .20.167 (war stale, live per ARP bestaetigt),
  branch-Uplink "sw1 GE8" -> "core ether8", ALLNET-/Omada-Gotchas als Historie.
- switch/ als Archiv gekennzeichnet (Geraet ausgebaut, Runner nicht ausfuehrbar).
- omada-mcp + CF-Ingress live gegengeprueft: beides sauber, Punkt abgehakt.

Nebenbefund, eingetragen aber nicht angefasst: das CF-Tunnel-HA ist degradiert
(bf-nas und bf-pve mit je nur einem Connector), und vier tote Alt-Tunnel tragen
VLAN1-Origins — darunter die Aufloesung des "unidentifizierten VLAN1-Geraets
.41.133" aus TP19 (es ist das coolify-Origin).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-16 19:28:50 +02:00

8.2 KiB
Raw Blame History

Doku-Aufräum-Session — teilprojekte.md auf den Stand nach dem Core-Cutover bringen

✅ AUSGEFÜHRT 2026-08-16 — Punkte A, B, C, D vollständig; E weitgehend

Punkt Status Was passiert ist
A Ist-Stand-Block ✅ Neu geschrieben gegen den live geprüften Stand (MikroMCP: Identity, /ip/address, Interface-States). Alte Fassung als ausklappbare Historie erhalten, ⚠️-Provisorium-Vorspann entfernt. Zusätzlich die stale IP-Block-Zeile darüber korrigiert.
B Reihenfolge/Abhängigkeiten ✅ Auf den echten Rest-Pfad TP5 → TP6 eingedampft, plus „Follow-ups nebenher", „Nachgelagert" und „Durch". Die alte 1–7-Liste samt fortgeschriebenem Vorspann liegt als Historie im <details>.
C stale „ap1 = Router" ✅ TP4-Header, TP15 (Header + „als Nächstes" + CAPsMAN), TP16.1, TP21-Scope-Grenze korrigiert — fortgeschrieben, nicht überschrieben. Zusätzlich: TP3-Header (CAPsMAN → Standalone), TP-R-Sweep, TP15-Mgmt-Renumber-Zeile.
D Kleinkram ✅ omada-mcp + CF-Ingress live gegengeprüft → beides sauber, Punkt abgehakt. cudy1-Formulierung an den Live-Befund angeglichen. switch/README.md als Archiv-Kopf angelegt. (st-main war bereits korrekt.)
E CLAUDE.md + Memories 🟡 CLAUDE.md: Mac-mini-IP .41.167→.20.167 (war stale), branch-Uplink sw1 GE8→core ether8, ALLNET-/Omada-Gotchas als Historie, Nautobot-Zeile auf TP22-Stand, MCP-„nach Neustart"-Hinweise weg. Memories: 4 überholte mit Superseded-Kopf + Index nachgezogen. Offen: keine.

Zwei Live-Befunde nebenbei (in teilprojekte.md eingetragen, kein Eingriff): CF-Tunnel-HA ist degradiert (bf-nas/bf-pve haben nur je 1 Connector, s. TP16) und vier tote Alt-Tunnel mit VLAN1-Origins — darunter die Auflösung des „unidentifizierten VLAN1-Geräts .41.133" aus TP19.

Scope-Änderung am selben Tag: die DC-USV ist aus TP15 herausgelöst und heißt jetzt TP24.

Vorbereitet 2026-08-14. Reine Doku-Session, kein Netz-Eingriff, kein Gerät wird angefasst. Auslöser: docs/teilprojekte.md beschreibt an mehreren Stellen noch die Topologie vor dem 2026-08-08 (ap1 = Router, sw1/sw2 lebendig, Omada aktiv, CAPsMAN). Das Dokument sagt über sich selbst: „ganze Liste braucht mal eine Aufräum-Session" — das hier ist sie.

Warum das kein Kosmetik-Thema ist

CLAUDE.md schickt jede frische TP-Session zuerst in docs/teilprojekte.md („kein anderer Kontext nötig"). Steht dort ein überholter Ist-Stand, plant die Session Arbeit ein, die es nicht mehr gibt — oder trifft Entscheidungen auf Basis einer Topologie, die seit einer Woche nicht mehr existiert. Am 2026-08-14 sind beim Statusbaum vier solcher Stellen aufgefallen und sofort korrigiert worden; die Liste unten ist der Rest.

Leitplanken (Projektkonvention, gilt für die ganze Session)

  • Fortschreiben, nicht überschreiben. Historie bleibt lesbar — durchstreichen + datierter Nachtrag, so wie es TP1/TP2 mit ihrer Geräte-Abkündigung schon machen. Ein Doku-Stand, aus dem man nicht mehr rekonstruieren kann, warum etwas entschieden wurde, ist schlechter als ein veralteter.
  • Quelle ist das Gerät, nicht die Doku. Wo ein Ist-Stand behauptet wird, vorher per MikroMCP nachsehen (dieselbe Regel, an der TP22 Schritt 5 hing).
  • Zusammengehörige Marker mitziehen: Header-Marker, Abh.:-Zeile und die Erwähnung in „Reihenfolge / Abhängigkeiten" driften sonst auseinander.

Arbeitsliste

A — Der „Ist-Stand (Kurz)"-Block (Zeilen 21–25) 🔴 höchste Wirkung

Vier von fünf Zeilen sind Historie: ALLNET .11 als lebender Core, Omada-Controller .175 „🟢 live" (Container am 2026-07-16 gelöscht), ap1 .1 als Router + WAN-Edge, der Edge-Cutover-Pfad über sw1 gi16. Am 2026-08-14 wurde ein ⚠️-Vorspann davorgesetzt, der den Block als Historie markiert — die Neufassung steht aus.

Zu tun: Block neu schreiben gegen den echten Stand (crs326-core = L3 .99.1 / WAN vlan100 / 90.146.33.177, crs326-branch .99.2, ap1 .99.11 + ap2 .99.12 = reine APs, Nautobot GC als Config-Weg). Alte Fassung als datiertes Zitat darunter. Danach den ⚠️-Vorspann entfernen — er ist ausdrücklich ein Provisorium.

B — „Reihenfolge / Abhängigkeiten" (Zeilen ~664 ff.)

Die nummerierte Liste 1–7 ist inhaltlich tot, wird aber noch als Reihenfolge gelesen:

  • Punkt 3 („Jetzt: Omada-PVID-Fix") — obsolet, Omada ist raus (User-Entscheid 2026-07-22, „nie wieder aufgreifen").
  • Punkt 4 — TP5→TP6 stimmt inhaltlich, steht aber unter „Dann:" hinter einem obsoleten Punkt.
  • Punkt 7 — „TP20 hängt an TP18 ①" ist überholt (Abhängigkeit am 2026-07-16 entfernt).

Zu tun: Liste auf den tatsächlichen Rest-Pfad eindampfen (TP5 → TP6, daneben TP19-Restarbeiten und die Research-getriebenen TPs), Erledigtes als durchgestrichene Historie behalten.

C — Stale „ap1 = Router"-Aussagen in noch aktiven TPs

Diese TPs sind nicht abgeschlossen, tragen aber die alte Rollenverteilung — hier ist das Risiko am größten, weil sie noch gelesen und umgesetzt werden:

Stelle Was dort steht Realität
TP16.1 (~Z. 431) „Router bleibt ap1/ap2 rein für L3/WLAN" ap1/ap2 sind reine APs; L3 = core
TP21 Scope-Grenze (~Z. 548) „Router (ap1/ap2, dauerhaft) + beide CRS326"; „außerhalb bleibt Omada-WLAN" Omada existiert nicht mehr; Rollen vertauscht
TP15 (~Z. 384) „WLAN bleibt hAP ax²/CAPsMAN" CAPsMAN am 2026-08-08 abgeschafft
TP15 Header (~Z. 364) „Core-Tausch vorbereitet, Cutover = nächstes Wartungsfenster" Cutover am 2026-08-08 vollzogen (TP21.1)
TP15 (~Z. 372) „🔜 Als Nächstes: Core-Tausch = L3-Umzug" erledigt
TP4 Header „hAP#1 = Router + WAN-Edge" Rolle auf crs326-core (Teil-Nachtrag existiert bereits)

D — Kleinkram mit eigener Halbwertszeit

  • TP14.3 listet als offen: verwaister omada-mcp-Eintrag in ~/.claude.json (Server connectet nie mehr)
    • ungeprüfte CF-Ingress-Reste omada/omada-mcp. Beides in 10 Minuten erledigt oder abgehakt.
  • TP19 trägt noch cudy1 als „aktiver VLAN1-Leak" — laut TP22 Schritt 5 hat core ether11 keinen Link, Nautobot-Status Offline. Verifizieren, dann Formulierung angleichen.
  • Zeile 27 (Ziel-Absatz) nennt die ap2-frame-types-Härtung und st-main rrm/wnm als „Krücken, die mit VLAN1 rausfliegen". st-main ist seit TP3.3 (2026-08-13) fester Bestandteil der Golden Config — also keine Krücke mehr, sondern Zielzustand. Zeile entsprechend korrigieren.
  • switch/ (ALLNET-Telnet-Runner) + switch/ui-guides/02-vlan99-mgmt-cutover.md: Gerät ausgebaut → als Archiv kennzeichnen (README-Kopf), nicht löschen.

E — Gegenprüfen, nicht blind übernehmen

  • CLAUDE.md: Hardware-Tabelle ist aktuell gepflegt, aber die Gotcha-Liste enthält Sätze aus der ap1-als-Router-Zeit. TP3-Rebuild-Eintrag nennt „breiterer CLAUDE.md-Gotcha-Cleanup" bereits als offen.
  • Memory-Dateien: project_wifi_rebuild_crs326_l3, project_tp15_core_cutover_blocked_20260805, project_tp20_tp21_fasttrack_20260716 beschreiben Zwischenstände, die überholt sind. Memories sind Momentaufnahmen — überholte nach der Konsolidierungs-Regel zusammenführen oder löschen, nicht doppeln.

Reihenfolge & Aufwand

A → B → C → D, danach E als eigener Durchgang (anderes Substrat: Memory + CLAUDE.md). A und C sind die zwei, die wirklich Fehlentscheidungen verhindern — wenn die Zeit knapp ist, nur die. Grobschätzung: A+B+C ≈ eine Session, D+E ≈ eine halbe.

Abnahme

  1. Eine frische Session liest nur docs/teilprojekte.md und beschreibt daraus die Topologie korrekt: crs326-core als L3-Router, kein sw1/sw2, kein Omada, kein CAPsMAN, ap1/ap2 als APs.
  2. grep -n "CAPsMAN\|Omada\|ap1.*Router" docs/teilprojekte.md — jeder Treffer ist entweder als Historie markiert oder korrekt.
  3. Der ⚠️-Provisorium-Vorspann über Zeile 21 ist weg (weil überflüssig geworden).
  4. Statusbaum (/projektstatus) unverändert plausibel — die Aufräumaktion darf keinen TP-Status ändern; sie ändert nur, wie präzise er begründet ist.
Reference in New Issue View Git Blame Copy Permalink