HitonabiandClaude Opus 5.5
f4bbdad311
- 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>
109 lines
6.1 KiB
Markdown
109 lines
6.1 KiB
Markdown
# 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](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):
|
|
|
|
```ini
|
|
[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:
|
|
|
|
```ini
|
|
# /etc/systemd/system/llama-swap.service.d/vulkan.conf
|
|
[Service]
|
|
Environment=LD_LIBRARY_PATH=/opt/llamacpp-vulkan
|
|
```
|
|
|
|
```ini
|
|
# /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`.
|