SITE-TechnoLibre/README.md

# 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