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?
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?
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?
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 ?????????????
--
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 ?????????????
--
if everything is working , don't try to fix it
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
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
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 à 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...
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...
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...
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.
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.
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.
là il faudra qu'on m'explique
Production, tout marche bien , distrib maintenue en terme de sécurité
Pourquoi changer ?????????????
là il faudra qu'on m'explique
Production, tout marche bien , distrib maintenue en terme de sécurité
Pourquoi changer ?????????????
là il faudra qu'on m'explique
Production, tout marche bien , distrib maintenue en terme de sécurité
Pourquoi changer ?????????????
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 ?
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?
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!)
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!)
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!)
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!