La mieux va dépendre du contexte.

De mon côté perso, la famille est en Fedora, upgrade à chaque majeur, top à jour, ça juste marche.

Côté pro, je suis tombé dans Debian en 2001, la stabilité de la distro est appréciable en entreprise et on peut ajouter des repos d'éditeurs pour avoir des versions précises ou à jour de logiciels (DB, web, drivers, ...).

Néanmoins la prolifération des systemd-* dans Debian me pose problème, car il faut gérer le changement de beaucoup d'industrialisation avec l'IaC. Et quand on fait rencontrer deux mondes qui campent sur leurs positions, ça donne Debian 12 ou Fedora 40 nftables avec Docker Engine (de leur repo) qui n'en veut pas et qui ne sait pas se contenter de iptables-legacy qui wrappe vers nftables. Alors que toutes les docs de Docker disent qu'ils sont compatibles nftables ... Oui y a d'autres moteurs de conteneurs, mais ils ne sont pas tous compatibles avec les images clients.

Tout cela me fait dire qu'avoir une distribution stable dans le temps devient plus difficile ces temps-ci.

Je pense me tourner vers des distros minimalistes comme Alpine qu'on utilise en CICD ou conteneur ou du Arch, pour gérer du bare metal ou de la VM. Néanmoins il faudra faire une croix sur les repos d'éditeurs tiers beaucoup ne gèrent pas ces distributions.

Email Signature Le 03/09/2024 à 18:08, Paul Rolland (ポール・ロラン) a écrit :

Bonjour, plop, plop,

La question posee par David a propos de Debian8/12/whatelse me fait m'en poser une autre... On a tous une type de distrib qu'on prefere, parce qu'on est tombe dedans en meme temps que dans la potion magique, on connait ses secrets, bref c'est "la mieux" (tm).

Mais si on regarde en terme de duree de vie en production, tout en conservant des (vraies) mises a jour de securite, ou un vrai chemin d'upgrade qui ne casse pas tout, ca devient quoi "la mieux" ?

C'est la rentree des classes, vous avez 2H, et les reponses doivent etre argumentees, bien evidemment ;)

Salutations, Paul _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/

Salut,

"Paul Rolland (ポール・ロラン)" rol+frsag@witbe.net wrote on 03/09/2024 at 18:08:07+0200:

Bonjour, plop, plop,

La question posee par David a propos de Debian8/12/whatelse me fait m'en poser une autre... On a tous une type de distrib qu'on prefere, parce qu'on est tombe dedans en meme temps que dans la potion magique, on connait ses secrets, bref c'est "la mieux" (tm).

Mais si on regarde en terme de duree de vie en production, tout en conservant des (vraies) mises a jour de securite, ou un vrai chemin d'upgrade qui ne casse pas tout, ca devient quoi "la mieux" ?

Puisqu'on parlait de Debian, un petit paragraphe sur son cycle de vie.

Une release stable sort en moyenne tous les deux ans. Elle est supportée par la Release Team et la Security Team en tant que stable jusqu'à la sortie de la suivante (~2 ans). Ensuite elle devient « oldstable » et elle est encore maintenue par les mêmes teams environ un an.

Quand les teams en questions arrêtent de la supporter, l'équipe des backports ferme aussi les backports, et l'équipe LTS prend le relais. C'est typiquement ce qui est arrivé à Bullseye mi août.

La LTS permet de porter le support environ à 5 ans. Ensuite, c'est le projet Extended LTS porté par Freexian qui prend le relais.

ELTS en rajoute 5 de plus environ.

Par exemple, Jessie est encore supportée via ELTS jusque fin juin 2025.

Mais officiellement ce n'est plus le projet qui la supporte.

Donc selon comment tu comptes, Debian est en haut du panier (sans doute avec RHEL, qui fait 5 ans de full support, 5 ans de maintenance support, + des options - chères pour3 ans de plus après).

Perso j'utilise pas Debian pour ça. Mais c'est cool de savoir que les vieilles releases sont bien couvertes.

À la boite, l'idée est de :

- Se simplifier la vie : On est en *"nodoze mode"* sur tout le parc.

- D'avoir quelque chose de raisonnablement uniforme : Serveurs : Xen + Debian (actuellement de 8, 10,11,12, legacy oblige). Stations : Ubuntu 18.04 LTS (il doit en rester 4/5),  22.04 LTS et maintenant 24.04 LTS On a en commun la 'racine debian', l'arborescence, le packaging, systemd, etc. Mais bien sûr, les diff. de versions sont telles qu'en dev, on télé-compile sur les servs.

*Coté serveurs*

J'aurais peut être eu une /autre approche/ si je n'avais eu que des serveurs à gérer. Peut-être que j'aurais été vers /FreeBSD/. Mais Debian est très fiable.

Pour l'hypervision des serveurs, Xen est un bonheur absolu. On maîtrise le mode PVH de Xen depuis 4 ans, qui est une tuerie de speed. La R&D, ça vaut le coup parfois.

