Files
bf-infra/docs/announcements.md
Christoph Emsenhuber 3877c23505 GC-Backup: täglicher Scheduler angelegt (vorher gab es keinen)
Diagnose: die GC-Backups standen seit 2026-09-04, weil NIE ein Scheduler
existierte — Backup/Intended/Compliance liefen nur manuell aus Sessions. Die
"2×/Tag per SSH"-Annahme (CLAUDE.md Bot-Master-Zeile + gc-snapshot.py-Docstring)
war nie real; beide korrigiert.

Fix: Nautobot-Job "Execute All Golden Configuration Jobs - Multiple Device"
enabled + ScheduledJob "GC Backup+Compliance – taeglich" (platform=RouterOS,
täglich 03:30 UTC, Backup→Intended→Compliance). Sofort-Lauf SUCCESS, alle 5
Geräte backup/compliance auf 2026-09-12 10:35, frischer bf-golden-config-Commit.
Announcement-Eintrag ergänzt.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-12 12:36:48 +02:00

3.3 KiB
Raw Permalink Blame History

Announcements — bf-infra

Breaking News / Querschnitts-Änderungen, die jede folgende Session kennen muss, bevor sie losarbeitet — Dinge, die man sonst erst nach dem ersten Fehlschlag merkt. Kein Ersatz für die TP-Prosa (docs/teilprojekte.md) oder das Gitea-Board; hier steht nur, was quer zu den TPs gilt.

Format je Eintrag: Überschrift ## YYYY-MM-DD — <Titel>, dann die Zeilen Betrifft: (wer/was) und Aktion: (was eine Session konkret anders machen muss), optional ein, zwei Sätze Kontext. Neueste oben. Der Skill /news liest diese Datei und zeigt die Einträge, die seit dem letzten /news-Lauf dazugekommen sind (Rest auf Wunsch).


2026-09-12 — Golden-Config-Backups laufen jetzt täglich (vorher KEIN Scheduler)

Betrifft: alle, die sich auf GC-Backups/Compliance oder gc-snapshot.py-Werte verlassen. Aktion: Es gab nie einen automatischen GC-Backup-Zeitplan — Backup/Intended/Compliance liefen nur manuell aus Sessions (zuletzt 09-04 → 8 Tage Stillstand). Jetzt ScheduledJob „GC Backup+Compliance – taeglich" (Nautobot, Execute All GC Jobs - Multiple Device, platform=RouterOS, täglich 03:30 UTC, Reihenfolge Backup→Intended→Compliance). Wenn backup_last_success_date eines Geräts alt ist: zuerst prüfen, ob der ScheduledJob noch enabled ist (/api/extras/scheduled-jobs/), nicht das Gerät verdächtigen.

2026-09-12 — claude.json-Secrets laufen über {env:} (TP35 Schicht 2 ✅)

Betrifft: alle, die ~/.claude.json oder ~/.secrets/exports.zsh anfassen. Aktion: Keine Klartext-Secrets mehr in ~/.claude.json — MCP-Credentials referenzieren jetzt {env:MCP_*} (dieselben Namen wie opencode.jsonc, bidirektional kompatibel). SSoT ist ~/.secrets/exports.zsh (25 Vars). Nach jeder Änderung dort: ~/dev/.bin/gui-env-sync.sh und App-Neustart (laufender Prozess erbt die launchd-Umgebung nicht). ⚠ ~/.claude.json nie aus einer laufenden Session editieren — Claude Code schreibt dort State, der Edit würde überschrieben; der Flip läuft bei beendeter App über ~/dev/.bin/schicht2-claude-json-migrate.py --apply-claude.

2026-09-12 — TP36-Live: Gerätedaten stehen als CustomFields in Nautobot

Betrifft: alle, die Geräte-Ist-Werte (RouterOS-Version, Compliance %, DHCP-Server-Zahl, DNS-Modus, Mgmt-IP) brauchen. Aktion: Nicht mehr aus der Prosa ablesen und nicht raten — die fünf Felder (grouping: TP36-Live) hängen an den 5 RouterOS-dcim.Device in Nautobot. Aktualisieren: python3 nautobot/gc-snapshot.py --commit (liest nur aus Nautobot/GC, kontaktiert kein Gerät). Die Werte sind so aktuell wie das letzte Golden-Config-Backup (backup_last_success_date am Gerät).

2026-09-07 — SSoT-Cutover: Index/Status = Gitea, NICHT mehr teilprojekte.md

Betrifft: jede Session, die einen TP-Status ändert, anlegt oder abschließt. Aktion: Status/Reihenfolge/„was lief zuletzt" gehen ins Gitea-Issue (admin/bf-infra, Labels status:*/thema:*), nicht in eine Tabelle in docs/teilprojekte.md. Die Datei trägt nur noch die ### TPnn-Prosa. /projektstatus liest Baum + Status aus der Gitea-API. Branch tpNN-kurz jederzeit möglich, Merge nach main, sobald Code/Config steht.