la production de ksplice est-elle prête?

Je serais intéressé d'entendre les expériences de la communauté serverfault avec Ksplice en production.

Présentation rapide de wikipedia:

Ksplice est une extension gratuite et open source du noyau Linux qui permet aux administrateurs système d'appliquer des correctifs de sécurité à un noyau en cours d'exécution sans avoir à redémarrer le système d'exploitation.

et

Ksplice peut, sans redémarrer le noyau, appliquer n'importe quel correctif de code source qui n'a besoin que de modifier le code du noyau. Contrairement à d'autres systèmes de mise à jour à chaud, Ksplice prend en entrée uniquement un diff unifié et le code source du noyau d'origine, et il met à jour le noyau en cours d'exécution correctement, sans aucune assistance humaine supplémentaire requise. De plus, tirer parti de Ksplice ne nécessite aucune préparation avant le démarrage initial du système (le noyau en cours d'exécution n'a pas besoin d'avoir été spécialement compilé, par exemple). Afin de générer une mise à jour, Ksplice doit déterminer quel code dans le noyau a été modifié par le correctif de code source.

Donc, quelques questions:

Quelle a été la stabilité? des problèmes étranges que vous avez rencontrés avec son «patching en direct sans redémarrage» du noyau? Panique du noyau ou histoires d'horreur?

Je l'ai exécuté sur quelques systèmes de test et jusqu'à présent, il fonctionnait comme annoncé, mais je suis intéressé par ce que d'autres expériences d'administrateur système ont eu avec Ksplice avant de `` tout faire '' et de déployer cela sur nos serveurs de production.

Alors, quelqu'un utilise Kspice en production?

mise à jour: hmm, ne voyant aucune activité réelle sur cette question après quelques heures (à part quelques votes positifs et favoris). Peut-être pour déclencher une activité, je poserai également quelques questions supplémentaires et voir si nous pouvons lancer cette discussion ...

"Si vous connaissez Ksplice, y a-t-il une raison pour laquelle vous ne l' utilisez pas?"

"Sentez-vous que son bord est encore trop saignant, non prouvé ou non testé?"

"Ksplice ne s'intègre-t-il pas bien dans votre système actuel de gestion des correctifs?"

"Vous détestez avoir des systèmes qui ont des temps de fonctionnement longs (et sécurisés)?" ;-)

(Tout d'abord, un avertissement: je travaille pour Ksplice.)

Nous l'utilisons sur notre propre infrastructure de production, naturellement, mais plus important encore, tout comme nos 500+ clients commerciaux (nombre à partir de décembre '10).

Un administrateur système pose la même question sur une liste de diffusion d'utilisateurs Red Hat Enterprise Linux et reçoit un certain nombre de réponses, dont quelques-unes sont extraites ci-dessous:

Nous exécutons Ksplice en production depuis quelques mois sur une dizaine d'hôtes. Jusqu'à présent, cela fonctionne comme annoncé.

et

J'ai plus de 500 machines sous mon contrôle, environ 445 d'entre elles sont connectées à uptrack (rhel 4 & 5). Nous avons utilisé ksplice pour bloquer quelques exploits root avant de pouvoir redémarrer les machines. Comme nous testons toujours, nous avons quand même déployé le nouveau noyau, mais j'ai couru pendant des semaines avec ksplice sans problème.

Une préoccupation exprimée par les gens ne concerne pas la stabilité, mais plutôt son intégration avec les outils d'audit et de suivi existants:

Le seul "problème" concernant l'utilisation de ksplice est qu'il n'y a pas encore d'outils d'audit "compatibles avec ksplice".

Comme vous pouvez vous y attendre, c'est maintenant un domaine dans lequel nous investissons massivement.

J'ai entendu parler de Ksplice et à l'époque je pensais que c'était une bonne idée. Pas de temps d'arrêt, pas de redémarrage. Mais ensuite, je l'ai approfondi un peu et j'ai eu peur de l'essayer.

