Files
mission-control-v2/docs/WIEDERAUFBAU.md
T
HitonabiandClaude Opus 5.5 f4bbdad311 doku: Betriebsdoku neu (ARCHITEKTUR, BETRIEB, UPDATES, RADAR, WIEDERAUFBAU)
- ARCHITEKTUR.md (neu): Prozesse und Units, Rollen box/homelab und Partner-Instanz aus
  Phase 2a (kern/einstellungen.py, kern/zeit.py, kern/partner.py, /api/partner), Modell-Rollen,
  Bild-Weiche, wer welche Datei schreibt (inkl. mc2-quittiert.json), Meldeweg mit
  Telegram-Zweitweg, alle 62 /api-Routen, Herkunftspruefung, kurzer Ausblick Homelab-Teil.
- BETRIEB.md (neu, loest RUNBOOK.md und BACKUP.md ab): Handgriffe, Meldungen und Betreffzeilen,
  Waechter-Regeln (Partner nach 5 Takten, Spracherkennung nur wenn wach, Ausblenden-Knopf),
  Dienste schlafen/wecken, zweistufiger Deploy mit Prueftor, Sicherung und Zurueckspielen,
  Notfall, Pfade auf der Box.
- UPDATES.md (neu): Sonntags-Kette per Timer, Postchecks, Festhalten und Freigeben, Handbetrieb,
  Update-Verlauf, Fallen.
- RADAR.md (neu): Modell-Radar (Leitplanken, Nachtablauf, Pruefstand, Uebernehmen/Verwerfen,
  Merkliste) und Stack-Radar.
- WIEDERAUFBAU.md (neu, loest DISASTER_RECOVERY.md ab): entschlackte Schrittfolge, Anhang A
  (llama-swap-Unit und Drop-ins) behalten.

Stand der Aussagen: Code in main 75611be.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-24 17:37:09 +02:00

6.1 KiB

Wiederaufbau — die KI-Box von null

Stand 24.09.2026. Für den Totalschaden (neue Platte, neue Hardware). Für kleinere Störungen gilt BETRIEB.md, Abschnitt „Notfall".

Die Reihenfolge stammt aus dem Konzept vom 28.06.2026, aktualisiert auf den Stand vom 24.09.; auf einer frischen Box geprobt wurde sie nie. Das dort geplante Bootstrap-Skript mit Einrichtungs-Assistent wurde nie gebaut; der Volltext steht in der Git-Historie (docs/DISASTER_RECOVERY.md, letzter Stand 28.08.2026).

Was woher zurückkommt

Teil Quelle
Code des Box-Warts Gitea, main
Hermes: config.yaml, .env, Plugins, cron/, state/, Gedächtnis (memories/), SOUL.md, Skills, Cron-Skripte Sicherung (Tarball)
llama-swap-Config, Box-Wart-Zustand (/srv/models/mc2-*.json) Sicherung
Units und Drop-ins, auch die nicht im Repo liegenden Sicherung, Ordner systemd/ (zum Nachschlagen), dazu deploy/ im Repo
Lucys Stimmreferenz Sicherung, lucy-stimme/ref.wav
Versionen, die zusammen liefen Sicherung, known-good/
Modelle neu laden; die Pfade stehen in der llama-swap-Config
Engine, llama-swap, Hermes, Python-Umgebungen neu installieren

