Comment bien débuter avec Yum ? Cette mine d’information !

I. Présentation

Il peut arriver que l’on cherche à récolter de l’information sur les logiciels installés au sein d’un serveur afin de connaître l’auteur de l’installation ou des configurations précédemment effectuées. Sachez qu’il existe sur le système d’exploitation GNU/Linux une base interne ô combien précieuse, car elle est capable de décrire l’histoire de la vie d’une machine aussi efficacement que n’importe quel agent. Je veux parler du gestionnaire de paquetage yum (Yellowdog Updater Modified).

REMARQUE : dans les fonctionnalités, sur des distributions Debian ou dérivées, le gestionnaire de paquetage s’appelle aptitude et possède globalement les mêmes fonctions que yum. Seules les commandes diffèrent légèrement.

Ainsi, sur n’importe quelle distribution de type CentOS (ou dérivées : RedHat, Fedora et compagnie), cet utilitaire est présent et va permettre aux administrateurs de connaître dans les moindres détails les logiciels ou programmes installés. Il me semble important, alors qu’on parle en coulisse de remplacer yum par un autre utilitaire issu de Fedora : DNF, de lister un peu plus précisément de quoi est capable cette commande.

II. Les fonctionnalités

Comme on vient de le dire yum est avant tout, un gestionnaire de paquets, utilisé par certaines distributions Linux comme CentOS, Fedora, RedHat, etc. Il permet de gérer l’installation et la mise à jour des logiciels installés sur le système d’exploitation. Il s’agit d’une surcouche de RPM, gérant à la fois les dépendances et les téléchargements de la même façon, que le fait APT sur Debian vis-à-vis d’Aptitude.

REMARQUE : sous GNU/Linux tout est fichier, y compris les paquets logiciels permettant d’ajouter ou retirer des fonctionnalités au système d’exploitation. Ainsi, un paquetage (ou paquet), contient l’ensemble des fichiers nécessaires au bon fonctionnement d’un programme : binaires, bibliothèques, fichier de configuration, etc.

Tout paquet RPM (du moins sur des distributions CentOS ou dérivées), possède l’extension .rpm (pour RedHat Package Manager), par opposition au paquetage Debian, qui possède l’extension .deb. En résumé, yum peut :

  • Lister les mises à jour disponibles
  • Lister les paquets installés
  • Rechercher un paquet particulier
  • Installer/Désinstaller un paquet
  • Mettre à jour le système d’exploitation

Mais, outre ce genre d’utilisation, nous verrons également qu’il est possible de se faire avertir de nouvelles mises à jour ou de disposer de plus d’informations concernant paquetages et les dépôts associés.

III. Utilisation basique de yum

Commençons par voir les informations que l’on peut tirer de yum ainsi que sa configuration basique. Dans son utilisation standard, yum possède un fichier de configuration dans /etc appelé yum.conf. Si l’on parcourt rapidement ce fichier, on découvre alors que le gestionnaire de paquets possède un cache dont l’emplacement est précisé par la variable cachedir, impliquant donc que l’on peut également connaitre à tout moment les dernières transactions effectuées. Ce cache peut être rafraîchit grâce à la commande ci-dessous :

# yum makecache

Tout message en sortie concernant les paquets sont journalisés par défaut, dans le fichier /var/log/yum.log. Cet emplacement peut également être modifié via la variable logfile.

ATTENTION : les versions des paquetages sont liées à la version du système d’exploitation via la variable distroverpkg. Cette dernière est également en relation avec la gestion des dépôts se trouvant dans /etc/yum.repos.d. On ne peut donc mixer des paquets d’une version non compatibles avec celle du système d’exploitation.

Ce même fichier contient également une variable d’ajustement des métadonnées engrangées : metadata_expire. Par défaut, la durée limite est de 90 jours. Ce délai laisse suffisamment de temps pour ne pas avoir à rechercher ces métadonnées et gagner ainsi en performance. Le fichier de logs, quant à lui, permet de lister l’ensemble des transactions effectuées:

