Objetivo
Nuestro objetivo es acostumbrarnos a las herramientas disponibles para encontrar información sobre las dependencias de los paquetes en un sistema basado en RPM.
Sistema operativo y versiones de software
- Sistema operativo: Red Hat Enterprise Linux 7.5
- Software: rpm 4.11, mmm 3.4.3
Requisitos
Acceso privilegiado al sistema.
Dificultad
FÁCIL
Convenios
- # – requiere que los comandos de Linux dados se ejecuten con privilegios de root, ya sea directamente como usuario root o mediante el uso de
sudocomando - $ – comandos de Linux dados para ser ejecutados como un usuario regular sin privilegios
Introducción
RPM, que significa Red Hat Package Manager, es un administrador de paquetes bien conocido y maduro que utilizan todas las distribuciones de Red Hat, así como SuSE. Con RPM, el empaquetador puede definir relaciones entre paquetes, e incluso con versiones de paquetes; por ejemplo, un servidor Apache Tomcat necesita un entorno Java adecuado para poder ejecutarse.
Por otro lado, para instalar un entorno Java, no necesita un servidor Tomcat; puede decidir ejecutar alguna aplicación diferente basada en Java, tal vez una escrita por usted mismo e iniciada a mano cuando sea necesario para hacer su trabajo. En otras palabras, el servidor Tomcat depende en Java.
RPM puede hacer que la vida de un administrador de sistemas sea mucho más fácil al presentar estas dependencias y herramientas que dependen de RPM, como rpm utilidad, o yum puede resolver automáticamente estas dependencias e instalar todos los paquetes adicionales necesarios para que un nuevo componente funcione correctamente.
Recopilación de información
Para averiguar la lista de paquetes de los que depende el paquete foo.bar, simplemente ejecute:
# yum deplist foo.bar
Y para encontrar la lista de paquetes que requieren (dependen del) paquete foo.bar:
rpm -q --whatrequires foo.bar
Un ejemplo de la vida real con un paquete genérico:bash . Veamos qué paquetes necesita el paquete 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
Desde la perspectiva del paquete, bash es muy genérico y, como se ve arriba, depende de algunos paquetes principales. Pero si quisiéramos instalar algo mucho más dependiente, digamos, el konzole Emulador de terminal KDE en Red Hat Linux con un administrador de escritorio Gnome, es posible que obtengamos una lista de dependencias de más de una página. Y con konzole , el caso es aún más complicado, ya que se basa en los paquetes QT y KDE, por lo que para instalarlo, deberá instalar todo el entorno KDE además de Gnome (lo que ciertamente puede hacer) para proporcionar todo konzole necesidades.
Para obtener más información sobre qué paquetes se instalarán, consulte la lista proporcionada por yum antes de comenzar la instalación:
# 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 = [...]
En el caso de un sistema Red Hat con Gnome, puede llevar bastante tiempo resolver las dependencias de una aplicación de KDE por primera vez, y cuando termine, yum presentará el único paquete que solicitamos, con un tamaño pequeño y agradable. . Seguido por más de cien paquetes instalados para dependencias:
[...]
--> 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
[...]
Y en el resumen podemos ver que la instalación usará mucho más espacio en el disco al final, entonces el tamaño del paquete que necesitamos:
[...]
Transaction Summary
==============================================================================================================================
Install 1 Package (+120 Dependent packages)
Total download size: 108 M
Installed size: 307 M
Esto es mucho, pero obtuvimos información útil sobre cuánto espacio se usará. Esto es especialmente útil si instalamos muchos paquetes en una sola transacción.
Si bien en este caso la transacción es un desperdicio, el objetivo de las dependencias es, en última instancia, ahorrar recursos:si alguien implementa alguna funcionalidad en su código, y eso se puede llamar en el sistema, es posible que el próximo desarrollador no necesite implementar la misma funcionalidad. nuevamente, pero use la implementación ya existente. Para el konzole ejemplo, si desea instalar akregator la próxima vez, el sistema ya tendrá muchas dependencias resueltas, como kdepim paquete que contiene akregator también se basa en qt , kdelibs , y tal.
Podemos usar rpm utilidad para obtener la información al revés:enumeremos los paquetes instalados que requieren el bash paquete:
# 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
Limpieza de paquetes innecesarios
Si mantenemos nuestros sistemas actualizados y cambiamos o ampliamos sus roles, inevitablemente aparecerán paquetes “basura”. En el sentido de paquete, basura significa paquetes que ya no se necesitan y/o obsoletos. Para seguir el ejemplo anterior, ya no necesitamos akregator , porque movimos el “servicio” de manejo de RSS a un concentrador de RSS central hipotético dentro de nuestro sistema, por lo que después de migrar nuestros feeds al lugar central, desinstalamos la aplicación de manejo de RSS local. Eso no eliminará todos los paquetes de KDE, ya que muchos otros paquetes pueden depender de ellos. Pero si no, esos paquetes son basura y consumirán recursos, incluidos tiempos de actualización más largos, como yum por defecto actualizará todo a ciegas para lo que encuentre nuevos paquetes/erratas.
Gastar recursos en actualizar algunos paquetes innecesarios en una computadora portátil con conexión de banda ancha y SSD puede no parecer un problema, pero imagine un centro de datos con cientos o miles de computadoras y obtendrá una imagen. En general, es una buena idea mantener todos los sistemas simples y la administración de recursos es solo un punto. Cuanto más complejo es un sistema, más propenso a errores es. Más componentes significan más errores posibles.
Para obtener una descripción general de los paquetes innecesarios instalados en el sistema, podemos usar yum y limpieza de paquetes de la misma manera que en CentOS, u otra característica de yum, autoremove :
yum autoremove
Los paquetes que estas herramientas marcan como innecesarios no son idénticos.
Al usar cualquiera de estas herramientas, se recomienda verificar dos veces qué yum va a eliminar, y posiblemente pruebe en qué resultará la limpieza en máquinas de prueba con contenido de paquete idéntico antes de limpiar los sistemas de producción.
Estas herramientas son realmente inteligentes, pero no lo saben todo:por ejemplo, no habrá entrada en la base de datos rpm sobre una aplicación PHP personalizada que se ejecuta en la parte superior de un servidor web que llama a cups para imprimir los pedidos entrantes en una impresora conectada al servidor. Es decir, puede ser una entrada si la aplicación se empaqueta con las dependencias correctas incluidas y se instala correctamente con rpm o yum – pero eso requiere esfuerzo, y todos los servicios deben empaquetarse de la misma manera si desea sentirse seguro con las limpiezas automáticas basadas en yum.
Resolviendo problemas de dependencia
Especialmente en entornos grandes, puede haber problemas de dependencia al instalar o actualizar sistemas.
La siguiente captura de pantalla muestra un problema simple:
Resolviendo dependencias con rpm
En la pantalla de terminal anterior, intentamos instalar el nrpe paquete, el cliente necesitaba monitorear muchos aspectos del sistema con Nagios. Descargamos el cliente para la distribución, pero ambos rpm y yum falla con el mismo error:el nrpe el paquete requiere (depende de) el nagios-common paquete. En este ejemplo podemos obtener el paquete necesario de la misma fuente, y al instalar ambos el rpm La utilidad ve que la dependencia en la que fallamos anteriormente se satisfará al final de la transacción e instala ambos paquetes, saliendo silenciosamente con éxito.
Conclusión
Yum y rpm son herramientas esenciales cuando se trabaja con distribuciones utilizando el administrador de paquetes RPM. Al conocer el conjunto de herramientas, es mucho más fácil y, por lo general, más seguro resolver tareas de instalación, actualización y modificación en el entorno de software de un sistema determinado.