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](#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)).

---

## 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](../shared/zone-axion1337.md)) 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](matrix.md#matrix-02--pusht-per-remote-write-auf-einen-offenen-prometheus--erledigt-2026-07-30))
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-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 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](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:** 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](#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 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-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.