ghostnet.ai/infrastructure
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
b40f726d2276dc9d8fbf0d01793ac42e998e19c7
infrastructure/docs/GNAI-000-DOC_Index.md
T

8.9 KiB
Raw Blame History

Ghostnet.AI – Dokumentationsindex und Projektstand

Stand: 2026-10-05

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 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
Ansible-Control-Projekt ausführbare Playbooks, Rollen und belegter technischer Stand

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 und Regelwerke am 22.09.2026 live geprüft; Schlüsseldateien auf 0600 gehärtet serverseitige Rollenrechte, negative Tests, IPv6-/Restart-/Restore-Abnahme
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-Lesekonto, persönlicher Schlüsselzugang mit passwortgeschütztem sudo sowie SSH- und LAN/WireGuard-Netzbaseline einschließlich Reboot abgenommen; lokales Stop-Mode-Backup technisch geprüft; NPM 2.15.1 und Fail2Ban aktiv; sensible NPM-Dateirechte gehärtet wirksame Jails/Bans und deren Wiederanlauf; internen Keycloak-Adminweg bestätigen und öffentlichen Adminpfad sperren; hostunabhängige Backupkopie/Restore-Test
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.

Reference in New Issue View Git Blame Copy Permalink