Daniel Allaire
ac85278366
La refonte de ce matin posait une convention. Une convention qu'on n'outille pas tient tant que quelqu'un y pense : c'est le raisonnement de D-70, applique au corpus documentaire. Etat de depart mesure : 2 documents sur 34 declaraient leur lecteur. Les 32 autres disaient leur SUJET — ce qui avait enfoui le runbook de reprise le plus utile du depot au §6 de autorisation.md. Les 38 le declarent desormais, lecteur determine document par document et non colle au gabarit : l'exploitant (devis, migration de tenant, cycle de vie, gabarit d'or), le mainteneur (conceptions, registres, carte), le lecteur externe (ecosysteme-chezlepro), l'agent IA (MISE-A-JOUR-CODEX-CLAUDE). Deux exemptions DERIVEES, pas listees — un chemin en dur aurait vieilli a la premiere page ajoutee : un document qui s'annonce genere, et un fragment sans titre. Les 13 exemptes verifies un par un ; aucun document ecrit a la main n'est exempte par accident. La preuve ne lit que l'EN-TETE, ce qui empeche frontiere-opnsense.md et plan-et-generation.md — qui parlent de generation dans leur corps — d'etre exemptes a tort. Eprouvee dans les deux sens. Elle a echoue seule des sa premiere execution en nommant deux documents que mon inventaire avait manques (docs/audit/). Puis test negatif delibere : declaration retiree de meta-classe.md -> ECHEC la nommant ; restauree -> OK. Ce qu'elle ne teste pas : que le lecteur declare soit le BON. Ca se juge en revue ; elle garantit qu'on a du y penser. P01–P34. Comptes perimes corriges au passage (AGENTS.md et devis-services.md annoncaient encore 30 preuves). Verifie : prouver.py 0 (34 OK), plan-recette inchange. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
152 lines
8.8 KiB
Markdown
152 lines
8.8 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/production/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` | `modele-debian13` | Nom de référence du template (lisibilité ; doit correspondre au modèle). |
|
|
|
|
> 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
|
|
environnement** : `instance/inventories/<env>/group_vars/all/vault.yml`. Un seul
|
|
fichier, un seul mot de passe — fini les voûtes éparpillées. Gabarit committé :
|
|
[`exemples/vault.exemple.yml`](../exemples/vault.exemple.yml) (token Proxmox +
|
|
17 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
|
|
ANSIBLE_VAULT_PASSWORD_FILE=~/.config/setops-vault-pass \
|
|
python3 scripts/voute.py saisir vault_opnsense_api_key vault_opnsense_api_secret
|
|
```
|
|
|
|
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).
|