Files

T

Thore CimbalandClaude Fable 5 3fe05e7bd1 LABNET-03: Uebergabe-Issues nach git.lab, Gitea-Ausnahme zurueckgebaut

Die letzte Ausnahme von ADR-0002 ist erledigt. Sie bestand, weil CFGMON git.lab
nicht erreichte; mit dem Site-to-Site-Tunnel (ADR-0004) ist der Grund weg.

Umgezogen mit dem Werkzeug der ersten Migration (verfahren/issue-migration/
migrate.py), damit derselbe Fusstext und dieselbe Idempotenz gelten:
- sorb/management#1 (offen)      -> management#25
- sorb/management#2 (geschlossen) -> management#26, mit allen 11 Kommentaren

Original-Autor und -Zeitstempel sind erhalten (der Admin-Token darf created_at
setzen); die Gitea-Issues sind geschlossen und verweisen auf ihr Gegenstueck.
Der Gitea-Tracker ist damit leer.

Issue-Vorlage konvertiert statt kopiert: Gitea nutzt YAML-Issue-Forms, GitLab
Markdown-Templates. Die Feld-Begruendungen - der eigentliche Wert der Vorlage,
weil jedes Feld fuer eine real schiefgegangene Uebergabe steht - sind als
Kommentare erhalten. .gitea/ ist entfernt, damit dort keine neuen Uebergaben
mehr angelegt werden koennen.

Nachgezogen: README, roadmap, CLAUDE.md, ADR-0002 (Ausnahme durchgestrichen +
als zurueckgebaut markiert), ADR-0004 (Ernte eingeloest), hosts/overmind.md,
hosts/cfgmon.md, verfahren/README.md, verfahren/deploy-uebergabe.md.
55 relative Links geprueft, keiner tot.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj

2026-08-02 12:00:00 +00:00

8.6 KiB

Raw Blame History

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 sechs gespiegelten Repos der Gruppe axion1337.chat — die fünf Produkt-Repos (ThreadNet-Web, threadnet-call, thread-net-git, threadnet-operating, axion1337.chat-gitops) und management, also dieses Repo. Push-Mirrors nach rohana/Gitea, direkte Gitea-Pushes tabu.

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

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
Lab-DNS: registry.git.lab → 10.58.73.17
Dokploy: Domain registry.git.lab → GitLab-Service Port 5050 (Zertifikat von der aXionLabs-CA wie gehabt)
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)
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 — 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: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).

8.6 KiB Raw Blame History Unescape Escape