Les mises à jour du noyau Proxmox sont épuisantes, mais les ignorer semble pire

Les mises à jour du noyau arrivent à un tel rythme ces derniers temps que même les utilisateurs Proxmox les plus patients commencent à sentir l'usure. Un admin a parfaitement résumé cette lassitude : pour lui, mettre à jour ne se résume pas à un clic en passant. Il doit tout arrêter, appliquer le noyau, redémarrer, puis tout relancer. Faites ça trois ou quatre fois en peu de temps et même une maintenance responsable finit par ressembler à un tapis de course avec une invite de connexion. La question était simple : y a-t-il vraiment autant de bugs et de problèmes, ou est-ce juste la vie maintenant ? La réponse du fil, en gros : oui, oui et, malheureusement, oui.

Ces mises à jour ne sont pas du bruit aléatoire

La réponse la plus solide a dissipé le brouillard d'un coup : une bonne partie des mises à jour récentes du noyau était liée à des failles de sécurité baptisées CopyFail, DirtyFrag, CIFSwitch, Fragnesia, DirtyDecrypt et PinTheft. Le commentateur les décrivait comme des failles d'élévation de privilèges locale et d'évasion de conteneur, ce qui pèse autrement dans un contexte Proxmox. Sur un poste de travail, une appli bizarre plante et vous soupirez ; ici, vous avez une infrastructure qui fait tourner des invités, des conteneurs, du stockage et des services réseau. Quand des bugs de privilèges locaux ou des chemins d'évasion de conteneur sont en jeu, le va-et-vient des noyaux cesse de ressembler à une corvée inutile et commence à ressembler à de la limitation des dégâts.

Le processus n'en devient pas moins pénible, mais l'agacement est plus facile à justifier. Quelqu'un a dit que des mises à jour fréquentes sont une nuisance, mais qu'un logiciel d'infrastructure négligé est bien pire. Un autre préférait lui aussi gérer les mises à jour plutôt que les conséquences d'une absence de mise à jour. C'est le triste marché. Personne n'aime redémarrer ses hôtes ni caler des reboots autour de services en production, mais l'alternative consiste à faire comme si les vulnérabilités attendaient poliment que votre week-end soit libre. Elles n'attendent pas, parce que la sécurité a de très mauvaises manières.

La lassitude des mises à jour est réelle

Au cœur émotionnel du fil, on trouvait l'épuisement plutôt que le déni. Un commentateur a souhaité à tout le monde la bienvenue dans « la vie maintenant » et a reconnu qu'il ressentait déjà une lassitude des mises à jour. L'expression fait mouche parce qu'elle décrit un problème d'admin très actuel. Les outils sont meilleurs, les alertes plus rapides, les vulnérabilités plus visibles, et pourtant c'est toujours un humain qui doit décider quand appuyer sur le bouton. Dans un homelab, cet humain est en général aussi l'admin stockage, l'ingénieur réseau, la personne d'astreinte en cas d'incident et celle qui essaie de regarder un film sans redémarrer la machine qui fait tout tourner.

Certains ressentent la douleur plus vivement parce que leur processus de mise à jour comporte plus de risques. Une personne parlait d'un système distant sans IPMI, où chaque mise à jour du noyau devient un petit pari : journée normale, ou moitié de dimanche passée à rouler jusqu'à une machine qui n'a pas redémarré ? Rien de mélodramatique là-dedans. Quiconque a géré du matériel headless sans vraie console distante connaît cette sueur froide. Les mises à jour du noyau sont peut-être nécessaires, mais la nécessité n'ajoute pas par magie une gestion hors bande à du vieux matériel.

Le rollback sert de soupape de sécurité

Le plus grand réconfort du fil, c'est que Proxmox rend le retour à un ancien noyau assez accessible. Un utilisateur disait avoir évité les mises à jour après un noyau qui refusait de démarrer sur des systèmes Intel, et un autre a fait remarquer que revenir à un noyau précédent est facile. Un troisième était ravi de pouvoir démarrer sur un ancien noyau, épingler le bon et passer à autre chose. C'est important, parce que des cycles de mise à jour rapides sont bien plus supportables quand la plateforme offre une porte de sortie raisonnable.

Reste que le rollback ne fait que rendre le risque surmontable. Les pires bugs, comme l'a dit un commentateur, sont ceux qui ne se voient pas tout de suite. Un noyau qui ne démarre pas fait peur, mais au moins c'est évident. Un problème de stockage subtil, une bizarrerie de passthrough, un bug réseau intermittent ou une faille d'isolation des conteneurs peuvent être bien plus sournois, parce qu'ils vous laissent croire que tout va bien jusqu'au moment où ce n'est plus le cas. C'est pour ça que les mises à jour du noyau ressemblent à un impôt psychologique. En plus de « Est-ce que ça va démarrer ? », vous vous demandez aussi : « Qu'est-ce qui a changé que je ne remarquerai que la semaine prochaine ? »

