Installer le nœud

Une seule commande, lancée en root, fait d’un serveur Ubuntu vierge votre nœud. Donnez-lui le jeton de votre contact chez detachbox et le disque vide destiné au pool :

curl -fsSL https://api.detachbox.com/api/v1/node-host/install \
  | sudo bash -s -- <token> --disk /dev/sdb

Comptez 30 à 60 minutes, surtout pour compiler OpenZFS et construire la première image de base. La commande se termine par « The node … is live », et les terminaux de votre compte s’ouvrent sur https://my.detachbox.com.

Sur un serveur où d’autres personnes se connectent, ne mettez pas le jeton dans la commande : tant que l’installation tourne, chaque utilisateur local peut lire sa ligne de commande. Sans le jeton, la commande vous le demande dans votre terminal par detachbox enrollment token: et n’affiche pas ce que vous tapez.

curl -fsSL https://api.detachbox.com/api/v1/node-host/install \
  | sudo bash -s -- --disk /dev/sdb

Ce que prend la commande

Une relance sans --private-network garde les réseaux reçus par l’exécution précédente. Une fois le nœud enregistré, modifiez-les avec private-networks, pas avec la commande d’installation.

Les vérifications d’abord

La commande commence par un tableau de vérifications : le système, root, systemd, le système de fichiers racine, d’autres conteneurs ou tunnels sur le serveur, CPU et RAM, le disque, les réseaux privés, l’horloge, Secure Boot et les en-têtes du noyau quand ZFS doit être compilé, le DNS, chaque destination sortante, TLS et le jeton. Chaque ligne affiche ✓ ou ✗, et sous chaque ✗ figure la correction. Rien ne change sur le serveur tant que toutes les lignes ne sont pas à ✓.

Pour voir ce tableau avant le jour de l’installation, ajoutez --check après le jeton :

curl -fsSL https://api.detachbox.com/api/v1/node-host/install \
  | sudo bash -s -- <token> --check --disk /dev/sdb

La commande lance alors les vérifications seules et se termine par Nothing on this machine changed and the token is not spent: the same command without --check installs the node. Le node-host téléchargé et vérifié reste sur le serveur pour cette prochaine exécution, comme après chaque exécution.

Les huit étapes

1. Les paquets : la dernière version d’Incus depuis le dépôt stable de Zabbly (7.6 ou plus récente) et la dernière version de cloudflared depuis Cloudflare, depuis leurs propres dépôts apt, avec leurs clés de signature intégrées à l’installateur. L’installation les bloque tous les deux (apt-mark hold) : un redémarrage de l’un ou de l’autre coupe pendant quelques secondes les connexions ouvertes vers le nœud, ils ne changent donc de version qu’au moment que vous choisissez, ou un jour où aucun terminal ne tourne.
2. OpenZFS 2.4.4 et la limite du cache ZFS. L’installateur compile OpenZFS depuis la version officielle, avec son SHA-256 figé et sa signature vérifiée par la clé de publication d’OpenZFS, en paquets dotés d’un module DKMS, si bien que chaque noyau qui a ses en-têtes le reçoit. Il remplace le module d’Ubuntu par le nouveau sans redémarrage.
3. Le pool ZFS boxes sur votre disque.
4. Incus : son stockage, deux bridges (un pour les terminaux, un pour l’edge du nœud), leurs règles de pare-feu, les projets, et l’API d’Incus elle-même, sur le bridge de l’edge seulement.
5. La première image de base : Ubuntu avec Docker, Claude Code, Codex et OpenCode, en 10 à 20 minutes. Le nœud la reconstruit toutes les 6 heures.
6. L’enregistrement auprès d’api.detachbox.com : le nœud reçoit son nom, ses clés, son tunnel Cloudflare et son propre domaine sous detachbox.dev ; node-host reçoit sa configuration et ses unités.
7. cloudflared et node-host démarrent.
8. La mise en service par le serveur : detachbox joint node-host par le tunnel, démarre l’edge (la passerelle des terminaux et le proxy des aperçus), lance un smoke test et configure le Compute de votre compte. La commande affiche chaque étape à mesure que le serveur l’atteint.

Chaque étape affiche la partie en cours, comme la configuration, la compilation et l’empaquetage du build d’OpenZFS. Pendant une partie longue, une ligne arrive toutes les 30 secondes.

Une relance reprend là où l’installation s’est arrêtée

Si quelque chose arrête l’installation, comme un hôte bloqué, une connexion coupée ou un redémarrage, relancez la même commande. Elle reprend à l’étape qui s’est arrêtée, et le travail terminé n’est pas refait. Le node-host téléchargé et vérifié reste sur le serveur, lisible par root seul, jusqu’à ce que l’installation le mette en place. Un jeton télécharge node-host trois fois, puis une fois toutes les 30 minutes ; la commande indique combien de temps attendre.

• Quand le shell distant d’où vous l’avez lancée se coupe, l’installation s’arrête là où elle en est. Lancée sans terminal, depuis un script ou un outil avec une limite de temps, elle continue. Sur une connexion fragile, lancez-la dans tmux.
• Ctrl-C, ou sudo kill <pid> depuis une autre session, arrête une exécution en quelques secondes, avec tout ce que son étape a lancé.
• Une exécution à la fois. Si vous lancez la commande pendant qu’une exécution travaille, elle ne change rien : elle indique depuis quand cette exécution travaille, son processus, et comment la suivre.
• Une relance utilise le même disque. Pour repartir sur un autre disque, désinstallez d’abord.

Quand une étape échoue

La commande affiche ce qui a échoué, pourquoi, et la commande ou le changement qui le corrige, avec les 30 dernières lignes de la commande en échec. L’échec part chez detachbox avec votre jeton, si bien que votre contact chez detachbox le voit aussi. Corrigez, puis relancez la même commande. Dépannage du nœud couvre les cas courants.

Le journal

/var/lib/detachbox-node/install/install.log garde chaque exécution en entier : la ligne qui indique son début et sa version, chaque ligne de chaque commande lancée, et comment elle s’est terminée. Si vous avez perdu la session, le journal dit comment l’exécution s’est terminée. Pour suivre une exécution depuis une autre session :

sudo tail -f /var/lib/detachbox-node/install/install.log

Ce qui tourne sur le serveur

Ce qui va où