management/hosts/overmind.md

Overmind

Homelab-Host: GitLab (Dokploy-verwaltet) + CI-Runner. Nur im Lab erreichbar — git.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.lab → 10.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 5 gespiegelten Repos (ThreadNet-Web, threadnet-call, thread-net-git, threadnet-operating, axion1337.chat-gitops) — Push-Mirrors nach rohana/Gitea, direkte Gitea-Pushes tabu. Gitea bleibt: Flux-Source (via Mirror beliefert), Registry, Packages, Issues, Backlogs (dieses Repo, ungespiegelt).

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.lab → 10.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 1–4 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, Beobachtung

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:05–19: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).