Ayant simultanément ressenti un trouble dans la force, vos administrateurs des serveurs LinuxFr.org ont noté un souci sur le site hier matin. Et d'autres personnes de l'équipe ont aussi signalé le problème (supervision efficace et réactive par le lectorat).

Le serveur hébergeant les conteneurs de production et de développement a redémarré (hors de toute opération planifiée) à 06h15 Paris le 26 juin 2025, et contrairement aux redémarrages habituels pour les mises à jour, cela a entraîné un changement des adresses IP internes des conteneurs de production et de développement, après redémarrage (06h18). Tous les services avaient bien redémarré, mais les accès aux sites web n'étaient plus possibles : le serveur web frontal ne pouvait plus joindre les adresses prévues, aboutissant à des réponses techniques 502 Bad Gateway.

La correction sur les adresses IP a été faite à 08h08 pour la production et 08h16 pour le développement.

Les deux autres serveurs hébergés au même endroit n'ont pas été affectés.

Changement d'adresses IP

Les conteneurs de production et de développement sont configurés en DHCP et gardent normalement les mêmes adresses sur les redémarrages.

Exemple de redémarrage propre pour des mises à jours de sécurité :

mai 24 10:06:08 oups dnsmasq-dhcp[1256]: DHCPREQUEST(lxc0) 192.168.0.2 aa:aa:aa:aa:aa:aa
mai 24 10:06:08 oups dnsmasq-dhcp[1256]: DHCPACK(lxc0) 192.168.0.2 aa:aa:aa:aa:aa:aa prod
mai 24 10:06:22 oups dnsmasq-dhcp[1256]: DHCPRELEASE(lxc0) 192.168.0.2 aa:aa:aa:aa:aa:aa
---redémarrage---
mai 24 10:08:57 oups dnsmasq-dhcp[1228]: DHCPDISCOVER(lxc0) 192.168.0.2 bb:bb:bb:bb:bb:bb
mai 24 10:08:57 oups dnsmasq-dhcp[1228]: DHCPOFFER(lxc0) 192.168.0.2 bb:bb:bb:bb:bb:bb
mai 24 10:08:57 oups dnsmasq-dhcp[1228]: DHCPREQUEST(lxc0) 192.168.0.2 bb:bb:bb:bb:bb:bb
mai 24 10:08:57 oups dnsmasq-dhcp[1228]: DHCPACK(lxc0) 192.168.0.2 bb:bb:bb:bb:bb:bb prod

(les IP, MAC et interfaces ont été changées)
On a demande et attribution de l'IP pour une adresse MAC donnée, puis elle est relâchée à l'arrêt de la machine, puis réattribuée au démarrage.

Incident :

juin 26 03:57:46 oups dnsmasq-dhcp[951195]: DHCPREQUEST(lxc0) 192.168.0.2 cc:cc:cc:cc:cc:cc
juin 26 03:57:46 oups dnsmasq-dhcp[951195]: DHCPACK(lxc0) 192.168.0.2 cc:cc:cc:cc:cc:cc prod
---redémarrage---
juin 26 04:18:42 oups dnsmasq-dhcp[1222]: DHCPREQUEST(lxc0) 192.168.0.2 dd:dd:dd:dd:dd:dd
juin 26 04:18:42 oups dnsmasq-dhcp[1222]: DHCPNAK(lxc0) 192.168.0.2 dd:dd:dd:dd:dd:dd address in use
juin 26 04:18:46 oups dnsmasq-dhcp[1222]: DHCPDISCOVER(lxc0) dd:dd:dd:dd:dd:dd
juin 26 04:18:46 oups dnsmasq-dhcp[1222]: DHCPOFFER(lxc0) 192.168.0.100 dd:dd:dd:dd:dd:dd
juin 26 04:18:46 oups dnsmasq-dhcp[1222]: DHCPREQUEST(lxc0) 192.168.0.100 dd:dd:dd:dd:dd:dd
juin 26 04:18:46 oups dnsmasq-dhcp[1222]: DHCPACK(lxc0) 192.168.0.100 dd:dd:dd:dd:dd:dd prod

On a demande et attribution de l'IP pour une adresse MAC donnée. Elle n'est pas relâchée à l'arrêt de la machine, n'est pas disponible au redémarrage, et une autre est alors attribuée.

Nature du redémarrage

Le redémarrage a été brutal, sans arrêt propre des services. Il ne s'agit donc pas d'un arrêt logiciel propre depuis le serveur.

