Repositorios YUM personalizados en RHEL4 ( y RHEL5 y RHEL3)

Para tener yum en RHEL4, lo primero que necesitas es instalar los siguientes paquetes: python-elementtree, python-sqlite, python-urlgrabber, sqlite y yum

... y los podrás encontrar en la página:
http://rpmfind.net/linux/RPM/Dag_Apt_Repository_for_Red_Hat_Enterprise_Linux_4.html

... hay que tener paciencia a que termine de cargar que es muy grande. Las versiones que yo estoy usando en RHEL4, en todos los Updates hasta en el 6, y de momento no me ha dado ningún problema, que yo sepa, son:

   python-elementtree-1.2.6-7.el4.rf.i386.rpm
  python-sqlite-0.5.0-1.2.el4.rf.i386.rpm
  python-urlgrabber-2.9.7-1.2.el4.rf.noarch.rpm
  sqlite-2.8.17-1.el4.rf.i386.rpm
  yum-2.4.2-0.4.el4.rf.noarch.rpm

Las dependencias de estos paquetes (si tuvieran) las instalo desde la distribución oficial de RHEL4 que esté usando, poniendo el contenido de los CDs accesible vía NFS. Instalando todo esto tendremos el comando "yum" en nuestro equipo RHEL4 donde ya podremos configurar los repositorios que nos interese, igual que si estuviéramos en RHEL5: /etc/yum.conf y/o /etc/yum.repos.d/. A efectos practicos, llamaremos a todas estas máquinas hostclient.

Para publicar nuestro repositorio de paquetes, además necesitaremos el comando "createrepo", en al menos una máquina RHEL4 con el que poder crear la estructura del repositorio, por lo que habrá que descargar también el paquete: createrepo (yo uso: createrepo-0.4.4-1.noarch.rpm). A efectos prácticos, llamaremos a esta máquina configurator.

Luego tendremos que disponer de una máquina con el servidor Web o FTP configurado y con espacio suficiente, como para ir dejando ahí todos los paquetes que conformarán nuestros diferentes repositorios. Si este equipo es diferente de la máquina configurator, necesitaremos tambien que esta pueda montar por NFS los directorios donde tengamos los repositorios de paquetes, y así poder ejecutar el comando createrepo. A efectos prácticos, llamaremos a este equipo reposerver.

Imaginar que en el reposerver queremos publicar varias distribuciones:
- RHEL4U6, en el directorio /opt/repos/RHEL4U6
- RHEL4U5, en el directorio /opt/repos/RHEL4U5
- RHEL4U1, en el directorio /opt/repos/RHEL4U1

Crear estos directorios en reposerver y copiar el contenido de todos los CDs o DVDs (sobreescribiendo si hubiera conflictos) en ellos, de manera que los directorios con los RPMS de RHEL4U1 (por ejemplo) quedarán en /opt/repos/RHEL4U1/RedHat/RPMS. El hacerlo así, es porque también podremos usar scripts personalizados de anaconda para instalar las distribuciones, dejando los paquetes vía http.

En reposerver, debemos exportar por NFS el directorio /opt/repos para que configurator pueda escribir. Una vez en configurator, montaremos el directorio NFS (mount -t nfs reposerver:/opt/repos /mnt/reposerver) y ejecutaremos:

 cd /mnt/reposerver
for i in RHEL4*
do
  cd /mnt/reposerver/$i/RedHat/RPMS
  createrepo .
done
sync
cd
umount /mnt/reposerver

Con esto, deberíamos tener directorios repodata dentro de cada /opt/repos/RHEL*/RedHat/RPMS/.
De nuevo sobre la máquina reposerver, crearemos el siguiente enlace simbólico:

ln -s  /opt/repos/RHEL4U6  /opt/repos/RHEL4-ultima

Configurar Apache para que podamos navegar por los subdirectorios de /opt/repos desde nuestra red sin problemas, y que se sigan los enlaces simbólicos, de manera que si desde nuestro navegador accedemos a http://reposerver/repos/RHEL4-ultima/ ... veamos los mismos archivos que si lo hacemos en la URL http://reposerver/repos/RHEL4U6/


Una vez hecho esto, ya podemos acceder a cualquiera de las máquinas "hostclient". Supongamos que lo hacemos a una máquina RHEL4U1. Editaremos /etc/yum.conf (o crear un fichero /etc/yum.repos.d/) y añadiremos el siguiente contenido:

