Déplacer un hôte d'une zone à une autre

Faire passer un poste ou un serveur dans une autre zone, lors d’un déménagement par exemple. La clé zone de l’hôte porte l’essentiel du changement ; restent ses sauvegardes, les services qu’il héberge et l’ordre de déploiement.

Une passerelle ne change pas de zone, elle la définit. Pour la remplacer, voir Migrer le matériel d’une passerelle.

Ce qui suit tout seul

Régénéré par just clean, puis propagé au déploiement.

Repris automatiquement	Pourquoi
Adresse, DNS et DHCP	Dérivés de la clé `zone`
Adresse de passage dans l’ancienne zone	Même dernier octet partout
Supervision et journaux	Features rattachées à la zone
Cache binaire de zone	Choisi d’après la zone
Pare-feu borné à la zone	Suit le préfixe de zone
Utilisateurs, secrets, clés SSH	Indépendants de la zone

Ce qui reste à traiter

Point	Risque	À faire
Sauvegardes restic	Cible et passphrase suivent la zone	Épingler l’ancien serveur
Services hébergés	Changent de zone et d’URL	Prévenir les utilisateurs
Features en `:<zone>`	Zone explicite, ne suit pas	Corriger la zone
Fuseau horaire, langue	Ceux de la nouvelle zone	Surcharger si besoin
Configuration machine citant `zone`	Suit la zone déclarée	Relire `usr/machines/<hôte>/`

Un service hébergé passe de <service>.<ancienne-zone>.domain.tld à <service>.<nouvelle-zone>.domain.tld et ne sert plus que sa nouvelle zone. Un service global garde son adresse publique, relayée par le HCS.

grep -rn 'zone\.' usr/machines/poste/

Fuseau horaire et langue se surchargent par darkone.system.i18n.timeZone et darkone.system.i18n.locale.

Procédure

Exemple : poste quitte la zone maison (10.0) pour la zone atelier (10.1).

Activer le cache itinérant

Les substituters deviennent neutres et suivent la zone où la machine est branchée, ce qui évite au premier déploiement après le déplacement de télécharger à travers le VPN. Voir Cache binaire.
usr/machines/poste/configuration.nix
```
darkone.service.nix-cache.roaming = true;
```
Fenêtre de terminal
```
just apply poste
```
Changer la zone

Choisir une adresse libre selon la convention d’adressage de la zone d’arrivée.
etc/config.yaml
```
- hostname: "poste"
  zone: "atelier:2.1"   # ancienne valeur : "maison:2.1"
  mac: "aa:bb:cc:dd:ee:ff"
```
La passerelle d’arrivée attribue l’adresse fixe sur l’adresse MAC. Sans elle, l’hôte reçoit une adresse dynamique et son nom désigne une adresse qu’il n’a pas.
Épingler les sauvegardes

Pour garder l’historique, la cible continue de viser le serveur de l’ancienne zone, avec la passphrase de cette zone.
usr/machines/poste/configuration.nix
```
darkone.service.restic = {
  enable = true;
  targets = [
    {
      root = "rest:http://100.64.0.20:8888"; # IP tailnet du serveur de maison
      zone = "maison"; # passphrase restic-password-maison
      categories = [ "system" ];
    }
  ];
};
```
Côté serveur, listenAll doit être actif : voir Sauvegarder hors-site.

Face à un serveur dans la nouvelle zone, elle initialise un dépôt vide et repart de zéro. Sans serveur, chaque sauvegarde est sautée sans erreur, et seule l’alerte ResticBackupStale le révèle.
Régénérer et valider
Fenêtre de terminal
```
just clean
git diff var/generated/
just commit "chore(poste): move from maison to atelier"
```
Le diff doit montrer l’adresse fixe dans atelier et une adresse de passage 10.0.6.x dans maison.
Préparer l’arrivée

Déployer le HCS, puis la passerelle d’arrivée, puis les autres passerelles, sauf celle de départ.
Fenêtre de terminal
```
just apply hcs
just apply gw-atelier   # puis les autres passerelles, sauf gw-maison
```
La passerelle d’arrivée réserve la nouvelle adresse sur la MAC de l’hôte. Le HCS relaie les services global et tient les règles VPN des postes d’administration : tous deux visent l’adresse de l’hôte.
Déplacer la machine

Branchée dans atelier, elle reçoit sa nouvelle adresse par DHCP, avant tout redéploiement.
Finir les passerelles

L’hôte parti, la passerelle de départ peut publier son nouveau nom et lui réserver son adresse de passage.
Fenêtre de terminal
```
just apply gw-maison
```
Déployer l’hôte
Fenêtre de terminal
```
just apply poste
```
Les exporteurs de supervision écoutent sur l’adresse déclarée. Un hôte déployé avant d’avoir sa nouvelle adresse voit ces services échouer.
Vérifier
- dig poste.atelier.domain.tld rend la nouvelle adresse.
- La cible poste est UP dans le Prometheus de atelier.
- Une sauvegarde manuelle retrouve les anciens snapshots.
Retirer le cache itinérant

Supprimer darkone.service.nix-cache.roaming, sauf pour un portable qui change souvent de zone, puis just apply poste.

FAQ

Et si l’hôte est le poste d’administration ?

Pendant le transport, plus rien ne déploie : prévoir un déployeur alternatif. À l’arrivée, il déploie la passerelle de départ à travers le VPN, puis lui-même avec just apply-local.

Pourquoi la passerelle de départ en dernier ?

Elle retire à l’hôte son adresse fixe. Encore branché, il recevrait son adresse de passage au renouvellement du bail, sans la configuration qui va avec, et le nom de l’hôte ne désignerait plus l’adresse qu’il occupe.

Faut-il s’attendre à des alertes ?

Oui, pendant le transport l’hôte est injoignable des deux côtés. Il est attendu par atelier dès l’étape 5 et encore surveillé par maison jusqu’à l’étape 7. Pour un poste, ce ne sont que des avertissements (voir classes d’alerte).

Comment revenir en arrière ?

Rétablir l’ancienne zone, régénérer, puis rejouer la procédure en sens inverse. Grâce aux adresses de passage, l’hôte reste joignable dans chaque zone entre-temps.