La cause possible peut donc être un souci d'instabilité électrique, l'arrêt/extinction physique sur le serveur, un bug ou une faille logicielle, ou encore le redémarrage électrique via la carte d'administration. Cette cause n'est actuellement pas connue.

Mesures préventives et correctives

Il pourrait être utile de figer les IP internes et/ou d'assurer la synchronisation/reconfiguration du frontal web.

Il n'est pas prévu d'avoir de la redondance sur la production à court/moyen terme, donc un souci sur le conteneur de production continuera à avoir un effet visible.

La supervision peut certainement être améliorée (et l'état des services rendu visible depuis un simple navigateur web).

Je travaille depuis quelque temps sur Elpe, un projet qui vise à obtenir les bonnes propriétés de Nix/NixOS (les mises à jour atomiques, la reproductibilité), mais avec des paquets Ubuntu.

Le code : https://nest.pijul.com/pmeunier/elpe

L'idée est de définir des recettes de compilation en OCaml et de les envoyer à un backend Rust, qui se charge de les exécuter dans un conteneur sans réseau, en exposant uniquement le contexte nécessaire à la bonne exécution de la compilation. Les produits du build sont indexés par le contenu de la recette du build, et indexés une deuxième fois par le résultat : c'est ce deuxième hash qui est utilisé dans les dépendants du paquet, ce qui permet de construire un arbre de Merkle du système complet (et non seulement de ses sources), qui rend toute modification ultérieure facilement détectable.

De plus, le système de base provient des dépôts de paquet Debian ou Ubuntu. Cependant, tous les chemins sont hard-codés (comme dans Nix), ce qui permet de garantir la reproductibilité, au détriment toutefois du coût de mise à jour en termes d'espace et opérations disque.

Si le choix de Rust devient relativement consensuel par les temps qui courent, OCaml est plus surprenant. Après divers essais avec plusieurs langages, je l'ai choisi parce que c'est le seul langage avec à la fois :

• Une bonne approximation du système de types dont j'avais besoin: typage nominal et aussi structurel, entre autres.
• Un système de types relativement simple (pas de typeclasses ni de monades comme en Haskell, de borrow checkers comme en Rust ni de types dépendants comme en TypeScript).
• Du late binding, nécessaire pour exprimer des "overrides" et des "hooks", courants quand on veut compiler des choses (autoconf et make ont plein d'options de ce type, par exemple).
• Un compilateur ultra-rapide.
• Un bytecode, pour (dans le futur) contrôler aussi l'isolation du code de build de façon très légère.

La simplicité et l'expressivité d'OCaml sont bien adaptés à ce projet: les fonctions simples à concevoir y sont relativement claires à énoncer.

Pourquoi pas NixOS, me direz-vous ? En tant qu'utilisateur et contributeur depuis environ 10 ans, un certain nombre de problèmes plus ou moins récents m'ont motivé à explorer une alternative:

• En termes de gouvernance, la communauté a traversé dans la dernière année plusieurs crises de différentes tailles (Anduril, Devenv…). On pourrait y voir un signe de maturation ou au moins de croissance du projet, mais plusieurs éléments me permettent d'en douter, dont les réactions répétées de la fondation Nix, qui semble avoir beaucoup de mal à comprendre les messages pourtant clairs des contributeurs.

• Je vois aussi les choix de design imposés par les fondateurs du projet depuis quelques années comme un bien mauvais signe: les flakes (en 2020) étaient une première incarnation de cette tendance, et plus récemment la "distribution propriétaire" de Nix est clairement une mauvaise idée, alors que la qualité de code de Nix n'est pas au niveau où on l'attendrait et que le gros du projet repose depuis plusieurs années sur le travail pharaonique des contributeurs de Nixpkgs.

• On pourrait parler longtemps de la sécurité de Nix, qui me fait de plus en plus peur y compris pour mon usage personnel. Les process de gestion des rapports ne me conviennent pas, de même que l'opacité de certains choix techniques (les flags de compilation désactivés sur certaines plateformes, entre autres), souvent bien cachés dans les entrailles de Nixpkgs.

• Enfin, le langage trop complexe à utiliser (principalement par manque de typage statique et de messages d'erreurs pertinents) rend Nix difficile à utiliser au sein d'une organisation d'une taille importante, et encourage les comportements peu inclusifs (éviter d'écrire de la doc, inventer des casse-têtes pour faire des choses simples…). Je suis bien sûr conscient que des entreprises (comme Anduril) et des ONGs (comme Médecins Sans Frontières) l'utilisent, mais je ne pense pas que ce soit généralisable aux situations où j'aimerais voir ce genre de projet utilisé.