- 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>
Beides ging ueber den Auftrag hinaus: die Vorlage war nicht gefragt, und
k3s.md beschrieb einen Host, auf dem nichts geprueft wurde -- die
Eintraege dort waren von mir abgeleitet, nicht migriert.
Mitgezogen, weil durch die Loeschung verwaist: die TEMPLATE-Zeile im
Aufbau-Block und die k3s-Zeile in der Host-Tabelle des README. Die
uebrigen k3s-Erwaehnungen bleiben -- sie stehen als Kontext in
cfgmon.md, game.md und matrix.md und haengen nicht an der Datei.
Damit verschwindet k3s ganz aus dem Index. Falls der Host dort als
bekannt gelistet bleiben soll, ohne eigenen Backlog, waere eine Zeile
ohne Link die Alternative.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Inbound-Regel fuer TCP 443 in der Hetzner-Cloud-Firewall enthaelt
laut Console beide Eintraege, 0.0.0.0/0 und ::/0. Der vermutete
IPv6-Fallstrick besteht also nicht.
Quelle ist ausdruecklich die Console, keine Messung: vom Host aus ist
die Cloud-Firewall unsichtbar, es gibt keinen zweiten Host fuer eine
Rueckverbindung und Traefik laeuft ohne Access-Log. Ebenso festgehalten,
dass die Ausstellung vom 30.07. um 12:00 UTC nichts ueber IPv6 aussagt --
zu dem Zeitpunkt hatte selendis noch keinen AAAA-Record.
Damit bleibt als Risiko nur, ob die Ports bis zur Erneuerung offen
bleiben; der Normalzustand ist hier eingeschraenkt. Option A um einen
Kalendereintrag auf Mitte September ergaenzt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bisher lag der Backlog als BACKLOG.md in threadnet-operating und damit
in einem Repo, das nur einen Stack auf einem Host beschreibt. Da die
Arbeit inzwischen mehrere Hosts umfasst, hier ein File pro Host plus
shared/ fuer Themen, die sich nicht pro Host trennen lassen.
Uebernommen und auf die Hosts verteilt:
- CFGMON: Cert-Erneuerung inkl. IPv6-Firewall, nicht versionierter
Portainer-Stack (traefik/gitea/cadvisor), offener Remote-Write-
Receiver, Grafana-API-Credentials; dazu drei erledigte Punkte von
heute als Historie
- game: Host von CFGMON aus nicht erreichbar, 2 Targets down
- matrix: Mailversand klaeren, bevor die Zone gehaertet wird
- k3s: pusht auf den offenen Receiver, liegt aber schon im privaten Netz
- shared/zone-axion1337: DNS-Bereinigung und Apex-DMARC-Policy
Konventionen in README.md, Vorlage in TEMPLATE.md. IDs sind pro File
fortlaufend und werden nicht wiederverwendet. Praefix fuer DNS-Themen
ist ZONE-, nicht DNS-, weil DNS-01 der Name eines ACME-Challenge-Typs
ist und hier laufend als Fachbegriff vorkommt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
