Salut,
Un serveur avec un OS de plus de 2-3 ans est symptomatique d'un problème technique (capacité à deployer limité, faible maitrise de ce qui tourne sur le serveur) ou organisationnelle (incapacité à gérer le changement de manière régulière)
Une forte longévité des OS, c'est un piège Les machins qui tournent depuis 7-10 ans, ce sont des pots de pus, qui n'ont pas évolué depuis des années, et dont l'évolution sera naturellement douloureuse
Alors bien sûr, avec certains OS (Debian), tu peux mettre à jour ton serveur et c'est plus facile: - modifier tes modules puppet pour intégrer la nouvelle version, incluant les nouvelles confs etc - upgrade ou rebuild ton serveur (en fonction de ce qu'il fait) - profit
Comme la mise à jour n'est pas supportée chez RHEL, bah tu l'as dans l'os et ça passe en mode "projet" avec rebuild impératif etc etc
Également, le support "LTS", c'est du bullshit (partout). Officiellement, y'a du support, oui. Dans les faits, si y'a un terrible problème, on mettra bien quelques ressources dessus. Mais croire qu'on va bichonner un vieux bousin ? De la naiveté.
Plus on s'éloigne de la release date, et plus le support du produit se détériore.
On 9/6/24 3:15 PM, Paul Rolland (ポール・ロラン) wrote:
Bonjour,
Beaucoup de reponses interessantes, et qui amenent d'autres questions. Alors, je vais reprendre un certain nombre de points ci-dessous.
D'abord, systemd. Cite plusieurs fois, il semble avoir un petit cote clivant, genre on aime/on n'aime pas du tout. J'ai rale contre lui quand il est apparu, j'aime bien init, mais surtout j'y etais habitue. Mais comme l'a ecrit Stephane :
La 'pieuvre' Systemd, c'est nettement mieux qu'initd, mais à condition de lire la doc...
et je suis assez d'accord, on finit par faire des choses bien sympa avec ;)
Mais pour revenir a la question telle que je la pensais dans mon mail initial, il semble que pas mal d'entre vous sont plutot Debian (je ne compte pas les *BSD-lovers, je pensais Linux quand j'ai redige mon premier mail... et j'ai oublie de l'ecrire). Pierre-Elliott nous a presente le cycle de vie/release de Debian, et il semble qu'une version soit "supportee" environ 10 ans si j'ai bien compris:
- 2 ans par la Release Team+Security Team
- 1 an par les meme en "oldstable"
- 2 ans de plus en "LTS"
ce qui fait un total de 5 ans, avec le passage en ELTS pour 5 ans de plus. C'est comme ca sur toutes les versions ?
Laurent de son cote a mentionne le point :
Encore disponible à l'installation pour permettre sa réinstallation, au cas où ce serait nécessaire.
De mon cote, je garde toujours dans un coin une copie des ISOs d'installation, et a ce jour, je ne suis pas encore tombe sur le cas ou une ISO serait inutilisable parce que reference a des repos qui ne sont plus dispos. Ca permet d'avoir un peu de stabilite dans les installations, mais encore faut-il etre en mesure de mettre a jour une fois installe, pour ne pas avoir une passoire.
Tiens, d'ailleurs, en parlant de passoire... On est tous ici bien au courant que les bugs de secu, ca existe, et que les distributions mettent a jour (plus ou moins vite). Mais la facon de mettre a jour n'est pas homogene et cote RH/CentOS, l'approche "patch sur la version retenue", c'est un peu casse-pieds. Je m'explique, exemple a l'appui : debut d'ete 2024, cve-2024-6387 aka RegreSSHion. Le probleme est present (entre autre) sur versions from 8.5p1 up to, but not including, 9.8p1 (source Qualys). CentOS9S, c'est une 8.7p1... mais le package est 8.7p1-43... et en cherchant, on tombe sur : https://bugzilla.redhat.com/show_bug.cgi?id=2294604 Dans le monde RedHat, c'est a partir de -38 qu'on a le fix. Donc, evidemment, avec une version 8.7, on a droit a une banner qui dit remote software version OpenSSH_8.7 et donc forcement, tous les remotes scans passent la C9s en mode "critical".
Sur les autres distris, c'est gere comment ?
Paul _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/