Jan 16 10:29:15 Installed: 1:php-pear-1.9.4-21.el7.noarch

Jan 16 10:29:15 Installed: php-pear-MDB2-2.5.0-0.9.b5.el7.noarch

Jan 16 10:29:15 Installed: php-pear-Net-Socket-1.0.14-1.el7.noarch

Jan 16 10:29:15 Installed: php-pear-DB-1.7.14-6.el7.noarch

Jan 16 10:29:16 Installed: php-pear-Auth-SASL-1.0.6-5.el7.noarch

Jan 16 10:29:16 Installed: php-pear-Net-SMTP-1.7.2-1.el7.noarch

Jan 16 10:29:16 Installed: php-pear-Mail-1.3.0-1.el7.noarch

Jan 16 10:29:16 Installed: libmcrypt-2.5.8-13.el7.x86_64

Jan 16 10:29:16 Installed: perl-DBD-MySQL-4.023-5.el7.x86_64

Jan 16 10:29:16 Installed: php-pdo-5.4.16-42.el7.x86_64

Jan 16 10:29:16 Installed: php-mysql-5.4.16-42.el7.x86_64

Jan 16 10:29:17 Installed: 1:mariadb-5.5.52-1.el7.x86_64

 

Là où cela devient vraiment intéressant, c’est qu’en plus de cela, yum possède une base interne yumdb, permettant de lister ou rechercher de l’information sur l’ensemble des paquetages ou des dépôts existants, sur le serveur. Il est d’ailleurs possible de vérifier la cohérence de cette même base grâce à la commande : yum check. En exécutant la commande ci-dessous, on peut alors récupérer la liste complète des paquets installés, ainsi que les dépôts associés, la version des paquets, etc. :

# yum list

On devrait alors récupérer les informations sous la forme suivante :

On peut aussi se servir de cette option pour ne lister que certains packages. Le caractère joker ‘*’ peut être utiliser. C’est d’ailleurs valable pour toute commande nécessitant une recherche :

# yum list php*

Si l’on souhaite ne faire afficher que les paquets précédemment installés, on peut exécuter la commande suivante :

# yum list installed

Il est alors facile de rechercher un paquet parmi ceux déjà installés, en exécutant l’instruction suivante :

# yum search <Package>

Il est également possible de fournir de l’information sur un paquet en particulier, dans la mesure où l’on connait son nom, en utilisant la directive ‘info’ :

Exemple : lister les informations concernant le package yum :

REMARQUE : lorsqu’il est fait mention du dépôt anaconda, cela signifie que le paquet en question est installé dès l’initialisation du système. Dans les autres cas, le nom du dépôt est mentionné en face du champ Repo.

Le fait de disposer de dépôt permet ainsi de pouvoir installer ou désinstaller à volonté des paquets. Afin de connaître les dépôts dont dispose le serveur, il suffit simplement d’interroger la base locale via la commande suivante :

# yum repolist

Cela permet alors de lister les différents dépôts présents sur le système d’exploitation :

REMARQUE : si l’on souhaite disposer de plus d’informations concernant un dépôt, on peut utiliser l’option repoinfo :

# yum depoinfo <Repo>

Cela permettra de récupérer l’emplacement, la constitution du dépôt sa taille ainsi que la date de mise à jour, comme ci-dessous avec le dépôt ‘base’ :

La recherche peut aussi être effectuée dans l’autre sens. Imaginons que l’on recherche quel package fournit une commande ou un programme particulier. Dans ce cas, on utilisera alors l’instruction ‘provides’ pour déterminer à quel package appartient cette commande.

Exemple :recherche du package fournissant la commande df :

Il est alors facile d’installer un nouveau paquetage grâce à la commande ci-dessous, dès lors que l’on a identifié le dépôt dans lequel se trouve le nouveau programme :

