Dis Next, c’est quoi le « live patching » sans redémarrage dans les OS ?
Correction à chaud et sans clim
Canonical a annoncé ce 23 juin la compatibilité de sa fonction Livepatch avec la variante Arm64 d’Ubuntu. Au-delà de cette extension, quels systèmes d’exploitation disposent aujourd’hui de ce type de mise à jour sans redémarrage ? Comment fonctionne un tel processus ?
Canonical n’était pas peu fière d’annoncer la disponibilité de son Livepatch sur Ubuntu Arm64. L’architecture, qui a largement le vent en poupe depuis plusieurs années, finit par posséder les mêmes capacités que le monde x86, au fur et à mesure que la chaine d’outils nécessaire murit. C’est en tout cas la vision qu’en donne Canonical dans son billet d’annonce, notant que la « prolifération des processeurs Arm hautes performances dans les environnements cloud et l’augmentation des dispositifs complexes en périphérie » avaient rendu ce travail « impératif ».
L’éditeur indique que cette nouveauté a nécessité plusieurs années d’efforts. Il ne suffisait pas de distribuer du code nativement arm64, toute l’infrastructure de production devait être adaptée. Cela signifiait, dans le cas présent, ajouter tout l’appareil de compilation et de test pour ces nouvelles versions, sur de multiples versions du noyau, sans passer par l’émulation.
En conséquence, les entreprises utilisant Ubuntu 26.04 LTS et Ubuntu Core 26 (version entièrement conteneurisée du système) sur du matériel Arm64 peuvent maintenant profiter de Livepatch. Tout du moins s’ils ont l’abonnement Ubuntu Pro, comme pour les autres architectures déjà concernées. Rappelons que la formule est gratuite pour une utilisation personnelle et peut donc intéresser les « enthousiastes », dans une limite de cinq appareils.
Et chez les autres ?
La capacité de patcher en direct un système d’exploitation sans nécessiter de redémarrage est déjà ancienne. On trouve ce type de fonction chez les éditeurs tournés vers les entreprises.
Chez Red Hat par exemple, le live patching a longtemps reposé sur la technologie kpatch. L’entreprise se concentre sur les architectures x86_64 et ppc64le pour son système Red Hat Enterprise Linux (RHEL). Elle délaisse l’architecture Arm64, en tout cas pour l’instant. Les correctifs sont cumulatifs et distribués toutes les six semaines sous forme de packages RPM classiques via le Content Delivery Network de Red Hat. La fonction n’est disponible qu’à travers un abonnement RHEL.
Commentaires (7)
Le 25 juin à 11h32
Je veux dire, une boite est censé tester régulièrement son PRA, donc s'assurer de pouvoir couper son serveur/Routeur/BDD (et même des DC complets pour les banques/Assurances avec DORA) et d'avoir toujours les services qui tournent.
Et si une app n'a pas de PRA (ou de haute-dispo) alors elle n'est pas critique et pourrait être coupé 30mins (en comptant large).
Après ils vont être obligé de redémarrer un serveur qui ne l'aura pas été depuis X années, ça va planter, l'IT va se faire taper dessus alors que c'est la faute de l'orga/Mentalité (beaucoup d'ingé aussi sont contre le redémarrage, "trop de risque", ben oui, t'es censé redémarrer au moins 1-2 fois par ans depuis des années pour patcher/Vérifier ton PRA, mais c'est jamais fait...).
Donc pas du tout pour ces sytème de live-patching, ça repousse encore un problème d'organisation :(
Le 25 juin à 15h05
Je reboot dès qu'une faille exploitable dans le kernel le nécessite.
Quand ça touche un host KVM ça reste toujours un peu chiant.
Ces dernières semaines on a bien été gâté au niveaux des reboot d'ailleurs.
Le 26 juin à 00h19
Cette confusion tendant à renforcer la croyance qu'une infrastructure physique serait synonyme d'obsolescence de pratiques m’interroge.
D'aucuns demanderaient d'ailleurs "Mais quel rapport, dans le contexte ?"…
L'aversion au risque et la rigidité mentale telles que pointées par Ramaloke sont encore couramment croisées en entreprises.
L'inverse, à savoir les têtes brûlées qui s'affranchissent de tout impact sur les utilisateurs et/ou de tout risque de conséquences plus graves que celles escomptées par confort personnel de maintenance, sont la deuxième face de cette délétère médaille, et encourage d'ailleurs la rigidité mentale par la suite.
Le 26 juin à 07h20
Modifié le 26 juin à 13h00
Coût matériel ET logiciel.
Elle entraîne aussi une complexité supplémentaire, notamment dans le cas où l'applicatif que le serveur fait tourner ne sait pas ou sait très mal la gérer (genre les gros ERP de l'enfer qui ont déjà un TCO colossal en termes d'infra et de licences).
Donc oui, on peut le déplorer, mais c'est aussi la réalité du terrain avec parfois une vision court terme ou basée sur des lignes budgétaires différentes (build versus run). Et c'est comme ça qu'on se retrouve avec un événement où il faut planifier un mois à l'avance un reboot pour du patch management.
Quand il ne faut pas casquer un projet à 2 millions pour monter de version l'OS.
Hélas, les projets sous estimant souvent la partie IT ou la projetant en mode "à gérer plus tard", on ne se rend pas compte que le ROI peut s'obtenir en évitant justement de reclaquer 2 millions pour changer une VM.
Le 30 juin à 22h51
Notamment la cible ce sont aussi des supercalculateurs ou des systèmes assez critiques. Un employé Red Hat m'avait expliqué que beaucoup des machines qui disposent de ce mécanisme mettent beaucoup de temps à démarrer (on parle de dizaines de minutes à plusieurs heures). On évite de redémarrer à la moindre CVE corrigée sinon tu ne t'en sors pas.
Ce sont des machines souvent chères qu'on ne peut pas redonder à l'infini et la redondance existe souvent, mais la redondance c'est fait pour éviter l'imprévu.
Si tu redémarres ton serveur X pour corriger la faille et qu'il y a un pépin, le service tournera peut être grâce au serveur Y, mais ça signifie que si Y tombe pour une raison différente et imprévue (dont une forte charge), ta redondance est morte et ton service coule.
Alors que tu pourrais faire en sorte de retarder au maximum pour être dans un creux d'activité (voire absence d'activité, de nombreux services ne tournent quasiment pas à certains moments de la journée ou de la semaine) pour réduire les risques ou nuisances.
Alors oui tu peux multiplier la redondance à l'infini pour éviter le moindre risque, mais ça coûte sans doute plus cher que cette alternative. N'est-ce pas finalement une bonne chose d'éviter de recourir à plus de matériel ?
Le 25 juin à 15h05
(oui, je sors)
Signaler un commentaire
Voulez-vous vraiment signaler ce commentaire ?