History

Daniel Allaire b0e56cbfc0 intégrations : le rôle déclare sa politique ; le cluster passe à l'hébergeur Deux corrections de propriété, l'une dans le plan, l'autre dans les intrants. 1. Intégrations universelles (D-33/D-34, P26) Le plan portait 57 lignes d'intégration écrites à la main, dont 28 disaient oui à quelque chose de vrai pour tous les hôtes. Elles n'existaient que pour être oubliées — et elles l'avaient été : dans Chezlepro, backup-01 et infra-pki-01 n'étaient ni supervisés, ni journalisés, ni certifiés. Le rôle déclare désormais sa politique une fois, dans meta/integration.yml ; le plan ne garde que les vrais choix et refuse la recopie. Les exemptions se dérivent du service rendu (sauf_role), jamais d'un nom d'hôte : l'AC ne s'enrôle pas auprès d'elle-même, et l'exemption suit step-ca si on le déplace. Une seule fonction de résolution — integrations_de() — lue par l'inventaire, la voûte et le panneau. Sans le passage par la voûte, les secrets des intégrations universelles auraient cessé d'être exigés et P18 serait passé au vert sur une voûte incomplète. Vérifié : diff vide sur Technolibre (la politique reproduit exactement les 41 lignes retirées) ; sur Chezlepro, exactement les groupes manquants, et pas client_pki sur infra-pki-01. 2. Vue Intégrations : la matrice La fiche montrait les intégrations d'UN serveur ; le trou de Chezlepro n'a pas été trouvé par le panneau mais par le devis de pare-feu. Matrice serveurs x intégrations : colonnes de politique en lecture seule, facultatives cochables sur place, ligne de couverture n/N qui rend le motif visible sans le juger. 3. Propriété des intrants (D-35/D-36, P27) Le cluster Proxmox appartient à l'hébergeur, comme sa fabric et sa frontière. Recopié chez chaque tenant, son inventaire avait déjà divergé : deux listes de stockages contradictoires pour le même matériel. API/nœuds/stockages/ponts vont dans proxmox-hebergeur.yml, à côté d'underlay.yml, dont le chemin se dérive — l'hébergeur reste non déclaré (D-17). Restent au tenant son golden template et ses défauts de placement. Le panneau nomme désormais le propriétaire de chaque section : éditer une section « hébergeur » vaut pour tous ses tenants, et l'écran ne le disait pas. 26 preuves OK, 0 échec. --syntax-check des deux playbooks Proxmox. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>		2026-08-03 14:09:22 -04:00
..
cloner_vm_debian.yml	intégrations : le rôle déclare sa politique ; le cluster passe à l'hébergeur	2026-08-03 14:09:22 -04:00
README.md	Mise en conformité prouvable : registre d'affirmations + make prouver	2026-07-20 19:53:18 -04:00
supprimer_vm_debian.yml	intégrations : le rôle déclare sa politique ; le cluster passe à l'hébergeur	2026-08-03 14:09:22 -04:00

README.md

Playbooks Proxmox

Ces playbooks pilotent Proxmox par API depuis le poste Ansible.

Les valeurs Cloud-Init communes déjà définies sur le modèle Proxmox sont héritées par les clones. Set-OPS ne les redemande pas.

Prérequis du poste Ansible

Le clonage Proxmox utilise les modules community.general.proxmox_*.

Le poste Ansible doit donc avoir :

la collection Ansible community.general ;
la bibliothèque Python proxmoxer disponible dans le Python utilisé par Ansible.

Sur Debian, installer généralement :

sudo apt install python3-proxmoxer

Vérification locale :

python3 -c 'import proxmoxer'

Les paramètres non sensibles sont dans :

instance/inventories/production/group_vars/proxmox.yml

Assistant terminal (écrit proxmox.yml et place le token dans la voûte unifiée) :

make config

Les secrets d'API vivent dans la voûte unifiée de l'instance — le token Proxmox aux côtés des autres vault_*, un seul fichier chiffré, non versionné :

instance/inventories/production/group_vars/all/vault.yml

make config la sème depuis le gabarit et y place le token. Le clonage lit cette voûte unifiée (une proxmox.vault.yml séparée reste acceptée en compatibilité). Détail des paramètres : docs/config-proxmox.md.

Créer un clone Debian depuis le modèle :

make creer-vm \
  HOTE=web-frontal-01 \
  VMID=95301 \
  VLAN=15 \
  ADRESSE_IP=10.0.15.31 \
  PASSERELLE=10.0.15.1 \
  GROUPES="serveur_debian serveur_durci"

VLAN doit être saisi à chaque création de VM pour éviter de réutiliser par erreur un réseau d'un autre clone.

Le disque du clone hérite de la taille du modèle. Pour l'agrandir à la création, fournir explicitement une taille supérieure à celle du modèle :

make creer-vm HOTE=web-frontal-01 VMID=95301 VLAN=15 ADRESSE_IP=10.0.15.31 PASSERELLE=10.0.15.1 TAILLE_DISQUE=64G GROUPES="serveur_debian serveur_durci"

Proxmox ne permet pas de réduire un disque existant.

creer-vm clone la VM, applique les paramètres Cloud-Init et ajoute l'hôte à l'inventaire. La conformité Ansible reste séparée :

make deployer HOTE=web-frontal-01