Redémarrer le serveur maintenant ou plus tard ? (Ni l'un ni l'autre, merci)

Étiez-vous présent à AWS re:Invent 2019?

Je l'étais, et ce fut une révélation.

"Allez-vous redémarrer votre serveur Linux dans les 30 prochains jours ?"

C'est ce que j'ai demandé à presque tous ceux qui sont venus au stand de KernelCare.

Un tiers d'entre vous a répondu oui. La raison principale ? La conformité.

C'est logique. La plupart des politiques de conformité indiquent aux entreprises qu'elles doivent installer les correctifs de sécurité dans les 30 jours suivant leur publication. Le problème, c'est que sous Linux, l'installation d'un correctif sur le noyau implique le redémarrage du serveur - il n'y a aucun moyen d'y échapper. (Ou bien existe-t-il ?)

J'ai dû demander à environ 2000 personnes. Pensez au nombre de serveurs dont chacune d'entre elles s'occupe. Multipliez ensuite par le temps que prend un redémarrage, non seulement pour le réaliser, mais aussi pour le planifier et le coordonner. Même avec ce petit échantillon, cela représente une quantité étonnante d'efforts humains. Et d'argent.

Le redémarrage : Une nécessité qui dérange

La gestion des correctifs Linux est la façon élégante de dire "maintenir un serveur à jour en installant les derniers logiciels". Lorsque ce logiciel est le noyau Linux, vous trouvez la raison la plus courante des redémarrages du système. Pour les grandes entreprises, l'application de correctifs de sécurité (comme l'échec) n'est pas une option - c'est une obligation.

Une politique typique de conformité à la sécurité informatique comprendra une clause du type suivant :

"...les correctifs de sécurité doivent être appliqués au système dans les X jours suivant leur publication par le fournisseur..."

X est généralement de 30 jours. C'est pourquoi, dans la pratique, les administrateurs système rassemblent les correctifs et les installent en vrac, en effectuant le travail dans une fenêtre de maintenance pré-planifiée, un moment où tout le monde est d'accord pour que le système soit indisponible pendant une courte période. (Malheureusement, cette fenêtre est souvent le samedi soir/dimanche matin, lorsque l'impact sur les clients est le plus faible).

Planifier cette fenêtre demande beaucoup d'efforts : du temps passé en réunions, des mots déversés dans des courriels, des cœurs brisés dans des compromis. Et c'est sans compter les week-ends perdus de café froid et de pizza rassie. Lors de mon passage à AWS re:Invent, j'ai eu le sentiment que 30 % des administrateurs de systèmes Linux souffrent inutilement.

Continuer la lecture : Les 10 principaux avantages des correctifs en direct avec KernelCare

L'automatisation : Une nécessité absolue

Personne ne devrait gérer les patchs manuellement. Même pour un seul serveur, cela représente un effort considérable pour le maintenir à jour.

Les administrateurs système, étant les créatures techniques qu'ils sont, adorent automatiser de telles tâches de routine, surtout s'ils gèrent de grands parcs de serveurs. Souvent, le travail d'automatisation est plus amusant que ce qui est automatisé. Il y a aussi d'autres avantages :

• C'est plus sûr, moins sujet à l'erreur humaine.
• Le processus peut être enregistré et contrôlé.
• Il est plus facile de partager le travail et les responsabilités.

Il existe de nombreuses façons d'automatiser. Décider laquelle utiliser peut être un obstacle en soi. Par exemple, devez-vous :

1. Construire votre propre outil d'automatisation ? Il existe de nombreux langages de script, mais lequel est le meilleur, et avez-vous les compétences, la patience et le temps nécessaires ?
2. Utiliser l'outil de support préféré du fournisseur ? Red Hat propose Satellite (et Spacewalk, l'équivalent open-source), et Canonical propose Landscape, mais ces outils sont destinés à leurs propres plates-formes et ne sont fournis que dans le cadre d'une offre groupée d'assistance.
3. Utiliser un service ? Là encore, il y a l'embarras du choix : Automox, GFI, Ivanti, Kaseya, ManageEngine, Pulseway, pour n'en citer que quelques-uns. Quelqu'un doit les examiner, déterminer ce qu'ils font, comment ils le font et s'ils conviennent. Pendant ce temps, les correctifs continuent d'arriver et doivent être installés.
4. Vous utilisez un outil d'orchestration ? Ansible, Chef ou Puppet sont quelques options, mais elles aussi doivent être vérifiées, et il y a une courbe d'apprentissage à gravir avant que leur puissance ne porte ses fruits.

Il existe une autre option tentante, si vous travaillez avec des services de cloud gérés comme VMware Cloud sur AWS, qui s'occuperont d'une plateforme virtualisée pour vous (moyennant finance, bien sûr). Mais la virtualisation ne supprime pas les redémarrages. Elle les rend simplement plus rapides et moins pénibles, en atténuant leur effet grâce à la mise en grappe et à d'autres approches de redondance du système.

