veilletech.frCe qui se passe
Le 30 août 2026, à la MiniDebConf Winterthur, deux ingénieurs du CERN — Federico Vaga et Nikos Tsipinakis — ont présenté « Controlling CERN's Accelerators with Debian ». Il ne s'agit pas du centre de calcul, qui reste sur RHEL et AlmaLinux, mais des machines qui pilotent la chaîne d'accélérateurs : 2 200 ordinateurs, reliés par 70 000 câbles à 17 000 dispositifs, répartis sur plus de 43 km² et jusqu'à 100 mètres sous terre.
Le déclencheur : un drapeau de compilation
Red Hat a choisi d'optimiser RHEL 9 pour le niveau x86-64-v2, puis RHEL 10 pour le v3. Concrètement, les binaires exigent des jeux d'instructions que les processeurs anciens n'ont pas.
L'analyse interne de Vaga donne le chiffre qui a tout décidé : 47 % des systèmes du CERN, équipés de processeurs anciens de type Intel Core Duo, ne pourraient pas exécuter des binaires v2 — ils ne démarreraient pas. 17 % de plus tomberaient avec le v3. Près de 65 % du parc, avec pour seule explication un message de la glibc.
Renouveler le matériel n'était pas une porte de sortie :
- les cartes de contrôle PCI sont conçues au CERN, et les PC actuels offrent un connecteur, deux sur un modèle industriel — contre plusieurs sur les machines d'avant 2010 ; certains systèmes devraient donc être remplacés par trois ;
- les cartes-mères VMEbus, « le cheval de trait du système de contrôle », seraient rendues obsolètes ; la génération suivante est conçue, mais sa production dépend des tensions du marché ;
- il faudrait deux ingénieurs électroniciens, deux développeurs et deux techniciens supplémentaires, plus, parfois, l'excavation de nouveaux espaces pour les racks.
Le devis total du renouvellement : 5,4 millions de francs suisses, soit environ 6,67 millions de dollars.
Ce qui migre, et ce qui ne migre pas
L'infrastructure est en trois couches, et une seule change :
| Couche | Rôle | Système |
|---|---|---|
| Consoles | postes des physiciens et opérateurs, applications Java et Python | AlmaLinux 10 + Xfce, inchangé |
| Centre de calcul | journalisation, authentification, contrôle des paramètres de sûreté | RHEL 9 → AlmaLinux 10 |
| Ordinateurs frontaux | 2 200 machines à 100 m sous terre, traduisent une commande en signal électrique | Debian 13 « trixie » |
Le CERN construira son propre noyau depuis les sources de kernel.org, avec tous les pilotes maison intégrés — ces pilotes en espace noyau étant, de son propre aveu, ce qui rend la stabilité plus difficile à tenir qu'avec de simples applications.
Le calendrier commande
L'accélérateur tourne 24 heures sur 24 et n'accepte aucune mise à jour en marche. Les arrêts techniques de quelques jours ne suffisent pas à une montée de version majeure : il faut viser les arrêts longs. « Vous avez peut-être un plan à cinq ans ; au CERN, nous avons un plan à quinze ans minimum, donc nous connaissons l'état de la machine jusqu'en 2041. »
D'où le plan : arrêt de l'accélérateur le 1er septembre 2026, migration des 2 200 systèmes embarqués vers trixie pendant la fenêtre, déploiement visé début 2027, stabilité tenue jusqu'à fin 2033. Le cycle Debian — trois ans de vie normale, deux ans de LTS, cinq ans d'ELTS chez Freexian — permettrait de rester sur la même version jusqu'en 2035 si aucune montée majeure n'est possible pendant la période d'exploitation.
Ce que ça a demandé de construire
Le CERN partait d'un parc entièrement RPM, avec peu d'expérience Debian : Freexian a envoyé Sébastien Delafond pour une formation de quatre jours (construction de paquets, dépôts APT, dépôts de compilation).
Trois pièces ont été assemblées : ELBE (Embedded Linux Build Environment) pour compiler du logiciel Debian depuis des machines RHEL, un système de démarrage multi-serveurs sur Kubernetes remplaçant l'unique serveur bare-metal historique — celui « sur lequel on ne respire pas », puisque sa chute privait 2 000 systèmes embarqués de leur racine — et un plugin Koji écrit par Erick Andrei Vilcica pour produire des paquets Debian avec l'infrastructure RPM existante.
Les difficultés rencontrées sont instructives : pas d'outillage standard pour
automatiser construction et publication (buildd et dak sont trop spécialisés),
Debusine jugé prometteur mais bloquant sur leur infrastructure, et surtout le
mauvais support de plusieurs versions d'un même paquet dans un dépôt — une
branche de reprepro le permet, mais elle est encore dans experimental.
À retenir
La conclusion de Tsipinakis vaut pour un parc mille fois plus petit : c'est une erreur de supposer qu'un système qui fonctionne sur une version d'une distribution fonctionnera encore sur la suivante. Ce qui compte n'est pas la distribution choisie, c'est de garder la capacité d'en changer — le CERN avait rendu son infrastructure portable « avec Debian comme plan B » avant que Debian ne devienne le plan A.