# Ghostnet.AI – Dokumentationsindex und Projektstand **Stand:** 2026-09-22 **Status:** Plattformgrundlage vorhanden; Sicherheitsabschluss und LLM-Serving offen Dieses Dokument ist der zentrale Einstieg, nicht das technische Nachweisprotokoll. Details, historische Laufdaten und Bedienverfahren stehen ausschließlich in den jeweiligen Fachdokumenten. Die priorisierte weitere Umsetzung beschreibt der [High-Level-Implementierungsplan](GNAI-001-PLAN_Project-Roadmap.md). ## 1. Dokumente ### Projektsteuerung | Dokument | Verbindlicher Inhalt | | --- | --- | | [GNAI-001](GNAI-001-PLAN_Project-Roadmap.md) | priorisierte nächste Schritte, Entscheidungstore und Abnahmekriterien | ### Plattform und Sicherheit | Dokument | Verbindlicher Inhalt | | --- | --- | | [Bereichsindex](platform/README.md) | Einstieg in Host-, Zugriffs-, Reverse-Proxy- und VPN-Dokumentation | | [Ghostnet.AI-Host](platform/ghostnet-ai/GNAI-002-INFRA_BaseSystem.md) | GNAI-002 Hardware und Debian-Basis des KI-Servers `10.0.0.90` | | [Ghostnet.AI-Zugänge](platform/ghostnet-ai/GNAI-003-INFRA_Users.md) | GNAI-003 Benutzer, Hostnetz, Resolver und SSH des KI-Servers | | [GNAI-005](platform/GNAI-005-SEC_Access-Control.md) | Rollen- und Zugriffsziel | | [Proxmox-LXC-SSH](platform/proxmox-lxc/GNAI-011-SEC_LXC-SSH-Architecture.md) | GNAI-011 gemeinsame SSH-Sicherheitsarchitektur der LXCs; Hypervisor ausgenommen | | [CT 103 / GNAI-006](platform/proxmox-lxc/ct-103/GNAI-006-SEC_Reverse-Proxy.md) | NPM, Fail2Ban und Keycloak-Adminpfad | | [CT 105 / GNAI-007](platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN.md) | WireGuard-Gateway und Rollen-Firewall | | [VPN-Client-Verwaltung](platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN_Client-Management.md) | Ausgabe, Änderung und Widerruf von Geräteprofilen | | [Windows 11](platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN_Clients_Windows11.md) / [Linux](platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN_Clients_Linux.md) | Client-SOPs | | [VPN-Implementation-Log](platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN_Implementation-Log.md) | historische Umsetzung und datierte Evidenz | ### KI und Deployment | Dokument | Verbindlicher Inhalt | | --- | --- | | [Bereichsindex](ai/README.md) | Einstieg in die KI-Dokumentation | | [GNAI-004](ai/GNAI-004-INFRA_Architecture.md) | Zielarchitektur und Vertrauensgrenzen | | [GNAI-008](ai/GNAI-008-PLAN_Ansible-Deployment.md) | detaillierter Ansible-/Gitea-Planungsstand und Implementierungshistorie | | [GNAI-009](ai/GNAI-009-PLAN_Llama-Model-Evaluation.md) | reproduzierbarer Modellvergleich | | [GNAI-010](ai/GNAI-010-TECH_Llama-Serving.md) | technische Sollkonfiguration des Testing-Servings | | [Ansible-Control-Projekt](../ansible/README.md) | ausführbare Playbooks, Rollen und belegter technischer Stand | ### Video-Encoding | Dokument | Verbindlicher Inhalt | | --- | --- | | [GNENC-000](video-encoding/GNENC-000-DOC_Index.md) | Bereichsstatus und offene Festlegungen | | [GNENC-001](video-encoding/GNENC-001-PLAN_Architecture.md) | vorläufige Architektur des CPU-Encoding-Workloads | Die Dokumente wurden am 21.09.2026 neu geordnet: Die Roadmap belegt `GNAI-001`; die zuvor bestehenden Dokumente `GNAI-001` bis `GNAI-009` wurden unter Beibehaltung ihrer Reihenfolge zu `GNAI-002` bis `GNAI-010`. Am 22.09.2026 wurden KI-Host und Proxmox-LXCs in getrennte Unterverzeichnisse überführt; GNAI-011 beschreibt die gemeinsame SSH-Architektur der LXCs. ## 2. Belegter Stand | Bereich | Nachgewiesen | Noch nicht nachgewiesen | | --- | --- | --- | | KI-Host | Debian 13.6, Deployment-Zugang, Podman 5.4.2, getrennte rootless Konten, Gerätezugriff für beide KI-Konten | Host-/Treiber-Upgradepfad, Backup und Restore | | GPU/ROCm | beide RX 6900 XT als `gfx1030`, `ROCm0` und `ROCm1` im gepinnten Testing-Image erkannt | Modellladen, Layer-Verteilung, reale Inferenz, 64k/128k-Stabilität | | LLM-Serving | zwei unveränderlich definierte Modellkandidaten und technische Sollkonfiguration | Modelle, Quadlets, dauerhaftes Podman-Netz und Health Checks | | Deployment | lokales Ansible-Control-Projekt und idempotente Hostrollen | statische CI, Runner, geschützte Freigaben, Production-Inventar und automatisierter Rollback | | VPN | wg-easy v15.4.0 und Regelwerke am 22.09.2026 live geprüft; Schlüsseldateien auf `0600` gehärtet | serverseitige Rollenrechte, negative Tests, IPv6-/Restart-/Restore-Abnahme | | Reverse Proxy | CT-103-Lesekonto, persönlicher Schlüsselzugang mit passwortgeschütztem sudo sowie SSH- und LAN/WireGuard-Netzbaseline einschließlich Reboot abgenommen; Root-/Passwortzugriff abgelehnt; NPM 2.15.1 und Fail2Ban aktiv; sensible NPM-Dateirechte gehärtet | wirksame Jails/Bans und deren Wiederanlauf; Keycloak-Adminpfad weiterhin offen | | Encoding | Konto, Pfade und eigener rootless Store | Workload, Zeitsteuerung, Ressourcenlimits und Lasttest | Ein Zielbild, eine Betreiberangabe oder ein erfolgreicher Teiltest gilt nicht als vollständige Abnahme. Datierte Details stehen im zuständigen Fachdokument. ## 3. Bestätigte Leitentscheidungen - Ein Infrastructure-Repository verwaltet den Sollzustand des gemeinsamen Hosts. - AI Production und AI Testing verwenden bereits getrennte Konten, Datenpfade und Podman-Stores; ihre späteren Units und Netze bleiben ebenfalls getrennt. Host, Kernel und GPUs teilen sie dennoch. Sie sind daher keine getrennten Fehlerdomänen und laufen GPU-seitig nicht gleichzeitig. - Video-Encoding bleibt CPU-basiert, besitzt keinen GPU-Zugriff und wird erst nach einem gemeinsamen Lasttest parallel freigegeben. - Container- und Modellartefakte werden unveränderlich über Version, Revision, Digest beziehungsweise SHA-256 festgelegt; `latest` ist kein Deploymentziel. - `llama.cpp` bleibt ein internes Backend ohne Host-Port. Eine öffentliche Schnittstelle benötigt eine eigene Authentifizierungs-, Quota- und Veröffentlichungsentscheidung. - Managementzugriff erfolgt über WireGuard plus Dienstauthentifizierung. Client-Routing allein ist keine serverseitige Autorisierung. - Der Schlüssel von `ansible-deploy` ist wegen `NOPASSWD: ALL` root-äquivalent und darf nicht ungeprüft an Pull-Request-Workflows weitergegeben werden. ## 4. Offene Sicherheits- und Entscheidungsgrenzen Vor einer neuen öffentlichen KI-Schnittstelle müssen mindestens diese Befunde geschlossen sein: 1. öffentliche Keycloak-Administration sperren und Vaultwarden-OIDC erneut prüfen; 2. VPN-Rollen serverseitig erzwingen und positive sowie negative Zugriffe einschließlich Gateway-INPUT testen; 3. Fail2Ban-Jails, kontrollierten Ban und Wiederanlauf nachweisen; 4. öffentliche IPv4-/IPv6-Exposure erneut erfassen. Noch zu entscheiden sind insbesondere: - Sicherheitsabschluss vor oder parallel zum internen LLM-Vertical-Slice; - API-only oder zusätzlich Weboberfläche als erstes Nutzerprodukt; - ob LiteLLM in der ersten Veröffentlichung für individuelle Keys, Quoten oder Routing tatsächlich benötigt wird; - Freigabe- und Secret-Modell für einen späteren privilegierten Runner; - Backupziel, Aufbewahrung und praktisch getesteter Restore; - akzeptierte Mindestkonfiguration: 64k als belastbare Basis und 128k als Ziel oder 128k als zwingende Production-Voraussetzung. ## 5. Pflegeprinzip Neue technische Evidenz wird zuerst im ausführbaren Projekt beziehungsweise im zuständigen Fachdokument aktualisiert. Dieser Index wird nur geändert, wenn sich ein bereichsübergreifender Status, eine Leitentscheidung oder die Priorisierung ändert. Dadurch werden lange Laufprotokolle und Sollparameter nicht mehr an mehreren Stellen dupliziert.