123 lines
7.4 KiB
Markdown
123 lines
7.4 KiB
Markdown
# 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.
|