Thore CimbalandClaude Opus 5
3e226fba40
Schritte 1-3 ausgefuehrt, Tunnel gestartet und enabled. Kein Handshake -- der Public Key von CFGMON ist noch nicht als UniFi-Client hinterlegt. Drei Befunde ueber den Auftrag hinaus: - enp7s0 seit 18:11 DOWN, ausgeloest durch die Hetzner-Range-Umstellung (NIC neu angehaengt, hc-net-ifup wegen unmet condition uebersprungen). Zeitstempel belegen: 29 Minuten VOR dem Tunnelstart, kein Zusammenhang. - ufw ist auf CFGMON inaktiv; das Briefing setzte eine erzwingende Forward-Policy voraus. Regeln liegen jetzt als iptables-ACCEPT in PostUp/PreDown der lab.conf statt in ufw. - sudo ist aus einer Agenten-Session nicht bedienbar (kein TTY); die Schritte liefen ueber die docker-Gruppe, die root-aequivalent ist. Die sudo-Passwortabfrage ist damit keine wirksame Grenze -- Entscheidung darueber liegt bei sorb. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Verfahren
Wiederkehrende Abläufe zwischen Personen und Hosts — dort festgehalten, wo sie nicht an einem einzelnen Projekt-Repo hängen.
| Datei | Inhalt |
|---|---|
| deploy-uebergabe.md | Ablauf und Prüfliste für „einer baut, ein anderer rollt aus" |
| aar-vorlage.md | Vorlage für den After Action Report nach einem Deploy |
| aar/ | Abgelegte AARs, benannt JJJJ-MM-TT-<vorhaben>.md |
Die zugehörige Issue-Vorlage liegt unter
.gitea/ISSUE_TEMPLATE/deploy-uebergabe.yaml und erscheint beim Anlegen eines
Issues in diesem Repo als Deploy-Übergabe.
Abgrenzung zum Rest des Repos: hosts/ und shared/ halten offene Punkte,
dieses Verzeichnis hält wie wir arbeiten. Ein Verfahren wird hier nur
aufgenommen, wenn es mindestens einmal an einem echten Vorfall gescheitert
oder bewährt ist — der auslösende AAR wird jeweils verlinkt.