Daniel Allaire
5bc3bceac1
Some checks failed
verifier / verifier (push) Has been cancelled
La revision a commence par un balayage par motifs — chemins morts, cibles make absentes, comptes derives. Il a trouve une trentaine d ecarts et rate presque tout le reste : un motif ne voit que ce qui s exprime en motif. make hote-planifier en est l exemple. La cible EXISTE, donc le controle passait au vert. C est une cible depreciee qui refuse et sort en 2, recommandee par AGENTS.md, et qui contredit la REGLE D OR du meme fichier trois ecrans plus haut. Il fallait lire pour la voir. 74 documents lus un par un. 66 corriges, 8 exacts. CE QUI ETAIT FRANCHEMENT FAUX AGENTS.md, la source d autorite, annoncait la flotte pas encore executee contre des VM reelles. Elle a ete rasee et remontee depuis zero trois fois. ecosysteme-chezlepro.md, le document montre a un client, portait la meme phrase : il se sous-vendait gravement. courriel-conception.md s ouvrait sur aucun role n est encore ecrit, au-dessus de son propre paragraphe 1 qui les nomme. autorisation.md se terminait sur rien n est construit alors qu il rapporte des mesures datees du role en fonctionnement. hebergeur-exploitation.md disait rien n est fait d un depot qui existe. filiation-emancipation.md se contredisait a deux ecrans de distance. DES MODELES DECRITS D APRES UN MONDE ANTERIEUR Le resolveur : cinq documents decrivaient un Unbound par VM en opt-in, trois le donnaient en exemple d integration FACULTATIVE — il est universel depuis le 2026-08-24. L adressage de nomenclature-vm.md : reseau unique, VLAN 11-15, VMID a cinq chiffres. Le nommage SDN de sdn-evpn.md contre le code : c est le wiki qui avait raison. CE QUI CASSE AU PREMIER ESSAI Le nom du gabarit dore etait faux a quatre endroits, dont la procedure qui le FABRIQUE et le critere R2 de l epreuve d operateur independant. preparer-un-site-hebergeur.md avertissait qu une VM faite a la main serait detruite : raser derive du plan, il ne la detruira jamais — le risque est l inverse. Un mot de passe d essai en clair dans un depot public. DEUX PREUVES ETENDUES, ET UNE QUI SE TROMPAIT ELLE-MEME P57 couvre les groupes : elle a signale aussitot 29 groupes annonces au-dessus d un tableau qui en cite 40. P29 confronte le tableau de authentification.md aux declarations reelles : 12 annonces, 21 reels. Et P57 imposait un chiffre faux — 56 preuves alors que le depot en porte 57, la conditionnelle vivant hors de tout comptage. Un garde-fou qui fait respecter une erreur ajoute l assurance a l erreur. CE QUI RESTE, ET QU AUCUNE PREUVE NE TIENT Deux comptes trouves a la main. Et une lacune reelle : rien ne garde les meta/acces.yml — ni qu un service web-sso en porte un, ni que le groupe qu il nomme existe. P29 tient les positions d authentification, personne ne tient les habilitations. make prouver : CONFORME, 56 OK, 0 echec, 1 saute. 0 lien mort. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
165 lines
9.9 KiB
Markdown
165 lines
9.9 KiB
Markdown
# `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](#4-secrets-de-linstance-).
|
|
|
|
À 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`](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`](../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>` |
|
|
|
|
```bash
|
|
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 :
|
|
|
|
```bash
|
|
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`](intrants-communs.md) — tous les intrants communs de l'écosystème.
|
|
- [`nomenclature-vm.md`](nomenclature-vm.md) — réseau, VLAN, fonctions.
|
|
- [`vm-lifecycle.md`](vm-lifecycle.md) — cycle de vie d'une VM (création → conformité).
|
|
- `make` — liste des cibles (l'aide est la cible par défaut).
|