#yum install <Package>

A l’inverse, il est possible de supprimer de la même façon un paquet :

# yum remove <Package>

Dès lors, on peut alors voir la liste des packages que l’on peut mettre à jour au niveau du système d’exploitation :

# yum check-update

On peut alors effectuer la mise à jour du système complet en exécutant la commande suivante :

# yum update

ATTENTION : la mise à jour complète du système peut s’avérer une opération très longue. Il est conseillé de prévoir plusieurs minutes voire, plusieurs heures. De plus, comme cela modifie l’ordre de dépendances, il peut y avoir des incompatibilités. Il est donc conseillé de commencer par mettre à jour en premier les machines de tests.

Ou, on peut également choisir de ne mettre à jour qu’un package particulier :

# yum update <Package>

Comme yum est une surcouche de RPM, il est possible de mettre à jour localement un package ou le système en utilisant l’une des options suivantes :

  • localinstall
  • localupdate

Ainsi, il suffit simplement de fournir le ou les packages .rpm. Dans le cas où cela est requis, on peut être amené à spécifier un dépôt pour résoudre les dépendances. Si l’on souhaite éviter de répondre en dynamique aux différentes questions proposées lors des requêtes yum, il suffit d’ajouter –y dans la commande :

# yum –y update

Enfin, afin de permettre de faire un peu de place sur le disque du système, on peut être amené à supprimer ce dont yum n’a plus besoin. A cet égard, on doit alors utiliser la commande :

# yum clean all

Rappelons que les fichiers rapatriés par l’utilitaire de gestion de paquets sont stockés dans /var/cache/yum qu’il est alors facile de scruter au travers des sous-répertoires retraçant l’arborescence sous forme des différents dépôts reconnus et actifs. Si l’on souhaite retracer l’intégralité de l’historique des transactions yum, il suffit d’interroger :

# yum history [summary]

On obtient alors les vingt dernières opérations avec le détail des opérations (installation, suppression, mise à jour) leur date et le compte ayant agi (en ajoutant l’option summary on obtient un condensé de cette liste):

De même, en utilisant l’option stats cela permet de récupérer un ensemble de statistiques générales sous la forme suivante :

REMARQUE : on notera au passage que les informations sont stockées au sein d’une base SQLite dans /var/lib/yum/history dont on peut aussi explorer l’arborescence.

De plus, yum utilise un mécanisme de transaction pour travailler. Aussi, il enregistre chacune de ses actions et permet aussi de les rejouer ou de les annuler. On peut disposer d’information concernant une transaction particulière :

# yum history info <n°>

On peut alors rejouer cette même transaction grâce à la commande ci-dessous :

# yum history redo <n°>

Comme on s’en doute, à l’inverse, pour annuler une transaction on peut simplement exécuter la commande suivante :

# yum history undo <n°>

IV. Fonctionnalités avancées de yum

Parfois, il arrive que l’on souhaite effectuer une mise à jour sélective, sans pour autant endommager le noyau actuel. Or, le noyau, au même titre que les autres programmes binaires peut être mis à jour via le gestionnaire yum. Pour pallier à ce problème, on peut utiliser l’option --exclude de la façon suivante :

# yum --exclude=kernel* update

Ainsi, tous les paquets, à l’exception du noyau, seront mis à jour. Cela s’applique évidemment aux autres paquets que le noyau lui-même :

# yum --exclude=<Package> update

ASTUCE : il existe également une option permettant d’exclure aussi un dépôt : --disablerepo. De la sorte, on peut désactiver temporairement ou non un dépôt de la liste officielle pour effectuer une installation ou une mise à jour. Dans le sens inverse, pour réhabiliter un dépôt précédemment désactivé, il suffit d’utiliser l’option --enablerepo.

# yum --disablerepo=<Repo> update

