infrastructure/docs/GNAI-000-DOC_Index.md

Ghostnet.AI – Dokumentationsindex und Projektstand

Stand: 2026-10-14

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.

1. Dokumente

Projektsteuerung

Dokument	Verbindlicher Inhalt
GNAI-001	priorisierte nächste Schritte, Entscheidungstore und Abnahmekriterien
GNAI-013	aktive Checkliste für Sicherheitsabschluss, Repository-Struktur und Übergang zum LLM-Stack

Plattform und Sicherheit

Dokument	Verbindlicher Inhalt
Bereichsindex	Einstieg in Host-, Zugriffs-, Reverse-Proxy- und VPN-Dokumentation
LLM-Server	Geräteindex für Host, AI-Serving und Encoding auf 10.0.0.90
Ghostnet.AI-Host	GNAI-002 Hardware und Debian-Basis des KI-Servers 10.0.0.90
Ghostnet.AI-Zugänge	GNAI-003 Benutzer, Hostnetz, Resolver und SSH des KI-Servers
GNAI-005	Rollen- und Zugriffsziel
Proxmox-Server	Geräteindex für den Hypervisor-Kontext und seine LXCs
Proxmox-LXC-SSH	GNAI-011 gemeinsame SSH-Sicherheitsarchitektur der LXCs; Hypervisor ausgenommen
GNAI-012	implementierter Pi-hole-LXC, FRITZ!Box-DNS, Split-DNS, Abnahme und Rückfallstand
CT 102 / GNAI-014	Keycloak-LXC, sichere SSH-Zugänge und Trennung von öffentlichem OIDC und interner Administration
GNAI-015	Blue/Green-Migration von Keycloak/H2 auf Podman, PostgreSQL und aktuelle 26.x-Version
GNAI-016	nachgelagerter reproduzierbarer Neuaufbau von CT 102 mit Ansible und zweiter Blue/Green-Cutover von CT 104
CT 103 / GNAI-006	NPM, Fail2Ban und Keycloak-Adminpfad
CT 105 / GNAI-007	WireGuard-Gateway und Rollen-Firewall
VPN-Client-Verwaltung	Ausgabe, Änderung und Widerruf von Geräteprofilen
Windows 11 / Linux	Client-SOPs
VPN-Implementation-Log	historische Umsetzung und datierte Evidenz

KI und Deployment

Dokument	Verbindlicher Inhalt
Bereichsindex	Einstieg in die KI-Dokumentation
GNAI-004	Zielarchitektur und Vertrauensgrenzen
GNAI-008	detaillierter Ansible-/Gitea-Planungsstand und Implementierungshistorie
GNAI-009	reproduzierbarer Modellvergleich
GNAI-010	technische Sollkonfiguration des Testing-Servings
LLM-Server-Ansible	ausführbare Host-/ROCm-Playbooks und Rollen für 10.0.0.90
Keycloak-Ansible	ausführbare Provisionierungs-, Restore- und Prüfautomation für CT 102

Video-Encoding

Dokument	Verbindlicher Inhalt
GNENC-000	Bereichsstatus und offene Festlegungen
GNENC-001	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. Am 05.10.2026 wurde die Dokumentation geräteorientiert neu geordnet: platform/proxmox-server/ bildet den Proxmox-Kontext und seine LXCs ab, platform/llm-server/ den physischen KI-Server mit AI und Encoding.

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; einziger Peer ghost-laptop als Server Admin; native nftables-Zielpolicy und NAT, Legacy-Bereinigung, Fremdnetz-, Positiv-/Negativ-, Dienst- und LXC-Wiederanlauftests bestanden; CT 104 am 07.10.2026 als zwölftes Ziel praktisch abgenommen	WAN-/IPv6-Managementport-Isolation, Backup-Restore, wg-easy-GUI-HTTPS und KI-Server-Test bei eingeschaltetem Host
DNS / Pi-hole	CT 100 unter 10.0.0.14 mit digest-gepinntem Pi-hole 2026.09.0 als Podman-Quadlet; SSH/nftables, UDP/TCP-DNS, Split-DNS, Blocking/Allowlist, FRITZ!Box-Cutover, LXC-Reboot und Stop-Mode-Backup am 01.10.2026 abgenommen	vollständige App-/OIDC-Regression, praktischer FRITZ!Box-Rollback, mobile DuckDuckGo-/IPv6-Strategie, WireGuard-Profile und hostunabhängiger Restore-Test
Reverse Proxy	CT-103-Zugänge, SSH-/Firewall-Baseline, Reboot und lokales Backup abgenommen; NPM 2.15.1 routet öffentlichen OIDC- und internen Admin-vHost getrennt; öffentliche Keycloak-Administration liefert 403	Fail2Ban-Jails/Bans und Wiederanlauf; hostunabhängige Backupkopie/Restore-Test
Keycloak	CT 102 unter 10.0.0.4 reproduzierbar per Ansible aufgebaut; gepinntes Keycloak 26.2.4 und PostgreSQL 16.15, Restore von CT 104, Container-/DB-Härtung, NPM-Cutover, interner Adminzugang, öffentliche Admin-Sperre, realer Vaultwarden-OIDC-Login und LXC-Neustart abgenommen	14-tägige Stabilisierungsphase, praktischer NPM-Rückfall auf CT 104, Betriebs-/Backup-/Restore-SOP und anschließende Rückfallbereinigung
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. Fail2Ban-Jails, kontrollierten Ban und Wiederanlauf nachweisen;
2. öffentliche IPv4-/IPv6-Exposure erneut erfassen;
3. die Keycloak-Stabilisierungsphase sowie den praktischen NPM-Rückfall auf CT 104 abschließen;
4. für DNS, Reverse Proxy und Keycloak hostunabhängige Backups und mindestens einen praktisch getesteten Restorepfad festlegen.

Die öffentliche Keycloak-Administration, der Vaultwarden-OIDC-Pfad und die serverseitigen WireGuard-Rollengrenzen sind zum Stand 14.10.2026 bereits positiv und negativ abgenommen. Sie bleiben Regressionstest, sind aber keine offenen Erstimplementierungen mehr.

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.