Fuenf Ursachen bei BookStack, die einander maskierten; wichtigste neue Lehre:
ein unhealthy Container ist fuer Traefik unsichtbar und sieht dabei exakt aus wie
ein fehlendes Netz. Dazu die electron-builder-Feinheit name vs. productName und
das Muster hinter meinen teuersten Fehlern: ungeprueft geaenderte Dinge.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Das Verfahren verlangt einen AAR nach Deploys; er fehlte und ist damit die
Luecke, die die zweite Konventionspruefung aufgedeckt hat. Neun Befunde, sieben
Lehren - darunter 'zuerst in die Traefik-Logs', 'thumbnail vergroessert nicht'
und 'Testumgebung ist nicht Zielumgebung'.
Nebenbei: Verweise auf wiki.lab auf die real genutzte Adresse axionwiki.lab
korrigiert.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Die Entscheidung wird bewusst vertagt, weil sie an einer Frage haengt, die sich
am Reissbrett nicht beantworten laesst: entsteht Dokumentation im Repo oder im
Browser? Mit BookStack entstuende eine zweite Quelle der Wahrheit neben git.lab -
das kann richtig sein, muss aber entschieden werden. Verfallsdatum fuer den
Parallelbetrieb: Ende August (DOC-03/#20).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Drei auseinandergelaufene Dokustaende aufgeloest: Gitea-Wiki-Repo (gepflegt,
nicht gespiegelt), wiki-Branch (Mai-Abzug von docs/), docs/ im main. Wiki liegt
jetzt im GitLab-Wiki; homelab/wiki baut daraus + homelab/docs + diesem Repo eine
Docusaurus-Seite. Damit entfaellt die letzte direkt-zu-Gitea-Ausnahme.
CLAUDE.md + README entsprechend nachgezogen; Rollout-Restarbeit als #18,
Branch-Entscheidung als #19.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
- ADR-0004: Status akzeptiert; real gebaute Architektur v2 dokumentiert
(UniFi bietet kein WG-Site-to-Site -> UDM-Server + CFGMON als Client mit
'Networks Behind Client'), inkl. Messwerten aus dem Negativtest
- AAR Lab-Seite: 5 Befunde, Eingrenzungsmethodik, 5 Lehren (u.a. 'Server'-Auswahl
erfasst nur das Tunnel-Subnetz; Portbedingung gehoert in beide Portfelder)
- README: Uebergabe-Issue-Ausnahme als auslaufend markiert
- shared/lab-netzwerk.md: beide WG-Zugaenge tabellarisch
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Host-Neustart 2026-08-01 ~21:57 CEST. Tunnel, Bootfix (After=docker.service),
Firewall-Regeln und Split-DNS kamen ohne manuellen Eingriff hoch; Handshake
2 s nach Messbeginn. Bootfix und Persistenz damit im Ernstfall verifiziert.
Der Handshake stand am 2026-08-01 ~21:15. Ursache des tagelangen Schweigens
war der in management#2 (Kommentar 399) als bestaetigt uebergebene UDM-Server-
PublicKey, der zu keinem Server auf der UDM gehoert. Nachtrag 2 dokumentiert
Eingrenzungsweg (tcpdump beidseitig, wg show am Geraet), Endzustand und Lehren.
Der Portversatz Fritzbox/UDM war ein realer zweiter Fehler, allein aber nicht
hinreichend.
Der AAR und der Kommentar an management#2 legten nahe, der Tunnel komme nach
dem Reboot von allein wieder, weil wg-quick@lab "enabled" war. Der Neustart am
2026-08-01 hat das widerlegt: der Dienst war ab 19:36 failed, weil wg-quick vor
dockerd startet und die PostUp-Regel an der noch fehlenden Kette DOCKER-USER
scheiterte -- wg-quick raeumte das Interface daraufhin ab.
Nachtrag als Abschnitt 6 ergaenzt, Fundstellen in Abschnitt 1 und Pruefpunkt 5
verweisen darauf. Behebung (systemd-Drop-in After=docker.service plus
idempotentes "iptables -N DOCKER-USER" in lab.conf) ist dort dokumentiert und
auf CFGMON umgesetzt.
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>
Uebergreifende Teile der gitops-CLAUDE.md (ThreadNet Server Suite) hierher
gehoben und erweitert: Topologie-Regeln, Kanban-Framework (ADR-0005),
Secrets-Handling, gelebte Lehren; Karpathy-Guidelines wortgleich uebernommen
(unantastbar). Lesbar von ueberall via Gitea-Mirror sorb/management.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
- README: Repo-Topologie-Abschnitt (git.lab = Quelle der Wahrheit, nie direkt
zu Gitea pushen); Ausnahme Deploy-Uebergabe-Issues bleiben auf dem Gitea-Tracker
(CFGMON erreicht git.lab nicht)
- issue-migration: alle 4 Repos migriert (62 Issues), gitops-Nummernverschiebung
dokumentiert, Cutover-Stand
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Nach dem Deploy der CVE-Pipeline (gitops#47) als Verfahren festgehalten. Der
Stand war korrekt und gelintet; der Blocker entstand erst aus der Datenmenge,
gegen die er lief -- eine Alarm-Instanz pro CVE, real 126 CRITICAL und 1222
HIGH. So etwas faellt in keinem Diff auf, nur beim Messen vor dem Deploy.
Neu:
- .gitea/ISSUE_TEMPLATE/deploy-uebergabe.yaml -- Uebergabe-Issue mit
Pflichtfeldern Mengengeruest, vollstaendiges Deploy-Kommando, Verifikation
im laufenden Dienst, Aussenwirkung samt Not-Aus, Rollback
- verfahren/deploy-uebergabe.md -- Ablauf und Pruefliste
- verfahren/aar-vorlage.md -- AAR-Vorlage
- verfahren/aar/2026-08-01-cve-pipeline-gitops47.md -- der ausloesende AAR
Abgrenzung im README ergaenzt: hosts/ und shared/ halten offene Punkte,
verfahren/ haelt, wie wir arbeiten. Die Uebergabe-Issues laufen bewusst hier
statt im Projekt-Repo, weil das Verfahren repo-uebergreifend gilt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Vom neuen Alerting (gitops#32) aufgedeckt, von CFGMON aus diagnostiziert
(kein kubectl dort, also per kube-state-metrics und Remote-Write-Serien).
Zwei getrennte Probleme:
- chronisch: DaemonSet-Pod in CrashLoopBackOff, 4880 Restarts, ~12/h,
reason=Error ohne OOM, laeuft seit mindestens 30 Tagen. Vermutlich
Portkonflikt auf 9100 mit dem eigenstaendigen node-exporter (hostNetwork).
Nicht verifiziert -- Pod-Logs brauchen Hostzugriff.
- akut: der Service-Endpoint auf 49.13.132.245:9100 antwortet seit
2026-08-01 01:19 UTC nicht mehr, 10.0.0.2:9100 dagegen schon. Kein Reboot
(77,6 Tage Uptime), faellt ins Fenster der Synapse-Portkorrektur.
Plus Nebenbefund: Job-Label prometheus.scrape.node_exporter existiert auf
CFGMON und MATRIX doppelt, External Label cluster= wuerde das trennen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Neue Befunde von CFGMON aus:
- Host lebt: Port 80/443 offen, antworten sofort -> Ursache 3 (Host weg) raus
- 8080/9100/22 laufen ins Timeout statt connection refused -> Signatur eines
Paketfilters, nicht eines toten Exporters -> Ursache 1 wahrscheinlich
- 10.0.0.0/24 abgeklopft: nur k3s (.2) und CFGMON (.3) -- der Host ist nicht
im vSwitch, damit ist die Zeile "Privat: unbekannt" beantwortet
- beide Targets waren im gesamten 45-Tage-Retentionfenster nie up
Seit dem Alerting-Rollout (gitops#32) erzeugen die Targets alle 4h echte
Alarme im Matrix-Raum. Zwei Alertmanager-Silences bis 2026-08-04 01:30 UTC
gesetzt, IDs im Eintrag vermerkt -- laufen bewusst ab, damit der Punkt nicht
still liegen bleibt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Stack laeuft versioniert und gepinnt aus sorb/thread-net-git statt aus
Portainer (verifiziert ueber Compose-Labels und docker compose ls),
Runner builder-1 ist registriert und meldet sich erfolgreich an Gitea
an. Dienste-Tabelle nachgezogen, CFGMON-01-Querverweis aktualisiert.
Workflow-Durchlauf weiterhin unbelegt, Tracking in gitops#33.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Schliesst die Doku-Luecke "Runner-Setup nur im Chat": Linux-Runner-Stolpersteine
(Docker-DNS/extra_hosts, CA-Pfad im Config-Volume), Windows-Runner-Plan mit
Image-Pin und Runbook-Verweis, Repo-Topologie-Kontext (git.lab kanonisch fuer
die 5 gespiegelten Repos).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Entscheidung 2026-07-30: Build-CI zieht ins Homelab-GitLab
(git.lab/axion1337.chat). CFGMON-11 haelt fest, was auf Gitea-Seite danach
zurueckgebaut werden kann (Actions-Toggles, Workflow-Dateien, ggf. der
Runner-Service) inkl. Token-Bilanz (npm-Token in .npmrc revoken, neuer
Registry-Push-Token fuer GitLab-CI als Gegenstueck). CFGMON-10 als
verworfen geschlossen - die Ressourcen-Hypothese wurde durch den
ThreadNet-Web-Webpack-OOM (Job 3442, heap out of memory bei 92%) im Kern
bestaetigt, aber der Fix entfaellt durch den Umzug.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Frueherer Stand ging von "kein Runner registriert, Standort offen" aus
(CFGMON-08). Beides falsch: builder-1 laeuft bereits auf CFGMON, als Teil
von thread-net-git's rework/stack-Branch (noch nicht in main gemergt, aber
produktiv aktiv, mit gezielt fuer Electron-Builds eingerichteten Labels).
CFGMON-02 entsprechend aktualisiert (in Arbeit statt offen, Merge-Rueckstand
als eigener Punkt benannt), CFGMON-08 nach Erledigt verschoben mit klarer
Korrektur-Notiz statt geloescht. Neuer Punkt CFGMON-10 fuer die dabei
entdeckten threadnet-call-CI-Fehlschlaege (Artifact-Schritt), verlinkt zum
neuen Issue threadnet-call#1.
Cross-referenziert in gitops#33 (korrigiert und geschlossen), gitops#44
(geschlossen als Duplikat), ThreadNet-Web#2 (praezisiert).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Der naechtliche Gitea-Backup-Cron ist auskommentiert, bis das Borg-Repo
auf der Storage Box steht — bis dahin laufen keine Backups, letzter
Stand ist der Dump vom 2026-07-30.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Stale K3S-01-Beispiel entfernt (hosts/k3s.md existiert seit 1c5e21c nicht mehr)
- Neuer Status "verworfen" fuer bewusst nicht umgesetzte Punkte, getrennt von
"erledigt"
- Explizite Konvention: Gegenstuecke in anderen Host-Dateien beim Schliessen
mitaktualisieren, nicht nur verlinkt stehen lassen
- Neuer Abschnitt "Verhaeltnis zu Gitea-Issues": Faustregel, wann etwas nur als
Issue, nur hier, oder als Eintrag mit Issue-Verweis landet
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
MATRIX-01 (Mail-Absender-Frage): per Config verifiziert, dass weder Synapse
noch MAS Mail versenden - kein Konfigurationsblock in den deployten Werten.
MATRIX-02: Korrektur einer falschen Annahme - "k3s-Host (10.0.0.2)" und
"matrix" sind dieselbe Maschine, nicht zwei getrennte. Remote-Write nutzt
bereits die private IP. MATRIX-04 neu: Host-Level Pre-Update-Benachrichtigung
(Issue #24). Cross-Referenzen in zone-axion1337.md (ZONE-02 entblockt) und
cfgmon.md (CFGMON-03-Update, neues CFGMON-08 fuer die Gitea-Runner-Standortfrage)
aktualisiert.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
