Ghostnet.AI – Dokumentationsindex und Projektstand

Stand: 2026-09-20 Status: Revisionen zusammengeführt; Sicherheitsumsetzung und technische Endabnahme offen

1. Dokumente und Zielgruppen

Plattform und Host

Dokument	Zweck / Zielgruppe
Bereichsindex	Einstieg in die Plattform- und Hostdokumentation
GNAI-001-INFRA_BaseSystem.md	Hardware und Debian-Installation; Intermediate IT
GNAI-002-INFRA_Users.md	Benutzer, statisches Hostnetz, Resolver und SSH; Intermediate IT
GNAI-004-SEC_Access-Control.md	verbindliches Rollen- und Zugriffsziel; Intermediate IT
GNAI-005-SEC_Reverse-Proxy.md	NPM/Fail2Ban und Keycloak-Korrekturverfahren; Intermediate IT
GNAI-006-SEC_VPN.md	wg-easy-Installation/Konfiguration in Proxmox LXC; Intermediate IT
GNAI-006-SEC_VPN_Client-Management.md	eigenständige GUI-SOP für Ausgabe, Änderungen und Widerruf; Intermediate IT
GNAI-006-SEC_VPN_Clients_Windows11.md	offizieller Windows-Client, Import und Verwendung; Junior IT
GNAI-006-SEC_VPN_Clients_Linux.md	Debian, Arch/CachyOS, Fedora/Kinoite; Junior IT
GNAI-006-SEC_VPN_Implementation-Log.md	historische v14/v15-Umsetzung und Evidenzkorrekturen; Intermediate IT

KI

Dokument	Zweck / Zielgruppe
Bereichsindex	Einstieg in die KI-spezifische Dokumentation
GNAI-003-INFRA_Architecture.md	Gesamtzielarchitektur und Inventar des KI-Stacks; Intermediate IT
GNAI-007-PLAN_Ansible-Deployment.md	nicht finaler Arbeitsentwurf zum Ansible-/Gitea-Deployment und zur geplanten Folgedokumentation; Infrastrukturadministratoren und Mitwirkende

Video-Encoding und Automatisierung

Dokument	Zweck / Zielgruppe
Video-Encoding-Dokumentation	getrennter Index für Architektur und spätere Nutzer-SOPs des CPU-Encoding-Workloads
Ansible-Control-Projekt	Control-Node, Preflight, Deployment-Account, Host-Baseline, Podman und Workload-Konten; Intermediate IT

2. Verbindliche, bestätigte Entscheidungen

NPM ist .10, WireGuard .15, Proxmox .2, KI-Server .90, Fritzbox .1, jeweils im Heimnetz 10.0.0.0/24. Server/LXCs verwenden statische Adressen bis .99, Client-DHCP .100–.200. Der aktuelle Bereich ist keine VLAN-Isolation und keine automatische Server-Admin-ACL.

Familie darf das gesamte Heimnetz erreichen; Server Admins Proxmox, Service-LXCs und KI-Server; LLM Admins ausschließlich KI-Server. Profile werden durch Administratoren pro Gerät erstellt und geschützt verteilt. Serverseitige Firewall Allowed IPs sollen die Rechte erzwingen. Per-Client Firewall ist aber derzeit deaktiviert. wg-easy-GUI-Zugriff ist für Familie und Server Admin vorgesehen; HTTPS ist ein offener Umsetzungsvorschlag.

wg-easy läuft rootful in CT 105 als Podman-Quadlet mit v15.4.0 und host-Netz im LXC. Ein lesender SSH-Abgleich am 18.09.2026 bestätigte aktives wg-easy/nftables, IPv4-Forwarding, eine breite VPN→LAN-Regel und MASQUERADE in iptables-legacy; Details und Grenzen stehen im Implementation-Log. MASQUERADE wird mangels Rückroute gebraucht. Ein nftables-Reload mit flush ruleset kann dynamische Regeln entfernen; Wiederanlauf muss abgenommen werden.

