admin/bf-infra
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
31d1253fbe033f40ba63a8975d6790a909e54b28
bf-infra/docs/doku-cleanup-session.md
Christoph Emsenhuber 9a777a6d5c WLAN-Status: TP3/TP3.3-Header waren die eigentliche Drift-Quelle 
Eine frische Session hat nach Core und CAPsMAN gefragt, weil die Datei sich
selbst widersprach. Ursache war nicht fehlende Information, sondern dass bei
Statuswechseln jeweils nur der neue Abschnitt geschrieben und der alte Header
stehengelassen wurde:

- TP3 trug im Header "beide hAP ax2 sind reine Standalone-APs, CAPsMAN
  abgeschafft", und sein Lesehinweis verwies als "Ist-Stand" auf den
  08-08-Eintrag. Wer die WLAN-Frage hatte, landete zuerst dort -- und bekam
  die falsche Antwort. TP3 ist jetzt als vollstaendig historisch markiert und
  verweist auf TP28.
- TP3.3 stand als "TODO (neue Session)", obwohl es seit 08-17 in TP25
  aufgegangen ist.
- TP28 selbst trug unter dem Header "KOMPLETT" noch einen Punkt "OFFEN -- das
  GC-Modell beschreibt weiter Standalone-APs" mit der stale Zahl 76/76. Das
  war mein Rest vom 18.: Header umgeschrieben, Punkte darunter nicht.
- Die Abnahme in doku-cleanup-session.md verlangte woertlich "kein CAPsMAN" --
  ein Kriterium, das den falschen Zielzustand beschreibt, bestaetigt genau die
  Session, die den ueberholten Stand wiedergibt.
- Dazu HW-Refresh-Zeile und die ft-over-ds-Notiz in TP25 nachgezogen.

Merkregel, die jetzt an drei Stellen im Dokument steht: bei einem Statuswechsel
nicht nur den Header umschreiben, sondern die Punkte darunter mitziehen.

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

9.9 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 und CAPsMAN-Manager, kein sw1/sw2, kein Omada, ap1/ap2 als reine CAPs. ⚠️ Korrigiert am 2026-08-19: hier stand bis dahin „kein CAPsMAN" — als Abnahmekriterium. Ein Kriterium, das den falschen Zielzustand beschreibt, macht jede Prüfung wertlos; es hätte eine Session bestätigt, die den überholten Stand wiedergibt. Seit TP28 (2026-08-17) ist CAPsMAN zurück.
  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