SITE-TechnoLibre — site de reprise

Pour qui : l'exploitant, quand il prépare ou joue une reprise.

Ce site n'héberge aucune production. Celle de Chezlepro vit chez Chezlepro, celle de TechnoLibre aussi — les deux écosystèmes habitent SITE-Chezlepro. Ce site-ci existe pour les reprendre, lors d'un exercice ou d'un sinistre.

C'est pourquoi son underlay.yml déclare les deux index : 17 et 23.

Ce qu'une reprise demande

Un écosystème se reconstitue depuis son propre dépôt. Reprendre, c'est :

1. faire pointer le symlink underlay.yml du moteur vers ce site ;
2. reprendre les sept intrants par make site-intrants ;
3. redéployer depuis le dépôt du locataire.

Le plan du locataire ne change pas. Seul change le site qu'il habite.

Ce que ce site doit porter pour qu'une reprise aboutisse

Les mêmes services prêtés que le site de production — cache, forge, noms, dépôt — plus la fabrique. Un site de reprise qui n'a pas de forge ne peut pas servir le génome ; un site qui n'a pas de cache fait sortir chaque machine sur Internet.

Ce qui n'est pas encore résolu

Les sauvegardes ne sont pas ici. Chaque écosystème dépose sur le dépôt de son site de production. Si ce site brûle, ses sauvegardes brûlent avec lui — et il ne resterait ici que de quoi reconstruire des machines vides.

Un site de reprise sans la donnée reprend l'infrastructure, pas le service. C'est la question à trancher avant de qualifier ce site de « site de reprise » devant quiconque.

Refait le 2026-10-12 sur le modèle de SITE-Chezlepro

Le dépôt de septembre ne suivait plus les méthodes du moteur : schéma de la carte (nature, segment_physique), zone de publication, edge et DNS public du site, domaines.yml, mainteneurs.yml, réglages de la frontière. Il porte désormais les mêmes fichiers, les mêmes zones et les mêmes noms de VM qu'au site de Chezlepro — un exploitant qui connaît l'un connaît l'autre. Seuls changent l'index (31), le domaine (socle.internal), les noms des équipements (requin, maurice, caillou) et ce que seul le matériel peut dire (<<…>>, voir COLLECTE.md).

On le juge sans toucher au lien underlay.yml du moteur :

SETOPS_UNDERLAY=../SITE-Technolibre/underlay.yml python3 scripts/prouver.py

Quatre écarts y restent, et ils sont attendus pour un site de reprise : les locataires désignent encore le site de Chezlepro, où ils tournent (P37, P69, P73, P79).

Ce qui le distingue du site de Chezlepro

	Chezlepro	TechnoLibre
Nœuds Proxmox	3 (asgard, gandalf, vishnu)	1 — maurice, ASUS Z10PE-D16 WS, 2 CPU, 2 × 128 Go
Version	PVE 8.4	PVE 9
Stockage	Ceph NVMe + TrueNAS iSCSI	local au nœud : nvme (VM), miroir ZFS 2 × 12 To (sauvegardes)
Clones	liés, sur stockage partagé	complets — pas d'autre nœud pour porter le gabarit
Frontière	OPNsense (bifrost-1)	OPNsense sur QOTOM (requin) — 5 × 2,5G, 4 × SFP+ 10G
Adresse publique	fixe (pool de quatre)	dynamique — face fixe : le relais (VPS), à confirmer

Trois conséquences directes :

1. Le point unique de panne est total et assumé. Perdre le nœud, c'est tout perdre — d'où le dépôt de sauvegarde hors nœud dès le premier jour.
2. clone_complet: true. Un clone lié dépend à vie de son gabarit ; sans second nœud, ce lien n'achète rien.
3. Proxmox 9 n'a jamais été éprouvé ici. Surveiller le pare-feu (proxmox-firewall nftables) et le SDN.

Le chiffre

SITE                 9 VM    23 Go RAM    816 Go provisionnés
OPS-Chezlepro      ~14 VM   ~37 Go RAM   ~460 Go   \ reprise : l'un, l'autre,
OPS-Technolibre    ~14 VM   ~37 Go RAM   ~460 Go   /  ou les deux
                   ───────────────────────────────
TOTAL              ~37 VM   ~97 Go RAM   ~1,7 To

Avec 256 Go, la mémoire n'est plus la contrainte : le site peut reprendre les deux locataires à la fois. Le disque, lui, est à mesurer (vgs ; df -h).

L'adressage

• Administration : 10.31.0.0/24, non étiquetée — frontière .1 (requin), nœud .11 (maurice), poste de l'exploitant .101, commutateur .111 (caillou).
• Zones du site : 10.31.31 à 10.31.37 (VLAN 31 à 37) — le 3e octet est le VLAN, comme chez Chezlepro. .1 = la frontière, mêmes derniers octets que chez Chezlepro pour les VM (site-forge-01 = .33.11, site-edge-01 = .37.11…).
• Transit : 10.0.4.0/24 (VLAN 40) ; VXLAN : 10.31.50.0/24 (VLAN 50).

L'ordre des gestes

1. PREMIERE-HEURE.md : adresses de la frontière et du nœud, comptes d'API et SSH.
2. Reporter dans opnsense.yml les dix noms optN, et dans underlay.yml les cartes du nœud (<<IFACE>>).
3. Voûte : les quatre jetons (Proxmox, OPNsense) — les quatorze autres secrets y sont.
4. make underlay, puis le harnais (ci-dessus) — il refuse ce qui ne concorde pas.
5. make site-creer CONFIRMER=true, puis le socle et les services.
6. Une fois site-pki-01 en place : scripts/frontiere_pki.py (autorité de la frontière, syslog, exportateur, interface), puis opnsense_api_verifier_certs: true.

Voir aussi

• docs/preparer-un-site-hebergeur.md — ce qu'un hébergeur doit fournir
• docs/implanter-un-tenant-sur-un-site.md — y poser un locataire
• docs/hebergeur-exploitation.md — l'exploitation courante