admin/bf-infra
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
ff3c3a0ab3e076e9cf945e1160efc7105ae6b592
bf-infra/docs/doku-cleanup-session.md
Christoph Emsenhuber ef20616919 Doku-Rest: ip-plan, Aufraeum-Liste und Memories nachgezogen 
ip-plan.md war als Statusdokument stale: ap1 stand als "Router/GW, ist GW,
kein Umzug" und sw1 als lebendes Geraet mit offenem Migrationsschritt.
Beides seit dem Core-Cutover falsch. Kopfblock mit der heutigen
Rollenverteilung davorgesetzt, die sechs betroffenen Zeilen nachgezogen --
die Planung von damals bleibt darunter lesbar, geloescht wurde nichts.

doku-cleanup-session.md: Punkt E geschlossen. Der Nachlauf haelt fest, dass
zwischen 16. und 19. zwei Runden Drift dazugekommen sind, und warum die
erste lehrreicher ist: nachgezogen wurden die TP-Abschnitte und CLAUDE.md,
stehen blieb ausgerechnet der Block, den eine frische Session zuerst liest.

Memories: project_tp3_ap_rebuild bekommt einen Superseded-Kopf (der Satz
"reine Standalone-APs, kein Manager/CAP" war bis 08-17 richtig), das
wifi-rebuild-Memory einen Hinweis, dass die CAPsMAN-Abschaffung inzwischen
selbst revidiert ist. In ref_nautobot_api_gotchas stand "kein CAPsMAN" als
Begruendung fuer den logischen Controller -- die Begruendung ist weg, der
Stand bleibt, und die Modellfrage ist jetzt als offen markiert statt still
falsch.

Neu: feedback_abnahme_wirkung_nicht_anzeige. Drei Fehlbefunde in einer
Nacht -- Registration-Table, Job-Status, 70-Sekunden-Zaehler -- hatten
dieselbe Ursache: gemessen wurde die Anzeige daneben, nicht die Wirkung am
Ziel. Der WLAN-Fall kostete 14 Stunden.

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

9.6 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.

✅ NACHLAUF 2026-08-18/19 — die Liste ist abgeschlossen

Zwischen dem 16. und dem 19. sind zwei Runden Drift dazugekommen, beide durch echte Arbeit und nicht durch Nachlässigkeit — die Doku hinkt hier naturgemäß einen Tag hinterher.

Runde was driftete erledigt
08-18 (Commit 0ec812c) der „Ist-Stand (Kurz)"-Block war an vier Stellen überholt (Standalone statt CAPsMAN, 7.19.5/7.23 statt 7.24, 1.1.1.1 statt DoH, 68/68 statt 92/92); TP26 + TP27 existierten nur als Commits ohne Abschnitt ✅
08-19 (diese Session) Rest-Selbstwiderspruch im kritischen Pfad · docs/ip-plan.md führte ap1 als Router und sw1 als lebend · TP13-Technikteil beschrieb Standalone-APs · Memories + Index ohne TP28-Nachtrag ✅

Die Lehre aus der ersten Runde ist die wichtigere: nachgezogen wurden damals die TP-Abschnitte und CLAUDE.md — ausgerechnet der Block, den eine frische Session zuerst liest, blieb stehen. Merkregel: der Ist-Stand-Block wird bei jeder Änderung mitgezogen, nicht nur der betroffene TP.

Punkt E ist damit geschlossen. Neu entstanden statt weiterer Aufräumarbeit: vier ausführbare Runbooks (tp6-praemisse-messrunbook, tp16.3-nautobot-mesh-only, tp14.4-cf-access-token, tp13-botschafts-wlan) — die TPs standen als Einzeiler da, aus denen niemand losarbeiten konnte.

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