infrastructure/README.md

Ghostnet.AI Infrastruktur

Dokumentation für die Infrastruktur eines privaten Homelabs mit öffentlich erreichbaren Webdiensten, einem WireGuard-Zugang und einem dedizierten KI-Server. Dieses Repository hält Architekturentscheidungen, den belegten Betriebsstand und Verfahren für Einrichtung, Betrieb und Sicherheitsabnahme fest.

Projektstand: 21.09.2026. Die Dokumentationsrevisionen sind zusammengeführt. Mehrere Sicherheitsmaßnahmen und technische Endabnahmen stehen noch aus. Auf dem KI-Server sind Host-Baseline, Podman, getrennte rootless Workload-Konten und der Gerätezugriff der KI-Konten auf beide AMD-GPUs eingerichtet. Ein gepinnter llama.cpp-ROCm-Build erkennt beide Karten im rootless Testing-Container; Swift- und Unsloth-Q6_K sind als 128k-A/B-Kandidaten geplant, aber dauerhafte LLM- und Encoding-Anwendungen sind noch nicht installiert.

Überblick

flowchart LR
    Internet --> Router[Fritzbox]
    Router -->|HTTP/HTTPS| NPM[Nginx Proxy Manager]
    Router -->|WireGuard| VPN[wg-easy]
    NPM --> Apps[Webdienste in eigenen LXCs]
    VPN --> LAN[Heimnetz]
    LAN --> PVE[Proxmox und Service-LXCs]
    LAN --> AI[KI-Server]
    NPM -.-> AI

Der Reverse Proxy und das VPN-Gateway laufen in getrennten Proxmox-LXCs. Weitere Webdienste befinden sich in eigenen LXCs. Der physische KI-Server ist für lokale Inferenz und darauf aufbauende Anwendungen vorgesehen. Die gestrichelte Verbindung zum KI-Server beschreibt einen geplanten Veröffentlichungsweg für LLM-Anwendungen; die Dienste sind dort noch nicht installiert.

Die drei vorgesehenen VPN-Netzwerkrollen sind Familie (gesamtes Heimnetz), Server Admin (bestätigte Server und Service-LXCs) und LLM Admin (nur KI-Server). Ihre serverseitige Durchsetzung ist noch nicht abgenommen. Anwendungsanmeldung, SSH-Schlüssel und API-Schlüssel bleiben zusätzliche, eigenständige Zugangskontrollen.

Aktueller Stand

Bereich	Belegter Stand	Nächster Nachweis oder Schritt
KI-Server	Debian-Basissystem, Deployment-Zugang, Podman 5.4.2, drei getrennte rootless Workload-Konten sowie zwei als gfx1030 und als llama.cpp-ROCm-Geräte geprüfte RX 6900 XT	nach der Prioritätsentscheidung internes llama.cpp-Testing ohne öffentliche Route bereitstellen
VPN	wg-easy v15.4.0 auf CT 105 aktiv; ein externer Laptop-Teiltest liegt vor	Rollenrechte serverseitig umsetzen und mit erlaubten sowie gesperrten Zielen testen
Reverse Proxy	NPM auf CT 103 dokumentiert; Fail2Ban laut Betreiber fest gepinnt und wieder in Betrieb	Effektive Jails, Sperren und Wiederanlauf prüfen
Identität	Keycloak/OIDC laut Betreiber produktiv für Vaultwarden	Öffentlich erreichbare Keycloak-Administration sperren und den OIDC-Login erneut prüfen

Der Dokumentationsindex enthält die datierten Quellen, offenen Angaben und Abnahmegrenzen. Er ist die maßgebliche Übersicht für den aktuellen Projektstand. Eine Zielbeschreibung in diesem README oder den Architekturdokumenten ist kein Nachweis für eine bereits wirksame Konfiguration.

Dokumentation lesen

Einstieg	Inhalt
Dokumentationsindex und Projektstand	Dokumentenübersicht, bestätigte Entscheidungen und offene Befunde
High-Level-Implementierungsplan	priorisierte nächste Schritte, Entscheidungstore und messbare Abschlusskriterien
Plattform-Dokumentation	Hostbasis, Zugriffsmodell, Reverse Proxy und VPN
KI-Dokumentation	KI-Zielarchitektur, Ansible-Planung, Modellbewertung und technische llama.cpp-Sollkonfiguration
Video-Encoding	getrennter Planungs- und späterer SOP-Bereich für den CPU-Encoding-Workload
Ansible-Control-Projekt	lokale Einrichtung, Preflight, Deployment-Account, Host-Baseline, Podman, Workload-Konten, AMD-GPU-Zugriff und rootless ROCm-Probe

Arbeiten mit dem Repository

Dieses Repository enthält Dokumentation und ein Ansible-Control-Projekt. Es prüft Inventar, SSH-Zugang, Hostidentität, Betriebssystem und die dokumentierten GPUs. Gemeinsame Rollen verwalten Plattform, Podman und getrennte Workload-Identitäten. KI- und Encoding-Fachdokumentation bleiben in getrennten Bereichen. Im Testing-Store liegt nur das gepinnte ROCm-Probeimage; dauerhafte Anwendungscontainer sind noch nicht bereitgestellt. Vor einer Infrastrukturänderung den Ist-Stand am betroffenen Host prüfen, die passende Fachanleitung lesen und die dort genannten Abnahmeschritte dokumentieren.

WireGuard-Profile enthalten private Schlüssel. Sie gehören nicht in Git, Ausgaben oder freigegebene Dokumente. Das lokale Verzeichnis docs/platform/GNAI-007-profiles/ wird vollständig durch die Repository-.gitignore ausgeschlossen; es ist kein Verteiler- oder Backup-Ort für Zugangsdaten.

Änderungen am Projektstand sollten zuerst im zuständigen Fachdokument mit Datum und Beleg erfasst werden. Anschließend den Index und diese README aktualisieren, wenn sich eine übergreifende Aussage geändert hat.