Mes raisons pour l'éviter sont:

• Le noyau Linux est déjà très complexe. Ksplice ajoute à la complexité. Plus de complexité = plus d'échec.

• Il sera imprudent d'expérimenter avec Ksplice sur un serveur distant où une panne entraînerait un long temps d'arrêt et une réparation coûteuse.

• Le seul avantage dans mon cas serait une statistique de disponibilité plus élevée.

J'utilise Ksplice sur mon serveur domestique (où la disponibilité n'est pas critique mais est agréable à avoir). Je n'ai eu aucun problème avec cela - des mises à jour occasionnelles via Apt pour le client, jamais aucun problème avec les mises à jour du noyau elles-mêmes, et aucune instabilité (notable).

La clause de non-responsabilité habituelle "YMMV" s'applique cependant! ;-)

Ksplice est une extension de noyau open source, mais gardez à l'esprit que bien que le logiciel soit gratuit et disponible pour tout le monde, il est créé spécifiquement par et pour une entreprise qui gère les correctifs Linux (également appelé "Ksplice"). Ksplice (le mod du noyau) n'est vraiment utile que si vous avez des correctifs utilisables par ksplice pour votre noyau, ce que vous n'allez probablement jamais voir à moins d'avoir un contrat de support avec Ksplice (la société).

Ainsi, bien que ksplice (l'outil) soit raisonnablement mature, cela n'est vraiment pertinent que si vous envisagez d'utiliser Ksplice (la société) pour la gestion de vos correctifs.

Bonne question. Ma réponse initiale serait quelque chose du genre "pourquoi ai- je besoin de cela?"

Vous n'en avez probablement pas besoin. Même dans une configuration à cinq neuf, la «maintenance planifiée» est souvent une clause d'un contrat SLA qui autorise ce type de temps d'arrêt. Si vous avez une configuration HA, passez au basculement, installez le noyau sur une case, redémarrez et répétez sur l'autre. Si vous ne pouvez pas vous permettre même cinq minutes de temps d'arrêt sur un boîtier, vous avez quand même besoin d'une configuration de basculement.

Bien qu'il s'agisse d'une nouvelle technologie, je n'en vois pas encore beaucoup d'utilisation pragmatique. Les mises à jour de sécurité du noyau sont bien sûr nécessaires et doivent être corrigées dès que possible, mais combien de temps / effort / inquiétude cela vous fait-il économiser par rapport à l'installation d'un nouveau noyau et au redémarrage? Et si quelque chose tourne mal? Combien de temps avez-vous perdu en réimaginant le système, en supposant que vous avez la chance d'avoir une option de récupération de type PXE?

De plus, comme mentionné ci-dessus, l'expérimentation à distance avec une technologie comme celle-ci pourrait être une catastrophe si elle se passe mal sur plusieurs serveurs. Dans vos tests, utilisez-vous exactement le même matériel que vous êtes dans le DC? Ce qui joue bien sur une machine peut ne pas jouer bien sur une autre.

Juste mon 0,02 $.

Il y a longtemps, mais ce que Ksplice peut faire pour vous, c'est beaucoup ...

• Amélioration de la sécurité car elle permet d'appliquer des correctifs à la volée sans temps d'arrêt, cela peut être extrêmement important dans des environnements très sensibles.

• Amélioration de la stabilité car elle permet de corriger à la volée sans temps d'arrêt, les choses peuvent s'améliorer alors qu'aucun temps de redémarrage n'est disponible.

• Performances améliorées car il permet de patcher à la volée sans temps d'arrêt, en appliquant exactement ce dont vous avez besoin pour ce que vous en avez besoin.

• Pro-activité améliorée car elle permet d'appliquer des correctifs à la volée sans temps d'arrêt, de sorte que la configuration d'une batterie de tests pour de nouveaux correctifs à chaud est possible tout en revenant facilement à un état antérieur.