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).

Offene Punkte → git.lab-Issues

Seit dem Framework-Umbau (2026-08-01) leben offene Punkte als Issues im management-Projekt; die IDs bleiben in den Issue-Titeln erhalten. Dieses File hält nur noch Bestand und Historie.

• CFGMON-01 — Zertifikatserneuerung braucht offene Ports (zeitkritisch ab 2026-09-28)
• CFGMON-03 — Prometheus-Remote-Write/Loki öffentlich ohne Auth (Weg A, nachgelagerte Prüfung)
• CFGMON-04 — Grafana-Admin-Credentials aus .env gelten nicht für die API
• CFGMON-09 — Gitea-Backups off-host (⚠️ Backup-Cron deaktiviert)

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 a876758)
• gitops: Verifikations-Job nach GitLab portiert + .gitea/workflows/ entfernt (Commit 5e46a24, 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 Repo, der API-Token für Issue-Verwaltung, das Gitea-Backup-Script (CFGMON-09).

(Stand der Analyse 2026-07-31. Issues und dieses Repo sind seitdem doch umgezogen — ADR-0002 —, das Repo dabei von Backlogs zu management umgewidmet ADR-0005. „Nicht rückbaubar" galt für den damaligen Rückbau der Gitea-CI, nicht auf Dauer.)

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: abgelöst durch gitops#48 (2026-08-01, sorb: HOHE Priorität — vollständige Issue-Migration + zentrale Gruppen-Roadmap; Plan-Skizze und die offene Erreichbarkeits-Entscheidung git.lab-only vs. extern stehen dort)

✅ Umgesetzt am 2026-08-01/02: Die Migration ist durch — 62 Issues liegen auf git.lab, die Gitea-Issues sind geschlossen und tragen einen Migrations-Fußtext. Alles darunter ist der Stand vor dem Umzug und bleibt als Historie stehen; die Aufzählung „Noch auf Gitea" gilt nicht mehr. Die zunächst verbliebene Ausnahme für Deploy-Übergabe-Issues ist am 2026-08-02 mit LABNET-03 ebenfalls zurückgebaut.

---

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 dieses Repo selbst (damals noch Backlogs, 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.