Application de correctifs aux périphériques Linux

Cette page contient des informations propres aux correctifs des périphériques Linux.

Approche sans contenu des correctifs sous Linux

La solution Ivanti de gestion des correctifs pour Linux diffère de celle utilisée pour Windows et macOS. Il est important de comprendre en quoi l'approche sans contenu des correctifs Linux diffère de l'approche basée sur le contenu des correctifs Windows et macOS, car elle modifie le moment où les données de correctif des différents systèmes d'exploitation apparaissent dans les produits Ivanti.

Voir la vidéo associée (02:44)

Pour Windows et macOS, les données de contenu de correctifs sont traitées et testées par Ivanti avant d'être publiées dans les produits pour utilisation. Pour en savoir plus sur ce processus, reportez-vous au site de la communauté Ivanti. Cette approche est nécessaire car ces systèmes d'exploitation autorisent l'installation de logiciels depuis différentes sources.

Linux a une approche différente : le déploiement et la maintenance des logiciels installés sont contrôlés via un gestionnaire de paquets connecté à des référentiels propres à la distribution. Les produits de correctifs Ivanti utilisent les sources de référentiel du périphérique pour remplir le contenu de correctifs requis lors de l'analyse des correctifs. C'est une approche sans contenu et elle rend les produits plus flexibles. Vous pouvez utiliser des référentiels tiers et internes sans qu'Ivanti ait besoin de mettre à jour son propre contenu de correctifs. De plus, dès que les mises à jour sont disponibles dans le référentiel, elles peuvent être installées sans qu'il soit nécessaire de mettre à jour le contenu de correctifs dans Ivanti.

Initialement, aucune donnée de correctif Linux n'apparaît dans Neurons tant qu'aucun périphérique n'a été analysé, et que les données de ce périphérique n'ont pas été téléchargées et traitées. Au fur et à mesure que davantage de périphériques sont analysés, toutes les données supplémentaires sont fusionnées pour fournir une image plus complète.

Ivanti Neurons for Patch Management respecte les conventions liées aux correctifs des périphériques Linux, car il effectue toujours la mise à jour vers le paquet le plus récent disponible dans le référentiel, même si une version antérieure est sélectionnée. Notez que, pour certaines distributions, c'est en réalité la seule option disponible ; les versions antérieures du paquet ne sont pas disponibles dans le référentiel.

Quand vous utilisez le gestionnaire de paquets dnf original fourni avec les distributions Linux dérivées du noyau (Kernel) Red Hat versions 8.1 à 8.4, l'analyse dnf avant déploiement peut générer des faux positifs qui n'apparaissent pas dans les résultats de l'analyse après déploiement. Ce comportement a été corrigé par Red Hat dans le gestionnaire de paquets fourni avec la version 8.5, et vous pouvez aussi le corriger avec la commande sudo dnf update dnf.

Modules et versions

Vous ne pouvez pas toujours installer la dernière version d'un paquet sur un périphérique Linux.

Pour Red Hat Linux et les distributions qui en dérivent, il est possible d'installer sur un périphérique des modules correspondant à plusieurs flux, alors qu'un seul peut être activé sur un périphérique.

Module A comporte trois flux, dont un seul est activé sur le périphérique

Prenons un exemple : Un conseil (Advisory) veut mettre à jour un paquet dans un module de ce type.

Mise à jour d'un paquet dans un module à plusieurs flux

Si la nouvelle version du paquet correspond à un flux spécifique, différent du flux activé sur le périphérique, le paquet de mise à jour n'est pas compatible et vous ne pouvez pas l'installer. Par conséquent, le fournisseur peut mettre à disposition une version du module plus récente que celle pouvant être installée sur le périphérique.

Le nouveau paquet correspond à un flux de module différent de celui activé sur le périphérique, si bien qu'il est impossible d'installer le nouveau paquet.

De même, il semble que le dernier paquet n'ait pas été installé en raison des dépendances de modules. Par exemple, le module perl-DBD-SQLite semble comprendre plusieurs mises à jour de module pour le paquet perl-DBD-SQLite :

  • perl-DBD-SQLite-0:1.58-2.module+el8.1.0+2940+55ca6856.x86_64
  • perl-DBD-SQLite-0:1.58-2.module+el8.1.0+2940+f62455ee.x86_64
  • perl-DBD-SQLite-0:1.58-2.module+el8.2.0+4265+ff794501.x86_64
  • perl-DBD-SQLite-0:1.58-2.module+el8.6.0+13408+461b4ab5.x86_64

Cependant, chacun de ces paquets comporte une dépendance envers un flux perl spécifique. Le premier ne peut être installé que si perl:5.24 est activé et le dernier, seulement si perl:5.32 est activé. Ainsi, il peut être impossible d'installer sur un périphérique spécifique ce qui semble être la dernière version d'un paquet.