Une autre fonctionnalité intéressante, permettant de contourner un niveau accru de sécurité du système, consiste à utiliser l’option --installroot. Cela spécifie un répertoire alternatif, relatif à l’emplacement où les différents paquets seront installés. On peut voir cela comme un mécanisme permettant de s’affranchir d’un cantonnement chroot. En d’autres termes, tant que l’on n’utilise pas cette option, on doit exécuter les requêtes yum suivantes :

# chroot <Directory> yum

Avec cette option, on peut se passer de "chrooter" la commande qui devient alors beaucoup plus simple :

# yum --installroot=<Directory> install <Package>

L’utilitaire yum possède même une option permettant de remplacer une version courante d’un package par une version antérieure. On parle alors d’opération de "downgrade" :

# yum downgrade <Package>

En guise d’informations, on peut récolter l’ensemble des paquets installés, disponibles, n’appartenant à aucun groupe ou au contraire assemblé en groupe. Dans un tout autre registre, on peut également récupérer les dépendances d’un paquet :

# yum deplist <Package>

Exemple :liste de dépendance pour le package yum :

REMARQUE : l’utilitaire yum possède également un interpréteur de commande permettant de grouper plusieurs transactions en une seule. Pour l’invoquer il suffit d’exécuter la commande ci-dessous. Il est possible d’utiliser des scripts shells ou des scripts yum:

# yum shell <Script>

Un autre aspect intéressant de l’utilitaire yum est que l’on peut le “proxyfier“ en ajoutant les lignes suivantes dans le fichier /etc/yum.conf (en remplaçant l’adresse et le port par ceux qui vous convient):

proxy=http://10.250.54.50:8080/

proxy_username=<User>

proxy_password=<Passwd>

Cela permet alors d’interroger le serveur proxy afin de s’assurer d’aller chercher les dépôts de paquets à cette adresse.

V. Automatiser les alertes de mises à jour

En plus de ces fonctionnalités de base que l’on vient de balayer rapidement, il existe quelques modules intéressants permettant d’étendre les fonctionnalités de l’outil. Lorsque l’on administre un ensemble de machines Linux, il peut s’avérer utile d’être averti en avance de phase des différentes mises à jour disponibles. On va alors mettre en œuvre le module yum-cron :

# yum install yum-cron

Cela permettra alors d’envoyer un message dès qu’une mise à jour d’un paquet, se trouvant sur le système d’exploitation, est détectée. La configuration s’effectue dans le fichier /etc/yum/yum-cron.conf et on doit notamment positionner les options suivantes :

exclude=kernel* mysql*

update_messages=yes

download_updates=yes

apply_updates=yes

email_to=phil@mydmn.org         # adresse de messagerie



[commands]

# What kind of update to use:

# default                                             = yum upgrade

# security                                  = yum --security upgrade

# security-severity:Critical           = yum --sec-severity=Critical upgrade

# minimal                                = yum --bugfix upgrade-minimal

# minimal-security                      = yum --security upgrade-minimal

# minimal-security-severity:Critical = --sec-severity=Critical upgrade-minimal

update_cmd = default

Cet outil se présente comme un daemon de service qu’il faut alors activer et démarrer :

# systemctl enable yum-cron

# systemctl start yum-cron

On disposera ainsi d’un mécanisme permettant de prévenir machine par machine des différents paquets à upgrader. Pour aller plus loin, on peut centraliser les sorties via la variable emit_via en mentionnant stdio ainsi les messages ne seront plus envoyés par messagerie mais directement sur la sortie standard (redirigée dans /var/log/cron), que l’on peut alors manipuler comme un fichier standard, et envoyer sur un serveur central, pilotés par la crontab au travers du script /etc/yum/yum-cron-hourly.conf. Dans ce dernier, il faut également modifier les options suivantes :

update_cmd=security

update_messages=yes

download_updates=yes

apply_updates=yes