Der KI-Server heißt laut lesendem SSH-Abgleich vom 18.09.2026 ghostnet-ki; damals bestanden die persönlichen Konten ghost, debugofen und das Agentenkonto ghost-agent. Inzwischen ergänzen ansible-deploy sowie die gesperrten Workload-Konten gnai-production, gnai-testing und gn-encoding diesen Bestand. admin existiert auf diesem Host nicht; der WireGuard-LXC verwendet separat admin. ghostnet.ki mit Punkt ist höchstens ein lokal angelegter SSH-Alias. OIDC ist laut Betreiber produktiv nur für Vaultwarden; weitere Dienste sind geplant.

Die getrennten Schlüsselzugänge für ghost und ghost-agent wurden am 19.09.2026 erfolgreich getestet. Der persönliche Login wurde vom Betreiber interaktiv bestätigt; der Agentenlogin wurde technisch gegen Benutzername und Hostname geprüft.

Der KI-Server wurde als frisches Debian-Basissystem begonnen. Inzwischen sind die dokumentierten Ansible-Zugänge, die minimale Host-Baseline und Podman eingerichtet. Die LLM-Anwendungen sind weiterhin nicht installiert; GNAI-003 und GNAI-004 beschreiben für sie ein Zielbild.

Der Ansible-Deployment-Entwurf persistiert den seit dem 19.09.2026 fortgeschriebenen Planungs- und Implementierungsstand. Er ist ausdrücklich keine verbindliche Spezifikation und kein Nachweis einer vollständig eingerichteten Deploymentkette. Die dort genannten Runner-, Freigabe- und Secret-Verfahren sind bis zu ihrer Prüfung und formalen Übernahme vorläufig.

Das erste Ansible-Control-Projekt mit Testing-Inventar und lesendem Preflight wurde am 19.09.2026 angelegt. Der Live-Lauf über ghost-agent bestätigte Hostidentität, Debian 13.6, IPv4-Adresse, Python, CPU, RAM und zwei Navi-21-Geräte mit changed=0, unreachable=0 und failed=0. Dieser Nachweis umfasst weder privilegierten Zugriff noch eine eingerichtete Production-/Testing-Laufzeitumgebung.

Der separate Ed25519-Schlüssel mit Fingerprint SHA256:IKEInbIo8VVI1USg5+a3ypGK8H8FweJiQu+v7KvhQDU und das Bootstrap-Playbook wurden am 19.09.2026 verwendet, um ansible-deploy einzurichten. Der private Schlüssel liegt ausschließlich außerhalb des Repositories. Der Account besitzt ein gesperrtes Passwort, einen auf LAN- und WireGuard-Quellnetze beschränkten Public Key und eine mit visudo validierte Regel NOPASSWD: ALL. Ein getrenntes Prüfplaybook bestätigte anschließend Anmeldung, Modulausführung und effektive UID 0 über sudo mit ok=5 changed=0 unreachable=0 failed=0.

Die erste schreibende Rolle host_baseline wurde am 19.09.2026 nach erfolgreichem Syntax- und Check-Modus-Lauf angewendet. Sie prüft Hostname, Debian-Hauptversion, Standard-IPv4 sowie mindestens 100 GiB freien Speicher. Die zunächst dort angelegten Umgebungsverzeichnisse werden seit Einführung der Servicekonten durch workload_accounts verwaltet; host_baseline besitzt nur noch die gemeinsamen Eltern und /var/lib/ghostnet-ai/shared. Der erste reale Lauf meldete ok=6 changed=1 unreachable=0 failed=0; der unmittelbar folgende identische Lauf belegte Idempotenz mit ok=6 changed=0 unreachable=0 failed=0.

Die Rolle podman_runtime wurde am 20.09.2026 angewendet. Sie installierte Podman 5.4.2 aus Debian 13 einschließlich expliziter DNS- und rootless Netzwerkvoraussetzungen, prüfte systemd, cgroup v2, Overlay-Storage und den Quadlet-Generator und legte /etc/containers/systemd an. podman.socket und podman-auto-update.timer werden deaktiviert und gestoppt gehalten. Der abschließende Gesamtlauf meldete ok=20 changed=0 unreachable=0 failed=0; eine getrennte Prüfung bestätigte leere Image- und Containerlisten sowie beide Units als disabled und inactive.

