[gull] [SPAM] Re: [SPAM] Re: Abus réseaux
Philippe Strauss
philippe at straussaudio.ch
Thu Aug 22 08:57:45 CEST 2024
On Wed, Aug 21 2024 at 10:35:15 PM +02:00:00, Daniel Cordey via gull
<gull at forum.linux-gull.ch> wrote:
>>
> Je tourne des kernel issus de mainline. J'en suis à 6.11.rc4 !
>
Pareil, de mon expérience c'est ce qui protège le mieux des attaques
ciblées, utilisant des vecteurs par le stack wifi ou même le hardware
wifi (failles hardware layer 1 ou "fonctionnalités" sécuritaires).
> Et j'ai encore les 6.8 que ma distribution insiste pour mettre à
> jour.
>
> Mais j'ai des doutes qu'un kernel 4.19, marqué "longterm", soit
> vraiment maintenu à jour avec tous les backport... Ça me semble
> extrêmement couteux, voire impossible dans certains cas. En fait,
> oui, c'est un support destiné à maintenir une version en l'état,
> mais certaines fonctionnalités qui corrigent des problèmes de
> divers types (performance, scheduler, etc.) ne sont pas intégrés,
> puisque dans des versions plus récentes. Par exemple, une
> technologie qui va limiter l'impact des DDOS risque de n'être
> disponible que dans des versions plus récentes. Ce qui fait que je
> n'adhère toujours pas à ce concept de garder des trucs figés
> pendant des années. Étant un fervent promoteur de Docker et
> Kubernetes, ce concept de "je ne touche à rien puisque ça marche"
> m'interpelle chaque fois. Tout dépend bien sûr du domaine qui est
> servi par une installation avec un tel concept. Mais dans des
> environnements de services avec des exigences de non-stop, cela me
> semble incompatible et contre-productif. Google, FB, Instagram,
> Twitter, etc. sont tous dans le CI/CD, qui est aussi antagoniste avec
> cette approche. Sans compter que, une fois que l'on est arrivé à la
> fin de vie d'une de ces anciennes versions, on passe à quoi ? On
> fait alors le grand saut dans 5.10 pour juste 2 ans ? Et ensuite...
> on recommence le cirque pour 2 ans avec 6.1 ? Sachant que de tels
> changements ne se font pas en quelques minutes, mais sont
> perturbants, à cause de fichiers de config dont la syntaxe à
> changer, etc. J'ai essayé cette stratégie pendant des années, mais
> j'ai fini par arrêter lorsque je me suis rendu compte que ça
> m'apportait plein de problèmes qui m'occupaient plusieurs jours à
> chaque changement. Dans un environnement 24/7 (avec des dizaines de
> milliers de requêtes par jour) c'est injouable. Pour moi, "stable"
> est suffisant et "longterme" renferme des pièges qui te sautent à
> la figure au moment où tu en as le moins besoin, non pas la version
> elle-même, mais le moment où tu dois changer... et là, tu te rends
> compte que tu avais une bombe à retardement.
>
> Ceci n'étant que mon avis très personnel, mais je ne trouve pas
> juste que l'on présente ces versions "longterm" comme le Graal pour
> éviter les problèmes.
>
> dc
More information about the gull
mailing list