[gull] [SPAM] Re: [SPAM] Re: Abus réseaux
Marc SCHAEFER
schaefer at alphanet.ch
Fri Aug 23 07:25:38 CEST 2024
Hello,
On Wed, Aug 21, 2024 at 10:35:15PM +0200, Daniel Cordey via gull wrote:
> 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.
Un des liens que j'avais mentionné dit bien que plus le kernel est
ancien, moins il est activement maintenu. Cela signifie que la
distribution qui veut garantir LTS aura plus de travail.
Du côté Debian, il y a des mainteneurs kernel. Et voici apparemment
un tableau récapitulatif de leurs tâches:
https://repology.org/maintainer/debian-kernel%40lists.debian.org
C'est assez euh divers et varié, il semblerait.
Très concrètement, depuis fin juin, il n'y a normalement plus personne
qui s'occupe des kernels 4.19 (fin du support de buster). Par contre,
chez Extended LTS, vu que buster est supporté jusqu'en 2029.
Quand on consulte [1] on voit même que des kernels bien plus anciens
sont potentiellement encore supportés vu que Debian 8 jessie [2] est
supporté jusqu'en juin 2025, par exemple: kernel: Linux 3.16 !!!
Après, Extended LTS ne supporte pas forcément tout. La page
https://www.freexian.com/lts/extended/docs/debian-8-support/ indique par
exemple les limitations: en ce qui concerne le kernel, ce n'est pas 3.16
qui est backporté mais un 4.19, puis aujourd'hui un 5.10.
Effectivement, ceux qui tournent des conteneurs (lxc, docker, etc)
savent bien que l'essentiel est d'avoir un kernel, sur le host,
compatible avec la libc et les outils du conteneur: en ce qui
me concerne, avec un conteneur bullseye (kernel 5.10), aucun
souci pour tourner du buster, bullseye et bookworm en conteneur.
Mais avec un buster 4.19, bookworm se comporte assez mal en
conteneur par exemple. De mémoire, buster supportait aussi 5.x
déjà quand elle était stable.
Et voici un exemple d'annonce de sécurité kernel pour oldstable actuelle
(bullseye): https://lists.debian.org/debian-security-announce/2024/msg00159.html
Il y a tous les CVE (précédemment, il y avait même un résumé par CVE,
qu'on avait posté et commenté ici même).
Et il y a le tracker:
https://security-tracker.debian.org/tracker/source-package/linux (avec
la vue d'ensemble de tous les CVE et qu'est-ce qui est patché ou non
pour quelle release).
Par exemple cette attaque locale n'est encore patchée nulle part:
https://security-tracker.debian.org/tracker/CVE-2024-43882
> 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.
Non, les versions long-term représentent une bonne solution dans des
contextes précis. Et il faut à mon avis différencier host et conteneur:
avec les solutions de conteneurisation actuelle, migrer des hosts ne
devrait plus être une tâche aussi difficile dès lors qu'on a prévu
la chose. Et les conteneurs peuvent attendre un peu plus longtemps,
ou être déployés semi-automatiquement: si leur granularité est faible,
il y a un seul service à adapter.
Par exemple il y a deux mois, plutôt que de mettre à jour un conteneur
mammouth, j'ai isolé un serveur de téléphonie Asterisk dans un autre
conteneur, réglé les aspects de sécurité et performance réseau, et
porté les diverses applications web, scripts de surveillance, etc.
Il a fallu aussi migrer de chan_sip à chan_pjsip (chan_sip n'étant
plus supporté). Le travail de pré-migration a été conséquent, mais
un petit test, puis un déploiement final, ont été fait en quelques
minutes.
J'ai procédé de même pour RT et mailman3.
En ce qui me concerne, j'essaie plutôt d'être dans stable & oldstable
Debian: ce n'est que pour des applications particulières que j'apprécie
le support LTS, et je le soutiens par un don annuel. Par contre, le
support ELTS je ne l'ai jamais utilisé -- un client qui est abonné m'a
dit par exemple que cela pouvait être pratique pour supporter UN package
le temps de faire la migration. Il semblerait toutefois que des
"gros comptes" paient d'assez énormes sommes pour supporter des
versions super-obsolètes de Debian, ils doivent avoir leurs
raisons! Je doute par contre que cela soient des bastions hosts
accessible directement d'Internet.
[1] https://www.freexian.com/lts/extended/
[2] https://wiki.debian.org/DebianJessie
More information about the gull
mailing list