La 'pieuvre' Systemd, c'est nettement mieux qu'initd, mais à condition de lire la doc... Faut évoluer parfois ;> Sur les serveurs, tout le reste de la pieuvre n'est pas utilisé (networkd, resolved, etc.) au profit de networking/interfaces. Les softs les plus utilisés sont recompilés avec les bons modules (nginx par exemple) pour implémenter du Fast_CGI compatible avec de la prod de site WP. Tout le routage et le firewalling est scripté à coups de commandes ip et iptables. Pas de proxmox, pas de "zinaagaz", rien que de la base et de l'automation maison. Notre philosophie est le KISS.

*Coté stations*

Si l'on cherche à faire une station qui puisse faire aussi bien, voire poutrer du doze (tas de merde) ou du MacOS (vieux tas pas si ergonomique) , il faut /nettement plus qu'une config de simple serveur/. Je souhaite avoir des stations avec des fonctionnalités a minima identiques à celles des OS pré-cités. Dans cet esprit (par exemple), l'hibernation hybride est systématiquement paramétrée (l'utilisateur replie l'écran de son portable, il passe en veille simple - qui consomme encore un peu mais permet une reprise immédiate -  Sans activité, au bout de 2 heures (notre choix), le portable sort fugitivement de sa veille et passe en hibernation totale puis coupe complètement son alimentation). Je ne comprends pas pourquoi ce n'est pas implémenté par défaut sous Ubuntu.

Sur les stations, on garde toute la pieuvre coté réseau, obligatoire quand on a du filaire, du wifi, du wlan et du BT dans un seul portable, sans compter une flopée de VPN internes ou externes. Jusqu'à la 22.04 LTS, snap était systématiquement viré. Depuis la 24.04 LTS, on a renoncé... Ils ont mis en snap trop de choses vitales et c'est pas fini semble t-il. Après tout, ça nous simplifie la vie sur certains softs qui doivent être à la dernière stable. Oui, c'est lâche. Oui, snap est un malware. Enfin, on est toujours sous x11 pour éviter cette chiure de wayland et toutes les emmerdes qui vont avec.

