Files

T

Thore CimbalandClaude Fable 5 92b448fe30 feat: slice 3 - wiki, sources and AARs in their neckbeard homes

Gate 4, slice 3: verfahren/, hosts/, vision/ and shared/ moved via git
mv - six AARs to docs/aar/ (four harvested by the 2026-08-09 retro,
two open), procedures and host knowledge to docs/wiki/ (admin,
deployment, architecture, new area vision), the retro protocol and the
commit mapping table to docs/sources/ (protokolle/, migration/). New:
the wiki index linking every page, and the mirror-topology page
carrying the why-two-places reasoning verbatim from the old CLAUDE.md
(F-013 preserved). All moved-path references retargeted; the link
checker drove the sweep to zero.

pruefe_prosa.py added (pattern C+D): SHA citations resolve via repo,
mapping table, optional component clones or a curated exemption list
(documented dead Gitea-force-push commits, a vendor-repo tag, an
Authentik uid that is hex but no git SHA, the external neckbeard
reference); wiki task prose without an issue reference errors, with a
visible pragma for deliberate checklists; the dead-tracker denylist
now covers every mirrored repo's retired Gitea tracker (F-005) - two
links re-verified against live GitLab titles and retargeted, five
defused into honest historical citations.

Verified: validate 0/0, gen_status --check current, drift 0. Demo on
the pre-migration state fires 6 findings (3 orphaned SHAs, 3 task
blocks); on the current tree exactly the 3 F-004 task blocks remain -
they turn green in slice 4 when the issues exist, which is why
pruefe_prosa joins CI only then.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

2026-08-11 12:00:00 +00:00

18 KiB

Raw Blame History

type, area, related

type

area

wiki-page

admin

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

~~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).
~~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.
~~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 (Gitea-Zählung, Tracker stillgelegt — verbindlich: Migrations-Fußtext im GitLab-Issue), threadnet-call#1 (Gitea-Zählung, Tracker stillgelegt).

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#45 auf git.lab (ehemals Gitea-gitops#47, Tracker stillgelegt). 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:

release-watch (gitops#22, deploybereit): Upstream-Releases/Security-Releases → aktuell als Notiz über den @alerts-Bot in den Alerts-Raum
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#46 auf git.lab (ehemals Gitea-gitops#48, Tracker stillgelegt) (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:

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.
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).
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 (Gitea-Zählung, Tracker stillgelegt).

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 (Gitea-Zählung, Tracker stillgelegt) (dieselbe falsche Prämisse) entsprechend korrigiert/geschlossen.

18 KiB Raw Blame History