Un Fanático de LINUX

Creación de un servidor repositorio APT para paquetes RPM

por Héctor Suárez Planas

Es este pequeño manual encontrará cómo poner a punto un servidor repositorio de APT para paquetes RPM. Gracias al proyecto Debian por dar a luz ese formidable gestor de paquetes que es APT y a los desarrolladores de Conectiva Linux por portarlo a paquetes RPM.

Tener un repositorio APT para paquetes RPM nos permite gestionar mejor los paquetes en las distribuciones que usan RPM como gestor de paquetes, ya que despoja al usuario/administrador del fatigoso trabajo de tener que instalar/actualizar los paquetes “a mano”. Una cosa sí es cierta: la mayoría de los usuarios y administradores de red que se inician en el mundo de GNU/Linux (principalmente los que comienzan con distribuciones que usan paquetes RPM como RedHat, SuSE, Mandrake, Mandriva, etc.) se topan con el terrible trabajo de gestionar paquetes.

La manera más fácil para hacer esta tarea es mediante la interfaz gráfica. Sí, la aplicación encargada de gestionar los paquetes es eficiente para este trabajo. Todo funciona bien cuando no se ha actualizado el sistema (en el caso de los que aún no tienen Yum configurado), cuando el sistema se actualiza con paquetes que se han emitido posteriores a la versión del SO ocurren verdaderos dolores de cabeza. Supongamos que se va a incluir un paquete que olvidamos y hemos actualizado el sistema, dicha aplicación emite mensajes de error indicando que cierto paquete no está instalado o no está disponible. Hum, ¡qué problema! :o(

Para los que gustan del shell, los problemas son mayores cuando vamos a instalar un paquete que tiene un montón de dependencias (sí, menudo trabajo lleva). Hay que instalar las dependencias primero antes de instalar el paquete que queremos. Ahora bien, supongamos que estamos instalando dichas dependencias y hay uno de los paquetes que pide más dependencias, ¿qué hacemos? Pues bien, usar las herramientas “gráficas” que gestionan los paquetes y nos quitamos el problema de encima. Ajá, todo bien, ¿y si hemos actualizado en sistema? Volvemos al problema antes mencionado (los paquetes que no están instalados o no están disponibles).

Ahí es donde entra APT para salvarnos la vida. Una buena parte de los usuarios y administradores de red que han usado Debian y sus derivados habrán notado que este gran gestor de paquetes nos ayuda a resolver problemas de actualizaciones y dependencias que se generan a la hora de instalar, actualizar o eliminar aplicaciones del sistema.

¿Qué es APT para RPM?

El APT original que la mayoría conoce es una verdadera joya nacida en Debian y ampliamente utilizada desde hace mucho tiempo, de lo cual pueden jactarse con regocijo y orgullo sus seguidores. APT para RPM fue trabajo realizado por el equipo de desarrollo de Conectiva Linux, y debido a lo verdaderamente práctico que ha resultado fue que otros desarrolladores optaron por portar está útil herramienta a otros sistemas operativos basados sobre RPM.

Utilizar APT para RPM puede llegar a resultar una experiencia reconfortante para cualquier usuario/administrador dada la simpleza para descargar y actualizar lo necesario en un sistema.

¿Cómo trabaja un repositorio?

Un repositorio (al estilo Debian) consiste, a lo sumo, en un directorio con varios paquetes DEB dentro y dos archivos especiales: Packages.gz, para los paquetes binarios; y Sources.gz, para los paquetes de código fuente. Si su repositorio está especificado correctamente en /etc/apt/sources.list, apt-get descargará los índices de los archivos binarios desde el archivo Packages.gz (cuando se especifica la palabra clave deb) y los de los archivos de código fuente desde el archivo Sources.gz (cuando se especifica la palabra clave deb-src).

El archivo Packages.gz contiene el nombre, versión, tamaño, las descripciones corta y larga, y las dependencias de cada paquete más alguna información adicional, la cuál no es de mucho interés para nosotros. Toda esta información es listada y usada por las aplicaciones de Debian que gestionan los paquetes como son dselect y aptitude.

El archivo Sources.gz contiene el nombre, versión, y las dependencias (fuentes que son necesarias para construir) de cada paquete (la información adicional no es de mucho interés para nosotros tampoco). Esa información es usada por apt-get source y herramientas similares.

El archivo Release es un archivo opcional que contiene informaciones acerca del repositorio. Esta es usada para el Pinning (véase el documento APT-HOWTO [http://www.debian.org/doc/manuals/apt-howto]).

Una vez que ya hemos levantado nuestro repositorio, podemos listar e instalar todos nuestros paquetes (tanto actualizaciones como los de la distro). Si queremos actualizar un paquete (cuando el usuario ejecute apt-get upgrade o apt-get dist-upgrade), veremos una descripción corta y alguna otra información acerca de los paquetes que van a ser actualizados.

Por lo tanto, tener un repositorio es muy importante (y muy cómodo), ya que si se dispone de varias plataformas de software (diferentes distribuciones) es más fácil si se tiene un servidor central desde donde se puede descargar tanto paquetes originales como actualizaciones.

Configuración y puesta a punto de un repositorio APT-RPM

Primero que nada, aclaro que en el servidor puede tener cualquier distribución de Linux corriendo (sea RedHat, Gentoo, Debian, Ubuntu, etc.). Para lo que se necesita no importa. La prueba la realicé con un CentOS 4.3 con resultados positivos.

Empecemos suponiendo que ya tenemos nuestra distro basada en paquetes RPM funcionando con apt-get (RedHat en nuestro caso) y controlamos apt-get a plenitud (o al menos una buena parte). Como resulta que los servidores de apt-rpm con las actualizaciones están algo saturados en algunos casos o no están accesibles (por no disponer de una conexión a Internet/Intranet), necesitamos un servidor de actualizaciones para APT rápido y accesible.

“Ingredientes” para crear un repositorio APT-RPM

· Un PC/Servidor con GNU/Linux instalado y con mucho espacio en disco.

· El demonio vsftpd (o el apache).

· Tener implementado un mecanismo de actualización..

· El paquete APT instalado.

Preparación

Empecemos creando un árbol de directorios donde almacenaremos los RPMs que vayamos a albergar en el servidor. Por ejemplo, para CentOS 4.3 yo utilizo el siguiente árbol de directorios:

/pub/linux/centos/4.3/i386/RPMS.centosplus

/pub/linux/centos/4.3/i386/RPMS.contrib

/pub/linux/centos/4.3/i386/RPMS.extras

/pub/linux/centos/4.3/i386/RPMS.os

/pub/linux/centos/4.3/i386/RPMS.updates

/pub/linux/centos/4.3/i386/SRPMS.centosplus

/pub/linux/centos/4.3/i386/SRPMS.contrib

/pub/linux/centos/4.3/i386/SRPMS.extras

/pub/linux/centos/4.3/i386/SRPMS.os

/pub/linux/centos/4.3/i386/SRPMS.updates

/pub/linux/centos/4.3/i386/centosplus

/pub/linux/centos/4.3/i386/contrib

/pub/linux/centos/4.3/i386/extras

/pub/linux/centos/4.3/i386/os

Evidentemente, podemos tener en el mismo servidor los paquetes para diferentes distribuciones o versiones de cualquier distribución basada en RPM. Sólo es cuestión de tener espacio en disco.

¿Y por qué esa estructura? ¿Esos RPMS.x/SRPMS.x qué son?

Primero, dentro de las carpetas centosplus, contrib, extras y os se encuentran las subcarpetas RPMS, SRPMS, headers y repodata. Los RPMS.x/SRPMS.x no son más que enlaces simbólicos a las subcarpetas RPMS/SRPMS de cada carpeta principal.

Esos enlaces simbólicos son importantes a la hora de generar la lista de archivos que utiliza APT a la hora de actualizar el sistema. Me explico:

Supongamos que se tiene la siguiente línea en el archivo /etc/apt/sources.list.d/os.list:

rpm http://repositorio.dominio.com centos/4.3/i386 os updates

El primer elemento indica el tipo de paquetes (deb para los Debianitas), el segundo elemento indica el servidor o repositorio de donde se descargarán los paquetes, el tercer elemento indica el camino “raíz” donde están los componentes (los RPMS.x para que me entiendan) y los demás elementos indican los componentes (RPMS.os apunta a os y RPMS.updates apunta a updates).

El siguiente paso radica en tener los paquetes de la distribución en cuestión. O sea, los paquetes que vienen en los CDs de instalación más las actualizaciones. En el caso de las actualizaciones existen diferentes vías de adquisición: transportación en un disco duro, CD o memoria flash, sincronizando con algún servidor de actualizaciones (rsync) o descargándolas de algún servidor conocido (esa parte se la dejo a ustedes :o)).

Paquetes de la distro

O sea, en /pub/linux/centos/4.3/i386/os/RPMS se copiarán todos los paquetes RPMs de los 4 CDs del CentOS 4.3 (CentOS/RPMS en cada CD de instalación), en /pub/linux/centos/4.3/i386/os/headers se copiarán todas las cabeceras de paquetes que aparecen en la carpeta headers del primer CD, y en /pub/linux/centos/4.3/i386/os/repodata se copiarán las listas de los paquetes que aparecen en la carpeta repodata del primer CD.

Paquetes de actualizaciones

En el caso de las actualizaciones es simplemente poner las actualizaciones del sistema. Para los que disponen de una conexión a la Intranet Nacional (lo más cerca que tenemos) o de alguien que se conecte a dicha intranet o Internet (en el mejor de los casos) en la URL http://ftp.softwarelibre.cu/centos/4/updates/i386 está lo necesario, y solamente es descargar, como mismo está ahí, los paquetes, las cabeceras y las listas de paquetes (aclaro, siempre respetando el orden de las carpetas).

Luego de tener todo eso de nuestro lado y situado en los lugares en donde debe estar, procedamos a ejecutar lo siguiente:

genbasedir /var/ftp/pub/linux/centos/4.3/i386 os updates

Lo cual creará una carpeta llamada base donde se situarán las listas de paquetes de cada componente. Aclaro que en este momento sólo tengo los paquetes de la distro y sus actualizaciones, luego descargaré los demás paquetes y generaré la lista de paquetes de los demás componentes (centosplus y extras). El comando utilizado viene en el paquete apt, del cual se hablará más adelante.

Del otro lado del sol (los que se benefician del repositorio local creado)

Ahora toca el turno de configurar las/los máquinas clientes/servidores para el uso del repositorio local.

Procedimiento

1. Obtener apt para RPM.

El primer paso consiste en descargar el software requerido para la versión del sistema operativo utilizado, el cual se puede obtener desde http://apt.freshrpms.net/, http://apt.sw.be/packages/apt/, http://apt.sw.be/packages/synaptic/ o desde cualquier réplica de CentOS en pub/centos/4.3/extras/i386/RPMS/.

A continuación se instala APT y su gestor gráfico en el sistema:

rpm -ivh apt-0.5.15*.rpm

rpm -ivh synaptic-0.57*.rpm

2. Descargar listas de actualizaciones.

Una vez instalado, se necesitan descargar los listados de software requerido, esto se realiza conectándose a un servidor en particular y un directorio específico definido en /etc/apt/sources.list.d/.list (esto puede hacerse con cualquier distro basada en RPMs que soporte APT):

Centos 4.3 (nuestro ejemplo /etc/apt/sources.list.d/centos43.list):

### Repositorio APT para CentOS 4.3

rpm http://repositorio.dominio.com centos/4.3/i386 os updates

rpm-src http://repositorio.dominio.com centos/4.3/i386 os updates

Luego de editar los archivos dentro de /etc/apt/sources.list.d/ se debe ejecutar:

apt-get update

para “refrescar” la lista de paquetes.

3. Instalando paquetes.

Si se requiere instalar algún paquete, así como también todo aquello de lo cual este depende, puede ejecutarse lo siguiente:

apt-get install

4. Actualizando paquetes.

Las actualizaciones de los paquetes son un gran éxito de APT. Pueden realizarse con tan sólo un comando: apt-get upgrade. Puede utilizar esa opción para actualizar los paquetes de la distribución actual, o bien para actualizar a una nueva distribución, aunque el comando apt-get dist-upgrade es una mejor opción.

Es muy útil utilizar este comando con la opción -u. Esta opción muestra la lista completa de paquetes que APT actualizará. Sin ella, se estaría actualizando a ciegas. APT descargará las versiones más recientes de cada paquete y las instalará de la manera más apropiada. Es muy importante ejecutar siempre apt-get update antes de probar esto.

Entonces ejecutando:

apt-get -u upgrade

o

apt-get -u dist-upgrade

se actualiza (de una manera) los paquetes del sistema.

El proceso es muy fácil. APT gestiona las actualizaciones y sus dependencias. En caso de que exista algún paquete que no se pueda actualizar por no disponer de las dependencias, este se conservará.

Es muy importante mencionar que APT siempre busca la versión más reciente de los paquetes. Así pues, si en su archivo /etc/apt/sources.list.d se encontrara alguna otra fuente que tuviera una versión más reciente que la del CD, APT descargaría esta versión.

5. Eliminando paquetes del sistema.

Si se requiere desinstalar algún paquete, así como también todo aquello de lo que dependa de éste, puede ejecutarse lo siguiente:

apt-get remove 

6. Reparando problemas de dependencias.

En caso de existir dependencias rotas, solo basta ejecutar lo siguiente (sin especificar paquete alguno) para repararlas y descargar o eliminar los paquetes problemáticos:

apt-get -f install

NOTA:  Para mayor información, remitirse al APT-HOWTO. Ahí se explica al detalle cómo trabajar con apt-get.

7. Aplicación GUI para apt-get.

Si se desea utilizar una herramienta gráfica para el comando apt-get, puede utilizarse Synaptic.

Por Hacer

· Explicar detalladamente cómo conseguir las actualizaciones a través de la sincronización con algún repositorio externo (caso de estudio – Repositorio de Software Libre [CUBA]). Scripts para automatizar el proceso (mi pimer script ;o)).

· (Ya se me ocurrirá algo).

Agradecimientos

· A GNU/Linux.

· Artículo en Libertonia “apt-rpm: tu propio update server” (y sus scripts) de Sinner.

· A GNU/GPL en general.

· A mis amigos por haberme conseguido la documentación y las distros.

· A los colegas de la Lista de discusión de Software Libre por su apreciada colaboración.

NOTA: Discúlpenme si soy malo redactando. Esa fue una característica que no puede aprender ni tener durante mis 5 años de carrera, jejeje.

Gracias por su atención.

:o)

============================================

Héctor Suárez Planas

Lic. Ciencias de la Computación

Usuario Linux No.: 317556

E-mail: hspcuba@gmail.com

hspcuba@yahoo.es

Blog: http://nihilanthlnxc.blogspot.com

--------------------------------------------

Cuando no hay consulta, los planes fracasan;

el éxito depende de los muchos consejeros.

SALOMÓN

============================================