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?
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?
C'est quel kernel 4.18 ? Celui 4.18.0-xx ou 4.18.xx ? -- http://zetrader.info & http://zetrader.fr http://aribaut.com - http://zeforums.com
Le 10/12/2018 à 00:09, denis.paris a écrit :
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?
C'est quel kernel 4.18 ?
Celui 4.18.0-xx ou 4.18.xx ?
--
http://zetrader.info & http://zetrader.fr
http://aribaut.com - http://zeforums.com
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?
C'est quel kernel 4.18 ? Celui 4.18.0-xx ou 4.18.xx ? -- http://zetrader.info & http://zetrader.fr http://aribaut.com - http://zeforums.com
Philippe Weill
Le 10/12/2018 à 00:09, denis.paris a écrit :
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?
là il faudra qu'on m'explique Production, tout marche bien , distrib maintenue en terme de sécurité Pourquoi changer ????????????? -- if everything is working , don't try to fix it
Le 10/12/2018 à 00:09, denis.paris a écrit :
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?
là il faudra qu'on m'explique
Production, tout marche bien , distrib maintenue en terme de sécurité
Pourquoi changer ?????????????
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?
là il faudra qu'on m'explique Production, tout marche bien , distrib maintenue en terme de sécurité Pourquoi changer ????????????? -- if everything is working , don't try to fix it
Pierre www.aribaut.com
Le 10/12/2018 à 06:51, Philippe Weill a écrit :
Le 10/12/2018 à 00:09, denis.paris a écrit :
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?
là il faudra qu'on m'explique Production, tout marche bien , distrib maintenue en terme de sécurité Pourquoi changer ????????????? -- if everything is working , don't try to fix it
J'avoue, si c'est pour du travail, autant rester sur du sûr, surtout si "tout fonctionne parfaitement" quel est le but de changer ? -- http://zetrader.info & http://zetrader.fr http://aribaut.com - http://zeforums.com
Le 10/12/2018 à 06:51, Philippe Weill a écrit :
Le 10/12/2018 à 00:09, denis.paris a écrit :
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?
là il faudra qu'on m'explique
Production, tout marche bien , distrib maintenue en terme de sécurité
Pourquoi changer ?????????????
--
if everything is working , don't try to fix it
J'avoue, si c'est pour du travail, autant rester sur du sûr, surtout si
"tout fonctionne parfaitement" quel est le but de changer ?
--
http://zetrader.info & http://zetrader.fr
http://aribaut.com - http://zeforums.com
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?
là il faudra qu'on m'explique Production, tout marche bien , distrib maintenue en terme de sécurité Pourquoi changer ????????????? -- if everything is working , don't try to fix it
J'avoue, si c'est pour du travail, autant rester sur du sûr, surtout si "tout fonctionne parfaitement" quel est le but de changer ? -- http://zetrader.info & http://zetrader.fr http://aribaut.com - http://zeforums.com
denis.paris
Le 10/12/2018 à 06:51, Philippe Weill a écrit :
là il faudra qu'on m'explique Production, tout marche bien , distrib maintenue en terme de sécurité Pourquoi changer ????????????? -- if everything is working , don't try to fix it
Je me doutais de la remarque, j'ai failli mettre un paragraphe supplémentaire pour la désamorcer par avance mais je n'ai pas voulu alourdir le post initial. Évidemment! J'applique d'ailleurs ce principe depuis des années, et même pour mon PC bureautique j'en reste à xubuntu LTS, je ne suis passé à la version 18.04 que récemment et sur le noteboot de voyage j'étais encore en 16-04 il n'y a pas très longtemps. Et ubuntu n'a pas une politique de mise à jour du kernel très agressive", et ça me va... Et pour en rajouter encore une couche, autant pour un PC bureau on peut vouloir bénéficier d'applications récentes, autant pour une machine sans interface graphique qui n'exécute que des services réseaux cela n'a pas d'importance dès lors que ces services font le boulot. Donc la question serait plutôt: "Y a-t-il des machines (évidemment non critiques) qui testent le noyau 4.18 et dont les administrateurs estiment qu'elles pourraient passer en production?" Selon ce que j'ai pu lire ici ou là dans la presse, ce noyau serait une avancée importante en matière de performance et de sécurité, donc il faut bien qu'on se pose la question à un moment donné... Sinon pourquoi continuer à développer! Cette question s'adresse bien-sûr à ceux qui ont une idée sur la question... mais je ne veux vexer personne! ;)
Le 10/12/2018 à 06:51, Philippe Weill a écrit :
là il faudra qu'on m'explique
Production, tout marche bien , distrib maintenue en terme de sécurité
Pourquoi changer ?????????????
--
if everything is working , don't try to fix it
Je me doutais de la remarque, j'ai failli mettre un paragraphe
supplémentaire pour la désamorcer par avance mais je n'ai pas voulu
alourdir le post initial.
Évidemment! J'applique d'ailleurs ce principe depuis des années, et même
pour mon PC bureautique j'en reste à xubuntu LTS, je ne suis passé à la
version 18.04 que récemment et sur le noteboot de voyage j'étais encore
en 16-04 il n'y a pas très longtemps. Et ubuntu n'a pas une politique de
mise à jour du kernel très agressive", et ça me va...
Et pour en rajouter encore une couche, autant pour un PC bureau on peut
vouloir bénéficier d'applications récentes, autant pour une machine sans
interface graphique qui n'exécute que des services réseaux cela n'a pas
d'importance dès lors que ces services font le boulot.
Donc la question serait plutôt: "Y a-t-il des machines (évidemment non
critiques) qui testent le noyau 4.18 et dont les administrateurs
estiment qu'elles pourraient passer en production?"
Selon ce que j'ai pu lire ici ou là dans la presse, ce noyau serait une
avancée importante en matière de performance et de sécurité, donc il
faut bien qu'on se pose la question à un moment donné... Sinon pourquoi
continuer à développer!
Cette question s'adresse bien-sûr à ceux qui ont une idée sur la
question... mais je ne veux vexer personne! ;)
là il faudra qu'on m'explique Production, tout marche bien , distrib maintenue en terme de sécurité Pourquoi changer ????????????? -- if everything is working , don't try to fix it
Je me doutais de la remarque, j'ai failli mettre un paragraphe supplémentaire pour la désamorcer par avance mais je n'ai pas voulu alourdir le post initial. Évidemment! J'applique d'ailleurs ce principe depuis des années, et même pour mon PC bureautique j'en reste à xubuntu LTS, je ne suis passé à la version 18.04 que récemment et sur le noteboot de voyage j'étais encore en 16-04 il n'y a pas très longtemps. Et ubuntu n'a pas une politique de mise à jour du kernel très agressive", et ça me va... Et pour en rajouter encore une couche, autant pour un PC bureau on peut vouloir bénéficier d'applications récentes, autant pour une machine sans interface graphique qui n'exécute que des services réseaux cela n'a pas d'importance dès lors que ces services font le boulot. Donc la question serait plutôt: "Y a-t-il des machines (évidemment non critiques) qui testent le noyau 4.18 et dont les administrateurs estiment qu'elles pourraient passer en production?" Selon ce que j'ai pu lire ici ou là dans la presse, ce noyau serait une avancée importante en matière de performance et de sécurité, donc il faut bien qu'on se pose la question à un moment donné... Sinon pourquoi continuer à développer! Cette question s'adresse bien-sûr à ceux qui ont une idée sur la question... mais je ne veux vexer personne! ;)
Pierre www.aribaut.com
Le 10/12/2018 à 09:58, denis.paris a écrit :
Le 10/12/2018 à 06:51, Philippe Weill a écrit :
là il faudra qu'on m'explique Production, tout marche bien , distrib maintenue en terme de sécurité Pourquoi changer ????????????? -- if everything is working , don't try to fix it
Je me doutais de la remarque, j'ai failli mettre un paragraphe supplémentaire pour la désamorcer par avance mais je n'ai pas voulu alourdir le post initial. Évidemment! J'applique d'ailleurs ce principe depuis des années, et même pour mon PC bureautique j'en reste à xubuntu LTS, je ne suis passé à la version 18.04 que récemment et sur le noteboot de voyage j'étais encore en 16-04 il n'y a pas très longtemps. Et ubuntu n'a pas une politique de mise à jour du kernel très agressive", et ça me va...
J'avais lu que Ubuntu (et dérivés) utiliseront le kernel 4.18 en février 2019, donc tu ne t'avances pas de beaucoup en voulant utiliser le kernel 4.18. La question c'est plutôt (dans ton cas), pourquoi ne pas attendre février 2019 pour avoir "naturellement" le kernel 4.18 ? D'autant plus que d'ici là, il sera encore un peu plus corrigé (je parle de la version en 4.18.0-xx pour debian, ubuntu et dérivés), l'autre version générique 4.18.xx est en fin de vie. -- http://zetrader.info & http://zetrader.fr http://aribaut.com - http://zeforums.com
Le 10/12/2018 à 09:58, denis.paris a écrit :
Le 10/12/2018 à 06:51, Philippe Weill a écrit :
là il faudra qu'on m'explique
Production, tout marche bien , distrib maintenue en terme de sécurité
Pourquoi changer ?????????????
--
if everything is working , don't try to fix it
Je me doutais de la remarque, j'ai failli mettre un paragraphe
supplémentaire pour la désamorcer par avance mais je n'ai pas voulu
alourdir le post initial.
Évidemment! J'applique d'ailleurs ce principe depuis des années, et même
pour mon PC bureautique j'en reste à xubuntu LTS, je ne suis passé à la
version 18.04 que récemment et sur le noteboot de voyage j'étais encore
en 16-04 il n'y a pas très longtemps. Et ubuntu n'a pas une politique de
mise à jour du kernel très agressive", et ça me va...
J'avais lu que Ubuntu (et dérivés) utiliseront le kernel 4.18 en février
2019, donc tu ne t'avances pas de beaucoup en voulant utiliser le kernel
4.18.
La question c'est plutôt (dans ton cas), pourquoi ne pas attendre
février 2019 pour avoir "naturellement" le kernel 4.18 ?
D'autant plus que d'ici là, il sera encore un peu plus corrigé (je parle
de la version en 4.18.0-xx pour debian, ubuntu et dérivés), l'autre
version générique 4.18.xx est en fin de vie.
--
http://zetrader.info & http://zetrader.fr
http://aribaut.com - http://zeforums.com
là il faudra qu'on m'explique Production, tout marche bien , distrib maintenue en terme de sécurité Pourquoi changer ????????????? -- if everything is working , don't try to fix it
Je me doutais de la remarque, j'ai failli mettre un paragraphe supplémentaire pour la désamorcer par avance mais je n'ai pas voulu alourdir le post initial. Évidemment! J'applique d'ailleurs ce principe depuis des années, et même pour mon PC bureautique j'en reste à xubuntu LTS, je ne suis passé à la version 18.04 que récemment et sur le noteboot de voyage j'étais encore en 16-04 il n'y a pas très longtemps. Et ubuntu n'a pas une politique de mise à jour du kernel très agressive", et ça me va...
J'avais lu que Ubuntu (et dérivés) utiliseront le kernel 4.18 en février 2019, donc tu ne t'avances pas de beaucoup en voulant utiliser le kernel 4.18. La question c'est plutôt (dans ton cas), pourquoi ne pas attendre février 2019 pour avoir "naturellement" le kernel 4.18 ? D'autant plus que d'ici là, il sera encore un peu plus corrigé (je parle de la version en 4.18.0-xx pour debian, ubuntu et dérivés), l'autre version générique 4.18.xx est en fin de vie. -- http://zetrader.info & http://zetrader.fr http://aribaut.com - http://zeforums.com
denis.paris
Le 10/12/2018 à 10:32, Pierre www.aribaut.com a écrit :
Le 10/12/2018 à 09:58, denis.paris a écrit :
Le 10/12/2018 à 06:51, Philippe Weill a écrit :
là il faudra qu'on m'explique Production, tout marche bien , distrib maintenue en terme de sécurité Pourquoi changer ????????????? -- if everything is working , don't try to fix it
Je me doutais de la remarque, j'ai failli mettre un paragraphe supplémentaire pour la désamorcer par avance mais je n'ai pas voulu alourdir le post initial. Évidemment! J'applique d'ailleurs ce principe depuis des années, et même pour mon PC bureautique j'en reste à xubuntu LTS, je ne suis passé à la version 18.04 que récemment et sur le noteboot de voyage j'étais encore en 16-04 il n'y a pas très longtemps. Et ubuntu n'a pas une politique de mise à jour du kernel très agressive", et ça me va...
J'avais lu que Ubuntu (et dérivés) utiliseront le kernel 4.18 en février 2019, donc tu ne t'avances pas de beaucoup en voulant utiliser le kernel 4.18. La question c'est plutôt (dans ton cas), pourquoi ne pas attendre février 2019 pour avoir "naturellement" le kernel 4.18 ? D'autant plus que d'ici là, il sera encore un peu plus corrigé (je parle de la version en 4.18.0-xx pour debian, ubuntu et dérivés), l'autre version générique 4.18.xx est en fin de vie.
Pour ubuntu je n'utilise que les LTS. Et la question concerne debian (la version la plus stable).
Le 10/12/2018 à 10:32, Pierre www.aribaut.com a écrit :
Le 10/12/2018 à 09:58, denis.paris a écrit :
Le 10/12/2018 à 06:51, Philippe Weill a écrit :
là il faudra qu'on m'explique
Production, tout marche bien , distrib maintenue en terme de sécurité
Pourquoi changer ?????????????
--
if everything is working , don't try to fix it
Je me doutais de la remarque, j'ai failli mettre un paragraphe
supplémentaire pour la désamorcer par avance mais je n'ai pas voulu
alourdir le post initial.
Évidemment! J'applique d'ailleurs ce principe depuis des années, et
même pour mon PC bureautique j'en reste à xubuntu LTS, je ne suis
passé à la version 18.04 que récemment et sur le noteboot de voyage
j'étais encore en 16-04 il n'y a pas très longtemps. Et ubuntu n'a pas
une politique de mise à jour du kernel très agressive", et ça me va...
J'avais lu que Ubuntu (et dérivés) utiliseront le kernel 4.18 en février
2019, donc tu ne t'avances pas de beaucoup en voulant utiliser le kernel
4.18.
La question c'est plutôt (dans ton cas), pourquoi ne pas attendre
février 2019 pour avoir "naturellement" le kernel 4.18 ?
D'autant plus que d'ici là, il sera encore un peu plus corrigé (je parle
de la version en 4.18.0-xx pour debian, ubuntu et dérivés), l'autre
version générique 4.18.xx est en fin de vie.
Pour ubuntu je n'utilise que les LTS. Et la question concerne debian (la
version la plus stable).
Le 10/12/2018 à 10:32, Pierre www.aribaut.com a écrit :
Le 10/12/2018 à 09:58, denis.paris a écrit :
Le 10/12/2018 à 06:51, Philippe Weill a écrit :
là il faudra qu'on m'explique Production, tout marche bien , distrib maintenue en terme de sécurité Pourquoi changer ????????????? -- if everything is working , don't try to fix it
Je me doutais de la remarque, j'ai failli mettre un paragraphe supplémentaire pour la désamorcer par avance mais je n'ai pas voulu alourdir le post initial. Évidemment! J'applique d'ailleurs ce principe depuis des années, et même pour mon PC bureautique j'en reste à xubuntu LTS, je ne suis passé à la version 18.04 que récemment et sur le noteboot de voyage j'étais encore en 16-04 il n'y a pas très longtemps. Et ubuntu n'a pas une politique de mise à jour du kernel très agressive", et ça me va...
J'avais lu que Ubuntu (et dérivés) utiliseront le kernel 4.18 en février 2019, donc tu ne t'avances pas de beaucoup en voulant utiliser le kernel 4.18. La question c'est plutôt (dans ton cas), pourquoi ne pas attendre février 2019 pour avoir "naturellement" le kernel 4.18 ? D'autant plus que d'ici là, il sera encore un peu plus corrigé (je parle de la version en 4.18.0-xx pour debian, ubuntu et dérivés), l'autre version générique 4.18.xx est en fin de vie.
Pour ubuntu je n'utilise que les LTS. Et la question concerne debian (la version la plus stable).
Nicolas George
Philippe Weill , dans le message <pukut8$gju$, a écrit :
là il faudra qu'on m'explique Production, tout marche bien , distrib maintenue en terme de sécurité Pourquoi changer ?????????????
Parce qu'un jour ou l'autre il faudra changer : un jour ou l'autre, le matos va casser, ou les besoins vont évoluer, ou les protocoles réseau vont être changés, et il sera nécessaire de changer. Et puisqu'il est nécessaire de changer, que penses-tu qui a plus de chances de bien se passer : - faire quinze ans de changements dans l'urgence ; - faire deux ans de changements tranquillement quand on en a le temps, à chaque fois ?
Philippe Weill , dans le message <pukut8$gju$1@shakotay.alphanet.ch>, a
écrit :
là il faudra qu'on m'explique
Production, tout marche bien , distrib maintenue en terme de sécurité
Pourquoi changer ?????????????
Parce qu'un jour ou l'autre il faudra changer : un jour ou l'autre, le
matos va casser, ou les besoins vont évoluer, ou les protocoles réseau
vont être changés, et il sera nécessaire de changer.
Et puisqu'il est nécessaire de changer, que penses-tu qui a plus de
chances de bien se passer :
- faire quinze ans de changements dans l'urgence ;
- faire deux ans de changements tranquillement quand on en a le temps, à
chaque fois ?
Philippe Weill , dans le message <pukut8$gju$, a écrit :
là il faudra qu'on m'explique Production, tout marche bien , distrib maintenue en terme de sécurité Pourquoi changer ?????????????
Parce qu'un jour ou l'autre il faudra changer : un jour ou l'autre, le matos va casser, ou les besoins vont évoluer, ou les protocoles réseau vont être changés, et il sera nécessaire de changer. Et puisqu'il est nécessaire de changer, que penses-tu qui a plus de chances de bien se passer : - faire quinze ans de changements dans l'urgence ; - faire deux ans de changements tranquillement quand on en a le temps, à chaque fois ?
Philippe Weill
Le 10/12/2018 à 10:50, Nicolas George a écrit :
Philippe Weill , dans le message <pukut8$gju$, a écrit :
là il faudra qu'on m'explique Production, tout marche bien , distrib maintenue en terme de sécurité Pourquoi changer ?????????????
Parce qu'un jour ou l'autre il faudra changer : un jour ou l'autre, le matos va casser, ou les besoins vont évoluer, ou les protocoles réseau vont être changés, et il sera nécessaire de changer. Et puisqu'il est nécessaire de changer, que penses-tu qui a plus de chances de bien se passer : - faire quinze ans de changements dans l'urgence ; - faire deux ans de changements tranquillement quand on en a le temps, à chaque fois ?
attention je suis pas contre le changement par contre basculer la prod sur une distribution qui n'est pas encore en 'feature freeze' ca me semble nettement plus osé
Le 10/12/2018 à 10:50, Nicolas George a écrit :
Philippe Weill , dans le message <pukut8$gju$1@shakotay.alphanet.ch>, a
écrit :
là il faudra qu'on m'explique
Production, tout marche bien , distrib maintenue en terme de sécurité
Pourquoi changer ?????????????
Parce qu'un jour ou l'autre il faudra changer : un jour ou l'autre, le
matos va casser, ou les besoins vont évoluer, ou les protocoles réseau
vont être changés, et il sera nécessaire de changer.
Et puisqu'il est nécessaire de changer, que penses-tu qui a plus de
chances de bien se passer :
- faire quinze ans de changements dans l'urgence ;
- faire deux ans de changements tranquillement quand on en a le temps, à
chaque fois ?
attention je suis pas contre le changement
par contre basculer la prod sur une distribution qui n'est pas encore en 'feature freeze'
ca me semble nettement plus osé
Philippe Weill , dans le message <pukut8$gju$, a écrit :
là il faudra qu'on m'explique Production, tout marche bien , distrib maintenue en terme de sécurité Pourquoi changer ?????????????
Parce qu'un jour ou l'autre il faudra changer : un jour ou l'autre, le matos va casser, ou les besoins vont évoluer, ou les protocoles réseau vont être changés, et il sera nécessaire de changer. Et puisqu'il est nécessaire de changer, que penses-tu qui a plus de chances de bien se passer : - faire quinze ans de changements dans l'urgence ; - faire deux ans de changements tranquillement quand on en a le temps, à chaque fois ?
attention je suis pas contre le changement par contre basculer la prod sur une distribution qui n'est pas encore en 'feature freeze' ca me semble nettement plus osé
denis.paris
Le 10/12/2018 à 00:09, denis.paris a écrit :
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?
Finalement, j'ai décidé de faire l'upgrade, en prenant toutes les précautions nécessaires (sauvegarde complète à froid des systèmes): changement des "sources-list", environ 350 paquets mis à jour, et 15 mn plus tard les deux machines sont opérationnelles en kernel 4.18.0-3 (7 minutes par machine!) Seule surprise: un temps de démarrage beaucoup plus long pour la machine qui sert de point d'entrée du réseau (firewall). C'est un script maison qui prenait environ 8 secondes avec l'ancienne machine et qui est passé maintenant à 50 secondes, et qui est chargé de n'autoriser que les réseaux français (c'est mon côté chauvin, et j'en avais assez de voir les déferlements de scan depuis la Chine ou le Brésil). Ce script commence par récupérer les adresses de tous les réseaux français, ce qui se fait très rapidement, puis implémente des règles iptables. Cela fonctionne car au final le résultat est le même, mais iptables à l'air d'être beaucoup plus lent. Comme cette fonction est implémentée directement dans le noyau, j'en déduis que la cause est dans le noyau 4.18. Il semble que ce soit à cause renforcement de la sécurité au niveau de bfilter, 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! Pour l'ipv6 c'est plus simple, je bloque tout et je n'autorise que 2 ou 3 réseaux.
Le 10/12/2018 à 00:09, denis.paris a écrit :
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?
Finalement, j'ai décidé de faire l'upgrade, en prenant toutes les
précautions nécessaires (sauvegarde complète à froid des systèmes):
changement des "sources-list", environ 350 paquets mis à jour, et 15 mn
plus tard les deux machines sont opérationnelles en kernel 4.18.0-3 (7
minutes par machine!)
Seule surprise: un temps de démarrage beaucoup plus long pour la machine
qui sert de point d'entrée du réseau (firewall). C'est un script maison
qui prenait environ 8 secondes avec l'ancienne machine et qui est passé
maintenant à 50 secondes, et qui est chargé de n'autoriser que les
réseaux français (c'est mon côté chauvin, et j'en avais assez de voir
les déferlements de scan depuis la Chine ou le Brésil).
Ce script commence par récupérer les adresses de tous les réseaux
français, ce qui se fait très rapidement, puis implémente des règles
iptables. Cela fonctionne car au final le résultat est le même, mais
iptables à l'air d'être beaucoup plus lent. Comme cette fonction est
implémentée directement dans le noyau, j'en déduis que la cause est dans
le noyau 4.18.
Il semble que ce soit à cause renforcement de la sécurité au niveau de
bfilter, 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! Pour
l'ipv6 c'est plus simple, je bloque tout et je n'autorise que 2 ou 3
réseaux.
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?
Finalement, j'ai décidé de faire l'upgrade, en prenant toutes les précautions nécessaires (sauvegarde complète à froid des systèmes): changement des "sources-list", environ 350 paquets mis à jour, et 15 mn plus tard les deux machines sont opérationnelles en kernel 4.18.0-3 (7 minutes par machine!) Seule surprise: un temps de démarrage beaucoup plus long pour la machine qui sert de point d'entrée du réseau (firewall). C'est un script maison qui prenait environ 8 secondes avec l'ancienne machine et qui est passé maintenant à 50 secondes, et qui est chargé de n'autoriser que les réseaux français (c'est mon côté chauvin, et j'en avais assez de voir les déferlements de scan depuis la Chine ou le Brésil). Ce script commence par récupérer les adresses de tous les réseaux français, ce qui se fait très rapidement, puis implémente des règles iptables. Cela fonctionne car au final le résultat est le même, mais iptables à l'air d'être beaucoup plus lent. Comme cette fonction est implémentée directement dans le noyau, j'en déduis que la cause est dans le noyau 4.18. Il semble que ce soit à cause renforcement de la sécurité au niveau de bfilter, 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! Pour l'ipv6 c'est plus simple, je bloque tout et je n'autorise que 2 ou 3 réseaux.
Pascal Hambourg
Le 10/12/2018 à 18:59, denis.paris a écrit :
Finalement, j'ai décidé de faire l'upgrade, en prenant toutes les précautions nécessaires (sauvegarde complète à froid des systèmes): changement des "sources-list", environ 350 paquets mis à jour, et 15 mn plus tard les deux machines sont opérationnelles en kernel 4.18.0-3 (7 minutes par machine!)
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).
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.
Le 10/12/2018 à 18:59, denis.paris a écrit :
Finalement, j'ai décidé de faire l'upgrade, en prenant toutes les
précautions nécessaires (sauvegarde complète à froid des systèmes):
changement des "sources-list", environ 350 paquets mis à jour, et 15 mn
plus tard les deux machines sont opérationnelles en kernel 4.18.0-3 (7
minutes par machine!)
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).
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!
Finalement, j'ai décidé de faire l'upgrade, en prenant toutes les précautions nécessaires (sauvegarde complète à froid des systèmes): changement des "sources-list", environ 350 paquets mis à jour, et 15 mn plus tard les deux machines sont opérationnelles en kernel 4.18.0-3 (7 minutes par machine!)
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).
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!
