management/hosts/cfgmon.md

CFGMON

Monitoring-Stack, Gitea und der Reverse Proxy für alles Öffentliche.

Hostname	CFGMON
OS	Ubuntu 24.04.4 LTS
IPv4	188.245.193.243
IPv6	2a01:4f8:c17:93eb::1
Privat	10.0.0.3 (enp7s0, Hetzner-Netz — dort liegt auch k3s auf 10.0.0.2)
DNS	rohana.axion1337.de → Gitea, selendis.axion1337.de → Grafana
Stand	2026-07-30

Dienste

Container	Image	Compose-Projekt	Definition
prometheus	prom/prometheus:v3.3.1	monitoring	sorb/threadnet-operating, monitoring/
loki	grafana/loki:3.7.1	monitoring	dito
grafana	grafana/grafana:12.0.0	monitoring	dito
alloy	grafana/alloy:v1.16.0	monitoring	dito
node-exporter	prom/node-exporter:v1.9.1	monitoring	dito
traefik	traefik:v3.7.9	thread-net-git	sorb/thread-net-git, seit 2026-07-30 in main (siehe CFGMON-02)
gitea	gitea/gitea:1.27.0	thread-net-git	dito, gepinnt (war :latest)
cadvisor	gcr.io/cadvisor/cadvisor:v0.49.1	thread-net-git	dito, gepinnt (war :latest)
runner	gitea/act_runner:0.6.1	thread-net-git	dito, Container gitea-runner, siehe CFGMON-02
portainer_agent	portainer/agent:2.27.5	—	standalone, kein Compose

Prometheus-Jobs: operating_prometheus, operating_node-exporter, operating_cadvisor, operating_traefik (alle lokal), k3s_host_node (10.0.0.2:9100), pterodactyl_host_node und gameserver_cadvisor (beide 157.90.155.206, siehe game).

---

CFGMON-01 — Zertifikatserneuerung braucht offene Ports (IPv4 und IPv6)

Status: offen — zeitkritisch ab 2026-09-28

Das Cert für selendis.axion1337.de wurde am 2026-07-30 ausgestellt und läuft am 2026-10-28 ab. Traefik erneuert ca. 30 Tage vorher, also ab Ende September. Gitea (rohana.axion1337.de) hängt am selben Resolver und ist damit genauso betroffen — inklusive der Erreichbarkeit dieses Repos per HTTPS.

Traefik nutzt TLS-ALPN-01 (--certificatesresolvers.letsencrypt.acme.tlschallenge=true). Die Challenge läuft ausschließlich über Port 443, erreichbar aus dem offenen Internet. Bei gesperrtem Port scheitert sie mit:

urn:ietf:params:acme:error:connection :: Timeout during connect (likely firewall problem)

Traefik liefert dann sein Default-Self-Signed-Cert aus. Das fällt niemandem auf, bis jemand die Seite aufruft — genau so ist es am 2026-07-30 passiert.

Eine IP-Allowlist ist keine Option: Let's Encrypt veröffentlicht seine Validierungs-IPs nicht und prüft seit Einführung der Multi-Perspective Validation aus mehreren Regionen gleichzeitig.

IPv6 war der vermutete Fallstrick — geprüft und in Ordnung. rohana, selendis (und noch www.*, siehe ZONE-01) haben AAAA-Records auf 2a01:4f8:c17:93eb::1. Damit validiert LE bevorzugt über IPv6. Die Hetzner-Cloud-Firewall kennt kein familienübergreifendes „any": das Feld Source IPs ist eine Liste, 0.0.0.0/0 deckt IPv6 nicht mit ab, ::/0 muss separat drinstehen.

Stand 2026-07-30 enthält die Inbound-Regel für TCP 443 beide Einträge — vom User in der Hetzner-Console nachgesehen. Damit ist der IPv6-Pfad frei.

Diese Angabe stammt nicht aus einer Messung von diesem Host aus, sondern aus der Console. Vom Host ist es nicht verifizierbar: die Cloud-Firewall liegt außerhalb des Systems, iptables und ufw sagen nichts darüber (und Root gibt es hier nicht), eine Verbindung auf die eigene öffentliche Adresse läuft lokal, es gibt keinen zweiten Host für eine Rückverbindung, und Traefik läuft ohne Access-Log — es existieren also auch keine historischen Client-IPs. Für eine Prüfung von hier aus wäre ein Hetzner-API-Token mit Read-Berechtigung nötig.

