Set-OPS-Public/docs/config-proxmox.md

make config — référence des paramètres Proxmox

Pour qui : l'exploitant qui raccorde le moteur à sa grappe Proxmox.

make config lance scripts/config_proxmox.py, l'assistant interactif qui écrit la connexion au cluster Proxmox et les valeurs de clonage par défaut. Il pose 16 paramètres non sensibles puis propose de saisir les secrets API.

• Non sensibles, côté tenant (golden template, défauts de placement) → instance/inventories/*/group_vars/proxmox.yml
• Non sensibles, côté hébergeur (API du cluster, nœuds, stockages, ponts) → <dépôt de l'hébergeur>/proxmox-hebergeur.yml, à côté d'underlay.yml. Le chemin se dérive du symlink qui désigne déjà l'hébergeur — rien de nouveau n'est déclaré. Sans underlay monté, tout retombe dans le fichier du tenant et make config fonctionne comme avant.
• Secrets → voûte unique instance/inventories/<inventaire>/group_vars/all/vault.yml (chiffrée par ansible-vault), qui contient tous les secrets de l'instance (token Proxmox + vault_*). Voir §4.

À chaque invite, la valeur courante (ou le défaut) est affichée entre crochets : appuyer sur Entrée conserve cette valeur. On peut donc relancer make config sans tout retaper.

Ces paramètres sont des intrants communs de l'écosystème (cf. intrants-communs.md §C). L'accès au cluster et le golden template sont des constantes ; le placement par défaut est surchargeable par hôte dans instance/plan/serveurs.yml.

---

1. Accès au cluster Proxmox (constantes — un seul cluster)

Invite	Variable	Défaut	Sens / quoi saisir
Hôte API Proxmox	proxmox_api_host	(vide)	Nom DNS ou IP du nœud qui répond à l'API. Ex. asgard.
Utilisateur API Proxmox	proxmox_api_user	(vide)	Utilisateur avec le realm. Ex. ansible@pve (realm PVE) ou root@pam.
Port API Proxmox	proxmox_api_port	(vide)	Port HTTPS de l'API. Quasi toujours 8006.
Valider les certificats TLS	proxmox_validate_certs	non	oui si le cluster a un certificat de confiance ; non pour un certificat auto-signé (cas usuel en lab).

2. Golden template (constantes — le modèle cloné)

Invite	Variable	Défaut	Sens / quoi saisir
VMID du modèle Debian 13	proxmox_clone_vmid_modele	9000	VMID de la VM-modèle existante à cloner pour chaque nouvelle VM.
Nom logique du modèle	proxmox_clone_source_nom	modeleSetOPS	Nom de référence du template. Il doit correspondre au nom réel du template Proxmox : sinon le clonage ne trouve pas sa source. (Ce tableau a annoncé modele-debian13 jusqu'au 2026-09-06 — un défaut qui n'a jamais été celui du code.)

Le golden template est l'actif central : il est cloné pour chaque VM, jamais jeté ni reconstruit à la légère.

3. Placement par défaut des clones (défauts surchargeables par hôte)

Ces valeurs s'appliquent à toute VM clonée, sauf si l'hôte les surcharge dans instance/plan/serveurs.yml.

Invite	Variable	Défaut	Sens / quoi saisir
Nœud Proxmox par défaut	proxmox_clone_noeud	(vide)	Nœud du cluster où créer la VM. Ex. asgard.
Stockage Proxmox par défaut	proxmox_clone_stockage	(vide)	Datastore qui héberge le disque. Ex. local-zfs, TrueNAS.
Pont Proxmox	proxmox_clone_pont	vmbr0	Bridge réseau de la NIC. Ex. vmbr0, vmbr1.
Format disque par défaut	proxmox_clone_format	(vide)	qcow2, raw, … ou vide pour laisser le stockage décider (recommandé : ZFS/LVM imposent leur format).
Clone complet	proxmox_clone_complet	oui	oui = clone indépendant (autonome) ; non = clone lié (dépend du modèle, plus léger mais fragile). Garder oui.
Timeout opérations Proxmox	proxmox_clone_timeout	600	Secondes avant d'abandonner une opération longue (clone, redimensionnement).
Disque principal	proxmox_clone_disque	scsi0	Bus + index du disque système. scsi0 est le standard Set-OPS.
Interface réseau	proxmox_clone_interface	net0	Identifiant de la NIC virtuelle.
Pare-feu interface Proxmox	proxmox_clone_parefeu_interface	non	Active le pare-feu Proxmox au niveau de la NIC. Laisser non : le filtrage se fait dans l'invité (nftables), pas chez l'hyperviseur.
Démarrer le clone après création	proxmox_clone_demarrer	oui	oui = booter la VM dès la création (nécessaire pour qu'Ansible la joigne ensuite).

4. Secrets de l'instance 🔒 (voûte unique)

Tous les secrets de l'instance vivent dans une seule voûte chiffrée par instance : instance/inventories/<inventaire>/group_vars/all/vault.yml. Un seul fichier par écosystème — fini les voûtes éparpillées.

Une voûte, une clé (2026-08-28). « Un seul mot de passe » a été vrai, et c'était le défaut : le même ouvrait toutes les voûtes de la flotte, celle de l'hébergeur comprise. Chaque dépôt a maintenant sa clé — ~/.config/setops-vault-<dépôt-en-minuscules> — et le Makefile les rassemble dans ANSIBLE_VAULT_IDENTITY_LIST via scripts/voutes.py. Créer une VM ouvre d'ailleurs deux voûtes dans la même exécution : celle du tenant, et celle de l'hébergeur qui détient le jeton Proxmox. Gabarit committé : exemples/vault.exemple.yml (les deux clés du token Proxmox + 15 clés vault_* pour PKI, LDAP/SSO, bases, forge, observabilité).

L'assistant demande « Configurer la voûte de secrets maintenant ». Si oui :

Invite	Variable	Défaut	Sens / quoi saisir
Token ID Proxmox	proxmox_api_token_id	set-ops	Identifiant du token API créé côté Proxmox.
Token secret Proxmox	proxmox_api_token_secret	(aucun)	Secret du token. Saisie masquée, écrit dans la voûte chiffrée.

• Si la voûte existe déjà, l'assistant ouvre directement ansible-vault edit (aucune re-saisie en clair).
• Si elle n'existe pas, l'assistant la sème depuis le gabarit (toutes les clés présentes, vides), y place le token, puis la chiffre. On renseigne ensuite les autres secrets avec ansible-vault edit …/all/vault.yml.
• Ces secrets ne transitent jamais par le GUI ni par aucun fichier en clair ; le GUI n'en affiche que les noms (panneau « Intrants »).

Deux façons de remplir la voûte, et il ne faut pas les confondre

	Qui est la source	Comment
Générer	le dépôt — Ansible configure les deux côtés depuis la même variable (ex. vault_nextcloud_oidc : le client Keycloak le déclare, le rôle Nextcloud le lit)	valeur aléatoire, 32 octets
Saisir	un tiers — le secret existe déjà ailleurs et ne s'invente pas (clé d'API OPNsense, jeton Proxmox)	python3 scripts/voute.py saisir <clés>

python3 scripts/voute.py saisir vault_opnsense_api_key vault_opnsense_api_secret

Il n'y a rien à exporter : voute.py trouve la clé de la voûte par la convention de nommage (scripts/voutes.py etat la montre). Il n'y a pas non plus de cible make pour ce geste — c'est délibéré : saisir un secret est une manœuvre rare et attentive.

(voute.py au singulier manipule le contenu d'une voûte ; voutes.py au pluriel dit où sont les clés. Les deux existent, et ce n'est pas une faute de frappe.)

Saisie sans écho, double confirmation, rien sur la ligne de commande — donc ni dans l'historique du shell, ni dans la liste des processus. Rien n'est écrit en clair sur disque : la voûte est déchiffrée en mémoire, complétée, reparsée et re-déchiffrée pour contrôle avant d'être posée. Une clé déjà renseignée est ignorée, sauf --remplacer.

Pourquoi la distinction compte. Inventer une clé d'API OPNsense produirait une valeur syntaxiquement correcte, refusée à la première requête — et P18 passerait au vert sur une voûte inutilisable. Pire qu'une absence : un faux confort.

proxmox.vault.yml n'est plus lue (retirée le 2026-08-03)

Les playbooks ne chargent plus ce fichier. Tolérée « en compatibilité », elle était restée le seul porteur du jeton chez un tenant — et comme *.vault.yml est gitignoré, ce jeton ne voyageait avec aucun dépôt. Une voûte unique qui ne l'était pas.

Si tu en as encore une :

cd instance/inventories/<env>/group_vars
ansible-vault view proxmox.vault.yml        # relève token_id + secret
ansible-vault edit all/vault.yml            # colle-les
rm proxmox.vault.yml proxmox.vault.yml.example
python3 ../../../../scripts/voute.py verifier   # confirme : plus rien ne manque

Le jeton se stocke tel que Proxmox l'affiche (utilisateur@realm!nom). Les playbooks n'en gardent que la partie après ! : proxmoxer recompose l'identifiant à partir d'api_user, et lui passer la forme complète produit un 401 muet — alors que le même jeton fonctionne en curl. Les deux écritures sont acceptées.

---

Comment créer le token API côté Proxmox

Dans l'interface Proxmox (ou en CLI pveum) :

1. Créer l'utilisateur API (ex. ansible@pve) et lui donner les droits requis (rôle avec VM.Allocate, VM.Clone, VM.Config.*, Datastore.AllocateSpace, SDN.Use/réseau selon le cluster).
2. Créer un token API pour cet utilisateur → noter le Token ID et le secret (affiché une seule fois).
3. Renseigner Token ID + secret dans make config.

Voir aussi

• intrants-communs.md — tous les intrants communs de l'écosystème.
• nomenclature-vm.md — réseau, VLAN, fonctions.
• vm-lifecycle.md — cycle de vie d'une VM (création → conformité).
• make — liste des cibles (l'aide est la cible par défaut).