- CT 101 kennt NFS nicht mehr: samba_nfs-Rolle und Ganesha-Artefakte entfernt, kein Podman, keine 2049-Firewall-Regel, kein seccomp-Sondereintrag; live restlos bereinigt und deckungsgleich mit dem Playbook (verify ok=47, Idempotenz changed=0). Dafür neue SMB-Freigabe [Encoding] (Export-Root) für die Kontrolle von anderen Geräten als ghostnet-ki. - Grund: Weder kernel-nfsd noch Ganesha (VFS-FSAL) laufen in einem unprivileged LXC — open_by_handle_at braucht CAP_DAC_READ_SEARCH in der init-userns und liefert dort immer EPERM (verifiziert auf Kernel 7.0.14-14-pve; Web-Recherche: NFS direkt auf dem PVE-Host ist gängige Praxis und anerkannte Ausnahme vom Host-Grundsatz). - Neuer Account ansible-deploy (UID 1001) auf dem PVE-Host 10.0.0.2 nach LXC-Muster: gelocktes Passwort, source-restrictierter passphrase-loser Key (nur pub im Repo), NOPASSWD-Sudoers; Host-Key-Fingerprint verifiziert. - Neues Host-Projekt proxmox/pve-host/ansible (Schema wie die CT-Projekte): preflight/site.yml/verify-production + Rollen pve_nfs_export (Kernel-NFS, /etc/exports nur 10.0.0.90/32, NFSv4-only, Export-Root 100000:970 2775, nft 2049 nur von 10.0.0.90) und pve_lxc_conf (seccomp-Leerzeile aus 101.conf entfernt). Auf dem Host grün: check changed=0, verify ok=15, Idempotenz changed=0. - Abnahme bestanden: NFSv4.2-Mount von ghostnet-ki gegen 10.0.0.2:/media/datenhdd3/Encoding (Export-Root 100000:970 2775 sichtbar), sauberer Unmount. CT 101 nach Reboot: Seccomp 2, keine failed units, 17 Shares, 10 CIFS-Mounts der Workstation hängen. - Doku aktualisiert: GNAI-017 §4.1 und GNAI-019 E2/E3/§15 revidiert, Bereichsindex ergänzt, READMEs angepasst; PVE-Lifecycle-Skripte ohne seccomp-Ausnahme (Hashes aktualisiert). Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
Proxmox-Server und LXCs
Dieser Gerätebereich dokumentiert den Proxmox-Kontext unter 10.0.0.2 und die
darauf betriebenen LXCs. Er beschreibt derzeit nicht die SSH-Konfiguration des
Hypervisors selbst.
| Dokument / Bereich | Inhalt |
|---|---|
| GNAI-011 | gemeinsame SSH-Sicherheitsarchitektur und Rolloutverfahren der LXCs |
| GNAI-012 / CT 100 | 10.0.0.14: Pi-hole-Quadlet, FRITZ!Box-DNS, Split-DNS, Abnahme und Rollback |
| GNAI-014 / CT 102 | 10.0.0.4: Keycloak, sichere Administration und OIDC-/Adminpfad-Trennung |
| GNAI-015 / Keycloak-Migration | Blue/Green-Plan für Podman, PostgreSQL, Versionsupgrade und Rückfall |
| CT-102-Automation | produktives Keycloak-Ansible-Projekt und CT-spezifische PVE-Helfer |
| CT-104-Rückfallartefakte | erhaltene Blue/Green-Referenz unter 10.0.0.16 |
| GNAI-006 / CT 103 | 10.0.0.10: Reverse Proxy, Keycloak-Adminpfad und Fail2Ban |
| GNAI-007 / CT 105 | 10.0.0.15: WireGuard-Gateway, Rollen-Firewall und Clientverfahren |
| GNAI-017 / CT 101 | 10.0.0.9: Samba-Dateiserver, NFS-Export und Encoding-Shares |
| GNAI-018 / CT 101 | Requirements der Encoding-Pipeline an CT 101 für den Ansible-Rebuild (Übergabe) |
| GNAI-019 / CT 101 | Entwurfsentscheidungen der Ansible-Migration: natives Samba, NFS-Ganesha als Quadlet, Fresh-State-Rebuild |
| CT-101-Automation | produktives Samba-Ansible-Projekt und CT-spezifische PVE-Helfer |
| PVE-Host-Automation | Ansible-Verwaltung des PVE-Hosts selbst (10.0.0.2): Deploy-Account, Kernel-NFS-Export, LXC-Conf |
Die versionierte Quelle für den optionalen, secretfreien
Community-Scripts-Post-install-Hook liegt unter
proxmox/shared/scripts/ghostnet-lxc-baseline.sh.
Einsatzgrenzen und Installation beschreibt die zugehörige
README.