[base]
name=RedHat 4 Update 1
baseurl=http://reposerver/repos/RHEL4U1/RedHat/RPMS/

#[updates-released]
#name=RedHat 4 Updates
#baseurl=http://reposerver/repos/RHEL4-ultima/RedHat/RPMS/

Para una máquina RHEL4U5, escribiremos...

[base]
name=RedHat 4 Update 5
baseurl=http://reposerver/repos/RHEL4U5/RedHat/RPMS/

#[updates-released]
#name=RedHat 4 Updates
#baseurl=http://reposerver/repos/RHEL4-ultima/RedHat/RPMS/

... y un hostclient con RHEL4U6:

[base]
name=RedHat 4 Update 6
baseurl=http://reposerver/repos/RHEL4U6/RedHat/RPMS/

#[updates-released]
#name=RedHat 4 Updates
#baseurl=http://reposerver/repos/RHEL4-ultima/RedHat/RPMS/

Una vez hemos editado el fichero de los repositorios, guardaremos los cambios, y ejecutaremos "yum update", para que se refresquen la lista de nuestros repositorios. En teoría, no debería pedirnos actualizar nada, porque solo hemos dejado visible el repositorio de paquetes el repositorio de paquetes de nuestra distribución. Esto nos permite, que cuando tenemos que instalar cualquier paquete de la distribución, en vez de andar como locos poniendo y quitando CDs, y de vueltas con el comando "rpm -ivh, rpm -Uvh", lo hagamos directoramente con "yum install", lo cual ya es una comidad, porque yum resolverá las dependencias e instalará los paquetes que le digamos.

En un momento dado, nos puede interesar actualizar los hostclient a la última distribución que tengamos publicada (RHEL4-ultima), por lo que en ese momento, tendremos que editar el fichero de yum.conf y descomentar la sección:

[updates-released]
name=RedHat 4 Updates
baseurl=http://reposerver/repos/RHEL4-ultima/RedHat/RPMS/

y luego ejecutar "yum -y update", lo cual provocará que nuestra distribución quede completamente actualizada.

Esto muchas veces no es posible hacerlo, porque generaría conflicto con el aplicativo que tengamos en el servidor ( Oracle, SAP, BEA, etc) y romperíamos la matriz de certificación. Para estos casos, tendremos dos alternativas:

1. Usar el parametro "exclude=" en /etc/yum.conf, y evitar que se actualicen los paquetes conflictivos, que nos romperían la matriz de compatibilidad:

[updates-released]
name=RedHat 4 Updates
baseurl=http://reposerver/repos/RHEL4-ultima/RedHat/RPMS/
exclude=kernel,glibc

2. Tener un directorio especial en reposerver, donde vamos colocando los paquetes que sólo queremos actualizar, por ejemplo /opt/repos/RHEL4-especial. Cada vez que copiemos ahí un archivo tendremos que ejecutar createrepo desde el configurator, y luego en los hostclients tendremos que tener un repositorio, con esta pinta más o menos:

[updates-especial]
name=RedHat 4 Updates Especial
baseurl=http://reposerver/repos/RHEL4-especial/

Este último mecanismo, podríamos usarlo para tener una máquina registrada en RHN configurada, para desacargarse todas las actualizaciones que publiquen en RedHat-Network, y copiarlas desde /var/spool/up2date/ a este directorio. Esto sería una forma de mantener completamente actualizados nuestros equipos, habiendo registrado sólo uno, aunque debo reconocer que nunca lo he probado y no se si funcionará.

Lo que últimamente sí estoy probando es a disponer en un repositorio de yum todos los scripts, personalizaciones, y scripts de administración que desarrollo de manera personaliza para mis clientes: Por ejemplo, los scripts de monitorización de Nagios, o los scripts de backup del sistema. Todos estos scripts, ficheros, etc, los desarrollo bajo un control de versiones basado en Subversion y les preparo con ant, reglas para construir un RPM, que tras construirlo coloco directamente en ese directorio especial. Luego a cada servidor, le programo un "yum -y update" nocturno/semanal y mantengo completamente actualizada la infraestructura, sin necesidad de ir servidor por servidor.