L'automatisation comme plan d'évasion

Une fois admis que les mises à jour ne vont pas disparaître, la conversation s'est tournée vers l'automatisation. Un utilisateur voulait des mises à jour échelonnées pour son homelab, nœud par nœud, pour que toute l'installation ne meure pas d'un coup dans d'atroces souffrances. C'est le bon réflexe. Même dans un petit lab, traiter chaque hôte comme un cobaye simultané, c'est chercher les ennuis. Un déploiement par étapes vous donne une chance de repérer un mauvais comportement avant qu'il ne se propage à toute la pile. Ce n'est pas glamour, mais ça évite que la maintenance tourne à la roulette.

Ansible s'est imposé comme la recommandation évidente. Plusieurs commentateurs l'ont vivement conseillé, l'un d'eux affirmant que plus on commence tôt, mieux c'est. Un autre expliquait que l'automatisation était la seule chose qui ne valait pas la peine d'être remise à plus tard, parce que bien la faire vous laisse plus de temps pour tout remettre à plus tard pendant que l'infrastructure tourne comme une horloge. C'est drôle parce que c'est vrai. Les mises à jour manuelles semblent gérables jusqu'au jour où elles ne le sont plus. Les premières machines sont faciles, puis vous ajoutez des rapports, des postes Windows, des conteneurs, des nœuds distants et un serveur maudit sans IPMI, et d'un coup le YAML commence à ressembler à une forme de bien-être.

Plus de bugs, ou de meilleures lampes torches ?

Sous les plaintes sur les mises à jour se cachait aussi une question plus large : les noyaux se dégradent-ils vraiment, ou trouve-t-on simplement plus de problèmes ? Un commentateur disait ne pas savoir si le volume et la gravité des bugs avaient changé, mais supposait que les revues assistées par LLM et de meilleurs outils mettent au jour des problèmes techniques passés inaperçus jusque-là. Un autre ajoutait que le nombre de CVE du noyau augmente à cause de nouveaux outils, d'un examen plus poussé et de changements dans la façon de classer les problèmes. La distinction est importante. Davantage de bugs signalés ne veut pas toujours dire qu'un logiciel s'effondre ; parfois, l'éclairage est simplement plus fort.

Bien sûr, un éclairage plus fort révèle quand même des pièces peu reluisantes. Que les failles soient nouvelles ou fraîchement découvertes, les admins doivent les corriger, et c'est la partie inconfortable. Un processus de sécurité plus sain peut paraître pire au quotidien parce qu'il produit plus de travail visible. La machine n'a jamais été magiquement sûre avant ; vous receviez juste moins de rappels. Désormais, chaque changelog apporte sa petite dose d'anxiété. Un commentateur conseillait de lire le changelog directement dans l'interface graphique en cliquant sur le paquet du noyau puis en ouvrant le changelog. Bon conseil, parce que le mystère aggrave la lassitude et que savoir ce qui a changé donne une raison au redémarrage.

La maintenance devient adulte

La réponse honnête à la question de départ n'a rien de net. Oui, il y a eu beaucoup de mises à jour du noyau. Oui, beaucoup sont liées à de vrais correctifs de sécurité. Oui, le rythme est fatigant. Et oui, les ignorer est en général le pari le plus risqué. Les utilisateurs Proxmox sont coincés au même endroit que le reste de l'infrastructure moderne, avec plus d'examen, plus de correctifs, plus de divulgations et plus de responsabilités. C'est pénible, sans pour autant signifier que tout est fichu.

La voie la plus saine consiste à arrêter de traiter chaque mise à jour du noyau comme un rituel sur mesure et à installer un rythme. Lisez les changelogs, gardez des options de rollback et ne supprimez pas trop vite les noyaux qui ont fait leurs preuves. Automatisez ce qui peut l'être, et échelonnez les mises à jour au lieu de les envoyer sur tous les nœuds en même temps. Assurez-vous que les machines distantes ont un plan de secours, surtout si elles n'ont pas d'IPMI. Le tapis de course des mises à jour ne ralentira peut-être pas de sitôt, mais il peut devenir moins personnel. L'objectif à viser, c'est moins de crises cardiaques par correctif, quel que soit le nombre de correctifs.