Repositorio de paquetes Debian «serio básico» y cómo usarlo

Esta receta explica cómo montar un repositorio de paquetes medianamente decente, que se pueda manejar con las herramientas estándares de Debian y se puedan utilizar firmas PGP tanto para el repo como para los paquetes.

Ingredientes

El ingrediente principal de esta receta es reprepro (aka mirrorer). Esta herramienta permite crear y gestionar un repositorio official (no trivial) de una forma trivial :-). Hay más herramientas para la gestión de repositorios.

Instala reprepro en la máquina que servirá el repositorio:

# aptitude install reprepro

Configuración

Creamos los siguientes directorios:

$ mkdir -p /var/repo/conf
$ mkdir -p /var/repo/incoming

En el directorio conf estarán todos los archivos de configuración para reprepro. El directorio incoming será la cola de entrada de paquetes subidos por los developers. A éste último volveré más adelante.

conf/distributions

En primer lugar, crea el archivo conf/distributions con el siguiente contenido:

Origin: Ciudad Real y Software Libre
Label: CRySoL
Suite: stable
Codename: stable
Architectures: i386 amd64 powerpc source
Components: main
Description: CRySoL repository
Pull: stable-pull

Origin: Ciudad Real y Software Libre
Label: CRySoL
Suite: unstable
Codename: sid
Architectures: i386 amd64 powerpc source
Components: main
Description: CRySoL repository
SignWith: PGP-ID-123
Uploaders: ./uploaders

Según lo especificado, el repositorio tendrá 2 ramas: stable y sid. Además de los campos evidentes, en la stable se ha especificado la propiedad Pull_. Esta propiedad nos servirá para definir una regla (_stable-pull) por la que se actualizará la rama stable a partir de sid. Las reglas de Pull se especifican en el fichero conf/pulls.

La distribución sid será donde, por defecto, subirán los paquetes los developers. El campo SignWith especifica el identificador de la firma PGP con la que se generarán los archivos Release.gpg (lo que se conoce comúnmente como «firmar el repo»). El usuario/os que tengan privilegios para reconstruir y modificar el repositorio deben tener dicha clave en su anillo.

Finalmente, la propiedad Uploaders especifica un archivo con el siguiente contenido:

allow * by key PGPID-DEVELOPER1
allow * by key PGPID-DEVELOPER2
allow * by key PGPID-DEVELOPER3

Es decir, los identificadores de las claves de los developers autorizados. Hay más atributos para las distribuiciones. Consulta el man de reprepro.

conf/pulls

Como ya se ha señalado, la rama stable del repositorio se actualizará automáticamente utilizando la regla pull-table. Un ejemplo puede ser el siguiente:

Name: stable-pull
From: sid
Components: main
Architectures: amd64 powerpc i386 source
FilterList: purge packages.old

Los campos más importantes son las reglas de filtrado como FilterList. En este caso, se utiliza el comando purge que indica que, en tiempo de actualización, se borren los archivos que no aparecen listados dentro de packages.old_. Éste es un nombre de archivo cualquiera. En mi caso, es generado por un programa que selecciona los paquetes que llevan más de 1 semana sin actualizarse. Como no se han actualizado en ese tiempo, pasan a stable.

conf/incoming

Finalmente, sólo queda configurar cómo se debe realizar la gestión de la cola de subida de paquetes. Un ejemplo de regla de gestión (sid-process):

Name: sid-process
IncomingDir: incoming
TempDir: /tmp
Default: sid
Allow: unstable>sid UNRELEASED>sid
Cleanup: on_deny on_error

Por defecto, los paquetes se subirán a sid tal y como se indica. Además, si los paquetes han sido firmados por alguien no autorizado o se produce un error durante su comprobación, se borrarán de la lista (propiedad Cleanup). La propiedad Allow permite que los paquetes en cuyos ChangeLog se hayan utilizado los términos
unstable o UNRELEASED (muy común si estás probando el paquete) vayan a parar a sid.

Gestión del repo

Los siguientes ejemplos se suponen ejecutados desde el raíz del repositorio (en nuestro ejemplo:/var/repo). La opción @-V @ puede ser omitida en todos los casos.

Importar paquetes .deb

$ reprepro -V includedeb sid path/to/*.deb

Eliminar un paquete

$ reprepro -V remove sid package_name

Procesar la cola de envíos

Nótese que se utiliza el nombre de la regla de procesamiento
sid-process

$ reprepro -V processincoming sid-process

Haz tu repo accesible

Si no lo has hecho aún, es necesario que permitas que los usuarios puedan acceder a tu repositorio utilizando HTTP u otro protocolo. Si tienes Apache, o algún otro servidor web, permite que tu repositorio sea accedido para leer (y listar) desde su raíz.

Exporta la clave

Si los usuarios empiezan a utilizar tu repositorio seguramente te den la brasa con: “¿no puedes exportar la clave? Es que me da error el apt…”. Exporta tu clave PGP y hazla accesible:

$ gpg --export --armor ID-KEY-123 > key.asc
$ mv key.asc /var/repo

Utilizando el repositorio

Veamos ahora lo que necesita el usuario para poder utilizar el repo y subir paquetes.

Importar clave y actualizar

$ wget -O- http://example.com/repo/key.asc | sudo apt-key add -
...
OK
$ sudo apt-get update

debsign

Una vez que hayas generado tu paquete Debian y te dispongas a subirlo, antes de nada debes firmarlo con tu clave GPG con debsign (te pedirá la clave un par de veces):

$ debsign -kID-KEY paquete_1.0-1_i386.changes

dupload

dupload es una herramienta para subir paquetes fuentes y binarios (ya firmados). Para que no sea un engorro utilizarlo con el repositorio, recomiendo que edites tu .dupload.conf:

package config;

$default_host = "host_del_repo";

$cfg{'host_del_repo'} = {
 fqdn => "example.com",
 login => "repo_user",
 method => "scpb",
 incoming => "/var/repo/incoming/",

# The dinstall on ftp-master sends emails itself
 dinstall_runs => 1,
};

Con todo ello, accederás por scp (batched) a example.com como el usuario repo_user. Ya sólo queda ejecutar:

$ dupload --to host_del_repo paquete_1.0-1_i386.changes

Referencias

• Man de reprepro
• Setting up your own APT repository with upload support. Muy
  buena, pero algo obsoleta.