# Athena-Leerhostaufbau – Praxisprotokoll

Dieses Protokoll hält die Abweichungen fest, die beim realen Neuaufbau auf
einem frischen Debian-13-Host sichtbar wurden. Jede dauerhaft notwendige
Korrektur muss zusätzlich im Installer, Restore-Skript oder in der regulären
Betriebsdokumentation umgesetzt werden. Das Protokoll enthält keine Secrets,
Chats oder privaten Nutzdaten.

## Zielsystem

- Hostname: `Athena`
- Betriebssystem: Debian 13 amd64
- Persistente Datenplatte: `/data`, ext4
- Haupt-GPU: NVIDIA RTX 5080 mit 16 GB VRAM
- Containerbetrieb: Docker CE und Compose-Plugin
- Inferenz: gepinnter llama.cpp-Build in Docker
- Oberfläche: OpenWebUI
- Werkzeuge: getrennte MCP-Container für Web, Home Assistant, ARR und Unraid

## Bereits eingearbeitete Korrekturen

| Bereich | Beobachtung im Leerhosttest | Dauerhafte Umsetzung |
|---|---|---|
| NVIDIA | Debian-Basispakete allein lieferten nicht den benötigten aktuellen Treiberzweig. | Offizielles NVIDIA-Repository, Mindestversion, Open-Kernelmodule und reproduzierbarer Neustartpfad im Installer. |
| CUDA | Container fanden einzelne CUDA-Kompatibilitätsbibliotheken nicht zuverlässig. | Bibliothekspfad und `ldconfig` werden vom Installer hergestellt und geprüft. |
| Modelle | Durch die restriktive Installer-Umask konnte der unprivilegierte Inferenzprozess GGUF-Dateien nicht lesen. | Nach erfolgreicher Hashprüfung werden Modelle unveränderlich, aber lesbar mit Modus `0444` gesetzt. |
| MTP | Das Fast-Modell besitzt den verwendeten MTP-Tensor bereits im IQ4-MIX-GGUF. | Kein redundanter Draft-Download und kein falscher separater Startparameter. |
| Router | Frische Volumes und der unmittelbar folgende API-Aufruf führten zu Ownership- beziehungsweise Start-Rennen. | Minimale Dateisystem-Capabilities, eigener Healthcheck, Abhängigkeit von gesundem Controller und explizite Readiness-Prüfung. |
| Installer | Ein erfolgreicher Containerstart wurde zu früh als erfolgreiche Installation gewertet. | Abschluss erst nach Router-Health, erfolgreicher Fast-Aktivierung und eindeutigem `INSTALL_READINESS_OK`-Marker. |
| Websuche | TinySearch/SearXNG wurden in mehreren Pfaden gestartet. | Websuche wird ausschließlich durch den Tool-Stack installiert und gestartet. |
| MCP | Altcontainer sollten nicht in die neue Architektur übernommen werden. | Neue, getrennte Tool-Container; Restore importiert nur freigegebene Secret- und Laufzeitdateien. |
| OpenWebUI | Eine gesicherte Datenbank war neuer als das zunächst gepinnte OpenWebUI-Image. | Datenbank und Image werden versionsgleich wiederhergestellt; Registry-Digest und OCI-Build-Revision werden geprüft. |
| Image-Backup | Das alte Archiv `openwebui-mcp-images.tar.gz` enthielt trotz seines Namens nicht das inventarisierte OpenWebUI-Image. | Restore nutzt als sicheren Fallback nur den gesicherten unveränderlichen Digest. Künftige Backups benötigen einen isolierten Probeimport. |
| Wiederholung | Ein späterer Installerlauf hätte die restaurierte OpenWebUI-Version wieder überschrieben. | Das Restore schreibt den geprüften lokalen Image-Tag auch in die dauerhafte Installationskonfiguration. |
| TinySearch-Volume | Das vom Installer vorbereitete Modellvolume wurde von Compose gleichzeitig als Compose-eigen behandelt. | Das Volume besitzt einen festen Namen und ist in Compose ausdrücklich als extern vorbereitet markiert. |
| Reasoning-Filter | Beide globalen Filter besaßen Priorität 0; bei gleicher Priorität entschied die ID-Sortierung statt der gewünschten Logik. | `Reasoning Default Off` läuft mit Priorität 10 sicher vor dem optionalen `Thinking`-Override mit Priorität 20. Filter und sicherer Installer liegen versioniert im Repository. |
| Folgefragen | OpenWebUI erzeugte nach Antworten zusätzliche Vorschläge und verbrauchte dafür einen weiteren Modellaufruf. | Folgefragengenerierung ist in der persistenten OpenWebUI-Konfiguration und im Compose-Standard deaktiviert. |

## Abnahmezustand am 21. August 2026

- Basisinstallation einschließlich Treiber, Docker, llama.cpp, Router und
  Fast-Profil erfolgreich.
- Fast-Profil mit 76.800 Token Kontext gestartet und durch Readiness bestätigt.
- HA-, ARR-, Unraid- und Web-MCP als getrennte Container gestartet.
- OpenWebUI-Daten und freigegebene MCP-Konfiguration aus dem Referenzbackup
  übernommen.
- Exakter OpenWebUI-Build anhand des gesicherten Registry-Digests und Commits
  rekonstruiert.
- Vollständiger Restore ein zweites Mal erfolgreich und ohne Datenbankmigration
  ausgeführt.
- OpenWebUI, Router und Fast-Inferenz sind gesund; HTTP-Zugriffe liefern Status
  200 und der Router meldet `qwen-fast`, `qwen-medium` und `qwen-long`.
- Alle vier MCP-Endpunkte sind aus dem OpenWebUI-Netz per TCP erreichbar.

## Noch abzunehmen

1. Anmeldung und Profilwechsel über die Oberfläche ohne Lesen alter
   Chat-Inhalte.
2. MCP-Protokolltest jedes Werkzeugs und Prüfung seiner Sicherheitsgrenze.
3. Neustarttest des gesamten Hosts.
4. WireGuard- und Fail-closed-Test am späteren Universitätsstandort.
5. Standardbenchmark mit RTX 5080 und anschließend mit der RTX 3060.
6. Push der lokalen Commits nach unabhängiger Prüfung des Git-Server-
   Hostschlüssels.

Erst nach diesen Punkten gilt Athena als vollständig reproduzierbare
Referenzinstallation.