Auch die erfolgreiche Ausstellung vom 2026-07-30 um 12:00 UTC belegt IPv6 nicht: zu dem Zeitpunkt existierte für selendis noch kein AAAA-Record, LE hat also über IPv4 validiert. Die Erneuerung Ende September ist der erste Lauf, der IPv6 überhaupt versucht.

Damit bleibt als Risiko nur, ob die Ports offen bleiben. Sie wurden am 2026-07-30 für die Ausstellung geöffnet; der Normalzustand dieser Umgebung ist, 80 und 443 aus Sicherheitsvorsicht auf die eigene IP zu beschränken. Werden sie wieder zugezogen, scheitert die Erneuerung Ende September genau wie heute Mittag — und zwar still.

Nächster Schritt: Entscheidung zwischen

• A — Ports offen lassen bzw. zur Erneuerung wieder öffnen. Nichts umzubauen, aber alle ~60 Tage daran zu denken, und ein Fehlschlag fällt erst auf, wenn jemand die Seite aufruft. Wenn A, dann mit einem Kalendereintrag auf Mitte September, nicht auf das Ablaufdatum.
• B — auf DNS-01 umstellen (empfohlen). Validierung über einen TXT-Record, kein offener Port nötig, läuft bei dichter Firewall durch. Braucht ein API-Token für die Zone bei IONOS, als Secret für Traefik hinterlegt. Ermöglicht zusätzlich Wildcard-Certs (*.axion1337.de), also künftige Subdomains ohne Portöffnung. Die frühere Voraussetzung — ein anfassbarer, versionierter Traefik-Stack — ist seit dem 2026-07-30 erfüllt (CFGMON-02, siehe „Erledigt").

---

CFGMON-03 — Prometheus-Remote-Write und Loki sind öffentlich ohne Auth

Status: offen — entscheidungsreif vorbereitet (2026-08-01 Nachtblock)

Vorbereitung/Empfehlung: Absender-Inventur ergab: Der k3s/Matrix-Host pusht längst übers private Netz (10.0.0.3, verifiziert) — öffentlich brauchen 9090/3100 nur noch Absender außerhalb des vSwitch, praktisch also der GAME-Host (157.90.155.206, siehe GAME-01).

• Weg A (empfohlen, 5 Minuten): Hetzner-Cloud-Firewall auf CFGMON — eingehend 9090/tcp + 3100/tcp nur von 157.90.155.206 (+ ggf. weitere bekannte Absender) erlauben; privater vSwitch-Verkehr ist davon unberührt. Sofort wirksam, kein Config-Umbau.
• Weg B (sauberer, später): GAME-Host in den vSwitch aufnehmen (deckt sich mit gitops#41 „privates Netz statt Internet" und der GAME-01-Firewall-Arbeit) — danach beide ports:-Blöcke aus der Compose entfernen, nichts mehr öffentlich.
• Weg C (verworfen): BasicAuth via Traefik — 9090/3100 sind direkte Port-Mappings, kein Traefik-Routing; der Umbau (Router+Middleware+htpasswd auf CFGMON, basic_auth-Block im GAME-Alloy) wäre deutlich mehr Bewegung als A/B für denselben Effekt.

Prometheus läuft mit --web.enable-remote-write-receiver und Port 9090 ist veröffentlicht, weil der k3s-Cluster und der Matrix-Server dorthin pushen. Loki ist auf 3100 ebenfalls veröffentlicht.

Ein offener Remote-Write-Receiver ohne Auth erlaubt Fremden, beliebige Metriken einzuspeisen — damit lassen sich Dashboards und Alerts unbrauchbar machen — und über die Query-API alle Daten auszulesen. Bei Loki auf 3100 gilt dasselbe für Logs, die typischerweise mehr Interna enthalten als Metriken.

In monitoring/docker-compose.yml steht dazu bereits ein Warnhinweis als Kommentar, umgesetzt ist er nicht.

Nächster Schritt: Beide Ports per Hetzner-Cloud-Firewall auf die Absender einschränken. Sauberer wäre, sie gar nicht öffentlich zu binden: k3s liegt mit 10.0.0.2 im selben privaten Netz wie CFGMON (10.0.0.3), der Push könnte also über das private Netz laufen.

Update 2026-07-30: der k3s/Matrix-Host (49.13.132.245, privat 10.0.0.2 — ist derselbe Host, siehe MATRIX-02) nutzt für seinen eigenen Remote-Write/Loki-Push bereits die private IP (http://10.0.0.3:9090/:3100, verifiziert in apps/monitoring/alloy-config.yaml), nicht 188.245.193.243. Der öffentlich erreichbare, unauthentifizierte Port bleibt trotzdem ein CFGMON-seitiges Risiko (jeder im Internet könnte ihn ansprechen, nicht nur der k3s-Host) - dieser Teil des Punkts ist also weiterhin offen, nur nicht mehr durch fehlende Netz-Erreichbarkeit des Matrix-Hosts blockiert.

---

CFGMON-04 — Grafana-Admin-Credentials aus .env gelten nicht für die HTTP-API

Status: offen, geringe Priorität

GF_SECURITY_ADMIN_USER und GF_SECURITY_ADMIN_PASSWORD greifen nur beim allerersten Start mit leerem Volume. Der Live-Admin wurde offenbar später in der UI geändert, die Werte aus der .env sind damit funktionslos. Verifikation von Datasources und Dashboards läuft deshalb über grafana.db statt über die API.

Kein Defekt, aber eine Falle: die .env sieht aus, als wäre sie die Quelle der Wahrheit, ist es aber nicht.

Nächster Schritt: entweder das echte Admin-Passwort in die .env nachziehen und dokumentieren, dass es nur den Ersteinrichtungsfall abdeckt, oder einen Service-Account mit API-Token für Verifikationszwecke anlegen. Letzteres ist sauberer, weil dafür kein Admin-Passwort nötig ist.

---

CFGMON-09 — Gitea-Backups off-host in die Storage Box (eigenes Borg-Repo)

Status: offen — bewusst zurückgestellt am 2026-07-30

Achtung: Der nächtliche Backup-Cron ist seit dem 2026-07-30 deaktiviert (auskommentiert in der Crontab von rantanplan). Bis zur Umsetzung dieses Punkts laufen keine Gitea-Backups — der letzte Stand ist /opt/backup/gitea-dump-2026-07-30.tar.gz. Beim Erledigen (oder Verwerfen) dieses Punkts den Cron wieder aktivieren.

Ausgangslage: Die Platte (38G) ist zu 73 % voll, der einzelne lokale Dump belegt 4,3 GB (beides df/du vom 2026-07-30). Das Backup-Script (/opt/thread-net-git/backup/gitea-backup.sh) rotiert deshalb auf genau einen Stand; Historie existiert nur, wenn jemand manuell per scp abzieht. Off-host-Kopien fehlen komplett.

Plan: Eigenes Borg-Repo auf der Hetzner Storage Box. Die Storage Box spricht Borg nativ über SSH (Port 23, laut Hetzner-Doku — nicht von hier verifiziert, es existiert noch keine Storage Box dafür), z. B. ssh://uXXXXXX@uXXXXXX.your-storagebox.de:23/./backups/gitea.

• Dedup: Die nächtlichen Dumps sind fast identisch — Borg überträgt nur geänderte Blöcke. Dafür den Dump unkomprimiert an Borg geben (das gzip im Script entfällt, Borg komprimiert selbst), sonst greift die Deduplizierung nicht.
• Retention über borg prune (z. B. 7 täglich, 4 wöchentlich, 6 monatlich) statt nur eines Standes.
• Optional ein Sub-Account der Storage Box mit eigenem Verzeichnis, damit das Gitea-Repo von anderen Backups getrennt bleibt.

Voraussetzungen, beide beim User:

1. Storage-Box-Username (uXXXXXX) bzw. Sub-Account (im Hetzner-Robot anlegen).
2. Der Host hat keinen SSH-Key (~/.ssh/ enthält nur authorized_keys, geprüft 2026-07-30) — Key generieren und den Public Key in der Storage Box hinterlegen (Robot-Webinterface oder einmalig per Passwort-Login).

CFGMON-11 — Gitea-CI-Rückbau nach GitLab-Umzug

Status: erledigt (2026-07-31 spätabends) — bis auf einen kosmetischen Handgriff: auf CFGMON cd /opt/thread-net-git && git checkout main && git pull (Checkout parkt noch auf dem inhaltsgleichen, inzwischen gelöschten Fix-Branch).

Dazu neu (2026-08-01 ~05:00): Auch /opt/threadnet-operating braucht einmal git fetch && git reset --hard origin/main — der State-Persistenz-Commit wurde dort direkt nach Gitea gepusht (dfe04c4a), vom Mirror überschrieben, vom Mac aus per Patch gerettet und kanonisch als 6ffab68 neu aufgelegt (inhaltsgleich, anderer Hash; Autorschaft erhalten).

Erledigt (2026-08-01, autonom):

• Actions-Toggles deaktiviert: ThreadNet-Web, threadnet-call, axion1337.chat-gitops
• ThreadNet-Web: alle .github/workflows/-Dateien entfernt (Commit 574c1bf)
• gitops: Verifikations-Job nach GitLab portiert + .gitea/workflows/ entfernt (Commit e58b8db, Pipeline grün, Mirror→Gitea verifiziert; milestone-release.yml war toter Code, siehe #33). Flux unberührt.
• thread-net-git: Runner-Service/Config/.env.example per Commit d904734 entfernt (auf git.lab; Mirror trägt nach Gitea) — noch nicht deployt, siehe unten.
• Registry-Entscheidung npm final (Evidenz: @sorb/threadnet-call-embedded ist pnpm-Dependency von apps/web, Lockfile pinnt Tarball-URL auf rohana): bleibt Gitea.

Verbleibende manuelle Schritte (User):

1. thread-net-git-Stand deployen erledigt (2026-07-31 spätabends, via CFGMON-Session): Runner-Container/Netz/runner-data//.env-Zeile entfernt, builder-1 aus der Gitea-Admin-UI gelöscht, Actions-Registrierungstoken rotiert. Stolperstein dabei: Rückbau-Commit d904734 hinterließ ein verwaistes networks:-Fragment (YAML invalide) — Fix nahm den kanonischen Weg Mac→git.lab→Mirror (15c8f2d), Hergang in thread-net-git#1 (geschlossen).
2. Token-Rotation a geklärt (2026-07-31 abends): der versehentlich in die VM getippte Token (a89bfb…) war der Gitea-Actions-Runner-Registrierungstoken (taucht nicht unter Access Tokens auf) — kein Access-Token-Risiko; wird mit Schritt 1 obsolet. Nach dem Runner-Löschen in der Admin-UI den Registrierungstoken dort einmal neu generieren (ein Klick), dann ist auch der exponierte Wert wertlos.
3. Token-Rotation b erledigt (2026-07-31 abends): Generalschlüssel (Projectplaning and implemantation axion, war npm-Publish UND Issue-Verwaltung, Klartext in .npmrc + Scratchpad + macOS-Schlüsselbund) gelöscht und durch drei least-privilege-Tokens ersetzt: gitlab-ci-npm (write:package, als maskierte GitLab-Gruppen-Variable GITEA_NPM_TOKEN), claude-issues (write:issue, ~/.config/gitea-rohana/token auf dem Mac), claude-push (write:repository, ~/.config/gitea-rohana/push-token). Erster CI-Publish 0.19.2-threadnet.6 verifiziert → threadnet-call#1 geschlossen. Alle Klartext-Reste entfernt (.npmrc, Skript, Schlüsselbund-Eintrag). Zusätzlich aufgeräumt: ungenutzte Alt-Tokens claude-push-20260730, claude-monitoring-rework-20260730 gelöscht.

Entscheidung vom 2026-07-30: Build-CI/CD zieht ins Homelab-GitLab (git.lab/axion1337.chat, Gruppe mit importierten Projekten angelegt; die Domain ist nur im Homelab auflösbar — von CFGMON/MATRIX aus nicht erreichbar, was für den Build-Anwendungsfall in Ordnung ist: Prod läuft bei Lab-Ausfall weiter, nur neue Builds pausieren). Der am 2026-07-30 auf Gitea-Seite aufgebaute CI-Unterbau wird damit teilweise überflüssig. Erst zurückbauen, wenn die GitLab-CI nachweislich läuft.

Sicher rückbaubar

• Actions-Toggle has_actions bei ThreadNet-Web (am 2026-07-30 per API aktiviert) wieder deaktivieren, ebenso bei threadnet-call (stoppt die fehlschlagende Workflow-Kaskade dort).
• .github/workflows/ in ThreadNet-Web (der kuratierte 6-Dateien-Satz) — wird durch .gitlab-ci.yml ersetzt. Die Erkenntnisse aus den Läufen vom 2026-07-30 mitnehmen: kein layered.sh (würde den js-sdk-Pin mit Upstream-develop überschreiben, braucht außerdem jq), stattdessen pnpm install --frozen-lockfile; webpack-Build braucht real ~4 GB Heap; contains(needs.*.result, ...)-Gates sind act-spezifisch kaputt.
• Geerbte Upstream-Workflows in threadnet-call (build/publish/test/translations/ zizmor/pr-deploy) — gleiches Schicksal.
• Runner-Identität: wenn der Runner-Service entfällt (siehe unten), builder-1 in der Gitea-Admin-UI deregistrieren und runner-data/.runner auf dem Host entfernen.
• Token: npm-Token in threadnet-calls untracked embedded/web/.npmrc (Klartext im Arbeitsverzeichnis, Fund vom 2026-07-30): revoken/rotieren. Der GitLab-CI-Publish bekommt einen eigenen, frisch erzeugten Token als GitLab-CI-Variable — der alte verschwindet von der Platte.

Entscheidungsabhängig

• Runner-Service in thread-net-git ganz entfernen? Hängt daran, ob das gitops-Repo seinen leichten deploy-on-push.yml (YAML-Validierung/Notification, läuft sauber) behält — dann bleibt ein Minimal-Runner nötig. Bei Komplett-Entfernung als Revert-Commit in thread-net-git: Compose-Service runner, runner/config.yaml, .env.example (RUNNER_TOKEN), Cache-Port-Bindung 8088, runner-data/.
• Registry-Ziel für @sorb/threadnet-call-embedded: bleibt die Gitea-npm-Registry (dann braucht GitLab-CI einen Push-Token dorthin — Neuanlage) oder wandert in die GitLab-Package-Registry (dann läuft die Gitea-Package-Seite leer).
• Container-Images bleiben in der rohana-Registry (Flux/k8s pullt von dort — spricht stark für Beibehalt). Gegenstück zur Token-Bilanz: GitLab-CI braucht dann einen neuen Deploy-/Push-Token für die rohana-Registry (Neuanlage, kein Rückbau).

Explizit nicht rückbaubar

Gitea selbst, gitops-Repo als Flux-Source, Issues/Wiki/dieses Backlogs-Repo, der API-Token für Issue-Verwaltung, das Gitea-Backup-Script (CFGMON-09).

Betroffene Issues (werden bei der GitLab-Migrations-Planung umformuliert): ThreadNet-Web#2, threadnet-call#1.

Nächster Schritt: die drei manuellen Schritte oben, dann → erledigt.

CFGMON-13 — Absender-Design für Release-/CVE-Meldungen: eigener Bot?

Status: entschieden (2026-08-01, sorb) — gleicher Bot (@alerts), eigener Raum !YRJvcEbVXtRlUIkNld:axion1337.chat. Umsetzungsplan inkl. CVE-Metriken/Grafana/ Alertmanager-Routing: gitops#47. release-watch ist bereits auf den Raum vorbereitet (Env MATRIX_RELEASE_ROOM_ID, Fallback Alerts-Raum). ⬜ Rest: @alerts in den Raum einladen (Join wurde als restricted abgelehnt — sorb), dann Deploy.

Zwei neue Meldequellen entstehen gerade neben dem klassischen Alerting:

1. release-watch (gitops#22, deploybereit): Upstream-Releases/Security-Releases → aktuell als Notiz über den @alerts-Bot in den Alerts-Raum
2. Trivy-CVE-Scans (gitops#31, läuft wöchentlich in der Lab-CI): Funde landen bisher NUR als Job-Artifact/-Log — keine aktive Benachrichtigung

Frage: Sollen diese "Informations-Meldungen" (Releases, CVE-Reports) einen eigenen Bot bekommen (z. B. @releases:axion1337.chat, ggf. eigener Raum), damit @alerts ausschließlich für echte Betriebsalarme steht und separat scharf/stumm schaltbar bleibt? Oder bewusst alles über @alerts bündeln?

Bei Entscheidung "eigener Bot": Anlage per mas-cli wie gehabt, release-watch-Env umziehen, Trivy-Anbindung (CI-Job → Matrix-Notiz bei Funden) gleich mit auf den neuen Absender bauen.

CFGMON-12 — Gitea-Projektmetadaten nach GitLab umziehen/integrieren

Status: offen · Prio MED · angelegt 2026-07-31

Beim CI/CD-Umzug (2026-07-31) ist nur der Code nach git.lab gewandert; alle Projektmetadaten liegen weiterhin auf Gitea/rohana. Verifiziert per API am 2026-07-31: alle 20 git.lab-Projekte melden open_issues=0.

Noch auf Gitea:

• Issues inkl. Kommentare/Labels: ThreadNet-Web (#2, #5, …), threadnet-call (#1), gitops (#24, #25, #32, …)
• Meilensteine (u. a. die Release-Meilensteine im gitops-Repo)
• Wiki (gitops-Wiki mit 00-TASKS.md-Log — bisher bewusst direkt-Gitea)
• Releases/Packages (npm-Registry bleibt laut Lockfile-Entscheidung in CFGMON-11 auf rohana — bei diesem Punkt prüfen, ob das so bleibt)

Vor Umsetzung zu klären:

1. GitLab-Gitea-Importer vs. API-Skript — der Importer verliert Autorenschaft (alles läuft unter dem Import-User) und Issue-Nummern können sich verschieben → Commit-/Kommentar-Referenzen prüfen.
2. Erreichbarkeit: rohana ist von überall erreichbar, git.lab nur im Homelab — das gilt dann für alle Issues und muss bewusst entschieden werden. Gleiches Argument betrifft das Backlogs-Repo selbst (bisher bewusst direkt-Gitea).
3. Flux-relevante Teile: ob die gitops-Wiki-Konventionen mitgehen.

Nach dem Umzug gehört ein Hinweis in die Topologie-Abschnitte (gitops README/CLAUDE.md, Fork-Docs) — dort steht aktuell „Issues/Wiki/Releases bleiben auf Gitea" als geltende Regel.

---

Erledigt

CFGMON-10 — threadnet-call-CI schlägt am Artifact-Schritt fehl · verworfen 2026-07-30

Ausgelöst durch einen Push nach threadnet-call am 2026-07-30: der Runner (builder-1) verarbeitete mehrere geerbte Upstream-Workflows, die meisten scheiterten am Artifact-Upload/-Download-Schritt. Ursprünglich unverifizierte Hypothese: das Job-Container-Limit (2,2 GiB / 1,5 CPU) ist zu knapp.

Hypothese inzwischen im Kern bestätigt — beim parallelen ThreadNet-Web-CI-Versuch starb der webpack-Build bei 92 % mit FATAL ERROR: ... JavaScript heap out of memory (Job 3442, 2026-07-30): diese Build-Klasse braucht real ~4 GB, der Host (3,7 GiB gesamt, ohne Swap, trägt daneben Gitea/Traefik/Monitoring) kann das strukturell nicht liefern.

Verworfen statt gefixt: Limit-Anhebung/Swap wird bewusst nicht weiterverfolgt — Build-CI zieht ins Homelab-GitLab um (siehe CFGMON-11), CFGMON bleibt bei leichten Jobs. Issue-Seite: threadnet-call#1.

CFGMON-02 — Traefik, Gitea, cAdvisor und Runner unter IaC gebracht · erledigt 2026-07-30

Liefen ursprünglich im Compose-Projekt thread-net-git aus /data/compose/8, einem von Portainer verwalteten Stack ohne Repo dazu. Jetzt in sorb/thread-net-git: :latest-Tags gepinnt (Gitea 1.27.0, cAdvisor v0.49.1), Projektname thread-net-git beibehalten (Volume-Kontinuität), README mit Betriebsregeln ("nie wieder über Portainer anfassen", Volume-Namen, Downgrade-Verbot für Gitea), nächtliches Backup-Script. Zusätzlich neu: ein runner-Service (gitea/act_runner:0.6.1, Container gitea-runner, Labels ubuntu-latest/linux-build/win-wine — die letzten beiden gezielt für Electron-Builds) — ursprünglich unter CFGMON-08 als offene Frage gelistet, siehe dort.

Entstanden auf Branch rework/stack, zunächst nicht gemergt (produktiv aber schon aktiv). 2026-07-30 nach main gemergt (origin/main == origin/rework/stack auf 02b3224, verifiziert) — damit spiegelt die Standardansicht des Repos jetzt den Live-Stand. Verifiziert am 2026-07-30 über die Compose-Labels der laufenden Container (working_dir: /opt/thread-net-git) und docker compose ls. gitea-data ist als external Volume deklariert — ein Deploy mit falschem Projektnamen schlägt laut fehl, statt leise ein leeres Volume anzulegen.

Zum Bootstrapping-Problem (Definition von Gitea liegt in Gitea): mitigiert, weil das Deploy-Verzeichnis selbst der Checkout ist — fällt Gitea aus, liegt die Definition weiterhin lokal auf dem Host. Gegen Verlust des ganzen Hosts hilft nur die Off-Host-Kopie, siehe CFGMON-09.

CFGMON-05 — Monitoring-Stack unter IaC bringen · erledigt 2026-07-30

Der Stack lief aus /opt/monitoring ohne Versionierung und mit :latest-Tags. Jetzt in sorb/threadnet-operating unter monitoring/, Images gepinnt, Grafana-Datasources und 9 Dashboards provisioniert. Projektname monitoring beibehalten, dadurch blieben die Volumes erhalten.

CFGMON-06 — Grafana-Certresolver zeigte ins Leere · erledigt 2026-07-30

Das Label sagte certresolver=le, Traefik kennt den Resolver aber als letsencrypt. Traefik protokollierte Router uses a nonexistent certificate resolver und lieferte für selendis.axion1337.de sein Default-Self-Signed-Cert aus. Aus dem Altbestand in /opt/monitoring unverändert übernommen und dort mindestens seit dem 2026-07-27 vorhanden.

Behoben in threadnet-operating, Commit a400f8a. Cert von Let's Encrypt (YR2) ausgestellt, gültig bis 2026-10-28 — die Nachfolge davon ist CFGMON-01.

CFGMON-07 — Alloy verlor seine Positions-Datei bei jedem Deploy · erledigt 2026-07-30

--storage.path=/var/lib/alloy/data war gesetzt, aber ohne Volume: die Positions-Datei lag im Container-Layer. Nach jedem Recreate las Alloy alle Docker-Logdateien von vorn, worauf Loki alles älter als 7 Tage mit HTTP 400 abwies (timestamp too old, reject_old_samples). Betroffen waren nur Alt-Logzeilen bis zurück zu 2025, keine aktuellen Daten.

Behoben durch ein alloy_data-Volume, Commit edac97e. Verifiziert: Positions überleben --force-recreate, zweiter Recreate erzeugt 0 Fehler.

CFGMON-08 — Kein Gitea-Actions-Runner registriert, Standort noch offen · erledigt 2026-07-30

Korrektur einer falschen Prämisse: der Eintrag ging davon aus, dass gar kein Runner existiert und wo einer laufen sollte, noch offen sei. Beides falsch — ein Runner (builder-1) läuft bereits, auf CFGMON, als Teil von thread-net-gits rework/stack- Branch, mit gezielt für Electron-Builds eingerichteten Labels. Details siehe CFGMON-02 — hier nicht dupliziert. gitops#33 (dieselbe falsche Prämisse) entsprechend korrigiert/geschlossen.