politique de patches

Le
Swaz
Bonjour,

Je me demandais quelle etait la tendance quant au passage de patches sur
un serveur UNIX. Si on suit strictement les READMEs (je suis sous
Solaris), certains patches *doivent* etre passes en single-user avec
reboot immediat. Mon but etant de minimiser l'arret de production sur
mes serveurs, j'aimerais avoir votre avis sur les risques encourus a
transgresser effrontement ces "lois".

Par exemple, que risque-je a passer un (ou plusieurs) patch kernel ou
libthread en mode multi user, sans prevenir personne, en planifiant de
rebooter quand j'aurais le temps ?
Le serveur est-il stable entre l'application des patches "critiques" et
le reboot ?
Et avec 200 patches ?

Je sais que beaucoup d'admins passent leurs patches a la volee, les
accumulent, et rebootent longtemps apres. C'est evidemment tres pratique
et ca augmente l'uptime, mais est-ce vraiment risque ?

Vos conseils sont les bienvenus.

Seb.
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Rakotomandimby Mihamina
Le #453254
Swaz wrote:
Bonjour,


Bonjour
Je te donne mon contexte : Je suis encore un petit etudiant, et bon ...
bref l'obligation de disponibilite d'un serveur a 99.999% , je ne l'ai pas .

Le serveur est-il stable entre l'application des patches "critiques" et
le reboot ?


patches critiques , a mon avis oui ... mais tout depends de ce qu'on
appelle critique .

Et avec 200 patches ?


c'est carrement une mise a jour de tout le systeme la ...

Tant que je sache , certains binaires sont charges en RAM pour ne plus y
etre deloges ... si tu applique les patches, c'est a leur copie situee
sur le disque dur .... il y a des chances pour que ce patche ne soit pas
pris en compte .

Si ton patch fais varier la taille du binaire ( ce qui est quasiment sur
) le systeme peut ne pas etre au courant du changement de taille dudit
binaire , et donc peut planter en tentant de le charger
Si au boot precedent le systeme s'est informe de la taille de ce fichier
et que tu le patche
Et que le systeme m'en est pas informe ...

Je sais que beaucoup d'admins passent leurs patches a la volee, les
accumulent, et rebootent longtemps apres. C'est evidemment tres pratique
et ca augmente l'uptime, mais est-ce vraiment risque ?


Il y a un risque qui evidemment est tres relatif.
Ton serveur est vraiment tres sollicite 24/24 ?

--
Rakotomandimby Mihamina Andrianifaharana
Tel : +33 2 38 76 43 65
http://stko.dyndns.info/site_principal/Members/mihamina

Vincent Bernat
Le #453253
OoO Lors de la soirée naissante du lundi 19 avril 2004, vers 18:15,
Rakotomandimby Mihamina
Si ton patch fais varier la taille du binaire ( ce qui est quasiment
sur ) le systeme peut ne pas etre au courant du changement de taille
dudit binaire , et donc peut planter en tentant de le charger
Si au boot precedent le systeme s'est informe de la taille de ce
fichier et que tu le patche
Et que le systeme m'en est pas informe ...


Cela ne fonctionne pas comme ça. Si le fichier original n'existe plus
sur le disque, son contenu est conservé en mémoire. Il y a donc juste
une hausse de consommation mémoire puisque l'on doit parfois conserver
le nouveau et l'ancien en mémoire (cas des librairies par exemple).
--
panic("Lucy in the sky....");
2.2.16 /usr/src/linux/arch/sparc64/kernel/starfire.c

Laurent Wacrenier
Le #453252
Swaz
Par exemple, que risque-je a passer un (ou plusieurs) patch kernel ou
libthread en mode multi user, sans prevenir personne, en planifiant de
rebooter quand j'aurais le temps ?


Heu.. ça ne sert à rien de faire un patch noyau et de ne pas rebooter.
Pour une librairie, les applications déjà lancées n'en bénéficieront
pas. Il faut donc les relancer à la main ou escompter qu'elles vont
terminer bientôt normalement.

En général, tout peut arriver. Il se par exemple peut que des applis
plantent toutes seules si le système est inconsistant.

Je sais que beaucoup d'admins passent leurs patches a la volee, les
accumulent, et rebootent longtemps apres. C'est evidemment tres pratique
et ca augmente l'uptime, mais est-ce vraiment risque ?


