Ce qu’il faut au serveur

Un serveur ou une VM suffit : Ubuntu Server 26.04, 4 cœurs, 17 GiB de RAM, un second disque vide et aucun port entrant. L’installation vérifie chaque point de cette page avant de toucher à quoi que ce soit, et affiche la correction de chaque point en échec. Installer le nœud montre comment lancer ces vérifications seules, des jours avant l’installation.

Le serveur

• Un serveur réservé au nœud. detachbox-node-host tourne en root et exécute les commandes que signe le serveur detachbox : le nœud prend donc tout le serveur. Rien du même genre ne tourne à côté : ni Docker, ni LXD, ni Incus ou cloudflared à vous, ni autre pool ZFS. La vérification liste tout ce qu’elle trouve, avec la commande qui le retire.
• Ubuntu Server 26.04 LTS sur x86_64 (amd64), démarré avec systemd et cgroup v2, son système de fichiers racine en ext4 ou xfs, pas en ZFS. Une VM dans votre hyperviseur ou votre compte cloud fait aussi bien que du matériel.
• 4 cœurs CPU ou plus. Deux restent au système ; tous les autres font tourner vos terminaux.
• 17 GiB de RAM au strict minimum ; c’est à partir de 64 GiB que le nœud devient rentable. 8 GiB restent au système et à la construction de l’image de base. Le cache ZFS prend un seizième de la RAM, arrondi à la puissance de deux inférieure, entre 1 et 16 GiB. Vos terminaux reçoivent le reste, et la vérification affiche la répartition pour votre serveur.
• Secure Boot désactivé, ou la clé DKMS enrôlée. Ubuntu 26.04 livre ZFS 2.4.1, qui perd des blocs écrits avec la déduplication : l’installateur compile donc OpenZFS 2.4.4 et son module noyau sur le serveur. Les en-têtes du noyau en cours doivent être disponibles dans apt.
• Une horloge synchronisée (NTP, UDP 123). Le nœud n’accepte les requêtes du serveur qu’à 60 secondes près de sa propre horloge.

Le disque

Le pool ZFS du nœud demande un second disque, entier et vide, de 100 GiB ou plus. 70 % du pool deviennent le disque de votre compte. Le reste accueille le disque système de chaque terminal, les images de base et l’espace libre dont ZFS a besoin pour rester rapide. Le pool tourne avec la compression lz4, la déduplication et autotrim.

L’installateur refuse un disque qui porte une table de partitions, un système de fichiers, une étiquette LVM, RAID ou ZFS, ou quoi que ce soit de monté. Il ne détruit jamais de données et n’a aucune option pour forcer. Si le contenu du disque ne compte pas, effacez-le vous-même d’abord :

sudo wipefs -a /dev/sdb            # le disque que vous donnez au pool
sudo zpool destroy <pool>          # d’abord, si le disque appartient à un pool ZFS

Le réseau

Le nœud n’a besoin d’aucun port entrant. Chaque connexion qu’il ouvre est sortante :

Le nœud reconstruit son image de base toutes les 6 heures : ces hôtes restent donc utilisés après l’installation.

Donnez aux terminaux le même accès sortant à internet que le portable d’un développeur : les agents appellent leurs fournisseurs de modèles, et les builds tirent leurs dépendances des registres de paquets.

Laissez passer ces hôtes sans inspection TLS. node-host et cloudflared n’acceptent que des certificats d’autorités publiques, et quand un équipement intermédiaire signe à nouveau le trafic, la vérification nomme l’autorité qu’elle a reçue.

Les navigateurs de vos ingénieurs joignent le tableau de bord sur my.detachbox.com et api.detachbox.com, ainsi que les adresses du nœud lui-même sous detachbox.dev, que liste Ce que joignent les terminaux.

Le jeton

L’installation prend un jeton d’enregistrement fourni par votre contact chez detachbox. Il vaut pour un serveur et une installation. Un serveur a 7 jours pour s’enregistrer avec lui, et une fois l’enregistrement fait, le jeton accepte les relances de cette installation pendant 7 jours de plus. Un nouveau jeton remplace l’ancien.