Le socle · les agents de terrain
Personne ne se connecte aux machines
pour les mettre à jour.
Le gardien est installé une fois pour toutes sur chaque machine de terrain. Ensuite, il tient ses agents à jour, renouvelle leurs certificats, entretient le système et rend compte au Hub. Si une version ne tient pas, il revient en arrière sans attendre personne.
À quoi il sert
Une flotte de machines posées chez des clients ne se met pas à jour à la main. Il faudrait s’y connecter une par une, au bon moment, et savoir revenir en arrière si quelque chose casse. Le gardien est né d’une nuit où une partie de la flotte est restée muette des heures sans que personne ne le voie. Son objectif est écrit en tête de sa spécification : plus aucune intervention manuelle sur la machine.
C’est un démon écrit en Go, livré pour Linux et macOS, sur processeurs Intel comme ARM, en paquet Debian sous Linux, servi par un dépôt signé. Il est installé une fois sur chaque machine qui porte un minihub ou un miniMiniHub. Il n’ouvre aucun port : il est seulement client du Hub.
Il fait cinq choses : il tient ses agents à jour, revient en arrière si une version ne tient pas, renouvelle les certificats, entretient le système — paquets, redémarrage de nuit — et rend compte au Hub.
Trois contrôles, tous obligatoires
Avant d’installer quoi que ce soit, le gardien vérifie trois choses. Il suffit qu’une seule échoue pour qu’il ne fasse rien.
La signature du manifeste
Le manifeste qui décrit la version à installer est signé (Ed25519). La clé publique qui permet de le vérifier est inscrite dans le binaire du gardien dès sa compilation.
L’empreinte publiée dans le DNS
L’empreinte du manifeste est publiée dans un enregistrement du DNS, et lue par des résolveurs publics. Pour tromper la flotte, il faudrait compromettre à la fois le stockage, la clé de signature et la zone DNS.
L’empreinte de chaque fichier
La taille et l’empreinte de chaque fichier à installer sont vérifiées avant usage.
S’y ajoutent une protection contre le rejeu — un manifeste plus ancien que le dernier connu est ignoré — et une rotation de clé encadrée : la nouvelle clé doit être signée par l’ancienne et publiée au DNS.
Comment il déploie
Il passe régulièrement
Toutes les trente minutes, plus quelques minutes d’aléa pour que toute la flotte ne se présente pas en même temps. Il sonde aussi les ordres du Hub chaque minute.
Il respecte les vagues
Le manifeste porte des vagues datées : une machine témoin d’abord, la flotte ensuite. Un canal « témoin » existe à côté du canal stable. Un arrêt d’urgence peut suspendre toute mise à jour.
Il installe et observe
Pour un minihub, la nouvelle version a dix minutes pour être saine et réussir un battement de cœur vers chacun de ses Hubs. Pour un miniMiniHub, trois minutes pour être vivant et voir un battement acquitté par son parent.
Il revient en arrière seul
Si le contrôle échoue, l’ancienne version est remise en place. Les machines passent une par une ; un échec arrête la série. Une version refusée n’est jamais retentée.
Il renouvelle et entretient
Il contrôle les certificats chaque jour, applique les mises à jour du système, redémarre la machine de nuit si besoin, et envoie un bilan toutes les six heures.
Il se met à jour en dernier
Le gardien se remplace lui-même après tout le reste : autotest du nouveau binaire, bascule, validation dix minutes plus tard. Un service de secours remet l’ancien binaire après trois démarrages ratés.
Les ordres et la console
Le Hub peut donner des ordres à un gardien, dans un vocabulaire fermé : état, journal, vérifier, pause, reprendre, maintenant, revenir en arrière, renouveler, système, redémarrer. Chaque ordre est signé par le Hub, expire en dix minutes et ne sert qu’une fois. Un ordre sensible exige la confirmation du même utilisateur dans les cinq minutes.
Ces ordres se donnent dans un salon du Hub, où les gardiens postent aussi leurs comptes rendus. Côté Hub, un service lit ce salon, repère les gardiens devenus muets et poste un bilan chaque matin.
En dernier recours existe une console de secours : un terminal ouvert dans une connexion qui part, elle aussi, de la machine vers le Hub. Elle est réservée au super-administrateur, ouverte par un ordre signé valable trente secondes, limitée à une heure, auditée — et désactivée par défaut chez les clients.
Le gardien sert enfin de canal d’approbation : quand un miniMiniHub rencontre une action sensible qu’on ne lui a pas permise, c’est par le gardien qu’un humain dit oui ou non.
- 30 min
Entre deux passages, plus un aléa - 3
Contrôles obligatoires avant toute installation - 10 min
Durée de vie d’un ordre signé - 0
Port ouvert par le gardien
Ce qu’il apporte
Une flotte qui se tient seule
On publie une version, on observe la machine témoin, on ouvre la vague suivante. Personne ne se connecte aux machines.
Une chaîne de confiance vérifiable
Signature, DNS, empreintes : une version piégée devrait franchir trois barrières indépendantes.
Des erreurs qui se défont
Une version qui ne tient pas est retirée sans intervention, et n’est jamais retentée.
Il veille sur les machines de minihub et de miniMiniHub. Le Hub publie les versions et suit les gardiens : le Hub →
Que se passe-t-il si une mise à jour casse un agent ?
Le gardien constate que la nouvelle version ne tient pas dans le délai prévu, remet l’ancienne, et arrête la vague.
Peut-on stopper toute mise à jour d’un coup ?
Oui : un arrêt d’urgence empêche les mises à jour, sans rien défaire de ce qui tourne.
Le gardien lui-même peut-il se casser ?
Il se met à jour en dernier, avec un autotest, et un service de secours remet l’ancien binaire après trois démarrages ratés.
La suite du socle
Les agents qu’il garde, et le gabarit de services qu’ils hébergent.