Capítulo 3
Manejo de paquetes
Para
administrar un sistema debemos saber cómo gestionar los programas.
Esto comprende la instalación y desinstalación mediante yum
y rpm.
A veces por políticas de seguridad nuestro equipo no tendrá salida
a Internet y tendremos que instalar un repositorio local para
descargar los programas, aunque en la mayoría de la ocasiones
podremos conectarlo a la RHN, que es el sistema de actualizaciones de
Red Hat.
Entendiendo el concepto de paquete
Un paquete
en un sistema Linux es lo que un programa de instalación ejecutable
es a los sistemas Windows. Cada distribución de Linux tiene su
principal sistema de paquetes. Por ejemplo, la distribución Debian
y sus derivados como Ubuntu, Knoppix
y una centena más utilizan el sistema de paquetes DEB; mientras que
la distro Slackware
y sus derivados utilizan TGZ, el cual empaqueta los archivos
utilizando las aplicaciones tar y gzip. En los sistemas RHEL, y por
ende las centenares de distribuciones que se basan en él (por
ejemplo, Mandriva
y SuSE
que son los más populares), utilizan el sistema de paquetes creador
por la propia corporación Red Hat: RPM.
Un administrador de paquetes permitirá instalar, actualizar,
desinstalar, verificar y solicitar programas.
La
pregunta que surge ahora es: ¿que contiene cada paquete?
Sencillamente contiene meta-información
tal como fecha de creación, descripción del mismo y sus
dependencias. Esta información es analizada por el sistema de
paquetes permitiendo la búsqueda de paquetes en el sistema, la
actualización de las librerías y aplicaciones instaladas, la
verificación de satisfacción de dependencias y su obtención en
caso de no estar instaladas.
Centrándonos
en los paquetes RPM,
que son los nativos en RHEL, estos siguen una nomenclatura clásica,
a saber: paquete-version-revision.arquitectura.rpm.
Esto significa que cada paquete tiene su nombre, su versión
principal, su número de revisión, la arquitectura en la que debe
instalarse (i686
si es 32 bits o x86_64
si es de 64 bits, entre otras) y por supuesto, la extensión del
paquete (rpm).
El contenido específico de cada archivo con extensión rpm
será un archivo comprimido en formato binario especial que contendrá
archivos con información tales como:
Archivos
a instalar: Binarios, Documentación,
Configuración por defecto.
Archivos
de resumen: Descripción y cambios en la
programa o nueva versión del programa.
Archivos
de instrucciones: Pre
y post
instalación, dependencias requeridas y sentencias de desinstalación.
Archivo
de verificación de firmas:
Para comprobar su integridad.
Comprobar la autenticidad de un paquete
Los
paquetes con extensión rpm
de RHEL están firmados con la herramienta GnuPG,
esto significa que podremos comprobar si el paquete a descargar y/o
instalar procede realmente de Red Hat. Por ejemplo, supongamos que
hemos descargado de Internet el archivo rpm de la última versión de
apache, y no es un sitio de confianza o simplemente queremos
asegurarnos de su procedencia, escribiendo:
$ rpm --checksig
apache-2.2.17.rpm
Primeramente
se verificará si las dependencias del paquete a instalar están
satisfechas, ya que de lo contrario podrían aparecer conflictos.
Solo en este caso se instalará el programa, ya que si aparecen
mensajes de error indicando los paquetes que faltan para cumplir con
las dependencias, rpm abortará. El administrador de paquetes rpm
contiene una pequeña base de datos que se encargará de evitar
conflictos siguiendo reglas básicas como que normalmente un archivo
debe pertenecer a un solo paquete, aunque pueden existir excepciones.
Por otro lado, para la actualización de un paquete las opciones
recomendable son -U
o --upgrade
y -F
o --freshen.
Una simple manera de actualizar un paquete es escribiendo:
$ rpm -F paquete.rpm
Aquí se
eliminará la antigua versión de un paquete instalando la nueva. La
diferencia entre los parámetros -F
y -U
radica en que en el caso de este último también se instalarán
paquetes que hasta ahora no estaban disponibles en el sistema,
mientras que la primera opción sólo actualizará un paquete solo en
el caso de que el mismo ya estuviese instalado. La estrategia que
sigue el administrador de archivos rpm para actualizar es comprobar
si hemos cambiado o modificado manualmente algún archivo de
configuración del programa a actualizar, ya que caso contrario, se
instalará la nueva versión sin nuestra intervención. Pero si algo
ha cambiado, lo que hace es guardar el archivo que hemos modificado
con la extensión .rpmorig
o .rpmsave
y luego instalar la nueva versión del paquete rpm (con la excepción
de que el archivo de configuración de esta nueva versión no haya
cambiado su estructura). Hay que tener en cuenta, que probablemente
sea necesario adaptar el nuevo archivo de configuración basándonos
en la copia de seguridad realizada (con la extensión .rpmorig
o .rpmsave).
En el caso de que ya exista el archivo de configuración y dentro del
archivo .spec
del paquete el indicador aparezca la expresión noreplace
la extensión será .rpmnew.
No
olvidemos luego de la actualización borrar estos archivos (.rpmorig,
.rpmsave
y .rpmnew)
para que estos no interfieran con la siguiente actualización. La
extensión .rpmsave
se selecciona cuando la base de datos RPM ya conoce el archivo, en
caso contrario se usa .rpmorig.
Estos últimos se generan cuando se actualizan paquetes que no tienen
formato rpm y mientras que los .rpmsave
se generan actualizando paquetes que ya estaba instalados en rpm.
Dato Útil
A tener en cuenta al actualizar paquetes
El parámetro para actualizar -U
es más que una simple equivalencia de -e
(desinstalar/eliminar) e -i
(instalar), de hecho, siempre que sea posible, es preferible usar la
opción -U.
Después de cada actualización es recomendable verificar las copias
de seguridad que el administrador de paquetes generó. Para evitar
problemas, una vez revisada la configuración deberían eliminarse
los archivos con las extensiones .rpmorig
o .rpmsave.
YUM: concepto y gestión de repositorios
Ahora que
hemos entendido el concepto de paquete en Linux y especialmente el
manejo de los paquetes en RHEL mediante archivos rpm, podemos
entender lo que es un repositorio y como actualizar completamente un
sistema. Un repositorio en RHEL es un depósito o directorio
centralizado donde se almacena y mantienen los paquetes en formato
rpm para la versión del sistema operativo que se desee actualizar.
Como sería muy tediosa la tarea de actualizar uno por uno los
paquetes de un sistema RHEL con el comando rpm los ingenieros de Red
Hat crearon el programa YUM.
Este programa, que se implementó por primera vez en la versión 5 de
RHEL (en reemplazo del comando up2date)
y continúa hasta la fecha como estándar, se ejecuta a través del
comando yum.
Así, el
mismo actúa como front-end
del comando rpm, permitiendo instalar y desinstalar programas así
como mantener al día nuestro sistema. Antes la instalación de un
paquete libXawe
presentaba problemas de dependencias si se hacía con el programa
rpm. Por ejemplo, supongamos que quiero instalar x3270-x11,
un programa para abrir ventanas en un sistema X
Window emulando la salida de un terminal de
mainframe,
al escribir rpm
-ivh x3270-x11-* en un RHEL 6 nos dirá que
faltan paquetes (denominados dependencias) pero si escribimos yum
install x3270-x11-* automáticamente
descargará las dependencias necesarias, en este caso: los paquetes
libXaw
y x3270.
En muchos
casos puede ser útil consultar la información de un determinado
paquete antes de instalarlo. Para el caso citado como ejemplo, la
sintaxis sería:
# yum info
x3270-x11-*
Loaded plugins: priorities, product-id, refresh-packagekit, rhnplugin, subscription-manager
Updating certificate-based repositories.
Unable to read consumer identity
Available Packages
Name : x3270-x11
Arch : x86_64
Version : 3.3.6
Release : 10.4.el6
Size : 419 k
Repo : rhel-x86_64-server-6
Summary : IBM 3278/3279 terminal emulator for the X Window System
License : MIT
Description : The x3270 program opens a window in the X Window System which emulates
: the actual look of an IBM 3278/3279 terminal, commonly used with
: mainframe applications. x3270 also allows you to telnet to an IBM
: host from the x3270 window.
:
: Install the x3270-x11 package if you need to access IBM hosts using an IBM
: 3278/3279 terminal emulator from X11.
Loaded plugins: priorities, product-id, refresh-packagekit, rhnplugin, subscription-manager
Updating certificate-based repositories.
Unable to read consumer identity
Available Packages
Name : x3270-x11
Arch : x86_64
Version : 3.3.6
Release : 10.4.el6
Size : 419 k
Repo : rhel-x86_64-server-6
Summary : IBM 3278/3279 terminal emulator for the X Window System
License : MIT
Description : The x3270 program opens a window in the X Window System which emulates
: the actual look of an IBM 3278/3279 terminal, commonly used with
: mainframe applications. x3270 also allows you to telnet to an IBM
: host from the x3270 window.
:
: Install the x3270-x11 package if you need to access IBM hosts using an IBM
: 3278/3279 terminal emulator from X11.
Administración de software mediante YUM
En muchas
ocasiones será necesario habilitar repositorios externos o privados
de paquetes para utilizarlos mediante yum.
Realizar está tarea es algo sumamente sencillo. Antes que nada
debemos crear un archivo vacío con el nombre elegido para nuestro
nuevo repo seguido de la extensión .repo
dentro del directorio /etc/yum.repos.d/.
Una vez hecho esto agregamos las líneas que siguen:
[nombre-repositorio]
name=Descripción del repositorio
baseurl=http://ipdenuestroservidorlocal/ruta/del/repo
enabled=1
gpgcheck=1
name=Descripción del repositorio
baseurl=http://ipdenuestroservidorlocal/ruta/del/repo
enabled=1
gpgcheck=1
Lo
mencionado arriba figura como modelo de definición de repositorio.
En el campo baseurl
puede ir cualquier servidor http
de repositorios rpm, incluso es posible crear nuestro propio
repositorio en el disco local y utilizarlo para instalar paquetes
especificando el protocolo file en lugar de http. Por ejemplo, si
tenemos montando el DVD
de instalación de RHEL 6 en el directorio /mnt/RHEL6
el parámetro de definición para el campo baseurl será:
baseurl=file:///mnt/RHEL6/
Hay dos
parámetros que también debemos tener en cuenta: enabled
y gpgcheck.
El primero habilita o deshabilita el repositorio, mientras que el
segundo hace lo mismo para la comprobación de la firma de paquetes a
través de GPG.
Para ambos casos, 0 es deshabilitado y 1 es habilitado. Es
conveniente y más seguro que los servidores productivos tengan en 1
el parámetro gpgcheck,
al menos que sea un repositorio montando en un disco local del cual
confiamos en su contenido. Cualquier otra configuración adicional se
debe especificar en el archivo de configuración /etc/yum.conf.
La
información de los repositorios en los sistemas RHEL es cacheada, es
decir, se descarga y guarda localmente una copia del subdirectorio
denominado repodata
cuando se consulta por primera vez un repositorio o cuando pasa
determinado tiempo sin consultarse. Por supuesto, este cache puede
limpiarse en cualquier comento escribiendo cualquiera de las dos
sentencias mencionadas a continuación:
#
yum clean
dbcache
# yum clean all
# yum clean all
Consultando paquetes con yum
Muchas
veces es necesario obtener información acerca de los paquetes, como
vimos anteriormente con el parámetro info
en la ejecución del comando yum
podremos obtener esto. Por ejemplo, si deseamos obtener información
sobre el paquete firefox
debemos escribir yum
info firefox. En un equipo que tenga
instalado RHEL con conexión a la RHN
o al Proxy
Satellite o a una copia de los paquetes del
DVD de instalación en un repositoriolocal al ejecutar la sentencia
citada mostrará en pantalla la siguiente salida:
Available
Packages
Name : firefox
Arch : i686
Version : 10.0.10
Release : 1.el6_3
Size : 20 M
Repo : rhel-x86_64-server-6
Summary : Mozilla Firefox Web browser
License : MPLv1.1 or GPLv2+ or LGPLv2+
Description : Mozilla Firefox is an open-source web browser, designed for standards
: compliance, performance and portability.
Name : firefox
Arch : i686
Version : 10.0.10
Release : 1.el6_3
Size : 20 M
Repo : rhel-x86_64-server-6
Summary : Mozilla Firefox Web browser
License : MPLv1.1 or GPLv2+ or LGPLv2+
Description : Mozilla Firefox is an open-source web browser, designed for standards
: compliance, performance and portability.
Esto
significa que podremos descargar desde el repositorio denominado
rhel-x86_64-server-6
para la arquitectura de procesador i686
la versión 10.0.10 de Firefox, un navegador web de código abierto
bajo la licencia GPL
que ocupa 20 MB de espacio en disco.
Otro
parámetro útil es list
para listar todos los paquetes o aquellos que no recordemos. Por
ejemplo: yum
list all listará todos los paquetes
disponibles para instalar en el sistema de acuerdo a los repositorios
instalado, pero puede ir acompañado de otros parámetros en vez de
all.
Así al escribir: yum
list installed aparecerá una larga lista
con los paquetes instalados en nuestro sistema. Si quisiéramos saber
si el paquete firefox
está instalado en nuestro sistema bastará con filtrar la salida del
comando yum,
como se muestra a continuación:
#
yum list
installed |
grep firefox
firefox.x86_64 14.0.1-1.el6.remi @remi
firefox.x86_64 14.0.1-1.el6.remi @remi
Lo de
arriba significa que en el equipo está instalada la versión 14 de
Firefox
y que fue adquirida desde el repositorio denominado remi (un conocido
repositorio con las últimas versiones de los paquetes para RHEL que
no están disponible en la release
oficial). Pero, además de all
e installed
existen otros parámetros útiles como available
y update,
para listar los paquetes disponibles para descargar y las
actualizaciones respectivamente. No olvidemos que el comando list
puede ir acompañado de comodines para realizar una búsqueda más
fina. Por ejemplo: para listar todos los paquetes que contenga la
palabra irefo,
entre ellos firefox,
escribiremos yum
list '*irefo*'
como se
muestra a continuación:
#
yum list
'*irefo*'
Loaded plugins: priorities, product-id, refresh-packagekit, rhnplugin, subscription-manager
Updating certificate-based repositories.
Installed Packages
firefox.x86_64 14.0.1-1.el6.remi @remi
Available Packages
firefox.i686 10.0.10-1.el6_3 rhel-x86_64-server-6
Loaded plugins: priorities, product-id, refresh-packagekit, rhnplugin, subscription-manager
Updating certificate-based repositories.
Installed Packages
firefox.x86_64 14.0.1-1.el6.remi @remi
Available Packages
firefox.i686 10.0.10-1.el6_3 rhel-x86_64-server-6
Esto
significa que está disponible para instalar (Available
Packages) desde el canal oficial
(rhel-x86_64-server-6)
la versión 10 de firefox
pero está instalada (Installed
Packages) la versión 14 desde un
repositorio extraoficial (remi).
También es posible listar grupo de paquetes con el parámetro
grouplist
e incluso obtener información sobre un grupo de paquetes con el
parámetro groupinfo.
Por ejemplo, para obtener información sobre el grupo de paquetes
denominado Xfce
(un entorno de escritorio liviano alternativo a GNOME)
escribiremos: yum
groupinfo Xfce
# yum groupinfo 'Gnome'
Figura
5. Uso de yum para listar grupo de paquetes e
información del mismo.
Será
necesario en muchas ocasiones consultar por la existencia o
disponibilidad de determinado paquete, para ello utilizaremos el
parámetro search
en el comando yum.
Siguiendo con el ejemplo del firefox,
si quisiéramos buscar todo los relacionado con el mismo, como ser
plugins
o paquetes adicionales debemos escribir lo que se muestra a
continuación:
# yum search firefox
Loaded plugins: priorities, product-id, refresh-packagekit, rhnplugin, subscription-manager
Updating certificate-based repositories.
epel-testing/pkgtags | 343 B 00:00
======================= N/S Matched: firefox
=======================
firefox.x86_64 : Mozilla Firefox Web browser
firefox.i686 : Mozilla Firefox Web browser
acroread-plugin.i686 : Adobe Acrobat® Reader plugin for Mozilla and Firefox
mozilla-https-everywhere.noarch : HTTPS/HSTS enforcement extension for Mozilla Firefox and SeaMonkey
Name and summary matches only, use "search all" for everything.
Loaded plugins: priorities, product-id, refresh-packagekit, rhnplugin, subscription-manager
Updating certificate-based repositories.
epel-testing/pkgtags | 343 B 00:00
======================= N/S Matched: firefox
=======================
firefox.x86_64 : Mozilla Firefox Web browser
firefox.i686 : Mozilla Firefox Web browser
acroread-plugin.i686 : Adobe Acrobat® Reader plugin for Mozilla and Firefox
mozilla-https-everywhere.noarch : HTTPS/HSTS enforcement extension for Mozilla Firefox and SeaMonkey
Name and summary matches only, use "search all" for everything.
Para
finalizar el tema de las consultas en yum,
también es necesario tener en cuenta la posibilidad de consultar que
paquete/s contiene/n un determinado archivo, ya que en ocasiones no
recordamos en paquete viene determinado programa. Por ejemplo, si
quisiéramos saber que paquetes contienen el archivo binario sendmail
escribiremos lo que se muestra a continuación:
# yum provides
/usr/sbin/sendmail
Lo
mencionado arriba buscará todos los paquetes (instalados o
disponibles) para el archivo binario /usr/sbin/sendmail
(siempre hay que indicarle la ruta completa). Así veremos que para
obtener sendmail
en nuestro sistema podremos hacerlo a través de la instalación del
paquete exim
o postfix
(ambos servidores de correo).
Instalación de nuevos paquetes
Una de las
tareas más frecuentes a instalar un servidor RHEL en un ambiente
productivo es instalar los programas necesarios para el servicio que
se quiera brinda. Así si lo que necesitamos es un servidor web con
el programa Apache
instalaremos el paquete httpd,
si necesitamos instalar un contenedor de servlets
(programas que funcionan atendiendo peticiones de clientes)
instalaremos el paquete tomcat6,
si necesitamos un sniffer
(capturador de paquetes para analizar tráfico de red y análisis de
seguridad) instalaremos el paquete nmap
y así en según sea el requerimiento. Lo anterior lograrse
ejecutando como usuario root las siguientes sentencias:
# yum install httpd
-y
# yum install tomcat6 -y
# yum install nmap -y
# yum install tomcat6 -y
# yum install nmap -y
Al suceder
el comando yum
con el parámetro install
seguido del nombre del paquete se descargará el mismo junto con las
dependencias necesarias de acuerdo a los repositorios definidos. En
el caso de que el paquete se un paquete local, es decir, un paquete
que hemos descargado en nuestro equipo y que no figura en los
repositorios habilitados, invocaremos el parámetro localinstall
en lugar de install.
Otro caso que puede surgir, es la posibilidad de instalar grupos de
paquetes, por ejemplo si deseamos instalar la suite de escritorio KDE
debemos escribir:
#
yum groupinstall
"Escritorio KDE"
Para
desinstalar un programa instalado a través de yum
debemos invocar el parámetro remove
seguido del nombre del paquete. Si queremos desinstalar el programa
nmap,
por ejemplo, debemos escribir:
# yum remove nmap
Un aspecto
muy útil de yum
es que es posible actualizar paquetes individuales escribiendo yum
update nombrepaquete,
o bien, actualizar todos los paquetes del sistema ejecutando yum
update
sin más.
Una advertencia sobre yum
update
El comando yum
es muy poderoso, versátil e implica altos riesgos si no se lo
utiliza correctamente. Por ejemplo, si deseamos actualizar un paquete
en particular y nos olvidamos de escribir el nombre del paquete, al
ejecutar yum
update
sin parámetros se actualizará el sistema completo, lo que puede
ocasionar problemas especialmente en equipos productivos.
Administración de software mediante la RHN
La RHN
(Red Hat Network) es un servicio proporcionado a través de
rhn.redhat.com
o un servidor Satellite
o Proxy
local. En cualquiera de los 3 casos se proporcionan los paquetes para
instalar programas y acceso remoto a cada cliente. La ventaja contra
un repositorio local de rpm es que podemos administrar o gestionar la
actualización automática de un o más servidores a través de una
interfaz web. La administración de sistemas de forma centralizada en
base a la RHN para sistemas RHEL puede ser a través de 2
soluciones:
RHN
Proxy
Server
RHN
Satellite
Server
En cuanto
al primero, RHN
Proxy Server es un servidor de
almacenamiento de paquetes en cache que reduce los requerimientos de
ancho de banda para RHN ya que un solo servidor descarga los paquetes
desde Internet y no cientos de clientes. Esto último, también es un
punto a favor de la seguridad ya que nuestros servidores productivos
estarán protegidos de tener que salir a Internet. Además, con esta
solución los usuarios guardarán en cache
los RPM, ya sean las actualizaciones de errata
o bien, paquetes personalizados generados por la organización, en un
servidor interno y centralizado. Tanto los perfiles de sistema de
nuestros clientes (servidores) como la información de nuestro
usuario se almacenarán de forma segura en los servidores centrales
de RHN. De esta forma, actúa como un intermediario almacenando
solamente los archivos de paquetes localmente. La comunicación
siempre es segura, ya que cada transacción se autentica y el Red
Hat Update Agent revisa la firma GPG
de cada paquete recuperado del RHN Proxy Server local.
Entre las
ventajas de usar el RHN
Proxy Server se incluyen:
Escalabilidad:
puede haber más de un RHN Proxy Server dentro de una organización.
Seguridad:
la conexión es siempre segura saliendo desde cada servidor o
sistema cliente al RHN
Proxy Server local y este último a su vez,
a los servidores RHN.
Velocidad:
los paquetes se entregan velozmente a través de una red interna
(no se necesita buscarlos en Internet).
Ahorro
de ancho de banda:
los paquetes son descargados desde el servidor de archivos de RHN
solamente una vez y almacenado para luego ser utilizados para cada
servidor o sistema cliente.
Actualizaciones
personalizadas: crea un sistema de entrega de paquetes
automatizado para paquetes de software personalizado, así como de
los paquetes oficiales de Red Hat requeridos por el sistema cliente.
Configuración
personalizada: la habilidad de restringir o conceder
actualizaciones a arquitecturas específicas o diferentes versiones
de sistema operativo.
Mínimos
requerimientos: Sólo se necesita una conexión a Internet
ya que cada sistema cliente se conecta a través del servidor RHN
Proxy y es es este que el que necesita una conexión a Internet para
contactar los servidores RHN.
En cuanto
RHN Satellite Server, es un administrador de plataformas que cuenta
con varias mejoras en el control de su bases de datos. Por ejemplo,
se recopilan estadísticas sobre los objetos de la base de datos de
RHN Oracle, se muestra los cuadros con estadísticas antiguas o
vacías, y se comprime los segmentos de la base de datos RHN
Oracle.
La últimas
versiones de Red Hat Network Satellite están construidas en base de
sugerencias planteadas por los usuarios y por lo tanto, cuenta con
varias ventajas:
Soporte
de plataforma RHEL 5
y 6: todas las suscripciones de Satellite
incluyen una suscripción de RHEL, por lo que los clientes que buscan
estandarizar su entorno pueden ejecutar Satellite en las versiones 5
y 6 de RHEL.
Soporte
Oracle 10g: soporta la Edición Estándar y
Empresarial de Oracle Database 10g, Versión 2, ofreciendo alto
rendimiento sobre plataformas de 64 bits, mayor capacidad y
flexibilidad en la implementación.
Al tener
que elegir entre las 2 soluciones la mejor alternativa es siempre RHN
Satellite Server porque agrega más funcionalidades que el RHN Proxy
Server.
Ambas
necesitan de un acceso a Internet para descargar los programas de la
RHN. Los clientes pueden estar en una Intranet o red privada, tener o
no conexión a Internet y conectarse a cualquiera de estos 2
servidores. Son los servidores los que salen a buscar afuera los
paquetes rpm
para mantenerse actualizados y a la vez mantener a los clientes.
Además, ambas soluciones pueden configurarse para utilizar acceso
seguro a través de certificados SSL mediante el protocolo HTTPS
(HTTP Seguro). Si pensamos instalar un RHN Proxy o un RHN Satellite
deberíamos considerar por defecto la implementación de este
protocolo.
Algo a
tener en cuenta sobre la RHN es la gestión de canales de programas
(software
channels). Los canales en la Red Hat Network
son una colección de paquetes de software que nos ayudarán a
dividir los paquetes según determinados criterios. Así un canal
puede, por ejemplo, contener paquetes de una distribución específica
de RHEL. Un canal puede contener paquetes para una aplicación o
familia de aplicaciones. Quizás necesitemos definir canales para un
necesidad particular; por ejemplo, nuestra empresa necesita crear un
canal que contenga paquetes para todos los empleados que se conecten
con sus equipos portátiles. Los canales de RHN personalizados
y privados
le permiten a una organización la entrega automatizada de paquetes
internos a ésta. En resumen, los canales son definiciones genéricas
de software. Por ejemplo, en un Satellite actual habrá 2 canales con
soporte oficial de Red Hat:
Red
Hat
Enterprise
Linux
Server
(v. 5
for 64-bit
x86_64)
Red
Hat
Enterprise
Linux
Server
(v. 6
for 64-bit
x86_64)
Esto
significa que si instalamos un equipo con la versión 6.3 de RHEL
para 64 bits, este se conectará automáticamente al momento de la
registración al canal Red Hat Enterprise Linux Server (v. 6 for
64-bit x86_64), mientras que si instalamos un equipo con la versión
5.0 o posterior de RHEL para 64 bits se adherirá al canal Red Hat
Enterprise Linux Server (v. 5 for 64-bit x86_64). Si deseamos
conectar un equipo de 32 bits al RHN Satellite arriba mencionado como
ejemplo no podremos ya que solo hay 2 canales
contratados y son para sistemas de 64
bits. En este caso, habrá que contactar con
RHEL para adquirir el canal o los canales de 32
bits para las versiones 5 y 6 de RHEL.
Cada canal
contiene a su vez subcanales
o canales
hijo, por ejemplo el canal principal o base
de RHEL 6 para 64 bits contiene los siguientes canales hijo:
RHEL
Server
High
Availability
(v. 6
for 64-bit
x86_64)
RHEL
Server
Optional
(v. 6
64-bit x86_64)
RHEL
Server
Resilient
Storage
(v. 6
for 64-bit
x86_64)
RHEL
Server
Supplementary
(v. 6
64-bit x86_64)
RHN
Tools
for
RHEL
(v. 6
for 64-bit
x86_64)
Información Útil
Existen muchos canales en RHN que están disponibles a todos mientras
que otros están disponibles solo para los usuarios de una
organización particular e incluso algunos otros están disponibles
únicamente si se han adquirido los derechos de acceso a ellos.
Básicamente pueden dividirse dentro de estas categorías: de
servicio pago (semiprivado,
todas las empresas tienen el mismo) y personalizados
(privados, solo la empresa que lo solicitó lo tiene).
Registration via rhn_register
El comando
rhn_register
actúa interactivamente con nosotros creando los archivos de
configuración necesarios para yum
se conecte automáticamente a la RHN o solución de Proxy o Satellite
local. La registración de un RHEL puede efectuarse durante el primer
booteo
al finalizar la instalación, incluso es posible utilizar el comando
rhnreg_ks
para automatizar el proceso de instalación rápida (denominado en
ingles Kickstart).
Una vez registrado, el comando yum
utilizará su conexión a la RHN (o Satellite local) para actualizar
o descargar paquetes a través de los canales (Channels)
permitidos en la RHN o repositorios locales privados agregados en el
directorio /etc/yum.repos.d/.
Periódicamente
el demonio rhnsd
se encarga de comprobar que las actualizaciones o erratas estén al
día. El intervalo por defecto para las versión 6 de los sistemas
RHEL es de 4 horas, pero puede cambiarse modificando el parámetro
INTERVAL
en el archivo /etc/sysconfig/rhn/rhnsd
que expresa el tiempo en minutos en que deberá comprobarse el estado
de las erratas del sistema, como se muestra a continuación:
#
cat
/etc/sysconfig/rhn/rhnsd
INTERVAL=240
INTERVAL=240
Si no
deseamos correr el demonio rhnsd,
como alternativa podemos utilizar el comando rhn_check
y programarlo mediante el comando cron
para que se ejecute con determinada frecuencia. Para deshabilitar el
demonio rhnsd
debemos ejecutar como root:
# service rhnsd stop
# chkconfig rhnsd off
# chkconfig rhnsd off
Como
mencionamos el comando yum
puede conectarse a la RHN o bien a un repositorio
local, a continuación veremos como hacerlo.
Creación de un repositorio local
En
determinadas ocasiones será necesario crear nuestros propios
paquetes rpm, o bien no tendremos licencias de Red Hat para
actualizar nuestros servidores por lo que, será útil para mantener
los rpm propios o del DVD
de instalación en un repositorio yum
local. La ventaja de esto es que, cuando se instala un paquete, YUM
automáticamente resuelve las dependencias, instalándolas desde
nuestro propio repo. Por lo tanto, al instalar un paquete (por
ejemplo mipaquete.rpm)
con el comando yum,
este será capaz de resolver todos las dependencias (siempre y cuando
estén en ese repositorio o en otro agregado y habilitado en el
sistema). Para crear un repositorio local necesitaremos una utilidad
denominada createrepo,
disponible a través de los repositorios extras de Fedora (EPEL).
Para instalar este programa debemos ejecutar como root:
# yum install
createrepo
Curiosidades: Utilidad de un
repositorio local
Un repositorio local no sólo sirve como un almacén de archivos en
RPMs personalizados, sino también como economizador de ancho de
banda, descargando todas las actualizaciones publicadas en RHEL y
sirviéndolas a todos los clientes que quieran descargarlas de allí.
Esta es una solución sencilla que permitirá a todos los servidores
de nuestra red interna, mantenerse al día con las actualización
ahorrando consumo de ancho de banda y tiempo.
A
continuación, debemos poner todos los paquetes en formato rpm en un
directorio (en el caso de querer disponer de un repo local de RHEL
debemos montar el directorio que contiene los rpm en el DVD de
instalación de RHEL). Suponiendo que este directorio es
/mnt/repolocal,
podremos generar todos los metadatos
necesarios escribiendo:
# createrepo
/mnt/repolocal
Ahora
tendremos un completo repositorio local de rpm. No debemos olvidar
que cada vez que coloquemos nuevos archivos en ese directorio o
incluso si eliminamos alguno/s, tendremos que volver a ejecutar el
comando anterior para que el repositorio de metadatos
se actualice.
Ahora
bien, en cada cliente del repositorio, debemos agregar la definición
del repositorio local a la lista de repos, de forma tal que al
ejecutar el comando yum
busque en el nuevo repo agregado. Esta información se define dentro
del directorio /etc/yum.repos.d/.
Como buena práctica, será recomendable crear un archivo con
extensión .repo
para cada repositorio que se quiera agregar. Para nuestro caso de
ejemplo, podremos crear un archivo denominado
/etc/yum.repos.d/local.repo
con la siguiente sintaxis:
[localrepo]
name=Repositorio Local
baseurl=file:///mnt/localrepo/
enabled=1
gpgcheck=0
#gpgkey=file:///ruta_del_archivo/RPM-GPG-KEY
name=Repositorio Local
baseurl=file:///mnt/localrepo/
enabled=1
gpgcheck=0
#gpgkey=file:///ruta_del_archivo/RPM-GPG-KEY
Aunque en
baseurl
en la mayoría de los casos aparece http://
(protocolo de para servicios web), ftp://
(protocolo de transferencias de archivos), o incluso smb://
(protocolo de archivos compartidos por red local) aquí se utilizó
el protocolo file://
por ser un directorio local
(/mnt/localrepo/),
por eso la sintaxis completa es file:///mnt/localrepo/
(es decir, la conjunción de file://
+ /mnt/localrepo/).
Podremos agregar tantos repositorios yum
locales como necesitemos.
En el
ejemplo anterior, la verificación de claves GPG está desactivada
(gpgcheck=0
). Si queremos comprobar la firma en los paquetes debemos establecer
el parámetro gpgcheck
en "1"
y descomentar la línea siguiente (gpgkey=...
) que es la que contiene la ruta de acceso a la clave pública con la
que se comprueba.
Dato Útil: Firma digital
para los paquetes de
RHN
Según Red Hat todos los paquetes distribuidos a través de RHN deben
tener una firma digital, la cual es creada con una llave privada
única y puede ser verificada con la correspondiente llave pública.
Después de crear un paquete, el SRPM
(RPM de código fuente) y el RPM pueden ser firmados digitalmente con
una llave GPG (o GnuPG).
Antes de que el paquete sea instalado, la llave
pública es utilizada para verificar que el
paquete fue firmado por alguien confiable y de que no ha sido
modificado desde el momento de la firma.
Actualizando a un nuevo kernel
Como todos
sabemos, Linux es el nombre que se le da al kernel
del sistema GNU, de allí que la denominación completa sea
GNU/Linux. El kernel es el núcleo del sistema, se encarga de
controlar y facilitar el acceso de los distintos programas al
hardware de nuestro equipo, gestionando recursos a través de
servicios
de llamada al sistema. En los sistemas RHEL
los kernles no se actualizan sino que se instalan en paralelo. Por lo
tanto no es recomendable actualizar el kernel con los comandos rpm
-U ni rpm
-F. En todo caso, se debería actualizar con
el comando rpm
-i, o mejor aún, con el comando yum
update. De esta forma, se instalará un
nuevo kernel en el sistema dejando el anterior en caso de que algo
salga mal.
Resumiendo
lo mencionado, estos son los pasos para actualizar el núcleo en un
sistema RHEL:
1-
Ejecutar el comando: yum
update kernel
2-
Reiniciar el equipo para probarlo (el nuevo kernel). El comando para
reiniciar es: reboot.
Si todo
funciona correctamente podremos eliminar la versión anterior
mediante la instrucción: yum
remove kernel-versionanterior, siendo
versionanterior
el número de versión del kernel anterior. En caso de que se
presenten errores, simplemente debemos reiniciar el equipo y elegir
la versión anterior de kernel al momento de inicio cuando aparece la
pantalla del GRUB
(gestor de arranque en los sistemas RHEL).
Consultas básicas a través de rpm
Aunque Red
Hat recomienda el uso de yum
para la instalación de archivo rpm, también podremos hacerlo a
través del comando rpm.
Así, al hacer rpm
-i será lo mismo a efectos prácticos que
hacer yum
install siempre y cuando las dependencias
para el archivo rpm a instalar estén completamente cumplidas, es
decir, el comando rpm
a diferencia de yum
no buscará las dependencias en los repositorios instalados. Para
actualizar paquetes se deben utilizar los parámetros -U
o --upgrade
y/o -F
o --freshen
con las siguiente sintaxis:
rpm -F <paquete>.rpm
El
parámetro -U
no es más que un equivalente a desinstalar
(-e)
e instalar (-i),
pero es recomendable hacerlo con -U
siempre que sea posible.
rpm -U <paquete>.rpm
Para
desinstalar un programa utilizaremos el parámetro -e
seguido del nombre del paquete en formato rpm:
rpm -e <paquete>.rpm
Lo
mencionado es un equivalente del comando yum
remove.
Consultas avanzadas a través de rpm
Es posible
realizar consultas de la base de datos de paquetes instalada en el
sistema. Por ejemplo para consultar toda la información sobre un
paquete instalado en el sistema denominado wget
debemos ejecutar el comando rpm
con los parámetros -q
(query)
y -i
(information)
como se muestra a continuación:
$
rpm -q
-i wget
Name : wget Relocations: (not relocatable)
Version : 1.12 Vendor: Red Hat, Inc.
Release : 1.4.el6 Build Date: lun 10 may 2010 10:56:18 ART
Install Date: vie 17 ago 2012 07:22:33 ART Build Host: x86-012.build.bos.redhat.com
Group : Applications/Internet Source RPM: wget-1.12-1.4.el6.src.rpm
Size : 1877597 License: GPLv3+ and GFDL
Signature : RSA/8, lun 16 ago 2010 17:21:35 ART, Key ID 199e2f91fd431d51
Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL : http://wget.sunsite.dk/
Summary : A utility for retrieving files using the HTTP or FTP protocols
Description :
GNU Wget is a file retrieval utility which can use either the HTTP or FTP protocols. Wget features include the ability to work in the background while you are logged out, recursive retrieval of directories, file name wildcard matching, remote file timestamp storage and comparison, use of Rest with FTP servers and Range with HTTP servers to retrieve files over slow or unstable connections, support for Proxy servers, and configurability.
Name : wget Relocations: (not relocatable)
Version : 1.12 Vendor: Red Hat, Inc.
Release : 1.4.el6 Build Date: lun 10 may 2010 10:56:18 ART
Install Date: vie 17 ago 2012 07:22:33 ART Build Host: x86-012.build.bos.redhat.com
Group : Applications/Internet Source RPM: wget-1.12-1.4.el6.src.rpm
Size : 1877597 License: GPLv3+ and GFDL
Signature : RSA/8, lun 16 ago 2010 17:21:35 ART, Key ID 199e2f91fd431d51
Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL : http://wget.sunsite.dk/
Summary : A utility for retrieving files using the HTTP or FTP protocols
Description :
GNU Wget is a file retrieval utility which can use either the HTTP or FTP protocols. Wget features include the ability to work in the background while you are logged out, recursive retrieval of directories, file name wildcard matching, remote file timestamp storage and comparison, use of Rest with FTP servers and Range with HTTP servers to retrieve files over slow or unstable connections, support for Proxy servers, and configurability.
Siempre
que este puesto el parámetro -q
significa que se consultar la base de datos
rpm local (-q
es una abreviación de query
que traducido al castellano significa consulta). Por supuesto,
existen otros parámetros de consulta. El parámetro -f
seguido de la ruta de completa de un archivo consultará por el
paquete rpm al que pertenece, es decir, nos dirá desde que archivo
rpm fue instalado. Veamos esto en la práctica: supongamos que
necesitamos saber donde se encuentran los paquetes rpm que nos
permitieron instalar los programas rpm
y wget,
entonces simplemente debemos ejecutar lo que se muestra a
continuación:
$
rpm -q
-f /bin/rpm
/usr/bin/wget
rpm-4.8.0-27.el6.x86_64
wget-1.12-1.4.el6.x86_64
rpm-4.8.0-27.el6.x86_64
wget-1.12-1.4.el6.x86_64
Otras
opciones avanzadas de rpm son la instalación pisando los que
paquetes que ya están instalados con la opción --replacepkgs,
instalar sobrescribiendo todos los archivos intervinientes incluso
los que están instalados con la opción --replacefiles,
hacer un downgrade
(volver a la versión anterior) con la opción --oldpackage
y hasta instalar un paquete rpm ignorando sus dependencias con la
opción --nodeps.
Curiosidades: Ver salida en
pantalla del comando rpm
Para ver la ayuda del programa y la salida en pantalla se pueden
utilizar los parámetros -v
y -h.
El comando rpm soporta URL
para la descarga de paquetes, lo que significa que se pueden
descargar paquetes desde cualquier sitio FTP
o HTTP
especificando la ruta correctamente al momento de ejecución (ftp://
y http://
respectivamente).
En ciertas
ocasiones es necesario comprobar la firma
digital
de un paquete rpm para asegurarnos de su procedencia. El parámetro
-V
o --verify
nos permitirá realizar dicha verificación sobre un paquete ya
instalado en el sistema como se muestra a continuación:
$ rpm -V paquete.rpm
$ rpm -V -p archivo.rpm
$ rpm -V -p archivo.rpm
Es posible
verificar también todos los paquetes del sistema acompañando al
parámetro -V
del -a:
$ rpm -V -a
Lo
anterior es especialmente útil en equipos productivos donde se
necesita asegurar la procedencia y fiabilidad de un paquetes, ya que
un paquete de una fuente dudosa puede contener algún programa que
afecte nuestro equipo. Mencionamos que es posible verificar la firma
de un paquete ya instalado, pero lo mejor será siempre verificar la
firma única del paquete antes de instalarlo, esto se hace de la
siguiente manera:
# rpm -K archivo.rpm
Por
ejemplo, si hemos descargado el archivo rpmforge
en formato rpm y queremos comprobar que es el que efectivamente está
instalado en nuestro sistema debemos escribir:
$ rpm -K
./Descargas/rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm
./Descargas/rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm: (sha1) dsa sha1 md5 gpg BIEN
./Descargas/rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm: (sha1) dsa sha1 md5 gpg BIEN
Nos
aparece el mensaje que dice BIEN
porque la firma del paquete instalado coincide con la firma del rpm
instalado que lleva el mismo nombre. Pueden haber excepciones y en
ocasiones se nos indicará que NO
ESTA BIEN, por ejemplo si hemos instalado
manualmente un archivo en formato rpm pero luego lo actualizamos
desde otros repositorios, la firma no coincidirá. Vemos un ejemplo
con una descarga manual de un programa llamado VirtualBox
que fue instalado con rpm
pero que fue actualizado con yum
desde otros repositorios externos:
$ rpm -K
./Descargas/VirtualBox-4.1-4.1.18_78361_rhel6-1.x86_64.rpm
./Descargas/VirtualBox-4.1-4.1.18_78361_rhel6-1.x86_64.rpm: (SHA1) DSA sha1 md5 GPG NO ESTA BIEN
./Descargas/VirtualBox-4.1-4.1.18_78361_rhel6-1.x86_64.rpm: (SHA1) DSA sha1 md5 GPG NO ESTA BIEN
Si
queremos nosotros firmar un paquete creado o que hemos descargado y
queremos enviárselo a alguien, podremos hacerlo escribiendo:
$ rpm --addsign
paquete.rpm
Si la
firma ya existe y queremos sobrescribirla deberíamos utilizar la
opción --resign
en vez de --addsign.
De igual modo, ambas opciones generaran e insertarán un nueva firma
para cada paquete especificado. Para importar un archivo de firmas
públicas rpm debemos hacerlo con el
parámetro --import:
# rpm --import
archivo_con_la_firma_pública_GPG
# rpm -qa firma_pública_GPG
# rpm -qa firma_pública_GPG
Resumen
El programa yum
nos permite instalar paquetes sin preocuparnos por las dependencias.
Vimos la configuración principal en el archivo yum.conf
y que es posible configurar un repositorio tanto local como remoto en
los archivos de configuración de repositorios agregados al
directorio /etc/yum.repos.d/.
Las actualizaciones en los sistemas RHEL son a través de la RHN.
Para esto se necesita que los sistemas estén registrados a la RHN,
esto puede ser durante la parte final de la instalación o luego de
finalizada con el comando rhn_register.
Los sistemas registrados buscarán cada determinado tiempo
actualizaciones de paquetes a través del demonio rhnsd.
Ademas, vimos que el comando rpm puede ser utilizado para consultas
avanzadas y tareas no incluidas en el comando yum.
Actividades
Preguntas teóricas
1- ¿Qué
es un paquete de RHEL?
2- ¿Cual
es la ventajas de los paquetes en formato rpm?
3- ¿Porque
conviene siempre que sea posible utilizar yum
en lugar de
rpm?
4- ¿Cuando
conviene crear un repositorio local?
5- ¿Qué
es el núcleo de RHEL y como se actualiza?
6- ¿Que
tipo de consultas puedo realizar a través del comando rpm?
7- ¿Que
ventajas presenta tener instalado la solución RHN
Satellite?
8- ¿Como
pueden listarse los paquetes que contienen el binario
/usr/sbin/sendmail?
9- En caso
de que se presenten errores al actualizar el kernel, ¿que debemos
hacer?
10- ¿Cómo
se puede instalar un software de virtualización como VirtualBox
en RHEL?
Ejercicios prácticos
1-
Descargar desde un repositorio externo el paquete rpm de VirtualBox
(por ejemplo: VirtualBox-4.1-4.1.18_78361_rhel6-1.x86_64.rpm
)
2-
Verificar la firma md5 del paquete descargado con rpm
-K
e instalarlo con el comando rpm
-ivh.
3-
Desinstalar el paquete anterior utilizando yum
remove
o el comando rpm
-e.
4- Crear
un repositorio local con todos los archivos rpm incluidos en el DVD
de instalación de RHEL con la aplicación createrepo.
5- Agregar
el repositorio EPEL a la lista de repositorios habilitados en un
sistema RHEL.
Escrito es su totalidad por Matías Colli. Perito Judicial en Informática.
M.N. A-128 COPITEC
http://estudiopericialinformatico.com
Todos los derechos reservados.
M.N. A-128 COPITEC
http://estudiopericialinformatico.com
Todos los derechos reservados.
