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/
_______________________________________________
Liste de diffusion du %(real_name)s
http://www.frsag.org/
