141 lines
10 KiB
Markdown
141 lines
10 KiB
Markdown
# 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.
|