Files
management/docs/wiki/admin/overmind.md
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

8.9 KiB
Raw Blame History

type, area, related
type area related
wiki-page admin

Overmind

Homelab-Host: GitLab (Dokploy-verwaltet) + CI-Runner. Nur im Lab erreichbargit.lab löst außerhalb des Homelabs nicht auf; Produktion (Flux auf CFGMON/MATRIX) hängt nicht von diesem Host ab, nur neue Builds pausieren bei Ausfall.

Hostname Overmind
DNS (Lab) git.lab10.58.73.17 (TLS via Dokploy-Proxy, Zertifikate von der aXionLabs-CA: step-ca, 24h-Leaf, Intermediate bis 2035)
CPU/RAM 14 Kerne, 30 Gi (Stand 2026-07-31: ~11 Gi verfügbar)
Disk 444 G NVMe (~278 G frei, Stand 2026-07-31)
KVM /dev/kvm vorhanden — Basis für die Windows-Build-VM
Stand 2026-07-31

Dienste

Dienst Definition Anmerkungen
GitLab CE 18.7.1 + Postgres 16 + Redis 7 Dokploy-Stack management-gitlabce external_url https://git.lab, SSH 2224; TLS terminiert der Dokploy-Proxy (GitLab-nginx lauscht nur :80)
gitlab-runner lab-builder-1 (v18.7.0) gleicher Stack, Service gitlab-runner Docker-Executor + Socket, concurrent = 1. Stolpersteine, live gefunden: (1) Docker-interner DNS löst git.lab auf den GitLab-Container auf, wo 443 zu ist → extra_hosts: git.lab:10.58.73.17 nötig; (2) Lab-CA muss nach /etc/gitlab-runner/certs/git.lab.crt (Config-Volume, übersteht Redeploys)
gitlab-runner lab-windows-1 Windows-Gast in der Build-VM Tags [windows], run_untagged=false, Shell-Executor PowerShell — siehe Runbook
Windows-Build-VM Dokploy-Stack windows-runner (live seit 2026-07-31) Image registry.git.lab/axion1337.chat/vendor/windows:stable (Eigenbau aus reviewtem Pin 7645a2b, Vendor-Repo git.lab/axion1337.chat/vendor/windows), on-demand (restart: "no", Start/Stop über CI-Jobs), 8G/6 Kerne/96G. Runbook: docs/axion-runner.md im Vendor-Repo. Gast-Uhr geht falsch (Traces stempeln ~+7h) — kosmetisch

Repo-Topologie (Kontext)

git.lab ist seit 2026-07-31 kanonisch für die gespiegelten Repos der Gruppe axion1337.chat — Stand 2026-08-09 sieben: die sechs Produkt-Repos (ThreadNet-Web, threadnet-call, thread-net-git, threadnet-operating, axion1337.chat-gitops, seit heute auch game-operating) und management, also dieses Repo. Push-Mirrors nach rohana/Gitea, direkte Gitea-Pushes tabu.

⚠️ gameserver (achtes Projekt der Gruppe) hat keinen Mirror — offen in management#32, dort liegt auf Gitea ein gleichnamiges Repo mit anderem Stand.

