fcd221388f99f1f502d35dca23c6158a2cbd1f9e
4 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
| 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> |
|||
| 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> |
|||
| 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> |
|||
| cbef32ca11 |
TP5-Session vorbereitet + Statuskorrekturen (TV-Beweis, TP19.1, Ist-Stand)
TP5 (Deny-by-default) ist nach TP22 der kritische Pfad und jetzt einsatzbereit vorbereitet — auf Live-Erhebung von crs326-core statt aus der Doku. Neu: - docs/tp5-deny-by-default-runbook.md: Ist-Stand forward/input/NAT/Interface- Listen, Inter-VLAN-Flow-Matrix aus conntrack + Countern, offene Entscheidungen D1–D6, 4 Etappen (Etappe 1 = reiner Log-Lauf ohne Blockierung), Rollback. - docs/doku-cleanup-session.md: Arbeitsliste A–E für die Aufräum-Session (Ist-Stand-Block, Reihenfolge-Liste, stale "ap1 = Router"/CAPsMAN-Aussagen). Statuskorrekturen in teilprojekte.md: - TP21.1 Punkt 4: TV-End-to-End-Beweis erbracht (Ping 5/5, MAC auf ether4/VID40 gelernt, RX 1.338 -> 6.909 Pakete). Das Kabel-Follow-up entfaellt — geloest wurde am Port, nicht am Kabel. - TP19.1: WIP -> erledigt (ap2 seit TP3-Rebuild auf .99.12, sw1/sw2 ausgebaut und in Nautobot Decommissioned). - TP5: Holes + WAN-Seal auf crs326-core re-verifiziert — die Verifikation vom 2026-07-02 galt ap1, das seit 2026-08-08 Werksreset ist. Befund: die 5 mDNS-Input-Regeln sind hinter TP10-seal-lan wirkungslos (0 Pakete). - Ist-Stand-Block als Historie markiert, "Naechster Schritt" auf TP5 -> TP6. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
