Daniel Allaire
e1550e3e29
- plan/10-intrants.yml : dns_public_pairs SITE-Chezlepro, etat actif. - opnsense.yml : opnsense_liens_sites vers SITE-Chezlepro, interface opt10 (wg1). - COLLECTE.md : la console de maurice sur la GTX 950 (fbcon=map:1). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
164 lines
8.5 KiB
Markdown
164 lines
8.5 KiB
Markdown
# À 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. Quinze valeurs : deux cartes, l'adresse du WAN, dix noms d'interface, deux paires de jetons.
|
||
|
||
| Ce qu'il faut | Où le lire | Pourquoi personne ne peut le décider |
|
||
|---|---|---|
|
||
| `<<IFACE>>` | `ip -br link` sur le nœud | Le nom de la carte réseau dépend du matériel (`eno1`, `enp1s0`…) |
|
||
| `<<IP_PUBLIQUE>>` | OPNsense, interface WAN | Donnée par le fournisseur d'accès |
|
||
| `<<optN>>` ×10 | OPNsense → Interfaces → Assignments | Les noms `optN` sont attribués dans l'ordre de création |
|
||
| `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 dix 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é.** Relevé le 2026-10-13 : `local-lvm` ne fait que 130 Go.
|
||
Les VM vont sur `nvme` (LVM-thin, NVMe 465 Go), `site-backup-01` sur `miroir` (ZFS, 2 × 12
|
||
To). Revérifier `pvesm status` AVANT de lancer la matérialisation.
|
||
|
||
**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 `.11`, commutateur `.111` — passerelle de tous : la frontière |
|
||
| 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 | `maurice` | Nom d'hôte posé à l'installation (2026-10-13) |
|
||
| Frontière | `requin` | Nom d'hôte de l'OPNsense (2026-10-13) |
|
||
| 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 |
|
||
| Ponts | `vmbr0` sur `nic0`, `vmbr1` sur `nic2` | Administration en 1G ; les VLAN des VM en 10G, VLAN-aware |
|
||
| Gabarit | `99998` | Le même dans toute la flotte |
|
||
|
||
---
|
||
|
||
## 1. Le chiffre qui décide de tout
|
||
|
||
```
|
||
SITE 9 VM 23 Go RAM 816 Go provisionnés
|
||
chaque locataire ~14 VM ~37 Go RAM ~460 Go provisionnés
|
||
```
|
||
|
||
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).
|
||
|
||
- [x] **RAM physique du nœud** : **256 Go** (2 × 128, ASUS Z10PE-D16 WS) — la mémoire n'est plus la contrainte
|
||
- [ ] **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
|
||
|
||
**Relevé du 2026-10-13** : `caillou`, commutateur de couche 2 seulement (4 × 2,5G, 4 × SFP+),
|
||
entre `requin` (`ix0`) et `maurice` (`nic2`) ; les VLAN 31 à 37 et 40 y passent étiquetés,
|
||
prouvés par ARP depuis `maurice` (témoin : VLAN 99, sans réponse).
|
||
|
||
- [ ] **Le VLAN 1 (administration) traverse encore les deux ports SFP+** du lien des zones,
|
||
non étiqueté : les diffusions du poste arrivent sur `nic2` et sur `ix0` (mesuré en
|
||
faisant émettre le poste pendant l'écoute). Retirer le VLAN 1 des MEMBRES de ces deux
|
||
ports, pas seulement du natif ; natif = un VLAN sans autre membre (999). Remis à plus
|
||
tard par Daniel le 2026-10-13.
|
||
|
||
## 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.
|
||
|
||
## Particularités matérielles relevées
|
||
|
||
- **`maurice` — la console sur la GTX 950** (2026-10-14). Deux cartes graphiques : la GTX 950
|
||
(`nouveau`, `fb1`, sortie DVI, carte de démarrage du BIOS) et l'ASPEED de la carte mère
|
||
(`ast`, `fb0`, sortie VGA). Depuis le noyau 7.0.14, la console reste sur l'ASPEED : écran
|
||
noir sur la DVI après « Loading initial ramdisk... ». Corrigé par `fbcon=map:1`
|
||
(`/etc/default/grub.d/90-console.cfg`, puis `update-grub`). À reposer après une
|
||
réinstallation ; à défaut, brancher l'écran sur la sortie VGA.
|