Die Rolle workload_accounts richtete am 20.09.2026 die gesperrten Konten gnai-production (UID/GID 980), gnai-testing (981) und gn-encoding (982) mit festen, getrennten SubID-Bereichen ein. Konfiguration bleibt rootverwaltet; Daten, rootless Podman-Stores und persistente systemd-User-Manager sind pro Workload getrennt. Der korrigierte Gesamtlauf meldete ok=36 changed=0 unreachable=0 failed=0 und bestätigte drei unterschiedliche rootless Graph Roots. Images und Container wurden nicht angelegt.

3. Sicherheitsbefunde mit Priorität

Befund	dokumentiertes Verfahren / Status
Keycloak-Administration öffentlich erreichbar, externe Anmeldung möglich	GNAI-005: Adminpfad-Schutz, interner Adminzugang, externe Sperrtests und Vaultwarden-OIDC-Prüfung; noch nicht angewendet
VPN-Zielrechte nur im lokalen Profil	GNAI-006 und GUI-SOP: Per-Client Firewall, Gateway-INPUT-Regeln und negative Tests; noch nicht angewendet
Fail2Ban-Image auf `1.1.0-r2-ls43` fest gepinnt; Container läuft wieder	GNAI-005: Pin umgesetzt; effektives Image, Jails, kontrollierte Bans sowie Dienst-/LXC-Wiederanlauf noch abzunehmen
HTTP-Client-User-Agents werden bewusst gebannt	GNAI-005: mögliche legitime Treffer und rollen-/routingabhängiger VPN-Ausweichweg dokumentiert

4. Noch erforderliche Angaben

Frage / fehlender Nachweis	Grund
Aktualisiert selfHOST den VPN-Eintrag nach einem WAN-IP-Wechsel zuverlässig?	Am 18.09.2026 stimmte `vpn.ghostnet.selfhost.eu` mit der ausgehenden IPv4 des Gateways überein; `vpn.ghostnet.dyndns.eu` zeigte auf eine andere IPv4. Profile verwenden `selfhost.eu`. Ein einzelner Abgleich belegt keinen dauerhaften DynDNS-Betrieb.
Gehört Altpeer Laptop-FullAdmin künftig Familie oder Server Admin?	neue Zielrechte und Gateway-INPUT-Freigaben hängen davon ab.
Welche Verwaltungsgeräte dürfen lokal auf die GUI und welcher interne Adminhostname soll verwendet werden?	VPN-Rollen ordnen lokale LAN-Quellen nicht automatisch zu.
Welchen OIDC-Issuer/Realm nutzt Vaultwarden und wo terminiert auth-HTTPS tatsächlich?	NPM-SSL-Optionen aus, externer HTTPS-Login möglich; Realm-Sperren dürfen den produktiven Login nicht unbeabsichtigt stören.
Welcher Dienst erzeugt `/etc/resolv.conf` auf dem KI-Server tatsächlich?	`networking` verwaltet die statische Schnittstelle; die Datei trägt einen dhcpcd-Kommentar, obwohl dhcpcd beim Abgleich nicht aktiv war. Vor einer DNS-Änderung den Erzeugungsweg prüfen.

Es werden keine Werte für diese offenen Angaben angenommen. Die betreffenden Verfahren sind entsprechend eingeschränkt oder als Vorschlag markiert.

5. Validierung und Abschluss

Bei der Dokumentationskonsolidierung wurden keine Serverkonfigurationen geändert, keine VPN-Praxisprüfungen nachgeholt und keine Keycloak-Sperre live bestätigt. Aussagen zum Ist-Stand beruhen auf den protokollierten Betreiberangaben und Tests; sie sind keine neue Live-Inventur.