Un redémarrage, aussi court soit-il, ferme les gestionnaires de fichiers, les connexions réseau, les sessions utilisateur et arrête tous les processus. Pour de nombreuses catégories d'applications et d'utilisateurs d'applications, ces interruptions passent inaperçues ; les sessions se rétablissent, les connexions sont rétablies. Mais pour d'autres types d'applications, les interruptions sont ruineuses. Pensez aux calculs scientifiques de longue durée, aux analyses en temps réel, aux serveurs de jeux en direct, aux appareils IoT, ....

Continuer la lecture : Endurance a mis en œuvre des mises à jour sans redémarrage avec KernelCare

Un remède au syndrome du redémarrage

Le live patching est un moyen d'installer les correctifs de sécurité du noyau Linux, automatiquement, et sans redémarrage. Bien que cette technique existe depuis 2010, elle n'a pas trouvé la notoriété qui entoure Linux.

C'est principalement parce que c'est difficile à réaliser. Il faut une connaissance approfondie du code source du noyau et la capacité de coder des correctifs rapidement et avec précision. Pour cette raison, seuls les grands fournisseurs de Linux peuvent offrir des solutions de correctifs en direct : Oracle (avec Ksplice), Red Hat (avec Kpatch), SUSE (avec SUSE Live Patching, appelé Kgraft) et Canonical (avec Livepatch).

Comment patcher le noyau Linux sans redémarrer ?

KernelCare fonctionne de la même manière que Ksplice, Kpatch et Kgraft. La différence entre KernelCare et ces outils réside dans la manière dont les correctifs sont créés. (Une autre différence est que ces produits font partie des contrats de service des fournisseurs, alors que les abonnements à KernelCare sont autonomes, et donc beaucoup plus rentables et flexibles). De plus, KernelCare prend en charge un vaste choix de versions et de types de noyaux, bien plus que tous les autres fournisseurs réunis.

Voici un aperçu simple de la façon dont KernelCare fonctionne.

Pourquoi les administrateurs système adorent KernelCare

J'ai parlé à de nombreux clients depuis que je suis responsable du marketing de KernelCare. Voici ce qu'ils m'ont dit être leurs avantages préférés.

1. Réduction des rapports. Il est moins nécessaire d'établir des rapports de gestion et de conformité indiquant ce qui a été fait, pourquoi et par qui.
2. Moins d'e-mails. Réamorcer moins signifie moins de communication et de négociation avec des dizaines de parties prenantes de divers départements.
3. Plus de sommeil. Le redémarrage du samedi soir/dimanche matin est logique pour tous ceux qui sont touchés par les temps d'arrêt. Mais c'est un enfer pour les personnes qui doivent le faire. Peu importe qu'ils soient sur place ou à distance, il faut toujours que quelqu'un soit éveillé pour exécuter les commandes, vérifier que l'automatisation se déroule sans problème et effectuer des vérifications de bon sens sur le système après son rétablissement. La paranoïa de la direction est monnaie courante dans de telles situations, à juste titre, compte tenu des enjeux.
4. La vie est plus simple. Le fait d'avoir moins de redémarrages planifiés rationalise la configuration de l'automatisation, quelle que soit la méthode. Les playbooks système sont plus simples et plus faciles à comprendre.

Pourquoi les fournisseurs de services aiment KernelCare

Si vous pensez que KernelCare est réservé aux techniciens, vous vous trompez. Toute personne ayant des connaissances de base de la console Linux peut installer KernelCare en quelques commandes. C'est une excellente nouvelle pour une catégorie de personnes que j'appelle les fournisseurs de services. Il s'agit des managers, des cadres et des propriétaires de petites entreprises qui ne s'embarrassent pas des détails techniques des correctifs en temps réel. Ils veulent simplement savoir que leurs serveurs Linux sont protégés par des correctifs, conformes et sûrs. J'ai également parlé à ces personnes et, comme vous pouvez vous y attendre, elles voient les avantages de KernelCare sous un angle différent.

1. Il y a moins de temps d'arrêt. Cela signifie moins de perturbations pour les clients, et moins de raisons pour eux d'aller voir ailleurs ou de se plaindre.
2. Il y a moins de risques que le système ne soit plus le même après un redémarrage, et moins de risques de devoir tout réinitialiser pour que l'entreprise puisse continuer à fonctionner.
3. Il y a moins d'argent dépensé en administration. Le live patching est une approche autonome de la gestion des correctifs du noyau Linux.

La fin (des reboots)

Cette année, la conférence AWS re:Invent 2019 a été une révélation, non seulement parce que c'était la première fois que j'y participais, mais aussi parce que j'ai pu constater par moi-même l'ampleur des efforts et des dépenses que les administrateurs de serveurs Linux doivent consentir pour faire face aux redémarrages pénibles. J'ai senti que je devais crier à tue-tête depuis notre stand KernelCare :

 

Ne soyez pas l'esclave des reboots ! Nous avons la réponse ! Rejoignez-nous !

Mais, bien sûr, je ne l'ai pas fait. J'ai juste distribué des brochures, des autocollants et des t-shirts, et j'ai eu de la peine pour des centaines de personnes très gentilles qui travaillaient dur car elles devaient redémarrer leurs serveurs pour appliquer des mises à jour de sécurité.

Continuez à lire : 5 mauvaises raisons de mettre à jour votre noyau Linux