IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Kgraft : une technologie open source pour patcher votre serveur Linux à chaud
Suse ambitionne de l'introduire dans le noyau Linux

Le , par Arsene Newman

26PARTAGES

1  0 
La gestion d’un parc de serveurs exécutant des programmes d’une importance cruciale se révèle difficile, spécialement dans certaines situations comme lorsqu’il est nécessaire de patcher les serveurs tout en sachant que leur redémarrage n’est pas réellement envisageable, ce qui pousse le désarroi du personnel chargé de la gestion du parc à son paroxysme.

Aujourd’hui, Suse et ses ingénieurs présentent une nouvelle technologie permettant de patcher des serveurs Linux à chaud, sans nécessité d’un quelconque temps mort, elle a été baptisée Kgraft et a été publiée sous licence GPLv3.

Pour ce faire, Kgraft tire parti de certaines fonctionnalités déjà existantes sous Linux, d’ailleurs la technique utilisée a été résumée en ces termes : « utilisant une approche semblable à ftrace pour remplacer tout un ensemble de fonctions dans le noyau Linux par des variantes fixées ». De plus, Kgraft ne fait pas appel à la fonction stop_machine() lors de la modification du code à chaud, ce qui limite les latences du système.

A noter que cette technologie n’est pas récente au monde IT même si Kgraft semble être la plus aboutie, auparavant Ksplice et OpenVZ Checkpointing ont vu le jour, mais avec leur lot de déceptions, le développement de la première technologie a reçu un coup de frein suite à son rachat par Oracle, quant à la seconde, elle nécessite une certaine infrastructure et de courtes interruptions de services qui restent visibles.

Parmi les limitations actuelles de Kgraft, son installation qui nécessite le patch préalable du système, autre point important une compilation manuelle des patchs est requise avant leur installation à chaud, Coté matériel, Kgraft ne supporte pour l’heure que l’architecture x86 même si les ingénieurs de Suse sont confiants dans son portage vers les architectures ARM et IBM Power.

Enfin, Suse note que cette technologie est encore au stade de prototype, mais elle espère que sur le long terme son développement permettra de l’introduire comme une fonctionnalité à part entière du noyau linux.

Consulter le code source de Kgraft

Source : Annonce de Suse
Et vous ?
Qu’en pensez-vous ?
Pensez-vous que cette technologie sera introduite un jour dans le noyau linux ? Pourquoi ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de gangsoleil
Modérateur https://www.developpez.com
Le 04/04/2014 à 14:38
Ca semble bien sur le papier, mais je vois de reels problemes de securite : si un tel mecanisme est installe, il sera possible pour un attaquant de modifier les programmes "a chaud", rendant la detection de problemes encore plus difficile.
3  0 
Avatar de Metalman
Membre expert https://www.developpez.com
Le 04/04/2014 à 15:23
Même remarque que gangsoleil...
Niveau sécu ça va être très comique...
Chez FreeBSD il y a des "niveaux" d'autorisation pour empêcher de charger des modules noyaux hors boot (ce système ne doit pas être infaillible, j'en conviens)...
Comment vont fonctionner les patchs grsec avec cette nouvelle fonctionnalité ?

Le fait de ne pas pouvoir rebooter "par peur" est déjà mauvais signe : aucune maîtrise de l'OS et de ses scripts de démarrage.
Même si la machine ne doit PAS rebooter sans qu'on l'ait souhaité, ne pas savoir si elle peut rebooter est encore pire.
Si cette fonctionnalité marche, elle risque de surpopulariser les très mauvaises pratiques de ce genre.

Mais cela reste une fonctionnalité intéressante qui peut combler certains besoins.
1  0 
Avatar de TiranusKBX
Expert confirmé https://www.developpez.com
Le 04/04/2014 à 12:33
Je suis totalement pour car ça pourrait un peut me faciliter la vie sur des serveurs en production
car mettre en places tout un système de bascule et faire les MAJ de tous les serveur UN à UN puis de tous re-basculer et chronophage et donne de grands risques de platages
0  0