Installez donc un patch pour mettre l'uptime à ce que vous voulez.

Le gros problème en retardant le reboot après des palanquées de
patchs, c'est qu'on est pas sûr que ça redémarre proprement après un
arrêt brutal.

Fabrice..Bacchella
Le #453251
On Mon, 19 Apr 2004 18:15:54 +0200, Rakotomandimby Mihamina

Swaz wrote:
Bonjour,


Bonjour
Je te donne mon contexte : Je suis encore un petit etudiant, et bon ...
bref l'obligation de disponibilite d'un serveur a 99.999% , je ne l'ai pas .

Le serveur est-il stable entre l'application des patches "critiques" et
le reboot ?


patches critiques , a mon avis oui ... mais tout depends de ce qu'on
appelle critique .

Et avec 200 patches ?


c'est carrement une mise a jour de tout le systeme la ...

Tant que je sache , certains binaires sont charges en RAM pour ne plus y
etre deloges ... si tu applique les patches, c'est a leur copie situee
sur le disque dur .... il y a des chances pour que ce patche ne soit pas
pris en compte .

Si ton patch fais varier la taille du binaire ( ce qui est quasiment sur
) le systeme peut ne pas etre au courant du changement de taille dudit
binaire , et donc peut planter en tentant de le charger
Si au boot precedent le systeme s'est informe de la taille de ce fichier
et que tu le patche
Et que le systeme m'en est pas informe ...


Sous Unix, quand un fichier est ouvert, il reste accessible par le
programme qui l'utilise, même s'il est effacé.
Si un fichier est modifié, l'OS va s'en rendre compte et l'image
mémoire sera mise à jour. S'il s'agit d'un exécutable, clairement on
part alors dans l'inconnu le plus total : le code ne correspond plus.

Contrairement à ce qui a été dit dans un autre message, ce n'est pas
la consommation mémoire qui est doublé, mais la consommation disque.
Les deux fichiers sont conservés sur le disque. L'un accessible
normalement. L'autre uniquement par le processus l'ayant ouvert ou
éventuellement par son inode. Dès que le file descriptor est fermé,
l'ancien fichier disparaît, son inode est libéré, il devient
totalement inaccessible.

Aussi bien dans une librairie que dans un binaire, un fichier est
caché en mémoire par page de taille fixe, généralement 4ko ou 8ko.
Seul les pages actives de la dernière version du fichier sont
présentes en mémoire. Donc il y n'y a pas un usage double de la
mémoire mais un doublon sur certaines pages du code qui sont présentes
deux fois au lieu d'une. Car effectivement les pages de codes sont
partagés entre processus. Par contre, jamais le contenu d'un fichier
effacé n'est conservé en mémoire.

Donc une procédure de patch bien faite va d'abord effacer un fichier
avant de le patcher pour éviter le problème que vous décrivez.
Je pense que c'est la procédure appliquée par Sun. En effet certains
patches impliquant la mise à jour de librairies, comme les librairies
C++, ne nécessitent aucune précaution particulière.

---
http://fba.homeip.net


Vincent Bernat
Le #453250
OoO En cette nuit nuageuse du mardi 20 avril 2004, vers 00:16,
Fabrice..Bacchella
Contrairement à ce qui a été dit dans un autre message, ce n'est pas
la consommation mémoire qui est doublé, mais la consommation disque.
Les deux fichiers sont conservés sur le disque. L'un accessible
normalement. L'autre uniquement par le processus l'ayant ouvert ou
éventuellement par son inode. Dès que le file descriptor est fermé,
l'ancien fichier disparaît, son inode est libéré, il devient
totalement inaccessible.


Exact, je me suis mélangé les pinceaux.
--
I WILL NOT PLEDGE ALLEGIANCE TO BART
I WILL NOT PLEDGE ALLEGIANCE TO BART
I WILL NOT PLEDGE ALLEGIANCE TO BART
-+- Bart Simpson on chalkboard in episode 7F09

Swaz
Le #453079
Laurent Wacrenier tint à peu près ce langage :

Installez donc un patch pour mettre l'uptime à ce que vous voulez.
:) et j'expliquerais ensuite a mes utilisateurs que, l'uptime faisant

foi, leur deconnection pour cause de reboot etait une hallucination.