Schritte

  1. Sicherung besorgen. Die Tarballs liegen auch auf dem Proxmox-Host unter /var/lib/vz/mc2-backups. Der Spiegel-Schlüssel ~/.ssh/mc2_offsite steckt nicht in der Sicherung: Den neuesten Tarball von Hand holen (z. B. vom PC per scp) oder den Schlüssel neu einrichten (Security-Config, nur mit User-Ja).
  2. Grundsystem: Ubuntu 26.04, Benutzer hitonabi, Zeitzone Europe/Berlin, sudo loginctl enable-linger hitonabi (ohne Linger starten die User-Dienste nach einem Neustart nicht). Pakete: Python 3.14 mit venv (Bezugsquelle offen, prüfen), git, curl, jq, rsync, ffmpeg (Sprachnachricht der Daily News), ttyd (Konsole). Die Vulkan-Treiber installiert Schritt 5.
  3. Ordner: /srv/models und /etc/llama-swap anlegen und hitonabi geben (sudo chown -R hitonabi:hitonabi /srv/models /etc/llama-swap); MC2 schreibt die llama-swap-Config selbst.
  4. Code und Python-Umgebung: git clone ssh://gitea@192.168.178.153:2222/Hitonabi/mission-control-v2.git ~/mission-control-v2 (der SSH-Schlüssel der Box muss in Gitea hinterlegt sein), dann python3.14 -m venv backend/.venv und backend/.venv/bin/pip install -r backend/requirements.txt -r backend/requirements-dev.txt. Was nachweislich zusammen lief: known-good/pip-backend.txt aus der Sicherung.
  5. Engine und llama-swap (root): sudo bash deploy/update-swap.sh (Binary nach /usr/local/bin/llama-swap), Unit aus Anhang A nach /etc/systemd/system/llama-swap.service, sudo bash deploy/provision-engine.sh (Vulkan-Treiber, llama.cpp-Build nach /opt/llamacpp-vulkan, Drop-ins vulkan.conf und warmup.conf, /usr/local/bin/llama-swap-warmup.sh), dann sudo systemctl enable --now llama-swap. Das dritte Drop-in warmset.conf liegt nur in der Sicherung (systemd/llama-swap.service.d/).
  6. Hermes neu installieren (Git-Install nach ~/.hermes/hermes-agent; welcher Stand lief, steht in known-good/versions.txt). Den Dienst hermes-gateway legt Hermes selbst an; hermes-builtin-ui.service samt Drop-ins aus systemd/user/ der Sicherung übernehmen.
  7. Zustand zurückspielen: Tarball nach /srv/models/mc2-backups/ legen, dann bash deploy/restore.sh --yes <datei>. Auf einer leeren Box kommen auch Gedächtnis, SOUL.md, Skills, Cron-Skripte und mc2-*.json zurück, weil sie fehlen.
  8. Lucys Stimme: ~/.lucy-stimme/ (pocket-tts mit pocket_server.py) neu einrichten; das Programm stammt aus dem Lucy-Repo, die Referenz ref.wav aus der Sicherung. Offen: Die Einrichtungsschritte sind nirgends beschrieben.
  9. Deploy: bash deploy/deploy.sh spielt alle Repo-Units, Drop-ins, Cron-Skripte, Skills und Plugins aus, aktiviert Dienste und Timer und prüft nach. Das Plugin mc2-web-lesen ist nach dem Restore schon in der Hermes-Config aktiv; sonst einmalig hermes plugins enable mc2-web-lesen und hermes config set web.extract_backend mc2-lesen.
  10. Modelle laden: Die Pfade stehen in der zurückgespielten llama-swap-Config (-m, --mmproj, --spec-draft-model); known-good/models.txt listet die Dateien mit Größe. Zuerst das Hirn, dann den Coder, dann die Drafts. Die Bild-Zwillinge nutzen dieselben Gewichte, brauchen also nur ihren Projektor. Laden über die Oberfläche („Modelle selbst suchen") oder mit backend/.venv/bin/hf download <repo> <datei> --local-dir /srv/models/<Ordner>.
  11. Prüfen: bash deploy/stack-postcheck.sh, bash deploy/hermes-postcheck.sh, dann http://192.168.178.151:9001 öffnen: Alle Warnlampen sollen grün sein.
  12. Spracherkennung (schläft, nur bei Bedarf): bash voice_service/install.sh legt ~/.voice/venv an; aktivieren mit systemctl --user enable --now voice-service.

Anhang A — llama-swap.service

Von der Box abgegriffen am 28.06.2026, seitdem nicht neu verglichen. Benutzer und HSA_OVERRIDE_GFX_VERSION sind boxspezifisch. Nach /etc/systemd/system/llama-swap.service (root):

[Unit]
Description=llama-swap (lokaler LLM Router)
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=hitonabi
Environment=HSA_OVERRIDE_GFX_VERSION=11.5.1
Environment=PATH=/usr/local/bin:/usr/bin:/bin
ExecStart=/usr/local/bin/llama-swap --config /etc/llama-swap/config.yaml --listen 0.0.0.0:8080 --watch-config
Restart=on-failure
RestartSec=3

[Install]
WantedBy=multi-user.target

Drop-ins, die deploy/provision-engine.sh anlegt:

# /etc/systemd/system/llama-swap.service.d/vulkan.conf
[Service]
Environment=LD_LIBRARY_PATH=/opt/llamacpp-vulkan
# /etc/systemd/system/llama-swap.service.d/warmup.conf
[Service]
ExecStartPost=-/usr/local/bin/llama-swap-warmup.sh

Das Drop-in warmset.conf (laut Prüfbericht vom 24.09. MC_WARMUP_MODELS=fast) steht in keinem Skript; es kommt aus der Sicherung.

Erstinstallation in dieser Reihenfolge: sudo bash deploy/update-swap.sh (Binary) → Unit anlegen → sudo bash deploy/provision-engine.sh (Engine und Drop-ins) → sudo systemctl enable --now llama-swap.