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