Objectif
Notre objectif est de s'habituer aux outils disponibles pour trouver des informations sur les dépendances de paquets sur un système basé sur RPM.
Versions du système d'exploitation et du logiciel
- Système d'exploitation : Red Hat Enterprise Linux 7.5
- Logiciel : rpm 4.11, miam 3.4.3
Exigences
Accès privilégié au système.
Difficulté
FACILE
Congrès
- # - nécessite que les commandes linux données soient exécutées avec les privilèges root soit directement en tant qu'utilisateur root, soit en utilisant
sudocommande - $ – commandes linux données à exécuter en tant qu'utilisateur normal non privilégié
Présentation
RPM, qui signifie Red Hat Package Manager, est un gestionnaire de packages bien connu et mature utilisé par toutes les distributions de saveur Red Hat, ainsi que par SuSE. Avec RPM, le conditionneur peut définir des relations entre les packages, et même avec des versions de packages - par exemple, un serveur Apache Tomcat a besoin d'un environnement Java approprié pour pouvoir s'exécuter.
D'un autre côté, pour installer un environnement Java, vous n'avez pas besoin d'un serveur Tomcat - vous pouvez décider d'exécuter une autre application basée sur Java, peut-être une écrite par vous-même et démarrée à la main lorsque cela est nécessaire pour faire son travail. En d'autres termes, le serveur Tomcat dépend sur Java.
RPM peut rendre la vie d'un administrateur système beaucoup plus facile en présentant ces dépendances - et les outils reposant sur RPM tels que le rpm utilitaire, ou yum peut résoudre automatiquement ces dépendances et installer tous les packages supplémentaires nécessaires au bon fonctionnement d'un nouveau composant.
Collecte d'informations
Pour connaître la liste des packages dont dépend le package foo.bar, exécutez simplement :
# yum deplist foo.bar
Et pour trouver la liste des packages qui nécessitent (dépendent) du package foo.bar :
rpm -q --whatrequires foo.bar
Un exemple concret avec un package générique :bash . Voyons quels packages ont besoin du package bash :
# yum deplist bash
package: bash.x86_64 4.2.46-30.el7
dependency: libc.so.6()(64bit)
provider: glibc.x86_64 2.17-222.el7
dependency: libc.so.6(GLIBC_2.11)(64bit)
provider: glibc.x86_64 2.17-222.el7
dependency: libc.so.6(GLIBC_2.14)(64bit)
provider: glibc.x86_64 2.17-222.el7
dependency: libc.so.6(GLIBC_2.15)(64bit)
provider: glibc.x86_64 2.17-222.el7
dependency: libc.so.6(GLIBC_2.2.5)(64bit)
provider: glibc.x86_64 2.17-222.el7
dependency: libc.so.6(GLIBC_2.3)(64bit)
provider: glibc.x86_64 2.17-222.el7
dependency: libc.so.6(GLIBC_2.3.4)(64bit)
provider: glibc.x86_64 2.17-222.el7
dependency: libc.so.6(GLIBC_2.4)(64bit)
provider: glibc.x86_64 2.17-222.el7
dependency: libc.so.6(GLIBC_2.8)(64bit)
provider: glibc.x86_64 2.17-222.el7
dependency: libdl.so.2()(64bit)
provider: glibc.x86_64 2.17-222.el7
dependency: libdl.so.2(GLIBC_2.2.5)(64bit)
provider: glibc.x86_64 2.17-222.el7
dependency: libtinfo.so.5()(64bit)
provider: ncurses-libs.x86_64 5.9-14.20130511.el7_4
dependency: rtld(GNU_HASH)
provider: glibc.x86_64 2.17-222.el7
provider: glibc.i686 2.17-222.el7
Du point de vue du package, bash est très générique et, comme indiqué ci-dessus, dépend de quelques packages de base. Mais si nous souhaitons installer quelque chose de beaucoup plus dépendant, disons, le konzole Émulateur de terminal KDE sur Red Hat Linux avec un gestionnaire de bureau Gnome, nous pouvons obtenir une liste de dépendances de plus d'une page. Et avec konzole , le cas est encore plus compliqué, car il repose sur les packages QT et KDE, donc pour l'installer, vous devrez installer tout l'environnement KDE à côté de Gnome (ce que vous pouvez certainement faire) pour fournir tout konzole besoins.
Pour avoir un meilleur aperçu des packages qui seront installés, consultez la liste fournie par yum avant de commencer l'installation :
# yum install konsole
Resolving Dependencies
--> Running transaction check
---> Package konsole.x86_64 0:4.10.5-4.el7 will be installed
--> Processing Dependency: konsole-part = [...]
Dans le cas d'un système Red Hat avec Gnome, cela peut prendre un certain temps pour résoudre les dépendances d'une application KDE pour la première fois, et quand cela sera terminé, yum présentera le seul paquet que nous avons demandé, avec une belle petite taille . Suivi de plus d'une centaine de packages installés pour les dépendances :
[...]
--> Running transaction check
---> Package boost-system.x86_64 0:1.53.0-27.el7 will be installed
---> Package boost-thread.x86_64 0:1.53.0-27.el7 will be installed
--> Finished Dependency Resolution
Dependencies Resolved
==============================================================================================================================
Package Arch Version Repository Size
==============================================================================================================================
Installing:
konsole x86_64 4.10.5-4.el7 rhel-7-server-rpms 78 k
Installing for dependencies:
OpenEXR-libs
[...]
Et dans le résumé on peut voir que l'installation va utiliser beaucoup plus d'espace sur le disque au final, puis la taille du paquet dont on a besoin :
[...]
Transaction Summary
==============================================================================================================================
Install 1 Package (+120 Dependent packages)
Total download size: 108 M
Installed size: 307 M
C'est beaucoup, mais nous avons obtenu une information utile sur la quantité d'espace qui sera utilisée. Ceci est particulièrement utile si nous installons de nombreux packages en une seule transaction.
Alors que dans ce cas, la transaction est inutile, l'objectif des dépendances est en fin de compte d'économiser des ressources :si quelqu'un implémente une fonctionnalité dans son code, et qui peut être appelée sur le système, le prochain développeur n'aura peut-être pas besoin d'implémenter la même fonctionnalité. encore une fois, mais utilisez l'implémentation déjà existante. Pour le konzole exemple, si vous voulez installer akregator la prochaine fois, le système aura déjà résolu de nombreuses dépendances, comme kdepim paquet contenant akregator repose également sur qt , kdelibs , et autres.
Nous pouvons utiliser rpm utilitaire pour obtenir les informations dans l'autre sens :listons les packages installés qui nécessitent le bash paquet :
# rpm -q --whatrequires bash
dracut-033-535.el7.x86_64
initscripts-9.49.41-1.el7.x86_64
autofs-5.0.7-83.el7.x86_64
lvm2-2.02.177-4.el7.x86_64
rsyslog-8.24.0-16.el7.x86_64
Nettoyer les paquets inutiles
Si nous gardons nos systèmes à jour et modifions ou étendons leurs rôles, des packages « indésirables » apparaîtront inévitablement. Dans le sens du paquet, le courrier indésirable signifie des paquets qui ne sont plus nécessaires et/ou obsolètes. Pour suivre l'exemple ci-dessus, nous n'avons plus besoin de akregator , parce que nous avons déplacé le "service" de gestion RSS vers un hypothétique concentrateur RSS central au sein de notre système, donc après avoir migré nos flux vers l'emplacement central, nous désinstallons l'application locale de gestion RSS. Cela ne supprimera pas tous les packages KDE, car de nombreux autres packages peuvent en dépendre. Mais sinon, ces packages sont indésirables et consommeront des ressources, y compris des temps de mise à jour plus longs, comme yum par défaut mettra à jour tout aveuglément pour lequel il trouve de nouveaux paquets/errata.
Dépenser des ressources pour mettre à niveau quelques packages inutiles sur un ordinateur portable avec connexion haut débit et SSD peut ne pas sembler être un problème, mais imaginez un centre de données avec des centaines ou des milliers d'ordinateurs, et vous obtenez l'image. C'est généralement une bonne idée de garder tous les systèmes simples, et la gestion des ressources n'est qu'un point. Plus un système est complexe, plus il est sujet aux erreurs. Plus de composants signifie plus de bugs possibles.
Pour avoir un aperçu des packages inutiles installés sur le système, nous pouvons utiliser yum et package-cleanup de la même manière que sur CentOS, ou une autre fonctionnalité de yum, autoremove :
yum autoremove
Les packages que ces outils marquent comme inutiles ne sont pas identiques.
Lorsque vous utilisez l'un de ces outils, il est conseillé de revérifier ce que yum va supprimer, et éventuellement tester le résultat du nettoyage sur des machines de test avec un contenu d'emballage identique avant de nettoyer les systèmes de production.
Ces outils sont en effet intelligents, mais pas omniscients :par exemple, il n'y aura aucune entrée dans la base de données rpm concernant une application PHP personnalisée exécutée sur un serveur Web qui appelle cups pour imprimer les commandes entrantes sur une imprimante connectée au serveur. Autrement dit, il peut être une entrée si l'application est empaquetée avec les bonnes dépendances incluses et installée correctement avec rpm ou yum - mais cela demande des efforts, et tous les services doivent être regroupés de la même manière si vous voulez vous sentir en sécurité avec les nettoyages automatiques basés sur yum.
Résoudre les problèmes de dépendance
Surtout dans les grands environnements, il peut y avoir des problèmes de dépendance lors de l'installation ou de la mise à niveau des systèmes.
La capture d'écran ci-dessous montre un problème simple :
Résoudre les dépendances avec rpm
Dans l'écran de terminal ci-dessus, nous essayons d'installer le nrpe package, le client avait besoin de surveiller de nombreux aspects du système avec Nagios. Nous avons téléchargé le client pour la distribution, mais les deux rpm et yum échoue avec la même erreur :le nrpe le paquet nécessite (dépend de) le nagios-common emballer. Dans cet exemple, nous pouvons obtenir le package nécessaire à partir de la même source, et lors de l'installation des deux, le rpm L'utilitaire voit que la dépendance sur laquelle nous avons échoué précédemment sera satisfaite à la fin de la transaction et installe les deux packages, en quittant silencieusement avec succès.
Conclusion
Yum et rpm sont des outils essentiels lorsque vous travaillez avec des distributions à l'aide du gestionnaire de packages RPM. En connaissant l'ensemble d'outils, il est beaucoup plus facile et généralement plus sûr de résoudre les tâches d'installation, de mise à niveau et de modification sur l'environnement logiciel d'un système donné.