Garder le nœud en marche

Le nœud se met à jour lui-même et surveille sa propre santé. Votre administrateur tient Ubuntu et son noyau à jour, et peut choisir le moment où Incus et cloudflared passent à une nouvelle version.

Le vérifier avec doctor

sudo detachbox-node-host doctor

doctor vérifie le nœud de bout en bout et ne change rien. Chaque vérification a 20 secondes et affiche sa ligne dès qu’elle se termine :

que detachbox accepte toujours le jeton du nœud, node-host et sa version, et la dernière réponse du serveur ;
les connexions du tunnel vers Cloudflare et le chemin retour par ce tunnel, jusqu’à node-host et à la passerelle des terminaux ;
le HTTPS et le TLS sortants vers api.detachbox.com ;
Incus, qu’il est bien bloqué dans apt, et si des versions plus récentes d’Incus ou de cloudflared attendent ;
le module ZFS chargé maintenant et celui que chargera le prochain noyau, la déduplication, la santé du pool et son taux de remplissage ;
vos réseaux privés face au pare-feu des terminaux ;
l’image de base et le début de sa dernière construction.

Chaque ✗ vient avec sa correction. Une partie qui ne répond plus, comme Incus ou ZFS, affiche … within 20 s sur sa ligne ✗, et les vérifications suivantes de cette partie affichent not checked: … did not answer above au lieu d’attendre. Un … marque ce qui ne fait pas échouer la vérification : ce qui ne peut pas encore être connu, comme la première réponse du serveur dans les minutes qui suivent un redémarrage de node-host, ou une mise à jour qui attend. La ligne des mises à jour indique ✓ Updates Incus <version>, cloudflared <version>: the newest builds apt knows of, ou … Updates not yet: …; <build> waits: sudo detachbox-node-host upgrade installs it (node-host does on a day no terminal runs).

sudo detachbox-node-host doctor --report envoie le résultat à detachbox, pour que votre contact chez detachbox voie ce que vous voyez.

Ce qui se met à jour tout seul

node-host se met à jour dans les minutes qui suivent chaque version de detachbox. Il n’installe que ce que la clé de publication de detachbox a signé, et remet en place la version précédente si la nouvelle ne démarre pas.
L’image de base de vos terminaux est reconstruite toutes les 6 heures avec les mises à jour d’Ubuntu et les dernières versions de Claude Code, Codex et OpenCode. Elle n’entre en service qu’après un smoke test ; une construction qui échoue laisse en place la dernière bonne image. Les terminaux en marche gardent l’image sur laquelle ils ont démarré, et un terminal nouveau ou redémarré reçoit l’image actuelle.

Incus et cloudflared

Les deux restent bloqués dans apt (hold), et ce blocage n’est jamais levé : votre propre apt upgrade ne les touche pas. Un redémarrage de cloudflared coupe une fois chaque connexion qui passe par le tunnel du nœud (onglets de terminal, aperçus, envois de fichiers), et un redémarrage d’Incus coupe les connexions des onglets de terminal ouverts. Dans les deux cas, elles se rétablissent d’elles-mêmes en quelques secondes, et les terminaux continuent de tourner avec leurs sessions tmux, leurs agents et tous leurs processus. Un terminal démarré ou arrêté pendant ces secondes échoue une fois et passe à la demande suivante, et une construction d’image de base en cours échoue puis est relancée dans les 6 heures. C’est pourquoi ils ne passent à une nouvelle version qu’au moment que vous choisissez, ou un jour où aucun terminal ne tourne.

sudo detachbox-node-host upgrade --check      # interroge les dépôts des deux éditeurs ; rien ne change
sudo detachbox-node-host upgrade              # dit ce qui est plus récent et ce qui arrive aux terminaux, demande [y/N]
sudo detachbox-node-host upgrade --confirm    # met à niveau sans poser la question

