Christoph Emsenhuber
bb2c87c68e
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>
119 lines
8.2 KiB
Markdown
119 lines
8.2 KiB
Markdown
# 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.
|