# À relever sur place — TechnoLibre **Tout ce qui pouvait être décidé l'a été le 2026-09-13.** Ce qui suit n'est pas un choix : ce sont des FAITS que seul le matériel peut dire. Treize valeurs, pas trente-cinq. | Ce qu'il faut | Où le lire | Pourquoi personne ne peut le décider | |---|---|---| | `<>` | `ip -br link` sur le nœud | Le nom de la carte réseau dépend du matériel (`eno1`, `enp1s0`…) | | `<>` | OPNsense, interface WAN | Donnée par le fournisseur d'accès | | `<>` | OPNsense, interface de gestion | Dépend du plan d'adressage existant sur place | | `<>` ×9 | OPNsense → Interfaces → Assignments | Les noms `optN` sont attribués dans l'ordre de création | | `<>` | Idem | Selon que la patte de gestion est la LAN d'origine ou une autre | | `proxmox_api_token_id` | Datacenter → Permissions → API Tokens | Délivré par le nœud à la création | | `proxmox_api_token_secret` | Idem — **affiché une seule fois** | Ne se relit jamais ; le noter tout de suite | | `vault_opnsense_api_key` | System → Access → Users → api keys | Délivré par la frontière | | `vault_opnsense_api_secret` | Téléchargé avec la clé, même fichier | Idem | **Le piège des `optN`.** Le devis raisonne en ARRIVÉE : une règle posée sur la mauvaise patte ne correspond jamais, et rien ne le signale. Relever les neuf noms exacts avant de poser quoi que ce soit, y compris celui de la patte face au nœud Proxmox — elle manquait chez Chezlepro et toutes les règles entrantes des locataires tombaient dans le vide. **Ce qui est mesuré, pas relevé.** `local-lvm` accueille quinze clones complets, soit environ 600 Go. Vérifier `vgs` et `df -h` AVANT de lancer la matérialisation : c'est la seule décision de ce document qui peut encore changer, et elle se prend avec un chiffre. **Les quatre jetons vont dans la voûte**, pas dans un fichier de plan : ``` cd ../Set-OPS-public ANSIBLE_VAULT_IDENTITY_LIST="$(python3 scripts/voutes.py identites)" \ ansible-vault edit ../SITE-Technolibre/underlay.vault.yml ``` Ils y sont déjà déclarés, **vides**. C'est volontaire : une clé absente donne une erreur de variable indéfinie, une clé vide donne l'assertion du rôle — qui dit quoi manque et où le prendre. Les dix autres secrets du site sont déjà engendrés. --- ## Ce qui a été décidé, et qu'il suffit de confirmer | | Valeur | Raison | |---|---|---| | Index du site | `31` | Les sites prennent leur propre index depuis le 2026-09-12 | | Plan d'administration | `10.31.0.0/24` | **Un seul** — frontière `.1`, nœud `.41`, passerelle amont `.254` | | Adresse du poste | une secondaire dans `10.31.0.0/24` | De là, l'API Proxmox, la frontière et le rebond sont tous joignables | | Nœud Proxmox | `atelier` | À poser comme nom d'hôte à l'installation | | Frontière | `portail` | Étiquette dans la carte ; l'OPNsense peut garder son nom réel | | Domaine du site | `socle.internal` | Distinct de `technolibre.internal`, qui est au locataire | | Routage des locataires | `sdn` (EVPN sur le nœud) | Sans commutateur L3, le mode `switch` obligerait la frontière à porter douze interfaces routées | | ASN | `65031` | Dérivé de l'index — deux sites reliés ne peuvent pas collisionner | | Contrôleur EVPN | `EVPN0031` | Objet de cluster : nommé d'après le site, pas d'après son premier locataire | | Pont | `vmbr0` | Un seul, VLAN-aware — sans seconde carte, d'autres ponts ne sépareraient rien | | Gabarit | `99998` | Le même dans toute la flotte | --- ## 1. Le chiffre qui décide de tout ``` SITE 7 VM 20 Go RAM 776 Go provisionnés tenant 14 VM 37 Go RAM 460 Go provisionnés ───────────────────────────────────────── TOTAL 21 VM 57 Go RAM ~1,2 To ``` Sur trois nœuds ça se répartit. Sur **un seul**, la même machine porte tout — et la RAM est la contrainte dure (le disque se dégonfle en provisionnement fin, pas la mémoire). - [ ] **RAM physique du nœud** : ______ Go → si < 64, décider de réduire AVANT de câbler - [ ] **Espace libre du stockage `images`** : ______ Go (viser 1,2 To ; 800 Go à la rigueur) ## 2. L'hyperviseur - [ ] **Nom exact du nœud** tel qu'il apparaît dans l'interface : ______ - [ ] **Version** : `pveversion | head -1` → ______ (attendu : `pve-manager/9.x`) - [ ] **Noms exacts des stockages** acceptant le contenu `images` : `pvesm status` - [ ] **Ponts** présents : `ip -br link | grep vmbr` - [ ] **Adresse de gestion** du nœud : ______ - [ ] **SDN disponible ?** `pvesh get /cluster/sdn` répond sans erreur : oui / non ### Compte d'API ``` pveum user add ansible@pve pveum aclmod / -user ansible@pve -role Administrator pveum user token add ansible@pve set-ops --privsep 0 ``` - [ ] **Token ID** + **secret** notés (le secret ne s'affiche **qu'une fois**) ## 3. La frontière (OPNsense) - [ ] **IP publique (WAN)** : ______ - [ ] **Version** : ______ - [ ] **Interfaces libres** pour les zones du site : ______ - [ ] **Clé + secret d'API** créés et notés - [ ] **Compte `ansible`** en SSH par clé, `sudo` vérifié : `sudo -n -l` - [ ] **Une patte face au nœud Proxmox** (le lien de transit) : interface ______ ## 4. Entre les deux — LA question de forme Ce qu'il y a entre le nœud Proxmox et l'OPNsense décide du mode de routage : - [ ] **Un commutateur capable de SVI et d'ACL** → mode `switch`, modèle : ______ - [ ] **Un commutateur simple (VLAN seulement)** → l'OPNsense route tout, mode `switch` avec l'OPNsense comme routeur - [ ] **Un lien direct nœud ↔ OPNsense** → trunk 802.1Q, l'OPNsense route tout - [ ] **SDN EVPN sur le nœud** → indépendant du matériel, mais jamais éprouvé sur un nœud unique ## 5. Cohabitation d'adressage - [ ] `ip route` sur le poste de Mathieu — quelles plages `10.x` sont déjà prises ? - [ ] Son réseau bureautique / son VPN utilisent-ils `10.31.x` ou `10.23.x` ? ______ - [ ] Docker présent sur ses machines d'administration ? (`172.17`+ déjà pris) ## 6. Le gabarit - [ ] Gabarit Debian 13 `modeleSetOPS-minimal` : **fait** / **à faire** (procédure : `docs/procedure-template-debian13-proxmox.md`, ~30 min) - [ ] Si fait : **VMID** ______ , **nom** ______ , **stockage** ______ - [ ] Vérifier `machine: q35` et `bios: ovmf` — **ne jamais convertir** un i440fx ## 7. Les accès réseau nécessaires depuis le poste | Cible | Port | Pour quoi | OK | |---|---|---|---| | Hyperviseur | 8006 | créer et détruire les VM | [ ] | | Hyperviseur | 22 | `pvesh`, `qm`, SDN | [ ] | | Frontière | 443 | poser les règles par API | [ ] | | Frontière | 22 | SSH, compte `ansible` | [ ] | | Zones du site | 22 | SSH vers les VM une fois créées | [ ] | ## 8. Les deux paires de secrets Par un canal chiffré, **séparément du reste**, et jamais dans git : - [ ] Token ID + secret de l'hyperviseur → voûte de l'instance - [ ] Clé + secret de l'API de la frontière → voûte de l'instance ## 9. Ce qui n'a jamais été éprouvé, et qu'il faut regarder de près - [ ] **Proxmox 9** — le moteur n'analyse aucune version et n'appelle que des chemins d'API stables, mais rien n'a jamais tourné contre un PVE 9. Surveiller le pare-feu (`proxmox-firewall` nftables en 9) et le SDN (passé GA). - [ ] **Nœud unique** — pas de Ceph, pas de migration, le gabarit et les clones sont sur la même machine. Le SPOF est total et assumé. - [ ] **Index 31** — celui du SITE. Vérifier qu'aucune plage `10.31.x` n'existe déjà chez Mathieu (`ip route | grep 10.31`). `make instances` garde la fédération.