upgrade liste ce qui est plus récent, combien de terminaux tournent et ce que les redémarrages leur font, puis pose la question. Lancé sans terminal où poser la question, il refuse et indique --confirm. Une fois que l’installation des paquets a commencé, la mise à niveau va jusqu’au bout quoi qu’il arrive à votre session ; suivez-la avec sudo tail -f /var/lib/detachbox-node/install/install.log. Elle se termine par doctor et ✓ Upgraded: …, au bout d’environ une minute sur notre nœud de test.

node-host tente la même mise à niveau une fois par jour, la première fois 15 minutes après son démarrage, et seulement quand rien ne tourne à part l’edge : aucun terminal, aucune construction d’image de base. Si un terminal tourne, il note dans son journal que la mise à niveau attend, et réessaie un jour plus tard. Un nœud où un terminal tourne en permanence ne se met jamais à niveau de lui-même : doctor continue d’afficher la mise à jour jusqu’à ce que vous lanciez upgrade.

Mises à jour du noyau

Ubuntu et son noyau, c’est à vous de les mettre à jour. Installez chaque nouveau noyau avec ses linux-headers, et DKMS compile de lui-même le ZFS 2.4.4 du nœud pour ce noyau ; sur notre nœud de test, cela a pris environ 4 minutes. doctor affiche ensuite une ligne ZFS for <kernel> pour le noyau en cours et une pour le noyau installé le plus récent, celui que chargera le prochain démarrage. Les deux doivent afficher ✓ avant que vous redémarriez ; après un redémarrage sur le nouveau noyau, le nœud revient de lui-même.

Si un noyau démarre un jour sans le ZFS du nœud, node-host désactive la déduplication avant qu’un terminal n’écrive le moindre octet, et le signale dans doctor et à detachbox. Il réactive la déduplication au premier démarrage sur un module corrigé.

Redémarrages

Un redémarrage arrête les processus en cours et les sessions tmux. node-host et le tunnel démarrent avec le serveur, et vos terminaux reviennent d’eux-mêmes avec leurs fichiers, paquets apt et images Docker en place ; les conteneurs Docker dotés d’une politique restart: repartent. Chaque agent revient de lui-même sur sa dernière conversation et attend son ingénieur. Celui qui n’est pas revenu y repart avec Redémarrer le terminal sur cette conversation.

Quand le nœud passe hors ligne

Une minute après que le nœud a cessé de répondre, le tableau de bord affiche Nœud hors ligne depuis 14:02 dans la barre du haut et sur la page Compute, et un terminal ouvert indique qu’il se reconnectera de lui-même dès le retour du nœud. Les fichiers restent sur le serveur. Après 10 minutes de silence, le compte propriétaire du nœud reçoit un e-mail, qui donne l’heure et renvoie à sudo detachbox-node-host doctor, puis un autre quand le nœud répond de nouveau. Un redémarrage ou une mise à jour de node-host ne dure jamais aussi longtemps.

Plus de cœurs ou de mémoire

Ajoutez-les au serveur, puis prévenez votre contact chez detachbox. node-host communique à detachbox les cœurs, la mémoire et le pool du serveur, et votre contact applique la nouvelle taille ; rien ne change de soi-même. Le Compute en marche prend la nouvelle taille sans redémarrage, et Activité l’enregistre.

Quand detachbox retire le nœud

Si l’enregistrement de votre nœud est annulé, doctor le dit en une ligne, « ✗ Account taken off », avec la marche à suivre : sudo detachbox-node-host uninstall --confirm, ou, si vous ne vous y attendiez pas, envoyez cette ligne à votre contact chez detachbox. D’ici là, node-host se tait, le tunnel et l’edge restent tels quels, et il interroge detachbox toutes les 15 minutes : un nœud refusé par erreur revient dans ce délai. Un refus qui ne vient pas dans les termes du serveur detachbox, comme celui d’un proxy qui exige sa propre connexion, ne signifie pas que le nœud est retiré : doctor le dit sur la ligne Account. Laissez passer le nœud par ce proxy sans connexion, ou envoyez la ligne à votre contact chez detachbox.