Die Stacks sind jetzt unter axion1337.chat/game-operating abgebildet. Der
Bestandseintrag sagt ausdruecklich, dass es ein Abbild und keine Quelle ist und
was ihm noch fehlt - sonst liest sich der Verweis wie eine Zusicherung, die er
nicht einloest.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Der Host ist seit 2026-08-02 im vSwitch (10.0.0.4). Damit liessen sich die
Compose-Definitionen einsehen, und die Ursache von GAME-01 steht fest: In keinem
der beiden Stacks gibt es einen ports:-Block. Coolify haengt alles an sein
eigenes Docker-Netz, auf 9100/8080 des Hosts lauscht nichts. CFGMONs Scrape-Ziele
auf der oeffentlichen IP konnten also nie funktionieren - was zum Befund passt,
dass up == 1 in 45 Tagen Retention nie vorkam. Die Firewall war eine zweite,
unabhaengige Schicht darueber.
Nachgetragen: beide Stacks mit Images, der Hinweis dass sie aus Coolify-Templates
stammen und nur dort existieren, und dass der Umzug nach Git bewusst zurueckgestellt
ist, bis das Matrix-Projekt fertig ist.
Der Host bleibt bewusst nur teil-inventarisiert - er wurde weiterhin nicht
betreten, OS-Stand und Plattenbelegung fehlen. Das steht jetzt explizit da,
statt ihn faelschlich als erfasst auszuweisen.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Gegenprobe vom Hausanschluss (178.25.213.70) zur CFGMON-Messung vom 01.08.
(188.245.193.243). Neu und aufschlussreich: Port 22 antwortet meiner Quelle
sofort und laeuft bei CFGMON in einen Timeout.
Zwei Schluesse, die die bisherige Vermutung praezisieren:
- Ein pauschaler Bann von CFGMON ist ausgeschlossen - waere die IP komplett
gesperrt, waeren auch 80/443 von dort tot. Es ist eine portbezogene Regel mit
Quellliste, keine IP-Sperre.
- 8080/9100 sind fuer NIEMANDEN freigegeben, auch nicht fuer den Hausanschluss.
Die Exporter sind also nicht versehentlich fuer CFGMON zu, sondern nirgends
offen.
Damit fehlt keine Ausnahme fuer CFGMON - die Empfehlung aus GAME-01 (Host in den
vSwitch statt oeffentliche Freigabe) traegt weiterhin.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Die letzte Ausnahme von ADR-0002 ist erledigt. Sie bestand, weil CFGMON git.lab
nicht erreichte; mit dem Site-to-Site-Tunnel (ADR-0004) ist der Grund weg.
Umgezogen mit dem Werkzeug der ersten Migration (verfahren/issue-migration/
migrate.py), damit derselbe Fusstext und dieselbe Idempotenz gelten:
- sorb/management#1 (offen) -> management#25
- sorb/management#2 (geschlossen) -> management#26, mit allen 11 Kommentaren
Original-Autor und -Zeitstempel sind erhalten (der Admin-Token darf created_at
setzen); die Gitea-Issues sind geschlossen und verweisen auf ihr Gegenstueck.
Der Gitea-Tracker ist damit leer.
Issue-Vorlage konvertiert statt kopiert: Gitea nutzt YAML-Issue-Forms, GitLab
Markdown-Templates. Die Feld-Begruendungen - der eigentliche Wert der Vorlage,
weil jedes Feld fuer eine real schiefgegangene Uebergabe steht - sind als
Kommentare erhalten. .gitea/ ist entfernt, damit dort keine neuen Uebergaben
mehr angelegt werden koennen.
Nachgezogen: README, roadmap, CLAUDE.md, ADR-0002 (Ausnahme durchgestrichen +
als zurueckgebaut markiert), ADR-0004 (Ernte eingeloest), hosts/overmind.md,
hosts/cfgmon.md, verfahren/README.md, verfahren/deploy-uebergabe.md.
55 relative Links geprueft, keiner tot.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Die Umwidmung ist in ADR-0002, ADR-0005 und dem README beschrieben - die
Verweise darauf hatte ich beim Umbau aber nie nachgezogen. Drei Stellen nannten
weiter den alten Namen, eine davon mit gleich drei falschen Aussagen im Praesens.
overmind.md, 'Repo-Topologie (Kontext)': sprach von '5 gespiegelten Repos' und
'Gitea bleibt: ... Issues, Backlogs (dieses Repo, ungespiegelt)'. Es sind sechs
(die fuenf Produkt-Repos plus management), die Issues liegen seit ADR-0002 auf
git.lab, und dieses Repo wird seit der Umwidmung selbst gespiegelt - es
behauptete also das Gegenteil des heutigen Zustands.
cfgmon.md: zwei Nennungen entschaerft. Beide stehen in Analyse-Abschnitten vom
2026-07-31 und sind als Historie richtig, lasen sich aber wie Gegenwart -
'Explizit nicht rueckbaubar' galt fuer den damaligen Gitea-CI-Rueckbau, nicht auf
Dauer. Datierte Marker statt Umschreiben.
Ausserdem trug der CFGMON-12-Abschnitt eine Liste 'Noch auf Gitea: Issues,
Meilensteine, Wiki', obwohl die Migration am 2026-08-02 mit 62 Issues durch ist.
Ergebnis vorangestellt, der Rest bleibt als Vorher-Stand stehen.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
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>
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>
