74 lines
7.1 KiB
Markdown
74 lines
7.1 KiB
Markdown
# 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. |
|
||
| Werkzeug-/Kontextschutz | Große MCP-Antworten und wiederholte identische Aufrufe konnten Kontextfenster sprengen beziehungsweise Tool-Schleifen erzeugen. | Globaler Stability Guard begrenzt Resultate, verdichtet alte Inhalte profilabhängig und stoppt Wiederholungen; JSON-Schemas und Bilder werden nicht beschädigt. |
|
||
| Werkzeugauswahl | Überlappende oder zu allgemeine MCP-Beschreibungen führten zu falschen Werkzeugen, unnötigen Wiederholungen und paralleler Nutzung von MUA und Unraid-Diagnose. | Klare USE-/DO-NOT-USE-Texte auf Server- und Werkzeugebene; Web-Unterwerkzeuge sind nach Lookup, Verifikation, Shopping und Tiefenrecherche getrennt. Bestehende OpenWebUI-Verbindungen werden ohne Änderung von URL, Schlüssel oder Berechtigungen aktualisiert. |
|
||
| Leistungsdaten | Benchmarkdaten sollten sichtbar sein, ohne private Chat-Inhalte zu protokollieren. | Ein globaler Abschlussfilter schreibt ausschließlich technische Zahlen in eine lokal rotierende JSONL-Datei und zeigt eine knappe Statuszeile. |
|
||
| Antwortaktionen | Wiederkehrende Nachbearbeitungen sollten bewusst per Klick statt als permanenter Zusatzprompt laufen. | Eine versionierte globale Action bietet lokale Kurzfassung, Checkliste, Diagnose, Unsicherheits-/Quellenprüfung, Thinking-Verbesserung und Markdown-Kopie; keine Schreib- oder Profilwechselaktion. |
|
||
| Sprachausgabe | Beim ersten Leerhostaufbau war kein TTS-Dienst Bestandteil des Compose-Stacks. | Piper `piper-tts` 1.6.0 läuft als eigener interner CPU-Container mit persistenter deutscher Stimme; Open WebUI nutzt ihn ausschließlich über den authentifizierten Router. |
|
||
| Persistente Audioeinstellungen | Die restaurierte OpenWebUI-Datenbank überstimmte Compose mit dem alten Modell `tts-1` und der Stimme `coral`; der Router antwortete deshalb mit HTTP 400. | Der OpenWebUI-Konfigurator setzt bei Installation und Restore gezielt Engine `openai`, Modell `piper`, Stimme `alloy` und die interne Router-URL. Andere Audio- oder Nutzereinstellungen bleiben unangetastet. |
|
||
|
||
## 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.
|