# 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](#cfgmon-02--traefik-gitea-cadvisor-und-runner-unter-iac-gebracht--erledigt-2026-07-30)) |
| 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](game.md)).

## Offene Punkte → git.lab-Issues

Seit dem Framework-Umbau (2026-08-01) leben offene Punkte als Issues im
[management-Projekt](https://git.lab/axion1337.chat/management/-/issues); 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)](https://git.lab/axion1337.chat/management/-/issues/7)
- [CFGMON-03 — Prometheus-Remote-Write/Loki öffentlich ohne Auth (Weg A, nachgelagerte Prüfung)](https://git.lab/axion1337.chat/management/-/issues/8)
- [CFGMON-04 — Grafana-Admin-Credentials aus `.env` gelten nicht für die API](https://git.lab/axion1337.chat/management/-/issues/9)
- [CFGMON-09 — Gitea-Backups off-host (⚠️ Backup-Cron deaktiviert)](https://git.lab/axion1337.chat/management/-/issues/10)

## 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-call`s 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](../docs/adr/0002-issues-und-management-ins-lab.md) —,
das Repo dabei von `Backlogs` zu `management` umgewidmet
[ADR-0005](../docs/adr/0005-pm-framework-kanban.md). „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](https://rohana.axion1337.de/sorb/ThreadNet-Web/issues/2),
[threadnet-call#1](https://rohana.axion1337.de/sorb/threadnet-call/issues/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](https://rohana.axion1337.de/sorb/axion1337.chat-gitops/issues/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](https://rohana.axion1337.de/sorb/axion1337.chat-gitops/issues/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](#cfgmon-11--gitea-ci-rückbau-nach-gitlab-umzug) 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-11--gitea-ci-rückbau-nach-gitlab-umzug)), CFGMON bleibt bei leichten
Jobs. Issue-Seite: [threadnet-call#1](https://rohana.axion1337.de/sorb/threadnet-call/issues/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](#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-09--gitea-backups-off-host-in-die-storage-box-eigenes-borg-repo).

### 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-01--zertifikatserneuerung-braucht-offene-ports-ipv4-und-ipv6).

### 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-git`s `rework/stack`-
Branch, mit gezielt für Electron-Builds eingerichteten Labels. Details siehe
[CFGMON-02](#cfgmon-02--traefik-gitea-cadvisor-und-runner-unter-iac-gebracht--erledigt-2026-07-30) — hier
nicht dupliziert. [gitops#33](https://rohana.axion1337.de/sorb/axion1337.chat-gitops/issues/33)
(dieselbe falsche Prämisse) entsprechend korrigiert/geschlossen.