Appliquer des correctifs au noyau sans redémarrer

Pause Café
#1

Bonjour à tous

Une fonctionnalité tend à se développer au sein du noyau : la possibilité de patcher son kernel sans avoir à redémarrer la machine : phoronix.com/scan.php?page=n … px=MTYyMTE

Il y a actuellement 3 projets plus ou moins concurrents : kPatch, kSplice et kGraft.

Ces projets sont en développement mais il est probable qu’à terme cette fonctionnalité soit intégrée au noyau. Autrement dit, on pourrait appliquer les mises-à-jours sans avoir besoin de (quasiment jamais) redémarrer le système.

Cela constitue une solution efficace pour appliquer rapidement des correctifs de sécurité sur (par exemple) des fermes de serveurs plutôt que de devoir attendre la fenêtre de maintenance. On réduit ainsi le temps de vulnérabilité des serveurs, tout en évitant un temps de redémarrage généralement important et d’éventuels problèmes au moment du boot.
Pour les utilisateurs que nous sommes, cela signifie qu’on s’évite des redémarrages désagréables, ce qui est toujours appréciable. Ca ne va pas fondamentalement changer notre quotidien mais c’est toujours une bonne chose :wink:

A quand un uptime de 10 ans ? :teasing-dunce:

#2

A terme ce sera peut-être la solution vs GNU/Mach

#3

Je suis presque certain qu’on en a déjà vu passer sur le forum :wink:

#4

Je suis presque certain qu’on en a déjà vu passer sur le forum :wink:[/quote]
Sachant qu’il existe un module pour falsifier l’uptime, j’ai déjà vu des uptime de plus d’un siècle.

Ces technique de mise à jour du noyau à chaud sont tout de même pour un usage assez limité. La plupart des boites étant capable de gérer les mises à jour de leur machines via la redondance qu’ils ont de manière générale (tu met à jour tes machines par tiers et ton load balancer oublie tes machines qui sont down le temps de la mise à jour). Ça permet de faire la mise à jour de manière fiable, puis de tester la mise à jour (pas de régression).

#5

Ce qui signifie que la puissance du parc diminue fortement durant la mise-à-jour ?
Mais je suis d’accord avec toi, c’est une solution qui relève plus de l’optimisation que d’une réelle évolution (même si techniquement c’est une vraie évolution).

En revanche ça peut avoir un grand intérêt pour les supercalculateurs puisqu’ils mettent environ une demi-heure à démarrer.

#6

Ce qui signifie que la puissance du parc diminue fortement durant la mise-à-jour ?[/quote]
Ils sont pas nombreux les systèmes qui ont besoin de 100% de leur ressources en 24/7. D’une part il ont une marge pour absorber des pics d’autres part, ils ont des heures creuse généralement.

Oui et le coût est faramineux par rapport au gain (c’est ça le libre :slightly_smiling: ).

Surtout qu’ils n’ont pas vraiment d’heure creuse, ils sont utilisés de manière assez permanente et je en sais pas si on peut facilement s’amuser à sortir des nœuds du calculateur.

#7

Je suis presque certain qu’on en a déjà vu passer sur le forum :wink:[/quote]
Sachant qu’il existe un module pour falsifier l’uptime, j’ai déjà vu des uptime de plus d’un siècle.

Ces technique de mise à jour du noyau à chaud sont tout de même pour un usage assez limité. La plupart des boites étant capable de gérer les mises à jour de leur machines via la redondance qu’ils ont de manière générale (tu met à jour tes machines par tiers et ton load balancer oublie tes machines qui sont down le temps de la mise à jour). Ça permet de faire la mise à jour de manière fiable, puis de tester la mise à jour (pas de régression).[/quote]
uptime-project-t31132.html#p314458

L’uptime retombe à zéro au bout de 496jours, mon record perso est de 678 jours:

rate-les-2-ans-t17874.html

et date du 4 janvier 2009. EDF est l’ennemi numéro 1.

#8

bonjour,
c’est une fonctionnalité qui existe déjà pour certains champs:
implémenté une valeur dans sysctl.conf
A+
JB1

#9

bonjour,
dommage de ne pas donner suite,
la discussion était intéressante
A+
JB1