Plus serieusement, que penser particulierement des reboots multiples
lors de l'application des patches ? Certains READMEs recommandent un
reboot *immediatement* apres l'application du patch, ce qui sur un
cluster important peur mener a un nombre consequent de reboots.

Est-ce vraiment risque de ne rebooter qu'une fois le cluster entier
passe ? On n'a de toute facon *que* ce choix quand on applique les
clusters de Sun. Et comme ca peut prendre 2 bonnes heures, ca fait un
laps de temps pendant lequel le systeme est dans un etat imprevisible.

J'ai egalement plusieurs patches (d'un cluster maison) qui demandent un
boot -r, un seul boot -r a la fin du cluster est-il suffisant ?

Merci pour vos remarques pertinentes et humoristiques, passees et a
venir.

Seb.

Laurent Wacrenier
Le #453077
Swaz
Installez donc un patch pour mettre l'uptime à ce que vous voulez.
:) et j'expliquerais ensuite a mes utilisateurs que, l'uptime faisant

foi, leur deconnection pour cause de reboot etait une hallucination.


Prévoyez un jour de maintenance fixe dans la semaine, annoncez le, et
ne faites vos maintenances lourdes que ce jour là.

Plus serieusement, que penser particulierement des reboots multiples
lors de l'application des patches ? Certains READMEs recommandent un
reboot *immediatement* apres l'application du patch, ce qui sur un
cluster important peur mener a un nombre consequent de reboots.


L'arrêt n'est pas toujours nessessaire et bien souvent les arrêts
devraients pouvoir être regroupés. C'est selon le patch, vos
applications, et votre capacité à gérer plusieurs choses en parallele.

Par exemple, s'il y a un patch de sécurité sur une application qui ne
sert jamais, appliquez le patch mais inutile de rebooter (regardez
quand même quels fichiers sont patchés).

Est-ce vraiment risque de ne rebooter qu'une fois le cluster entier
passe ? On n'a de toute facon *que* ce choix quand on applique les
clusters de Sun. Et comme ca peut prendre 2 bonnes heures, ca fait un
laps de temps pendant lequel le systeme est dans un etat imprevisible.

J'ai egalement plusieurs patches (d'un cluster maison) qui demandent un
boot -r, un seul boot -r a la fin du cluster est-il suffisant ?


En mode mono utilisateur, la résulat est déterministe, c'est l'interêt
principal. Pour avoir cette propriété sur un cluster, je présume qu'il
faut arreter et patcher tous les serveurs les uns après les autres et
redamarrer le tout.


Ollivier Robert
Le #453075
[copie de cet article par courrier électronique]

Dans l'article Swaz
Plus serieusement, que penser particulierement des reboots multiples
lors de l'application des patches ? Certains READMEs recommandent un
reboot *immediatement* apres l'application du patch, ce qui sur un
cluster important peur mener a un nombre consequent de reboots.


Mon expérience HP-UX montre que lors de l'installation d'un « bundle » de
patches, il va refaire son noyau plusieurs fois mais ne redémarrer qu'une
seule fois à la fin.

Ce qui est le « bon » comportement à mon avis, à moins qu'il y ait un
changement tel dans un patch noyau qu'il faille redémarrer de suite. C'est
plutôt rare.

J'ai egalement plusieurs patches (d'un cluster maison) qui demandent un
boot -r, un seul boot -r a la fin du cluster est-il suffisant ?


boot -r étant pour rebâtir /devices, ça devrait suffire.
--
Ollivier ROBERT -=- Eurocontrol EEC -=-
FreeBSD :
manu
Le #452702
Swaz
Je me demandais quelle etait la tendance quant au passage de patches sur
un serveur UNIX. Si on suit strictement les READMEs (je suis sous
Solaris), certains patches *doivent* etre passes en single-user avec
reboot immediat. Mon but etant de minimiser l'arret de production sur
mes serveurs, j'aimerais avoir votre avis sur les risques encourus a
transgresser effrontement ces "lois".


Disons qu'en passant tout d'un coup en single-user suivi d'un eventuel
reboot, ca doit plutot bien se passer.

Mais bon... le nombre de patches qu'il faut appliquer sur cers systèmes
est absolument hallucinant. C'est pas aussi délirant que Windows, mais
quand même...

--
Emmanuel Dreyfus
Un bouquin en français sur BSD:
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3


Publicité
Poster une réponse
Anonyme