[Aide] ubuntu serveur - redémarrer ou pas ?

R. Daneel Olivaw rdaneel.olivaw at gmail.com
Mon Jun 17 03:41:47 CEST 2013


Bonsoir,

Je comprends que j'arrive un peu tard dans la discussion, mais à lire 
les différents messages, je pense qu'un poil de clarification s'impose.

Un serveur dont le noyau a été mis à jour doit être redémarré. Point.
Que ce soit sur CentOS/RedHat ou Debian/Ubuntu-Server, cela ne fait 
AUCUNE différence. On peut discuter de la fréquence de mise à jour des 
uns et des autres, mais ce n'est en aucun cas un débat technique 
concernant ce qui nous intéresse.

Alors j'ai vu poindre ksplice et grsec:

- ksplice est un moyen d'appliquer des modifications au noyau à chaud, 
sans redémarrage. Cela nécessite une installation particulière et n'est 
pas une fonction standardisée du noyau. D'ailleurs, ça appartient à 
Oracle et n'est pas disponible pour nous autres pauvres de ce monde 
(mais je me trompe peut-être).

- grsec est une série de changements dans le noyau pour endurcir ce 
dernier (kernel hardening) pour empêcher que des débordements de 
certaines assiettes aillent tâcher le napperon et accessoirement 
compromettre le noyau. Ça aussi, ne vient pas de base avec nos 
distributions. Cependant, cela n'empêche pas une compromission, ça 
permet d'être plus sécurisé. Si une faille du noyau n'est pas 
directement dépendante d'un abus du noyau mais d'une combinaison 
malheureuse de facteurs 'normaux', grsec ne sera pas plus utile, et donc 
ne pas redémarrer pour appliquer les correctifs n'est pas plus 
conseillé. Leur site parle d'ailleurs "d'acheter du temps" en attendant 
les correctifs officiels et non de remplacer ces derniers.

Donc, dans la liste des choses qu'un sysadmin doit faire, il y'a par 
exemple prévoir une période de maintenance avec arrêt momentané de 
service pour ce type de mises à jour. De même que redémarrer le service 
lui même peut être disruptif (on n'arrête pas plus une grosse base de 
données qu'un serveur au complet, les applications ne vont pas être plus 
accommodantes qu'avec un reboot).

Ça se discute avec les 'consommateurs du service' et peut être remis à 
des dates prédéterminées. Tout dernièrement, d'ailleurs, une faille 
critique est apparue sur CentOS et la mise en place immédiate du patch 
était nécessaire donc ... reboot. Vous n'y couperez pas, tôt ou tard il 
faudra redémarrer (bon, avec pas mal d'argent, on peut faire des choses, 
mais c'est un autre monde).

Comme je l'ai lu aussi, si le service est tellement critique, il y'a des 
solutions (keepalived, haproxy, heartbeat, corosync, drbd, galera, nfs, 
...) pour fabriquer de la HA (se prononce 'aïtch é') haute disponibilité 
pour vos services chéris.

D'ailleurs, même dans un environnement virtualisé, la haute 
disponibilité est utile, justement pour les mises à jour 'roulantes' 
(rolling updates).

Enfin, le 'cloud' a tendance a fournir moins de garanties que plus, et 
il est fortement conseillé de concevoir le système complet, de l'OS 
jusqu'à l'application en mode résilient ... mais je m'égare.

Bonne soirée/nuit/journée à tous,

R. Daneel Olivaw,
The Human Robot Inside.


More information about the Aide mailing list