On tient à conserver Ubuntu car elle passe parfaitement pour les users (bien paramétré, c'est du MacOS en nettement mieux coté ergonomie). Pour le dev ou le graphisme, c'est juste top ainsi. Les PPA à dispo, des noyaux à jours, parfaits pour du CM récentes ou des écrans récents (je pense aux Dell 43" de station qui ne passent en veille que sur des noyaux d'au moins 2022).

*Les inconvénients*

Coté serveurs, Debian bouge un peu trop, de version en version, faut reprendre des choses. Avec FreeBSD, j'imagine que j'aurais plus de stabilité d'une version à l'autre. Et ZFS (entre autres). Ubuntu et Gnome bougent beaucoup. Le passage à la 24.04 a été un peu chronophage (mais on y est arrivé). Gnome est très cohérent coté UX quand on a du VPN, du WLAN, etc. mais Nautilus et Samba est (pour l'instant) un peu cassé en 24.04 (40 secondes pour se connecter (?!), donc on est passé par mount.cifs direct via un script iconifié.

*Conclusion*

Ce combo n'est pas parfait mais fonctionne plutôt bien. Le CTO a la paix ;>

À la base j’étais en train de répondre à l’email «Longévité des OS»… et puis en me relisant j’ai noté que ma réponse était un peu hors sujet: désolé :-)

Voici un petit retour d’expérience de plus de 15 ans avec un parc d’environ 15 000 machines physiques actuellement réparties dans le monde entier pour du CDN vidéo.

Le problème de la gestion de la durée de vie de l’OS en production a été résolu en passant en mode «rolling release». Le concept de montée de version est donc une tâche comme une autre, surtout quand la vie de la version en production n’est que de 4 semaines maximum. Pourquoi 4 semaines ? Car on met 4 semaines à mettre l’ensemble du parc à jour, et dès qu’une version est déployée on passe à la suivante. On se permet une pause pendant les fêtes de fin d’année.

L' équipe «ops» est composée de moins de 8 personnes, mais en réalité c’est uniquement 1 seule personne (celle d’astreinte) qui gère l’ensemble du parc pendant sa semaine d’astreinte. Les 7 autres pendant ce temps, ils sont soit en vacances soit en train de coder les outils d’automatisation de leurs tâches, pour pouvoir survivre à leur prochaine semaine d'astreinte. Et donc pour la mise à jour de l’ensemble du parc, la personne «on duty» lance un script, qui va se charger de mettre l’ensemble des machines, par groupe (un seul membre de chaque cluster à la fois par exemple pour ne pas perturber le service). Et ceci va se dérouler sur environ 4 semaines, pour laisser le temps de détecter un problème et de mettre en pause le déploiement en cas de découverte de problème de dernière minute.

Pour arriver à cela, le principe KISS est prioritaire sur l’ensemble du reste (pas de documentation par exemple: un nouvel arrivé dois être capable de comprendre comment cela fonctionne en lisant le code qui doit donc rester simple.

Pour cela, voici ce qui a été choisi: - Pour l’OS il faut un truc simple qui offre tout l’outillage pour s’autoconstruire intégralement depuis ses sources: du FreeBSD; - Pour les applications, l’arbre des ports FreeBSD dispose du reste (ici c’est du nginx pour l’essentiel). - Et pour le processus de MaJ c’est la fonctionnalité Boot-Environment de ZFS est utilisée. On compile une sorte de «firmware» (OS+applications) qui est déployé sur un dataset ZFS et on indique au système de démarrer sur ce nouveau dataset. En cas de problème lors du démarrage, il va redémarrer automatiquement sur l’ancien. À par les fichiers de configuration du système (merci le concept POLA de FreeBSD), rien n’est utilisé de l’ancien dataset. Les disques qui stockent le contenu, eux, sont en UFS et ne sont pas touchés par ces mises à jour. - Et toutes les 4 semaines, on synchronise notre version interne avec les dernières versions disponibles. Pas les branches de «production», mais les branches de «dévelopement», c’est trop facile sinon. - Et tous les jours ou presque, on pousse nos contributions vers les projets open source utilisés, ce qui simplifie énormément le merge de notre branche interne lors de nos synchros.

La tâche de créer ce firmware est dédiée à l’équipe «dev OS»: Moins de 10 personnes aussi, mais c’est beaucoup car il y a un gros travail d'optimisation (cf les conférences de Drew Gallatin par exemple), mais ça, c'est pour nous permettre d’acheter les machines les moins chères, et donc de mettre plus d’argent dans la création de contenu.

Et maintenant avec ça il faut un système de test de régression aux petits ognons… ha ben cela tombe bien, c’est aussi inclus avec FreeBSD qui embarque plus de 9000 tests de régression (cela va du kernel aux outils userland). Exemple des rapports de tests FreeBSD en ligne: https://ci.freebsd.org/job/FreeBSD-main-amd64-test/lastCompletedBuild/testRe... Et si vous n’en avez pas assez ou que vous vous amusez avec une pile TCP personnalisée comme nous, il y a en plus les une «tcptest suite» de disponible pour 1000 tests de plus: https://ci.freebsd.org/job/FreeBSD-main-amd64-test_tcptestsuite/lastComplete...

Ces tests de régression sont lancés sur des VMs ici, puis tous les jours on lance un test A/B de charge réelle. Mais il nous est très compliqué de simuler en labo la diversité des équipements de nos clients et leur réseau domestique. Alors pour nous aider l’équipe «dev client», celle qui code le client qui tourne dans vos télés, smartphones, consoles, etc. a fait du bon boulot: Le logiciel ouvre et supervise plusieurs sessions vers plusieurs serveurs pour basculer le plus rapidement vers un autre serveur en cas de problème. Et grâce à cette robustesse notre domaine de jeu s’étends… à toute la production :-) On peut redémarrer un serveurs en pleine charge sans aucun problème (et on en profite). Bon, cela n’est plus très vrais avec nos prototypes 400Gb/s et 800Gb/s: L’impact est un peu trop visible sur certains liens Internet. Donc tous les soirs, on passe une partie de la production sur la version «du jour». C’est la version jeune de quelques heures qui a passée les tests de régression en VM. Cette version est déployée sur une 50aine de serveurs qui disposent d’un double pratiquement identique. C'est-à-dire à la même hauteur dans le rack d'à côté pour essayer d’avoir les températures/vibrations/etc. les plus comparables. Le lendemain, après environ 12 heures de charge, on reçoit des raports d’analyses statistiques des différences entre les 2 groupes. Et là, on compare tout ce que l’on peut: consommation électrique, température des SFP, nombre d’IO disques, charge CPU par processus, etc. En plus des données provenant des serveurs on dispose aussi de la comparaison des stats remontées par les logiciels clients qui se sont connectés sur chacun de ces 2 groupes (utile par exemple pour découvrir que l’on a cassé le TLS sur une famille de matériel clients). Et après 4 semaines d’itération la version «du jour - 1» est sélectionnée pour être la version «production» et débute son déploiement sur l’intégralité de la production. Pour le détail technique de la gestion des branches, cf une ancienne présentation du manager de l’équipe: https://papers.freebsd.org/2019/FOSDEM/looney-Netflix_and_FreeBSD.files/FOSD...

En cas de problème ou patch de sécurité à déployer rapidement, le processus est le même: On applique le patch et on reconstruit un nouveau firmware.

Bref, pour résumer: - du KISS dans les équipes (il n’existe pas de poste «chef de projet» par exemple), dans les process et dans les choix techniques ; - Quand on a peur d’une tâche comme la montée de version, le plus simple est d’en faire tous les jours ;-)

Salutations, Olivier