Gitea bleibt: Flux-Source (via Mirror beliefert), Registry, Packages. Issues nicht mehr — die sind am 2026-08-01/02 nach git.lab gewandert (ADR-0002). Die letzte Ausnahme, die Deploy-Übergabe-Issues auf dem Gitea-Tracker sorb/management, ist am 2026-08-02 mit LABNET-03 zurückgebaut: beide umgezogen (#25, #26), der Tracker ist leer. Ohne Ausnahme: Issues leben auf git.lab.

(Bis 2026-08-01 stand hier „Backlogs (dieses Repo, ungespiegelt)" — das Repo heißt seit der Umwidmung zum Management-Repo management und wird seither gespiegelt, ADR-0005.)

OVERMIND-01 — GitLab-Container-Registry aktivieren, Images nach Konsument sortieren

Status: erledigt (2026-08-01)

Abschluss-Verifikation: desktop_image baut und pusht per CI_JOB_TOKEN nach registry.git.lab/axion1337.chat/threadnet-web/desktop-build:bullseye (Job 386 grün, Tag per API bestätigt); desktop_linux nutzt dieses Image als Job-Container und lief damit grün durch (Job 398 - beweist auch den anonymen Pull des public Projekts durch den Runner-Daemon). Die rohana-REGISTRY_*-Variablen bleiben nur noch für den App-Image-Push (docker_web) in Gebrauch - genau die Ziel-Sortierung nach Konsument.

Die eingebaute GitLab-Registry ist aus (kein registry_external_url im Omnibus-Config). Folge: lab-interne Build-Images (windows-vm, element-desktop-build) machen den Umweg Lab-CI → rohana (Prod, Internet) → zurück ins Lab — koppelt Lab-Infrastruktur unnötig an die Verfügbarkeit des Prod-Hosts.

Ziel-Sortierung nach Konsument:

  • rohana (Gitea) behält: sorb/threadnet-web (App-Image — Flux/Prod pullt es), npm-Packages
  • Lab-Registry (registry.git.lab) bekommt: windows-vm, element-desktop-build — beides konsumiert nur das Lab selbst

Umsetzung (TLS terminiert wie bei git.lab der Dokploy-Proxy):

  1. Omnibus-Config: registry_external_url 'https://registry.git.lab', registry_nginx['listen_port'] = 5050, registry_nginx['listen_https'] = false; Port 5050 in der Compose exposen
  2. Lab-DNS: registry.git.lab10.58.73.17
  3. Dokploy: Domain registry.git.lab → GitLab-Service Port 5050 (Zertifikat von der aXionLabs-CA wie gehabt)
  4. Docker-Daemon-Trust auf Overmind: CA-Kette nach /etc/docker/certs.d/registry.git.lab/ca.crt (Datei liegt schon als /tmp/git.lab.crt vom Runner-Setup — kopieren reicht; kein Daemon-Restart nötig)
  5. CI-Umstellung: vendor/windows pusht nach registry.git.lab (Bonus: GitLabs eingebaute $CI_REGISTRY/$CI_JOB_TOKEN-Auth statt Gruppen-Secrets), desktop_image/desktop_linux in ThreadNet-Web folgen; Registry-Speicher liegt im gitlab_data-Volume (278 G frei)

Fortschritt 2026-07-31: Punkte 14 umgesetzt (Registry live auf registry.git.lab, 401/Bearer-Auth korrekt, CA-Trust auf dem Host); vendor/windows pusht per CI_JOB_TOKEN in die Lab-Registry — verifiziert, Tags 5bc25447 + stable vorhanden, Runbook referenziert stable.

Nächster Schritt: element-desktop-build von rohana in die Lab-Registry umziehen (ThreadNet-Web-CI: desktop_image-Push-Ziel + desktop_linux-Image-Referenz) — bewusst zurückgestellt, bis kein Auto-Job das alte Image parallel referenziert (Reihenfolge: erst neues Image bauen, dann Referenz umstellen).

OVERMIND-02 — Host-Ausfall 2026-07-31 ~19:15 lokal (NIC-Hang, Fix aktiv)

Status: Fix aktiv — die Beobachtung läuft als Issue #4 (Framework-Umbau 2026-08-01); dieser Abschnitt ist Bestand/Historie.

Ursache (Journal des Vor-Boots, via Claude-Session auf Overmind): e1000e Detected Hardware Unit Hang auf eno1 in Endlosschleife — die Intel-NIC hing (bekanntes e1000e-Problem in Kombination mit EEE/Energiesparen), der Host lief weiter, war aber netzwerktot. Kein OOM, kein Bezug zur Windows-VM/CI. Passt zu allen Symptomen: Ping tot, aber der Windows-Runner erreichte GitLab host-intern noch (Job 413 wurde aufgegriffen) und scheiterte erst an der DNS-Auflösung übers tote Interface.

Fix (2026-07-31, Overmind-Session): ethtool --set-eee eno1 eee off live gesetzt

  • persistente udev-Regel /etc/udev/rules.d/71-disable-eee-eno1.rules (greift bei jedem Boot). Temporäre sudoers-Freigabe danach wieder entfernt.

Offen:

  • NIC-/BIOS-Firmware-Update 2.4.0.0 → 2.5.2.0 erledigt (Wartungsfenster 2026-08-01, durch sorb)
  • Falls der Hang trotz EEE-off + neuer Firmware wiederkehrt: gezielter ASPM-Fix statt globalem Kernel-Parameter

Zeitleiste (lokal, UTC+2):

  • 18:58 — Windows-VM nach händischem Container-Stop+Start zurück, Runner online
  • 19:00 — desktop_windows Job 399 (Versuch 5): läuft bis build:native, scheitert an fehlendem rustc (kein Host-Problem)
  • 19:0519:12 — Provision-Job 409 grün (Rust 1.97.1 maschinenweit, Strawberry Perl, Python 3.14, NASM-PATH), Dienst-Neustart via Scheduled Task funktionierte
  • 19:13/19:14 — letzte saubere Runner-Herzschläge
  • zwischen 19:14 und 19:21 — Host fällt aus: Ping 100 % Verlust, git.lab-API tot
  • 19:21 — Job 413 (Versuch 6) wird noch aufgegriffen, Git-Fetch scheitert nach 8 s mit Could not resolve host: git.lab → Host-Netz/DNS zu dem Zeitpunkt bereits kaputt; danach Funkstille
  • ~20:15 — Host pingt wieder (Reboot durch sorb), 20:21 GitLab-API zurück, lab-builder-1 online; windows-runner-Container down (restart: "no" — korrekt)

Wichtig: Der Windows-Build war NICHT die Ursache — Job 413 hat nie Quellcode geholt, die VM lief nur idle (frisch provisioniert; denkbare Gast-Hintergrundlast: Windows Update/Defender nach den choco-Installs). Die 8-G-Zuteilung der VM plus GitLab-Stack blieb aber auch nach dem Puma-Fix ein enges Budget auf 30 Gi.

Konsequenz für die Build-Kette: RAM-Budget war nicht das Problem — VM bleibt bei 8G. Nach dem NIC-Fix lief die Kette durch: desktop_windows Job 438 grün (2026-07-31 ~21:50 lokal, Element Setup 1.12.17.exe, 141 MB, unsigniert) — ThreadNet-Web#5 geschlossen, Folgethemen (Signing/Branding) in ThreadNet-Web#6. Auf dem Weg dahin zusätzlich gefixt: GitHub-CDN-Abrisse bei app-builder-Downloads (resumefähiges Prefetch-Skript im ThreadNet-Web-Repo, Jobs 415/416/424/431).


Weitere CI-Betriebsthemen laufen über die Projekt-Issues (ThreadNet-Web#5 Windows-Strecke, threadnet-call#1 npm-Ziel) und CFGMON-11 (Gitea-CI-Rückbau).