Cela permettra de tenir à jour régulièrement (toutes les heures en l’occurrence), le système d’exploitation et d’appliquer toute mise à jour détectée automatiquement par le système.

REMARQUE : l’autre valeur possible du paramètre emit_via est email permettant au contraire, d’envoyer un message au destinataire mentionné, dès qu’une mise à jour est détectée. Mais, cela ne permet pas de l’appliquer systématiquement.

 

VI. Faciliter les mises à jour avec la notion de groupe

La plupart des administrateurs Linux utilisant yum pour gérer leurs packages arrivent vite à la conclusion que l’administration de ces fichiers sont notablement faciliter par le regroupement de ceux-ci en groupes. En effet, au lieu d’installer un à un des packages permettant l’ajout de fonctionnalités telles que le web ou la messagerie, il suffit simplement d’installer le groupe associé. Pour se faire, il suffit déjà de lister les différents groupes existants :

# yum grouplist

Ainsi, on récupère les différents sous-ensembles de fonctionnalités regroupés entre eux :

On peut alors rechercher, par exemple le groupe permettant de faire afficher les menus graphiques du gestionnaire de fenêtre Gnome :

# yum grouplist|grep GNOME

On peut facilement obtenir de l’information concernant un groupe particulier et savoir alors quels sont les paquets le composant :

# yum groupinfo “Bureau GNOME“

On retrouve alors des informations concernant la composition du groupe de paquets sous forme de liste énumérée:

Il ne reste plus alors qu’à lancer l’installation, non plus d’un package particulier, mais du groupe complet :

# yum groupinstall "Bureau GNOME"

A l’inverse, il est possible aussi de supprimer l’intégralité des packages d’un même groupe :

# yum groupremove "Bureau GNOME "

Cela facilite alors la gestion des paquets. Car, au lieu de les gérer un à un, on peut les gérer par groupe de fonctionnalités. Si l’on a quelques difficultés à faire afficher les informations concernant les groupes, on peut convertir les groupes anciens en modèle objet, grâce à la commande suivante :

# yum groups mark convert

 

VII. Sécuriser le système de base

Les dépôts constituants la source de distribution des paquets, au sein du système GNU/Linux, sont composés de paragraphes décrivant le nom de l’archive dans laquelle on trouve alors les différents paquets. Par défaut, on trouve (du mois pour la distribution CentOS), les quatre strophes suivantes :

  • [base]: où l’on trouve les paquets de base de CentOS tels que figurant sur les images ISO ou les DVD.
  • [updates]: où l’on trouve les mises à jour de sécurité, de correction de bugs ou d’améliorations des paquets de base.
  • [extras]: où l’on trouve les paquets non intégrés par RedHat mais gérés par l’équipe CentOS.
  • [centosplus]: où l’on trouve des paquets issus de développeurs et utilisateurs de CentOS, susceptibles de remplacer ceux de base.

 

Afin de sécuriser un peu les définitions des différentes archives de paquets, on peut introduire la notion de priorité fournit par le module yum-priorities. Ce dernier, comme le module yum-cron doit être installé en supplément :

# yum install yum-plugins-priorities

Cela va permettre de définir un champ priority (avec une valeur comprise entre 1 et 99 où 1 représente la priorité la plus haute et 99 celle, la plus basse), à ajouter aux propriétés de description des archives au sein du fichier .repo. Lorsqu’on définit une priorité de 1 pour les dépôts concernant les strophes [base], [updates] et [extras] et une priorité autre pour le reste, les paquets intégrés à l’archive [centosplus] ne pourront jamais remplacer les paquets de base. L’utilitaire yum les en empêchera en les excluant de la liste.

Exemple :configuration de la priorité pour bloquer les paquets de [centosplus] :

[base]

enabled=1

priority=1

name=CentOS-$releasever - Base

...

[updates]

enabled=1

priority=1

name=CentOS-$releasever - Updates

...

[extras]

enabled=1

priority=1

