- 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>
spektr
6a1eff7392