Files

T

Thore CimbalandClaude Fable 5 92b448fe30 feat: slice 3 - wiki, sources and AARs in their neckbeard homes

Gate 4, slice 3: verfahren/, hosts/, vision/ and shared/ moved via git
mv - six AARs to docs/aar/ (four harvested by the 2026-08-09 retro,
two open), procedures and host knowledge to docs/wiki/ (admin,
deployment, architecture, new area vision), the retro protocol and the
commit mapping table to docs/sources/ (protokolle/, migration/). New:
the wiki index linking every page, and the mirror-topology page
carrying the why-two-places reasoning verbatim from the old CLAUDE.md
(F-013 preserved). All moved-path references retargeted; the link
checker drove the sweep to zero.

pruefe_prosa.py added (pattern C+D): SHA citations resolve via repo,
mapping table, optional component clones or a curated exemption list
(documented dead Gitea-force-push commits, a vendor-repo tag, an
Authentik uid that is hex but no git SHA, the external neckbeard
reference); wiki task prose without an issue reference errors, with a
visible pragma for deliberate checklists; the dead-tracker denylist
now covers every mirrored repo's retired Gitea tracker (F-005) - two
links re-verified against live GitLab titles and retargeted, five
defused into honest historical citations.

Verified: validate 0/0, gen_status --check current, drift 0. Demo on
the pre-migration state fires 6 findings (3 orphaned SHAs, 3 task
blocks); on the current tree exactly the 3 F-004 task blocks remain -
they turn green in slice 4 when the issues exist, which is why
pruefe_prosa joins CI only then.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

2026-08-11 12:00:00 +00:00

4.6 KiB

Raw Permalink Blame History

type, area, related

type

area

wiki-page

deployment

Verfahren: Deploy-Übergabe

Für die Konstellation „einer baut, ein anderer rollt aus". Zweck ist nicht mehr Prozess, sondern weniger Rückfragen und weniger stille Fehlschläge.

Eingeführt am 2026-08-01 nach dem Deploy der CVE-Pipeline (gitops#47), siehe aar/2026-08-01-cve-pipeline-gitops47.md.

Ablauf

Wer baut, öffnet auf git.lab ein Issue aus der Vorlage Deploy-Übergabe (.gitlab/issue_templates/Deploy-Übergabe.md, im Feld Description template).
Wer ausrollt, arbeitet die Prüfliste unten ab und deployt.
Wer ausrollt, hängt den AAR als Kommentar an dasselbe Issue (Vorlage: docs/aar/template.md). Bei Befunden ab MEDIUM zusätzlich als Datei unter docs/aar/.

Die vier Punkte, die den Unterschied machen

1. Mengengerüst vor dem Deploy

Bei allem, was etwas erzeugt — Nachrichten, Alarme, Zeitreihen, Requests — gehört die erwartete Anzahl beim ersten Lauf in die Übergabe. Geschätzt ist in Ordnung, gemessen ist besser; welches von beidem, muss dabeistehen.

Der Grund: „ein Alarm pro Fund" ist eine völlig unauffällige Zeile im Code und harmlos bei 5 Funden. Bei 126 ist es ein Ausfall. Der Unterschied steht nirgends im Diff — er ergibt sich erst aus den Daten, gegen die das Ding läuft.

Eine Stichprobe reicht: drei repräsentative Elemente von 29 messen und hochrechnen kostet Minuten und liefert die Größenordnung.

2. Verifikation dort, wo der Dienst liest

Ein grüner Linter belegt, dass eine Datei gültig ist — nicht, dass sie geladen wurde. Diese beiden Aussagen sind bei Bind-Mounts, Caches und Reload-Semantiken regelmäßig verschieden.

Also im Container prüfen, in der laufenden API, im tatsächlich geladenen Regelwerk. Ein Blick auf die Platte beweist nichts über den Prozess.

3. Deploy-Kommando vollständig übergeben

Inklusive Reload-, Restart- und Recreate-Schritten. Ein docker compose up -d, das Running meldet und dabei nichts aktiviert, ist der häufigste stille Fehlschlag: kein Fehler, kein Log, falscher Zustand.

Konkret auf dem Monitoring-Stack (CFGMON): Einzeldatei-Mounts hängen am Inode, git pull benennt beim Schreiben um und erzeugt damit einen neuen — der Container zeigt danach weiter auf die alte Datei. Es braucht --force-recreate. Details: gitops#52.

4. Zustellwege stumm schalten statt Deploy verschieben

Datensammlung und Außenwirkung lassen sich fast immer getrennt scharf schalten. Wenn der Zustellweg das Risiko ist, wird er abgeklemmt — nicht der ganze Deploy verschoben.

So läuft die Datensammlung ab sofort, das Dashboard steht, echte Zahlen ersetzen die Schätzung, und die Entscheidung über die Zustellung fällt auf Basis von Messwerten statt Vermutungen. Wichtig: die Stummschaltung gehört committet und dokumentiert, sonst ist sie in zwei Wochen ein Rätsel.

Prüfliste für den Ausrollenden

Diff gelesen, nicht nur die Beschreibung
Mengengerüst plausibel? Bei Zweifel an einer Stichprobe selbst messen
Configs mit den jeweiligen Werkzeugen validiert (promtool, amtool, compose config, py_compile …)
Außenwirkung identifiziert — was verlässt beim ersten Lauf das System?
Nach dem Deploy im Container verifiziert, dass die neue Config aktiv ist
Geprüft, ob vorher gesunde Dinge noch gesund sind (keine stille Regression)
AAR geschrieben, Folge-Issues angelegt, Stummschaltungen dokumentiert

Abgrenzung

Das Verfahren gilt für Übergaben zwischen Personen. Wer baut und ausrollt, braucht kein Issue — der AAR lohnt trotzdem, sobald es Befunde ab MEDIUM gab.

Kanonisierung nach CFGMON-Deploys (Topologie-Pflichtschritt)

CFGMON erreicht git.lab nicht — Commits aus Deploy-Sessions landen zwangsläufig direkt auf dem Gitea-Mirror und werden vom nächsten Mirror-Lauf kommentarlos überschrieben (zweimal passiert: dfe04c4→6ffab68 am 01.08. nachts, 2b715ca→0bd77e2 am 01.08. nachmittags). Deshalb gehört zu jeder Übergabe:

CFGMON-Seite vermerkt den Commit-Hash im Übergabe-Issue (Feld „Stand").
Mac-Seite kanonisiert zeitnah: Patch per https://rohana.axion1337.de/sorb/<repo>/commit/<sha>.patch ziehen (verwaiste Objekte bleiben eine Weile abrufbar), git am, Push nach git.lab. Der Hash ändert sich dabei — Autorschaft und Inhalt bleiben erhalten.
CFGMON vor dem nächsten Pull: git fetch && git reset --hard origin/main (inhaltsgleich, nur neuer Hash).

4.6 KiB Raw Permalink Blame History