name=CentOS-$releasever - Extras

...

En laissant le dépôt [centosplus] désactivé (c’est-à-dire, en ne déclarant aucune priorité dans la définition de la strophe [centosplus]), cela permet d’empêcher toute substitution ou remplacement de paquet de l’archive [base] par ceux de [centosplus] et de se trouver avec des dysfonctionnements incompréhensibles.

 

D’autre part, il existe un dépôt [cr], permettant d’obtenir les dernières mises à jour de paquet et de migrer de façon mineure vers ces versions récentes, avant la sortie de l’image ISO officielle. Ainsi, on évite des vagues de mises à jour, lors du passage à la nouvelle version majeure de la distribution CentOS. Pour mettre ce mécanisme en place, on peut utiliser la commande yum-config-manager (généralement fournit avec e paquet yum-utils), qui permet également d’activer le nouveau dépôt [cr].

# yum-config-manager --enable cr

Ainsi, on peut éditer le fichier de description des dépôts CentOS se trouvant dans le répertoire /etc/yum.repos.d pour ajouter les lignes suivantes :

[cr]

enabled=1

priority=1

name=CentOS-$releasever - cr

baseurl=http://mirror.centos.org/centos/$releasever/cr/$basearch/

gpgcheck=1

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

REMARQUE : en plus d’activer ce nouveau dépôt, il est fortement conseillé d’ajouter également le dépôt EPEL (Extra Packages for Enterprise Linux) fournissant des paquets non inclus dans la distribution CentOS et ajoutant nombre de fonctionnalités, sous forme de paquets à installer:

[epel]

enabled=1

priority=15

name=Extra Packages for Enterprise Linux 7 - $basearch

Mentionnons également l’existence de nombreux autres dépôts utiles, orientés fonctions étendus de la distribution CentOS :

  • Dépôt Nux-Dextop orienté poste de travail et multimédia
  • Dépôt Adobe orienté Macromedia flash
  • Dépôt ELRepo orienté pilote de périphériques
  • Dépôt rpmforge orienté multimédia et présentation

VIII. Conclusion

Voilà, après ce tour d’horizon, quoique succinct, du gestionnaire de paquets, on a une meilleure idée des fonctionnalités qu’il peut proposer. On pourrait développer certainement de nombreux autres points et certaines options intéressantes de l’utilitaire. Mais, ce qui est surtout pratique c’est que l’on peut récupérer, comme on l’a vu au long de ce billet, de nombreuses informations concernant les logiciels, composant le système d’exploitation. Cela est d’autant plus vrai que yum concerne aussi bien les paquets .rpm, mais aussi ce qui touche aux dépôts. Sans avoir d'à-priori, je trouve qu'il serait temps d'uniformiser les outils de gestion de paquets entre les différentes versions en intégrant DNF (issu de Fedora). A l'instar de SystemD (même si cela à généré de la polémique), il faut reconnaître que Linux y gagnerait en clareté et en fonctionnalités. J’espère que ce tutoriel ouvrira des perspectives et permettra à nombre d’entre vous de régler les petits incidents, concernant les paquetages et les dépôts du système d’exploitation.

Partagez cet article Partager sur Twitter Partager sur Facebook Partager sur Linkedin Partager sur Google+ Envoyer par mail

Philippe PIERRE

A exercé de nombreuses années en tant qu'administrateur de base de données et comme administrateur Système Unix/Linux. Il a enseigné les réseaux au CNAM (Paris). Aujourd'hui, employé en tant qu'ingénieur infrastructure, au sein d'un laboratoire pharmaceutique et administrant un cluster de calculs HPC, il connaît parfaitement les environnements GNU/Linux dans le cadre d'une entreprise et des systèmes de haute disponibilité. Il aime partager son expérience.

    philippe-pierre has 33 posts and counting.See all posts by philippe-pierre

    Laisser un commentaire

    Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

     

    Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.