Esto tiene otra ventaja. Ultimamente los servicios de informática para los que trabajo, están en proceso de certificación en alguna norma de calidad: ISO27000, ISO9000, ITIL, etc. En la mayoría de los sitios, tienen definido de manera bastante nítida, el proceso de desarrollo de aplicaciones, o correcciones de las aplicaciones que tienen en producción, y como trabajar con diferentes entornos productivos, lo que habitualmente se conoce como Desarrollo, Pruebas y Producción y el paso y maduración del código en estas plataformas. Trabajar con repositorios yum y control de versiones como he contado, permite convertir los trabajos del departamento de sistemas, como retocar una configuración, desarrollar un script, etc, en casi el trabajo de un programador-analista del departamento de desarrollo, y con ello no tener que definir procesos específicos para la administración de sistemas, lo cual me ayuda a vender mejor mis ideas ;).


Además, el tener los repositorios organizados de esta manera, me permite instalar de forma remota (vía http) los servidores, con ayuda de anaconda. La idea, es instalar un servidor RHEL4 con CDs, de manera atendida de manera que al terminar la instalación nos deje un fichero anaconda-ks.cfg, con todas las opciones que elegimos para la instalación. Luego lo editaremos y nos aseguraremos de incluir las siguientes opciones:

 
  url --url http://reposerver/repos/RHEL4U6/
  network --device eth0 --bootproto dhcp --hostname unattended-rh4u6

Este fichero anaconda-ks.cfg editado, lo renombro a rh4u6.cfg y lo coloco en un servidor Web (puede valer el mismo reposerver), en un subdirectorio HTTP llamado ks, (/opt/repos/ks/) de forma que podamos acceder con el navegador a http://reposerver/ks/rh4u6.cfg y veamos el fichero que hemos editado.

Luego, para instalar meto el primer de la distribución y cuando estamos ante el prompt de lilo, tecleo:
linux text ks=http://IP_de_reposerver/ks/rhel4u6.cfg

Suelo evitar la resolucion DNS en este punto de la instalación, para ganar velocidad y evitarme problemas. Esta linea esta indicando que queremos instalar en modo texto, y que la secuencia de repuestas para anaconda la encontrará en esa URL.
Este mecanismo de instalación, tiene sus problemas en con RHEL5, porque anaconda usa yum en la instalacion, por lo que cuando hacemos la copia de los CDs a /opt/repos/RHEL5UXX debemos conservar los directorios repodata que vienen con los paquetes en CD, y habilitar el FTP. En el script de instalación de anaconda pondremos:

  url --url ftp://reposerver/repos/RHEL5U2/
  network --device eth0 --bootproto dhcp --hostname unattended-rh5u2

Para publicar repositorios yum, tendremos la precaución de ejecutar en configurator el comando createrepo sin sobreescribir el directorio repodata que teníamos del CD:

cd /mnt/reposerver
for i in RHEL5*
do
  for k in `find  /mnt/reposerver/$i -type d -maxdepth 1 `
  do
     if [ -d $k/RedHat/RPMS ]
     then
        cd $k/RedHat/RPMS
        mv repodata repodata.cd
        createrepo .
        mv repodata repodata.web
        mv repodata.cd repodata
     fi
  done
done
sync
cd
umount /mnt/reposerver

Luego en Apache, tendremos crear diferentes alias para que la URL
http://reposerver/repos/RHEL5UX/YYYYY/RedHat/RPMS/repodata
apunte a /opt/repos/RHEL5UX/YYYYY/RedHat/RPMS/repodata.web
... donde UX será el Update de nuestra distribución RHEL5, e YYYYY, será el directorio de paquetes: Cluster, cluster-Storage, Server, etc...


Como este planteamiento nos obliga a tener varias máquinas configurator para crear los repositorios de diferentes distribuciones, lo que se puede hacer es usar el reposerver como DOM-0 con XEN, que ejecuta el mismo, el resto de máquinas configurator, las cuales son máquinas virtuales XEN ejecutadas como ya he dicho en el propio reposerver.


Si queremos usar todo esto en RHEL3, es posible, siguiendo las instrucciones de RHEL4, sólo que en los clientes necesitaremos instalar los paquetes: python-urlgrabber y yum, que podremos encontrar en
http://rpmfind.net/linux/RPM/Dag_Apt_Repository_for_Red_Hat_Enterprise_Linux_3.html

Yo uso las versiones: python-urlgrabber-2.9.7-1.1.el3.rf.noarch.rpm y yum-2.0.8-0.1.el3.rf.noarch.rpm, y tampoco me han dado problemas que yo sepa. Las dependencias como siempre, de los paquetes oficiales de la propia RHEL3.
Luego se hace todo de la misma forma que antes, pero en vez de usar el comando "createrepo ." se usará "yum-arch .", y no creará directorios "repodata" sino "headers".