infrastructure/proxmox/pve-host

PVE-Host (10.0.0.2) — Ansible-Verwaltung

Projekt zur deklarativen Verwaltung des Proxmox-VE-Hosts selbst (pve, 10.0.0.2). Bis 2026-10-30 liefen Host-Änderungen als manuelle Root-Skripte auf der Konsole; seit der NFS-Umstellung (GNAI-019 Entscheidung 2, revidiert) wird persistente Host-State über dieses Ansible-Projekt gepflegt — reproduzierbar und versioniert im Repo. GNAI-011 §1 sieht ein eigenes Host-Verfahren vor („Proxmox-Hostzugang … benötigen ein eigenes, späteres Verfahren“); dieses Projekt ist der Anfang davon. Die SSH-Härtung des Hosts selbst bleibt davon unberührt (GNAI-011 gilt nur für die LXCs) und ist ein eigenes, späteres Vorhaben.

Aktuell verwaltete Host-State:

• Kernel-NFS-Export /media/datenhdd3/Encoding → ghostnet-ki (10.0.0.90/32), NFSv4-only — Rolle pve_nfs_export (Ersatz für das frühere manuelle Script; CT 101 kann NFS nicht selbst serve, siehe GNAI-019).
• Legacy-Medien-Cron entfernt: Die root-Crontab-Einträge (chown -R root:root / chmod -R 0777 auf allen Medien-Mounts, alle 10 Minuten, installiert 2026-10-11) sind entfernt — Rolle pve_media_cron (Betreiberentscheidung 30.10.2026; Backup unter /var/backups/ghostnet/pve/). Der Cron hätte jedes echte Berechtigungsmodell unter den Medien-Mounts — inklusive der Encoding-Pipeline — alle 10 Minuten plattgewalzt.
• LXC-Configs: Entfernen der Ganesha-Ära-lxc.seccomp.profile:-Leerzeile aus /etc/pve/lxc/101.conf — Rolle pve_lxc_conf (wirksam beim nächsten CT-Start/Reboot).

Die CT-Lebenszyklus-Skripte (proxmox/lxc/<ct>/scripts/: pct create, Dist-Upgrade) bleiben Bootstrap-Skripte und laufen einmalig manuell als root@pve — sie erzeugen die CTs, bevor Ansible sie erreichen kann.

Zugang: dedizierter Deploy-Account auf dem Host

Muster wie auf den LXCs/ghostnet-ki: eigener Account, gelocktes Passwort, passphrase-loser Ed25519-Key mit Source-Restrictions, NOPASSWD-Sudoers. Der Key ist root-äquivalent — nur der public Key liegt im Repo (ansible/files/ssh/pve-ansible-deploy.pub), der private Key nur in ~/.ssh (mode 0600).

Einmalig auf der PVE-Konsole (root@pve) ausführen:

# freie UID >= 1000 wählen, z.B. 1000:
getent passwd | awk -F: '$3>=1000 {print $1, $3}' | sort -k2 -n | head
useradd -m -u <UID> -s /bin/bash ansible-deploy
usermod -L ansible-deploy                      # Passwort sperren
mkdir -p /home/ansible-deploy/.ssh && chmod 700 /home/ansible-deploy/.ssh
# public Key aus ansible/files/ssh/pve-ansible-deploy.pub eintragen:
cat >> /home/ansible-deploy/.ssh/authorized_keys <<'EOF'
from="10.0.0.0/24,10.8.0.0/24",no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFtneJFtlwj7D284Yar7ROTflZqKxi/IEyMcIoqazIDD ansible-deploy@ghostnet-pve
EOF
chown -R ansible-deploy:ansible-deploy /home/ansible-deploy/.ssh
chmod 600 /home/ansible-deploy/.ssh/authorized_keys
cat > /etc/sudoers.d/90-ghostnet-ansible-deploy <<'EOF'
ansible-deploy ALL=(ALL) NOPASSWD: ALL
EOF
chmod 0440 /etc/sudoers.d/90-ghostnet-ansible-deploy
visudo -c
# Host-Key-Fingerprint für die Workstation notieren (siehe unten):
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Auf der Workstation: Host-Key-Fingerprint gegen die PVE-Konsole prüfen (GNAI-011 Abschnitt 3.3), dann known_hosts befüllen und testen:

ssh-keyscan -t ed25519 10.0.0.2 >> ~/.ssh/known_hosts_ghostnet_pve   # erst nach Fingerprint-Prüfung!
ssh -o BatchMode=yes ghostnet-pve-ansible-deploy 'id; hostname; sudo -n id -u'

ssh-Alias auf der Workstation (bereits in ~/.ssh/config): ghostnet-pve-ansible-deploy → ansible-deploy@10.0.0.2 mit ~/.ssh/id_ed25519_ghostnet_pve_ansible_deploy (passphrase-los) und UserKnownHostsFile=~/.ssh/known_hosts_ghostnet_pve.

Runbook

Alle Befehle aus proxmox/pve-host/ansible/ mit dem venv der Repo-Wurzel:

cd proxmox/pve-host/ansible
../../../.venv/bin/ansible-playbook -i inventories/production/hosts.yml playbooks/preflight.yml --private-key ~/.ssh/id_ed25519_ghostnet_pve_ansible_deploy
../../../.venv/bin/ansible-playbook -i inventories/production/hosts.yml playbooks/site.yml --check --diff --private-key ~/.ssh/id_ed25519_ghostnet_pve_ansible_deploy
../../../.venv/bin/ansible-playbook -i inventories/production/hosts.yml playbooks/site.yml --private-key ~/.ssh/id_ed25519_ghostnet_pve_ansible_deploy
../../../.venv/bin/ansible-playbook -i inventories/production/hosts.yml playbooks/verify-production.yml --private-key ~/.ssh/id_ed25519_ghostnet_pve_ansible_deploy
../../../.venv/bin/ansible-playbook -i inventories/production/hosts.yml playbooks/site.yml --private-key ~/.ssh/id_ed25519_ghostnet_pve_ansible_deploy   # changed=0

Secrets-Policy

Keine Passwörter, privaten Schlüssel oder Secrets in Repo/Inventory/Logs. Der private Deploy-Key liegt nur in ~/.ssh (0600). Der Account hat NOPASSWD sudo — der Key ist root-äquivalent und wird nur für autorisierte Infrastruktur-Änderungen genutzt.