Move a host from one zone to another

Move a workstation or a server to another zone, during a move for instance. The host’s zone key carries most of the change ; its backups, the services it hosts and the deployment order remain to be handled.

A gateway does not change zone, it defines it. To replace one, see Migrate gateway hardware.

What follows automatically

Regenerated by just clean, then propagated to the deployment.

Handled automatically	Why
Address, DNS and DHCP	Derived from the zone key
Gateway address in the old zone	Same last octet everywhere
Supervision and logs	Features attached to the zone
Zone binary cache	Selected according to the zone
Zone-scoped firewall	Follows the zone prefix
Users, secrets, SSH keys	Zone-independent

What still needs handling

Item	Risk	To do
Restic backups	Target and passphrase follow the zone	Pin the old server
Hosted services	Change zone and URL	Warn users
Features in :<zone>	Explicit zone, does not follow	Fix the zone
Time zone, locale	Those of the new zone	Override if needed
Machine configuration citing zone	Follows the declared zone	Review usr/machines/<host>/

A hosted service moves from <service>.<old-zone>.domain.tld to <service>.<new-zone>.domain.tld and now only serves its new zone. A global service keeps its public address, relayed by the HCS.

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

Time zone and locale are overridden via darkone.system.i18n.timeZone and darkone.system.i18n.locale.

Procedure

Example : poste leaves the maison zone (10.0) for the atelier zone (10.1).

1. Enable the roaming cache

   Substituters become neutral and follow the zone the machine is plugged into, which saves the first deployment after the move from downloading through the VPN. See Binary cache.

   usr/machines/poste/configuration.nix

   darkone.service.nix-cache.roaming = true;

   just apply poste

2. Change the zone

   Pick a free address according to the addressing convention of the destination zone.

   etc/config.yaml

   - hostname: "poste"
     zone: "atelier:2.1"   # old value: "maison:2.1"
     mac: "aa:bb:cc:dd:ee:ff"

   mac key required

   The destination gateway assigns the fixed address based on the MAC address. Without it, the host gets a dynamic address and its name designates an address it does not have.

3. Pin the backups

   To keep the history, the target continues to point at the old zone’s server, with that zone’s passphrase.

   usr/machines/poste/configuration.nix

   darkone.service.restic = {
     enable = true;
     targets = [
       {
         root = "rest:http://100.64.0.20:8888"; # tailnet IP of the maison server
         zone = "maison"; # restic-password-maison passphrase
         categories = [ "system" ];
       }
     ];
   };

   On the server side, listenAll must be enabled: see Off-site backups.

   A target in restic.${zone.domain} follows the zone

   Against a server in the new zone, it initialises an empty repository and starts from scratch. Without a server, every backup is skipped without error, and only the ResticBackupStale alert reveals it.

4. Regenerate and validate

   just clean
   git diff var/generated/
   just commit "chore(poste): move from maison to atelier"

   The diff must show the fixed address in atelier and a 10.0.6.x gateway address in maison.

5. Prepare the arrival

   Deploy the HCS, then the destination gateway, then the other gateways, except the departure one.

   just apply hcs
   just apply gw-atelier   # then the other gateways, except gw-maison

   The destination gateway reserves the new address on the host’s MAC address. The HCS relays global services and enforces the VPN rules of the administration workstations : both target the host’s address.

6. Move the machine

   Once plugged into atelier, it receives its new address via DHCP, before any redeployment.

7. Finish the gateways

   With the host gone, the departure gateway can publish its new name and reserve its gateway address.

   just apply gw-maison

8. Deploy the host

   just apply poste

   Not before the move

   Supervision exporters listen on the declared address. A host deployed before it has its new address sees those services fail.

9. Verify

   • dig poste.atelier.domain.tld returns the new address.
   • The poste target is UP in the atelier Prometheus.
   • A manual backup finds the old snapshots.

10. Remove the roaming cache

    Delete darkone.service.nix-cache.roaming, except for a laptop that frequently changes zone, then just apply poste.

FAQ

What if the host is the administration workstation ?

During transport, nothing deploys any more : plan an alternate deployer. On arrival, it deploys the departure gateway through the VPN, then itself with just apply-local.

Why the departure gateway last ?

It takes away the host’s fixed address. Still plugged in, it would receive its gateway address when the lease renews, without the matching configuration, and the host name would no longer designate the address it occupies.

Should alerts be expected ?

Yes, during transport the host is unreachable from both sides. It is expected by atelier from step 5 onwards and still monitored by maison until step 7. For a workstation, these are only warnings (see alert classes).

How to roll back ?

Restore the old zone, regenerate, then replay the procedure in reverse. Thanks to the gateway addresses, the host stays reachable in each zone in the meantime.