# 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](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 |
| [GNAI-013](GNAI-013-PLAN_Security-Closure-and-Repository-Restructure.md) | aktive Checkliste für Sicherheitsabschluss, Repository-Struktur und Übergang zum LLM-Stack |

### Plattform und Sicherheit

| Dokument | Verbindlicher Inhalt |
| --- | --- |
| [Bereichsindex](platform/README.md) | Einstieg in Host-, Zugriffs-, Reverse-Proxy- und VPN-Dokumentation |
| [LLM-Server](platform/llm-server/README.md) | Geräteindex für Host, AI-Serving und Encoding auf `10.0.0.90` |
| [Ghostnet.AI-Host](platform/llm-server/host/GNAI-002-INFRA_BaseSystem.md) | GNAI-002 Hardware und Debian-Basis des KI-Servers `10.0.0.90` |
| [Ghostnet.AI-Zugänge](platform/llm-server/host/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-Server](platform/proxmox-server/README.md) | Geräteindex für den Hypervisor-Kontext und seine LXCs |
| [Proxmox-LXC-SSH](platform/proxmox-server/GNAI-011-SEC_LXC-SSH-Architecture.md) | GNAI-011 gemeinsame SSH-Sicherheitsarchitektur der LXCs; Hypervisor ausgenommen |
| [GNAI-012](platform/proxmox-server/lxc/ct-100-dns/GNAI-012-PLAN_Pi-hole-DNS-Handoff.md) | implementierter Pi-hole-LXC, FRITZ!Box-DNS, Split-DNS, Abnahme und Rückfallstand |
| [CT 102 / GNAI-014](platform/proxmox-server/lxc/ct-102-keycloak/GNAI-014-SEC_Keycloak.md) | Keycloak-LXC, sichere SSH-Zugänge und Trennung von öffentlichem OIDC und interner Administration |
| [GNAI-015](platform/proxmox-server/lxc/ct-102-keycloak/GNAI-015-PLAN_Keycloak-Podman-Migration.md) | Blue/Green-Migration von Keycloak/H2 auf Podman, PostgreSQL und aktuelle 26.x-Version |
| [GNAI-016](platform/proxmox-server/lxc/ct-102-keycloak/GNAI-016-PLAN_Keycloak-Ansible-Rebuild.md) | nachgelagerter reproduzierbarer Neuaufbau von CT 102 mit Ansible und zweiter Blue/Green-Cutover von CT 104 |
| [CT 103 / GNAI-006](platform/proxmox-server/lxc/ct-103-reverse-proxy/GNAI-006-SEC_Reverse-Proxy.md) | NPM, Fail2Ban und Keycloak-Adminpfad |
| [CT 105 / GNAI-007](platform/proxmox-server/lxc/ct-105-wireguard/GNAI-007-SEC_VPN.md) | WireGuard-Gateway und Rollen-Firewall |
| [VPN-Client-Verwaltung](platform/proxmox-server/lxc/ct-105-wireguard/GNAI-007-SEC_VPN_Client-Management.md) | Ausgabe, Änderung und Widerruf von Geräteprofilen |
| [Windows 11](platform/proxmox-server/lxc/ct-105-wireguard/GNAI-007-SEC_VPN_Clients_Windows11.md) / [Linux](platform/proxmox-server/lxc/ct-105-wireguard/GNAI-007-SEC_VPN_Clients_Linux.md) | Client-SOPs |
| [VPN-Implementation-Log](platform/proxmox-server/lxc/ct-105-wireguard/GNAI-007-SEC_VPN_Implementation-Log.md) | historische Umsetzung und datierte Evidenz |

### KI und Deployment

| Dokument | Verbindlicher Inhalt |
| --- | --- |
| [Bereichsindex](platform/llm-server/ai/README.md) | Einstieg in die KI-Dokumentation |
| [GNAI-004](platform/llm-server/ai/GNAI-004-INFRA_Architecture.md) | Zielarchitektur und Vertrauensgrenzen |
| [GNAI-008](platform/llm-server/ai/GNAI-008-PLAN_Ansible-Deployment.md) | detaillierter Ansible-/Gitea-Planungsstand und Implementierungshistorie |
| [GNAI-009](platform/llm-server/ai/GNAI-009-PLAN_Llama-Model-Evaluation.md) | reproduzierbarer Modellvergleich |
| [GNAI-010](platform/llm-server/ai/GNAI-010-TECH_Llama-Serving.md) | technische Sollkonfiguration des Testing-Servings |
| [LLM-Server-Ansible](../llm-server/ansible/README.md) | ausführbare Host-/ROCm-Playbooks und Rollen für `10.0.0.90` |
| [Keycloak-Ansible](../proxmox/lxc/ct-102-keycloak/ansible/README.md) | ausführbare Provisionierungs-, Restore- und Prüfautomation für CT 102 |

### Video-Encoding

| Dokument | Verbindlicher Inhalt |
| --- | --- |
| [GNENC-000](platform/llm-server/encoding/GNENC-000-DOC_Index.md) | Bereichsstatus und offene Festlegungen |
| [GNENC-001](platform/llm-server/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.
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.