Re: [SPAM] Re: [SPAM] Re: Abus rése aux

On Wed, Aug 21 2024 at 10:35:15 PM +02:00:00, Daniel Cordey via gull 
<[email protected]> 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


_______________________________________________
gull mailing list
[email protected]
https://forum.linux-gull.ch/mailman/listinfo/gull