Le kernel 4=2e18 peut-il =c3=aatre mis en production sur debian=3f
21 réponses
denis.paris
Sur mes serveurs "techniques" (hors laptop et postes de travail)
j'utilise debian, actuellement en version 9.6 "stretch" (kernel 4.9). Ce
sont essentiellement des services réseaux (dhcp, dns, routeur, montages
NFS pour des sauvegardes). Tous fonctionnent parfaitement, aucune panne
depuis des années, et quand un élément se plante c'est forcément
hardware (ce qui n'arrive pas car la plupart sont virtuels).
Donc la question est simple: j'ai passé une machine de test en "buster",
elle est maintenant en kernel 4.18 et tout semble OK, peut-on migrer les
machines de production?
Attention avec les vieilles machines : ce noyau a un bug (#914495) qui fait planter le module i915 avec les GPU Intel 4 Series (intégré à certains chipsets pour Core 2).
OK, mais ce module est lié au système graphique et les serveurs n'ont pas d'interface graphique. Et puis ce sont des machines virtuelles sous ESX. Mais c'est bon à savoir.
peut-être que mon script n'est plus adapté et qu'il y a une manière plus efficace que de faire "iptables -A INPUT -s -p tcp --dport 22 -j ACCEPT" pour chaque réseau trouvé? En ipv4 il y en a 3570!
ipset.
Je vais jeter un coup d'oeil. Merci
Le 10/12/2018 à 22:52, Pascal Hambourg a écrit :
Attention avec les vieilles machines : ce noyau a un bug (#914495) qui
fait planter le module i915 avec les GPU Intel 4 Series (intégré à
certains chipsets pour Core 2).
OK, mais ce module est lié au système graphique et les serveurs n'ont
pas d'interface graphique. Et puis ce sont des machines virtuelles sous
ESX. Mais c'est bon à savoir.
peut-être que mon script n'est plus adapté et qu'il y a une manière
plus efficace que de faire "iptables -A INPUT -s -p tcp --dport 22 -j
ACCEPT" pour chaque réseau trouvé? En ipv4 il y en a 3570!
Attention avec les vieilles machines : ce noyau a un bug (#914495) qui fait planter le module i915 avec les GPU Intel 4 Series (intégré à certains chipsets pour Core 2).
OK, mais ce module est lié au système graphique et les serveurs n'ont pas d'interface graphique. Et puis ce sont des machines virtuelles sous ESX. Mais c'est bon à savoir.
peut-être que mon script n'est plus adapté et qu'il y a une manière plus efficace que de faire "iptables -A INPUT -s -p tcp --dport 22 -j ACCEPT" pour chaque réseau trouvé? En ipv4 il y en a 3570!
ipset.
Je vais jeter un coup d'oeil. Merci
Pascal Hambourg
Le 10/12/2018 à 23:17, denis.paris a écrit :
Le 10/12/2018 à 22:52, Pascal Hambourg a écrit :
Attention avec les vieilles machines : ce noyau a un bug (#914495) qui fait planter le module i915 avec les GPU Intel 4 Series (intégré à certains chipsets pour Core 2).
OK, mais ce module est lié au système graphique et les serveurs n'ont pas d'interface graphique.
Ce module gère aussi l'affichage en console texte/framebuffer. Dans un système standard, il est chargé automatiquement en présence d'un GPU supporté.
Le 10/12/2018 à 23:17, denis.paris a écrit :
Le 10/12/2018 à 22:52, Pascal Hambourg a écrit :
Attention avec les vieilles machines : ce noyau a un bug (#914495) qui
fait planter le module i915 avec les GPU Intel 4 Series (intégré à
certains chipsets pour Core 2).
OK, mais ce module est lié au système graphique et les serveurs n'ont
pas d'interface graphique.
Ce module gère aussi l'affichage en console texte/framebuffer. Dans un
système standard, il est chargé automatiquement en présence d'un GPU
supporté.
Attention avec les vieilles machines : ce noyau a un bug (#914495) qui fait planter le module i915 avec les GPU Intel 4 Series (intégré à certains chipsets pour Core 2).
OK, mais ce module est lié au système graphique et les serveurs n'ont pas d'interface graphique.
Ce module gère aussi l'affichage en console texte/framebuffer. Dans un système standard, il est chargé automatiquement en présence d'un GPU supporté.
Marc SCHAEFER
denis.paris wrote:
manière plus efficace que de faire "iptables -A INPUT -s -p tcp --dport 22 -j ACCEPT" pour chaque réseau trouvé? En ipv4 il y en a 3570! Pour
Attention, il y a aussi l'option -w qui est nécessaire. Sans cette option, s'il y a des opérations concurrentes sur iptables, ta règle peut ne pas être considérée (il y aura un warning).
denis.paris <denis.paris@free.fr> wrote:
manière plus efficace que de faire "iptables -A INPUT -s -p tcp --dport
22 -j ACCEPT" pour chaque réseau trouvé? En ipv4 il y en a 3570! Pour
Attention, il y a aussi l'option -w qui est nécessaire.
Sans cette option, s'il y a des opérations concurrentes sur iptables,
ta règle peut ne pas être considérée (il y aura un warning).
manière plus efficace que de faire "iptables -A INPUT -s -p tcp --dport 22 -j ACCEPT" pour chaque réseau trouvé? En ipv4 il y en a 3570! Pour
Attention, il y a aussi l'option -w qui est nécessaire. Sans cette option, s'il y a des opérations concurrentes sur iptables, ta règle peut ne pas être considérée (il y aura un warning).
denis.paris
Le 11/12/2018 à 09:11, Marc SCHAEFER a écrit :
denis.paris wrote:
manière plus efficace que de faire "iptables -A INPUT -s réseau -p tcp --dport 22 -j ACCEPT" pour chaque réseau trouvé? En ipv4 il y en a 3570! Pour
Attention, il y a aussi l'option -w qui est nécessaire. Sans cette option, s'il y a des opérations concurrentes sur iptables, ta règle peut ne pas être considérée (il y aura un warning).
Je ne connais pas cette option et je ne la trouve pas dans la doc, tu as un exemple?
Le 11/12/2018 à 09:11, Marc SCHAEFER a écrit :
denis.paris <denis.paris@free.fr> wrote:
manière plus efficace que de faire "iptables -A INPUT -s réseau -p tcp --dport
22 -j ACCEPT" pour chaque réseau trouvé? En ipv4 il y en a 3570! Pour
Attention, il y a aussi l'option -w qui est nécessaire.
Sans cette option, s'il y a des opérations concurrentes sur iptables,
ta règle peut ne pas être considérée (il y aura un warning).
Je ne connais pas cette option et je ne la trouve pas dans la doc, tu as
un exemple?
manière plus efficace que de faire "iptables -A INPUT -s réseau -p tcp --dport 22 -j ACCEPT" pour chaque réseau trouvé? En ipv4 il y en a 3570! Pour
Attention, il y a aussi l'option -w qui est nécessaire. Sans cette option, s'il y a des opérations concurrentes sur iptables, ta règle peut ne pas être considérée (il y aura un warning).
Je ne connais pas cette option et je ne la trouve pas dans la doc, tu as un exemple?
Doug713705
Le 2018-12-11, denis.paris nous expliquait dans fr.comp.os.linux.configuration (<5c0fa29b$0$3520$) :
Le 11/12/2018 à 09:11, Marc SCHAEFER a écrit :
denis.paris wrote:
manière plus efficace que de faire "iptables -A INPUT -s réseau -p tcp --dport 22 -j ACCEPT" pour chaque réseau trouvé? En ipv4 il y en a 3570! Pour
Attention, il y a aussi l'option -w qui est nécessaire. Sans cette option, s'il y a des opérations concurrentes sur iptables, ta règle peut ne pas être considérée (il y aura un warning).
Je ne connais pas cette option et je ne la trouve pas dans la doc, tu as un exemple?
man iptables -w, --wait [seconds] Wait for the xtables lock. To prevent multiple instances of the program from running concurrently, an attempt will be made to obtain an exclusive lock at launch. By default, the program will exit if the lock cannot be obtained. This option will make the program wait (indefinitely or for optional seconds) until the exclusive lock can e obtained. -- J'étais beau comme un passage à niveau et toi tu étais douce Douce comme les roubignolles d'un nouveau-né... -- H.F. Thiéfaine, De l'amour, de l'art ou du cochon ?
Le 2018-12-11, denis.paris nous expliquait dans
fr.comp.os.linux.configuration
(<5c0fa29b$0$3520$426a34cc@news.free.fr>) :
Le 11/12/2018 à 09:11, Marc SCHAEFER a écrit :
denis.paris <denis.paris@free.fr> wrote:
manière plus efficace que de faire "iptables -A INPUT -s réseau -p tcp --dport
22 -j ACCEPT" pour chaque réseau trouvé? En ipv4 il y en a 3570! Pour
Attention, il y a aussi l'option -w qui est nécessaire.
Sans cette option, s'il y a des opérations concurrentes sur iptables,
ta règle peut ne pas être considérée (il y aura un warning).
Je ne connais pas cette option et je ne la trouve pas dans la doc, tu as
un exemple?
man iptables
-w, --wait [seconds]
Wait for the xtables lock. To prevent multiple instances of the program
from running concurrently, an attempt will be made to obtain an exclusive
lock at launch. By default, the program will exit if the lock cannot be
obtained. This option will make the program wait (indefinitely or for optional
seconds) until the exclusive lock can e obtained.
--
J'étais beau comme un passage à niveau et toi tu étais douce
Douce comme les roubignolles d'un nouveau-né...
-- H.F. Thiéfaine, De l'amour, de l'art ou du cochon ?
Le 2018-12-11, denis.paris nous expliquait dans fr.comp.os.linux.configuration (<5c0fa29b$0$3520$) :
Le 11/12/2018 à 09:11, Marc SCHAEFER a écrit :
denis.paris wrote:
manière plus efficace que de faire "iptables -A INPUT -s réseau -p tcp --dport 22 -j ACCEPT" pour chaque réseau trouvé? En ipv4 il y en a 3570! Pour
Attention, il y a aussi l'option -w qui est nécessaire. Sans cette option, s'il y a des opérations concurrentes sur iptables, ta règle peut ne pas être considérée (il y aura un warning).
Je ne connais pas cette option et je ne la trouve pas dans la doc, tu as un exemple?
man iptables -w, --wait [seconds] Wait for the xtables lock. To prevent multiple instances of the program from running concurrently, an attempt will be made to obtain an exclusive lock at launch. By default, the program will exit if the lock cannot be obtained. This option will make the program wait (indefinitely or for optional seconds) until the exclusive lock can e obtained. -- J'étais beau comme un passage à niveau et toi tu étais douce Douce comme les roubignolles d'un nouveau-né... -- H.F. Thiéfaine, De l'amour, de l'art ou du cochon ?
denis.paris
Le 11/12/2018 à 12:42, denis.paris a écrit :
Le 11/12/2018 à 09:11, Marc SCHAEFER a écrit :
denis.paris wrote:
manière plus efficace que de faire "iptables -A INPUT -s réseau -p tcp --dport 22 -j ACCEPT" pour chaque réseau trouvé? En ipv4 il y en a 3570! Pour
Attention, il y a aussi l'option -w qui est nécessaire. Sans cette option, s'il y a des opérations concurrentes sur iptables, ta règle peut ne pas être considérée (il y aura un warning).
Je ne connais pas cette option et je ne la trouve pas dans la doc, tu as un exemple?
OK, j'ai compris que c'est un verrouillage avec une valeur de timeout, mais ça ne peut qu'augmenter le temps de traitement des 7500 règles. À tout hasard j'ai testé avec -w 1 (donc une seconde) et mon script a pris 3 minutes... Ça reste encore acceptable car c'est une seule fois au boot d'une machine qui ne redémarre en principe jamais, mais c'est à rapprocher des 8 secondes avec le kernel 4.9! Quelles opérations concurrentes pourrait-il y avoir sur une machine dont je suis le seul utilisateur?
Le 11/12/2018 à 12:42, denis.paris a écrit :
Le 11/12/2018 à 09:11, Marc SCHAEFER a écrit :
denis.paris <denis.paris@free.fr> wrote:
manière plus efficace que de faire "iptables -A INPUT -s réseau -p
tcp --dport
22 -j ACCEPT" pour chaque réseau trouvé? En ipv4 il y en a 3570! Pour
Attention, il y a aussi l'option -w qui est nécessaire.
Sans cette option, s'il y a des opérations concurrentes sur iptables,
ta règle peut ne pas être considérée (il y aura un warning).
Je ne connais pas cette option et je ne la trouve pas dans la doc, tu as
un exemple?
OK, j'ai compris que c'est un verrouillage avec une valeur de timeout,
mais ça ne peut qu'augmenter le temps de traitement des 7500 règles. À
tout hasard j'ai testé avec -w 1 (donc une seconde) et mon script a pris
3 minutes... Ça reste encore acceptable car c'est une seule fois au boot
d'une machine qui ne redémarre en principe jamais, mais c'est à
rapprocher des 8 secondes avec le kernel 4.9!
Quelles opérations concurrentes pourrait-il y avoir sur une machine dont
je suis le seul utilisateur?
manière plus efficace que de faire "iptables -A INPUT -s réseau -p tcp --dport 22 -j ACCEPT" pour chaque réseau trouvé? En ipv4 il y en a 3570! Pour
Attention, il y a aussi l'option -w qui est nécessaire. Sans cette option, s'il y a des opérations concurrentes sur iptables, ta règle peut ne pas être considérée (il y aura un warning).
Je ne connais pas cette option et je ne la trouve pas dans la doc, tu as un exemple?
OK, j'ai compris que c'est un verrouillage avec une valeur de timeout, mais ça ne peut qu'augmenter le temps de traitement des 7500 règles. À tout hasard j'ai testé avec -w 1 (donc une seconde) et mon script a pris 3 minutes... Ça reste encore acceptable car c'est une seule fois au boot d'une machine qui ne redémarre en principe jamais, mais c'est à rapprocher des 8 secondes avec le kernel 4.9! Quelles opérations concurrentes pourrait-il y avoir sur une machine dont je suis le seul utilisateur?
Marc SCHAEFER
denis.paris wrote:
Je ne connais pas cette option et je ne la trouve pas dans la doc, tu as un exemple?
En fait, elle n'existe pas dans toutes les distributions et version. La mienne: -w, --wait Wait for the xtables lock. To prevent multiple instances of the program from running concurrently, an attempt will be made to obtain an exclusive lock at launch. By default, the program will exit if the lock cannot be obtained. This option will make the program wait until the exclusive lock can be obtained. Voir https://utcc.utoronto.ca/~cks/space/blog/linux/IptablesWOptionFumbles pour une discussion. Peut-être ta version est AVANT le changement, ou ta distribution a décidé de ne pas faire ce changement et de garder le comportement de verrouillage par défaut.
denis.paris <denis.paris@free.fr> wrote:
Je ne connais pas cette option et je ne la trouve pas dans la doc, tu as
un exemple?
En fait, elle n'existe pas dans toutes les distributions et version.
La mienne:
-w, --wait
Wait for the xtables lock. To prevent multiple instances of the
program from running concurrently, an attempt will be made to
obtain an exclusive lock at launch. By default, the program
will exit if the lock cannot be obtained. This option will make
the program wait until the exclusive lock can be obtained.
Voir https://utcc.utoronto.ca/~cks/space/blog/linux/IptablesWOptionFumbles
pour une discussion.
Peut-être ta version est AVANT le changement, ou ta distribution a décidé
de ne pas faire ce changement et de garder le comportement de verrouillage
par défaut.
Je ne connais pas cette option et je ne la trouve pas dans la doc, tu as un exemple?
En fait, elle n'existe pas dans toutes les distributions et version. La mienne: -w, --wait Wait for the xtables lock. To prevent multiple instances of the program from running concurrently, an attempt will be made to obtain an exclusive lock at launch. By default, the program will exit if the lock cannot be obtained. This option will make the program wait until the exclusive lock can be obtained. Voir https://utcc.utoronto.ca/~cks/space/blog/linux/IptablesWOptionFumbles pour une discussion. Peut-être ta version est AVANT le changement, ou ta distribution a décidé de ne pas faire ce changement et de garder le comportement de verrouillage par défaut.
Marc SCHAEFER
denis.paris wrote:
Quelles opérations concurrentes pourrait-il y avoir sur une machine dont je suis le seul utilisateur?
Je n'ai pas creusé: j'ai juste remarqué que sur un serveur avec des règles compliquées, certaines disparaissent aléatoirement et plus avec "-w". Il faut dire que certaines règles sont au boot, d'autres sont configurées quand les interfaces viennent en pre-up, etc. J'ai ensuite mis -w partout, y compris sur mes firewalls embarqués et je n'ai plus jamais eu de problème.
denis.paris <denis.paris@free.fr> wrote:
Quelles opérations concurrentes pourrait-il y avoir sur une machine dont
je suis le seul utilisateur?
Je n'ai pas creusé: j'ai juste remarqué que sur un serveur avec des règles
compliquées, certaines disparaissent aléatoirement et plus avec "-w".
Il faut dire que certaines règles sont au boot, d'autres sont
configurées quand les interfaces viennent en pre-up, etc.
J'ai ensuite mis -w partout, y compris sur mes firewalls
embarqués et je n'ai plus jamais eu de problème.
Quelles opérations concurrentes pourrait-il y avoir sur une machine dont je suis le seul utilisateur?
Je n'ai pas creusé: j'ai juste remarqué que sur un serveur avec des règles compliquées, certaines disparaissent aléatoirement et plus avec "-w". Il faut dire que certaines règles sont au boot, d'autres sont configurées quand les interfaces viennent en pre-up, etc. J'ai ensuite mis -w partout, y compris sur mes firewalls embarqués et je n'ai plus jamais eu de problème.
denis.paris
Le 11/12/2018 à 17:01, Marc SCHAEFER a écrit :
denis.paris wrote:
Quelles opérations concurrentes pourrait-il y avoir sur une machine dont je suis le seul utilisateur?
Je n'ai pas creusé: j'ai juste remarqué que sur un serveur avec des règles compliquées, certaines disparaissent aléatoirement et plus avec "-w". Il faut dire que certaines règles sont au boot, d'autres sont configurées quand les interfaces viennent en pre-up, etc. J'ai ensuite mis -w partout, y compris sur mes firewalls embarqués et je n'ai plus jamais eu de problème.
Je ne vais pas mettre cette option, car dans mon script je commence par tout bloquer, donc la sécurité est assurée, ensuite je viens lire en boucle les 7500 réseaux pour les autoriser un à un. Donc dans le pire des cas, si pour une raison ou une autre une commande "ACCEPT" n'est pas prise en compte, ce n'est pas grave. Il faudrait que j'aie besoin de me connecter à mon réseau depuis celui d'un ami que je ne connais pas encore, ou alors si c'est celui d'un des 2 ou 3 depuis lequel je me connecte habituellement ce serait vraiment pas de bol! :)
Le 11/12/2018 à 17:01, Marc SCHAEFER a écrit :
denis.paris <denis.paris@free.fr> wrote:
Quelles opérations concurrentes pourrait-il y avoir sur une machine dont
je suis le seul utilisateur?
Je n'ai pas creusé: j'ai juste remarqué que sur un serveur avec des règles
compliquées, certaines disparaissent aléatoirement et plus avec "-w".
Il faut dire que certaines règles sont au boot, d'autres sont
configurées quand les interfaces viennent en pre-up, etc.
J'ai ensuite mis -w partout, y compris sur mes firewalls
embarqués et je n'ai plus jamais eu de problème.
Je ne vais pas mettre cette option, car dans mon script je commence par
tout bloquer, donc la sécurité est assurée, ensuite je viens lire en
boucle les 7500 réseaux pour les autoriser un à un. Donc dans le pire
des cas, si pour une raison ou une autre une commande "ACCEPT" n'est pas
prise en compte, ce n'est pas grave. Il faudrait que j'aie besoin de me
connecter à mon réseau depuis celui d'un ami que je ne connais pas
encore, ou alors si c'est celui d'un des 2 ou 3 depuis lequel je me
connecte habituellement ce serait vraiment pas de bol! :)
Quelles opérations concurrentes pourrait-il y avoir sur une machine dont je suis le seul utilisateur?
Je n'ai pas creusé: j'ai juste remarqué que sur un serveur avec des règles compliquées, certaines disparaissent aléatoirement et plus avec "-w". Il faut dire que certaines règles sont au boot, d'autres sont configurées quand les interfaces viennent en pre-up, etc. J'ai ensuite mis -w partout, y compris sur mes firewalls embarqués et je n'ai plus jamais eu de problème.
Je ne vais pas mettre cette option, car dans mon script je commence par tout bloquer, donc la sécurité est assurée, ensuite je viens lire en boucle les 7500 réseaux pour les autoriser un à un. Donc dans le pire des cas, si pour une raison ou une autre une commande "ACCEPT" n'est pas prise en compte, ce n'est pas grave. Il faudrait que j'aie besoin de me connecter à mon réseau depuis celui d'un ami que je ne connais pas encore, ou alors si c'est celui d'un des 2 ou 3 depuis lequel je me connecte habituellement ce serait vraiment pas de bol! :)
Doug713705
Le 2018-12-11, denis.paris nous expliquait dans fr.comp.os.linux.configuration (<5c0fe426$0$21587$) :
si pour une raison ou une autre une commande "ACCEPT" n'est pas prise en compte, ce n'est pas grave. Il faudrait que j'aie besoin de me connecter à mon réseau depuis celui d'un ami que je ne connais pas encore, ou alors si c'est celui d'un des 2 ou 3 depuis lequel je me connecte habituellement ce serait vraiment pas de bol! :)
Compter sur la chance pour que ça tombe en marche me semble être une stratégie risquée. -- En ce temps-là, le rien s'appelait quotidien Et nous allions pointer dans les jobs interdits. Dans les musiques blêmes, dans les sombres parfums Dans les dédales obscurs où plane la folie. -- H.F. Thiéfaine, Exil Sur planète fantôme
Le 2018-12-11, denis.paris nous expliquait dans
fr.comp.os.linux.configuration
(<5c0fe426$0$21587$426a74cc@news.free.fr>) :
si pour une raison ou une autre une commande "ACCEPT" n'est pas
prise en compte, ce n'est pas grave. Il faudrait que j'aie besoin de me
connecter à mon réseau depuis celui d'un ami que je ne connais pas
encore, ou alors si c'est celui d'un des 2 ou 3 depuis lequel je me
connecte habituellement ce serait vraiment pas de bol! :)
Compter sur la chance pour que ça tombe en marche me semble être une
stratégie risquée.
--
En ce temps-là, le rien s'appelait quotidien
Et nous allions pointer dans les jobs interdits.
Dans les musiques blêmes, dans les sombres parfums
Dans les dédales obscurs où plane la folie.
-- H.F. Thiéfaine, Exil Sur planète fantôme
Le 2018-12-11, denis.paris nous expliquait dans fr.comp.os.linux.configuration (<5c0fe426$0$21587$) :
si pour une raison ou une autre une commande "ACCEPT" n'est pas prise en compte, ce n'est pas grave. Il faudrait que j'aie besoin de me connecter à mon réseau depuis celui d'un ami que je ne connais pas encore, ou alors si c'est celui d'un des 2 ou 3 depuis lequel je me connecte habituellement ce serait vraiment pas de bol! :)
Compter sur la chance pour que ça tombe en marche me semble être une stratégie risquée. -- En ce temps-là, le rien s'appelait quotidien Et nous allions pointer dans les jobs interdits. Dans les musiques blêmes, dans les sombres parfums Dans les dédales obscurs où plane la folie. -- H.F. Thiéfaine, Exil Sur planète fantôme