Am 18.09.2026 wurden WireGuard-LXC und KI-Server ergänzend lesend per SSH geprüft. Der KI-Server-Teilabgleich bestätigt Hostname, Konten, Netzkonfiguration, Debian-Version, CPU, RAM, zwei Navi-21-GPUs und SSD-Partitionierung; BIOS, ROCm und die Anwendungsdienste wurden dabei nicht abgenommen. Details stehen in GNAI-001 und GNAI-002.

Am 19.09.2026 bestätigte ein erster reproduzierbarer Ansible-Preflight über das unprivilegierte Konto ghost-agent erneut ghostnet-ki, Debian 13.6, 10.0.0.90, 14 vCPUs, 64.123 MiB RAM, Remote-Python 3.13.5 und zwei PCI-Geräte 1002:73bf. Der Play Recap lautete ok=5 changed=0 unreachable=0 failed=0. Das Playbook verwendete kein sudo und nahm keine Serverkonfiguration vor.

Beim anschließenden Bootstrap wurden Benutzer, Home-/SSH-Verzeichnisse, authorized_keys und sudoers-Datei erfolgreich angelegt. Nur die letzte Assertion des ersten Laufs schlug wegen einer als Mapping interpretierten YAML-Bedingung fehl; die Bedingung wurde anschließend als String korrigiert. Da alle schreibenden Tasks vorher erfolgreich waren, bestätigte das unabhängige Prüfplaybook den wirksamen Endzustand ohne weitere Änderung. Ein vollständiger zweiter Bootstrap-Lauf zur Idempotenzprüfung steht noch aus.

Für die gemeinsame Host-Baseline bestätigte ein vorgelagerter Check-Modus genau sieben neu anzulegende Verzeichnisse und rund 1.677,7 GiB freien Platz auf /. Der anschließende reale Lauf legte die Verzeichniswurzeln an. Eine sofortige Wiederholung ergab changed=0; die Rolle konvergiert damit für ihren derzeitigen Umfang. Dieser Nachweis umfasst keine Paket-, Runtime-, GPU- oder Anwendungsinstallation.

Am 20.09.2026 sagte der Podman-Check-Modus 38 neue Debian-Pakete und das Quadlet-Verzeichnis voraus. Der reale Lauf installierte diese Pakete; seine erste Nachprüfung bewertete den Debian-Symlink des Quadlet-Generators irrtümlich nicht als reguläre Datei. Nach Korrektur der Ansible-stat-Prüfung auf das aufgelöste Ziel bestanden Podman 5.4.2, cgroup v2, Overlay-Storage und der Generator-Dry-Run. Der finale Gesamtlauf war mit changed=0 idempotent. Es wurden weder Images geladen noch Container oder Anwendungsdienste angelegt.

Der anschließende Workload-Account-Lauf richtete drei Konten, feste SubUID-/SubGID-Bereiche, rootverwaltete Quadlet-Pfade und persistente systemd-User-Manager ein. Zwei reine Abschlussprüfungen deckten zunächst den nicht erlaubten direkten sudo-Benutzerwechsel sowie konkurrierende Verzeichniseigentümer zwischen Rollen auf. Nach Umstellung der Prüfung auf rootseitiges runuser und eindeutiger Eigentümerzuständigkeit endete der Gesamtlauf mit ok=36 changed=0 unreachable=0 failed=0. Die drei rootless Podman-Stores sind voneinander getrennt und noch leer.

Die WireGuard-Evidenz bleibt der Teiltest vom 12.09.2026: CachyOS-Laptop von WAN, Handshake, Ping auf Gateway/Proxmox und direkter IPv4-Internetpfad bestanden; KI-Server war ausgeschaltet. Neue Rollen, weitere Clientvarianten, Gateway-GUI-Zugriff, WAN-/IPv6-Isolation, Neustart und Restore sind noch nicht abgenommen. GNAI-006 ist erst nach Klärung der offenen Werte, Umsetzung und dokumentierter Abnahme technisch abgeschlossen.

14 KiB Raw Blame History Unescape Escape