Cómo crear tu propio repositorio de software para Linux

Montar tu propio repositorio de software para Linux es una de esas cosas que al principio suenan a “infraestructura de gran empresa”, pero que en realidad puedes tener funcionando en tu servidor (o incluso en tu propio PC) si sigues una serie de pasos lógicos. Si estás creando tu propia distribución basada en Debian o Ubuntu, o simplemente quieres distribuir .deb personalizados a tus usuarios, tener un repositorio APT propio es casi obligatorio.

Más allá de la parte friki, un repo bien montado te da control total sobre qué paquetes ofreces, cómo se actualizan y de qué manera llega ese software a las máquinas cliente. Desde un pequeño repositorio local para unos cuantos paquetes internos hasta una infraestructura fusionada con otros repositorios usando herramientas como reprepro o amprolla, las posibilidades son enormes.

Qué es exactamente un repositorio de software en Linux

En el ecosistema GNU/Linux, un repositorio no es más que un servidor (normalmente HTTP/HTTPS) que guarda paquetes y metadatos preparados para que el gestor de paquetes de tu distribución pueda buscarlos, descargarlos e instalarlos de forma segura. En Debian, Ubuntu y derivadas, esto se traduce en repositorios APT que distribuyen paquetes .deb y sus archivos de índice.

Cuando añades una línea deb … a tu /etc/apt/sources.list o a un fichero dentro de /etc/apt/sources.list.d/, le estás diciendo a APT: “aquí tienes otra fuente de programas; fíate de ella y úsala para instalar y actualizar paquetes”. El sistema descargará periódicamente los índices de esos repositorios para saber qué versiones hay disponibles.

Los repositorios oficiales de cada distribución suelen estar firmados y mantenidos por el propio proyecto (por ejemplo, Canonical en el caso de Ubuntu). Además de esos repos por defecto, puedes añadir repositorios de terceros o propios para distribuir software que no esté en los repos oficiales, versiones modificadas o compilaciones personalizadas.

Una gran ventaja del modelo de repositorios es la seguridad: los paquetes se firman criptográficamente y el gestor de paquetes comprueba esa firma antes de instalarlos. Si alguien manipula un paquete o la lista de paquetes en tránsito, la verificación de firma fallará y APT te avisará de que ese repositorio no es de confianza.

Tipos de repositorios en Debian/Ubuntu: main, universe, restricted…

En Ubuntu (y muchas derivadas) los repositorios se dividen en varias secciones o componentes, cada uno con su política de soporte y licencias. Conocer estas secciones te ayudará a organizar tu propio repositorio cuando definas qué partes quieres ofrecer.

La sección main es el núcleo del sistema: contiene software libre mantenido directamente por Canonical con soporte de seguridad y actualizaciones garantizadas durante el ciclo de vida de la versión. Ahí entran paquetes como Firefox, Nano o Evince, completamente libres y con mantenimiento oficial.

La sección universe incluye software libre mantenido por la comunidad, no por Canonical. Es decir, sigue siendo FOSS, pero el mantenimiento y corrección de errores corren a cargo de voluntarios. El riesgo de seguridad es algo mayor porque no hay un compromiso corporativo, aunque la mayoría de paquetes son perfectamente fiables. Cuando un paquete de universe se vuelve crítico o muy popular y tiene un buen mantenimiento, puede pasar a main.

Por su parte, la sección restricted agrupa software propietario o con licencias más restrictivas. Canonical lo mantiene en la medida de lo posible, pero las actualizaciones y correcciones pueden depender de los proveedores originales. Este tipo de software no puede redistribuirse tan libremente como el de main o universe.

En tu propio repositorio puedes crear tus propios componentes (por ejemplo main contrib non-free) y decidir qué entra en cada uno. Esta organización por componentes facilita separar software totalmente libre de piezas privativas o experimentales.

Cómo se añaden y gestionan repositorios APT en un sistema Debian/Ubuntu

Desde el punto de vista del usuario final, gestionar repositorios es relativamente sencillo. En entornos de escritorio Ubuntu, existe la herramienta gráfica “Software y actualizaciones” que permite añadir, quitar y editar repositorios sin tocar archivos de configuración a mano.

El flujo básico con la herramienta gráfica es el siguiente: buscas “Software y actualizaciones” en el menú de Actividades, entras en la pestaña “Otro software”, pulsas en “Añadir” y copias la línea APT que el desarrollador indica en su web. Tras confirmar, la aplicación te pedirá la contraseña de administrador y Ubuntu comenzará a refrescar los orígenes de software para tener en cuenta el nuevo repositorio.

Muchas veces, además, el repo viene acompañado de una clave de firma OpenPGP que tendrás que instalar para que APT pueda verificar los paquetes. Hoy en día lo recomendable es usar el mecanismo moderno de keyrings en /usr/share/keyrings o rutas similares, en lugar del ya obsoleto apt-key.

Si prefieres la consola o estás en un servidor, puedes editar directamente los ficheros de configuración. El archivo principal es /etc/apt/sources.list, pero cada repositorio adicional se suele definir en su propio fichero .list dentro de /etc/apt/sources.list.d/. Así todo queda más ordenado.

Por ejemplo, para ver y editar tu lista de repositorios podrías usar:

sudo nano /etc/apt/sources.list

y añadir al final una línea como:

deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main

Una vez guardados los cambios, es imprescindible actualizar el índice de paquetes con sudo apt update para que APT conozca el contenido del nuevo repositorio. Si además quieres aplicar las actualizaciones disponibles, usarías sudo apt upgrade.

Estructura y archivos clave de un repositorio APT

Un repositorio APT, por dentro, es básicamente un árbol de directorios con dos grandes piezas: la parte “dists” (índices y metadatos por distribución y componente) y la parte “pool” (los paquetes .deb propiamente dichos). Todas las herramientas que vamos a ver, como reprepro, dpkg-dev o amprolla, se dedican a generar y mantener esa estructura y los archivos de índice.

En el lado de los metadatos, los repositorios Debian-like usan archivos Release, InRelease y listados Packages o Packages.gz para describir qué paquetes hay, en qué versión, para qué arquitectura, etc. Estos archivos se colocan en rutas como:

dists/<codename>/main/binary-amd64/Packages.gz

y similares para otras arquitecturas y componentes.

En la parte de datos, el directorio pool/ contiene los .deb, clasificados normalmente por sección y nombre de paquete. La magia de APT consiste en cruzar los índices con los contenidos del pool para descargarse el .deb adecuado cuando le pides instalar algo.

Para que todo esto sea de confianza, la cabecera Release del repositorio se firma con una clave OpenPGP y el cliente APT comprueba esa firma usando un keyring local. Quédate con este concepto porque lo vamos a usar tanto en los repos locales simples como en los repos más avanzados con reprepro.

Crear un repositorio local simple con dpkg-dev

Si solo quieres un repositorio sencillo para unos cuantos paquetes locales —por ejemplo, para distribuir un .deb de Google Chrome o paquetes internos de tu empresa— puedes montarlo solo con el paquete dpkg-dev y un directorio accesible desde tus máquinas.

El primer paso es asegurarse de que tu sistema está al día e instalar dpkg-dev. En cualquier Debian o Ubuntu basta con actualizar índices e instalar el paquete con APT:

sudo apt update && sudo apt upgrade
sudo apt install dpkg-dev

Después creas el directorio que actuará como raíz de tu repositorio local. En muchos ejemplos se usa /opt/local/debs, pero puedes usar cualquier ruta a la que tengan acceso las máquinas cliente (directorio local, NFS, etc.):

sudo mkdir -p /opt/local/debs
cd /opt/local/debs

Ahora copias o descargas ahí tus paquetes. Por ejemplo, podrías bajar el .deb de Google Chrome directamente desde Google y dejarlo dentro de ese directorio:

wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb

Para que APT reconozca este directorio como un repositorio válido, necesita que generes los metadatos que describen qué paquetes hay dentro. Esto se hace con la herramienta dpkg-scanpackages incluida en dpkg-dev. Lo normal es ejecutarla como root si estás trabajando en rutas del sistema:

sudo su -
cd /opt/local/debs
dpkg-scanpackages . /dev/null > Release
dpkg-scanpackages . /dev/null | gzip -9c > Packages.gz

Tras ejecutar estos comandos, en el directorio tendrás el .deb, un fichero Release y un Packages.gz que APT sabe interpretar. Cada vez que añadas nuevos .deb al directorio tendrás que volver a lanzar estos comandos (o crear un pequeño script para automatizarlo).

El último paso es decirle a tu sistema que use este directorio como fuente de paquetes. Para ello editas /etc/apt/sources.list o añades un .list nuevo y apuntas a la ruta de archivos con el esquema file::

sudo nano /etc/apt/sources.list

Añade una línea como esta:

deb [trusted=yes] file:/opt/local/debs ./

El flag [trusted=yes] le indica a APT que no compruebe firmas para este repositorio, algo razonable en un entorno local controlado. Tras guardar el fichero, ejecuta sudo apt update y podrás instalar tus paquetes locales con apt install igual que si fueran de un repo remoto.

Crear un repositorio Debian completo con reprepro y firma OpenPGP

Cuando necesitas algo más serio —por ejemplo, ofrecer paquetes para varias versiones de Debian/Ubuntu, distintas arquitecturas y con control fino de componentes— lo más cómodo es usar una herramienta especializada como reprepro. Esta utilidad se encarga de mantener la estructura estándar de un repositorio Debian y firmar los índices de forma automática.

Lo primero es instalar reprepro en un sistema Debian o derivado. Con APT es tan simple como actualizar repositorios e instalar el paquete:

apt -y update
apt -y install reprepro

A continuación decides dónde va a vivir tu repositorio. Si vas a servirlo vía web con Apache o Nginx, una ruta típica es /var/www/html/repositorio. Crea la estructura básica con su carpeta de configuración:

mkdir -p /var/www/html/repositorio/conf

Antes de que reprepro pueda firmar los índices, necesitas una clave OpenPGP dedicada a firmar tu repositorio. Lo más limpio es generar una clave RSA de solo firma, personalizada para este uso, utilizando GnuPG:

gpg --full-generate-key

El asistente te preguntará el tipo de clave (elige la opción de RSA que solo firma si quieres algo específico para repositorios), el tamaño en bits (3072 es una buena elección hoy por hoy) y el periodo de validez (puedes indicar 0 para que no caduque). También te pedirá nombre, correo y un comentario, donde puedes poner algo tipo “Firma de paquetes Debian” para identificarla fácilmente.

Durante la generación, GnuPG te pedirá que generes “entropía” moviendo el ratón o usando el sistema. Al final obtendrás una salida donde verás el identificador de la clave (por ejemplo, ABCDEFGHIJKLMNO o un fingerprint largo) y se marcará como “de confianza absoluta” si la has configurado así.

Con la clave creada, debes exportar su parte pública para publicarla en el propio repositorio, de manera que los clientes puedan descargarla e instalarla como keyring de confianza. Puedes exportarla en formato ASCII armor y guardarla en tu directorio del repo:

gpg --armor --export ABCDEFGHIJKLMNO > /var/www/html/repositorio/repositorio.key

Dado que el antiguo formato .key está deprecado, conviene convertir esa clave a un keyring binario OpenGPG moderno, siguiendo el patrón de nombres recomendado:

cd /var/www/html/repositorio
cat repositorio.key | gpg --dearmor > repositorio-archive-keyring.gpg

Ahora toca decirle a reprepro qué distribuciones y componentes va a gestionar este repositorio. Esto se hace creando un fichero distributions dentro de /var/www/html/repositorio/conf con la descripción de cada distribución (codename) que quieras ofrecer:

cd /var/www/html/repositorio/conf
touch distributions

Edita ese fichero e incluye algo similar a lo siguiente para, por ejemplo, Debian buster:

Origin: repositorio.tu-dominio
Label: repositorio.tu-dominio
Codename: buster
Architectures: amd64 i386
Components: main contrib non-free
Description: Repositorio publico y personal
DebIndices: Packages Release . .gz .bz2
SignWith: ABCDEFGHIJKLMNO

La clave está en los campos Codename (nombre de la distribución, como buster, bullseye, jammy…), Architectures, Components y SignWith, donde especificas el ID de la clave que generaste antes. Si quieres mantener varias versiones a la vez, solo tienes que añadir nuevos bloques separados por una línea en blanco, cambiando el Codename en cada uno.

Con el fichero de distribuciones definido, ya puedes pedir a reprepro que genere la estructura necesaria dentro de tu repositorio. Los comandos básicos de inicialización son:

cd /var/www/html/repositorio
reprepro -VVV export
reprepro -VVV createsymlinks

A partir de aquí, incluir paquetes en tu repositorio es muy directo. Si tienes un fichero paquete.deb que quieres ofrecer para, digamos, la distribución bullseye, utilizarías:

reprepro -b /var/www/html/repositorio/ includedeb bullseye paquete.deb

Si quieres forzar que el paquete caiga en una sección concreta (por ejemplo, main), puedes añadir el parámetro -S:

reprepro -S main -b /var/www/html/repositorio/ includedeb bullseye paquete.deb

Para listar qué paquetes hay disponibles en una distribución concreta de tu repo, harías algo como:

reprepro -b /var/www/html/repositorio/ list bullseye

Y si necesitas eliminar un paquete concreto de una distribución:

reprepro remove bullseye nombre-del-paquete

Si en alguna operación reprepro te pide la passphrase de la clave y da problemas, puedes añadir --ask-passphrase para forzar ese diálogo y evitar errores silenciosos. Una vez que pillas la dinámica, mantener el repositorio se vuelve bastante rutinario.

Servir el repositorio con Apache o Nginx

Para que otras máquinas puedan usar tu repositorio, necesita estar disponible vía HTTP o HTTPS. Aquí entran en juego servidores web como Apache2 o Nginx, que simplemente van a exponer el directorio donde vive tu repo.

Si usas Apache2, lo habitual es crear un VirtualHost específico. Por ejemplo, podrías definir repositorio.tu-dominio apuntando a /var/www/html/repositorio como DocumentRoot. Un ejemplo simplificado de configuración sería:

<VirtualHost *:80>
ServerName repositorio.tu-dominio
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html/repositorio
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Si quieres servirlo por HTTPS, añadirías el bloque correspondiente en el puerto 443 con SSLEngine on y tu certificado. Es muy importante restringir el acceso a algunas subcarpetas internas de reprepro como db, conf o incoming, ya que contienen datos internos que no deberían descargarse desde fuera.

Una vez tengas el fichero, lo activas con:

a2ensite repositorio.conf
service apache2 reload

Con Nginx la idea es similar, aunque la sintaxis cambia. Creas un bloque de servidor en /etc/nginx/sites-available/ que escuche en el puerto 80 y apunte al directorio del repo:

server {
listen 80;
access_log /var/log/nginx/repo-access.log;
error_log /var/log/nginx/repo-error.log;
location / {
root /var/www/html/repositorio;
autoindex on;
}
location ~ /(.*)/conf {
deny all;
}
location ~ /(.*)/db {
deny all;
}
}

El autoindex on permite listar el contenido de los directorios, algo útil si quieres navegar por el repo con un navegador web. Tras enlazar el sitio desde sites-enabled, reinicias Nginx:

systemctl restart nginx

Con esto, tu repositorio ya será accesible desde cualquier máquina que pueda resolver el dominio o alcanzar la IP del servidor. Toca ahora ver cómo se configura en los clientes.

Configurar clientes APT para usar tu repositorio firmado

En las máquinas cliente, el procedimiento moderno para añadir tu repo es siempre el mismo: descargar el keyring OpenGPG, colocarlo en una ruta estándar y crear un .list que haga referencia a ese keyring con la opción signed-by.

Supongamos que has publicado repositorio-archive-keyring.gpg y un fichero repositorio.list en la raíz de tu repo. En el cliente, primero necesitas asegurarte de tener soporte para HTTPS si tu repo usa TLS:

apt-get install -y apt-transport-https

Después descargas el keyring y el fichero .list a sus ubicaciones definitivas. Una convención muy utilizada es guardar el keyring en /usr/share/keyrings y el .list en /etc/apt/sources.list.d/:

wget https://repositorio.tu-dominio/repositorio-archive-keyring.gpg \
-O /usr/share/keyrings/repositorio-archive-keyring.gpg
wget https://repositorio.tu-dominio/repositorio.list \
-O /etc/apt/sources.list.d/repositorio.list

El contenido típico de ese repositorio.list podría ser:

# Repositorio tu-dominio
deb [signed-by=/usr/share/keyrings/repositorio-archive-keyring.gpg] \
http://repositorio.tu-dominio/ bullseye main contrib non-free

Con eso listo, solo tienes que ejecutar:

apt -y update

y APT descargará los índices de tu repositorio, verificará la firma con el keyring y pondrá tus paquetes al mismo nivel que los del resto de fuentes. Desde ese momento, cualquier paquete que publiques en tu repo estará disponible mediante apt install, resolviendo dependencias contra el resto de repos configurados.

Fusionar repositorios con amprolla y montar infraestructuras más complejas

Si te metes en ligas mayores —por ejemplo, crear una distribución derivada que toma paquetes de Debian, Devuan, Gnuinos y a la vez introduce su propio repositorio local— puede interesarte una herramienta como amprolla. Amprolla actúa como un “proxy” que fusiona varios repositorios APT en uno solo, resolviendo qué paquete ofrecer de cada origen.

El flujo básico con amprolla consiste en clonar su repositorio (normalmente desde GitHub), revisar el archivo de configuración lib/config.py y ajustar rutas, lista de repositorios origen y nombre de tu distro. En esa configuración se definen cosas como mergedir (donde se generará el repo fusionado), spooldir (donde se guardan temporalmente los índices descargados) y el orden de prioridad entre repos.

Tras configurar, ejecutas primero el script que descarga y prepara los índices de los repositorios origen, generando la estructura de spool/<origen>/dists/<codename>/.... Después lanzas el script de fusión, que crea el directorio final (por ejemplo merged-volatile) con los índices combinados.

En ese paso, puedes decidir cómo firmar el repositorio resultante. Una opción práctica es firmar manualmente los archivos Release/InRelease usando tu clave GPG, del mismo modo que hacías con reprepro, y publicar también la clave pública en el servidor. APT comprobará esa firma exactamente igual que con cualquier otro repo.

Un detalle importante de la configuración de amprolla (y de muchos setups similares) es que la parte “pool” puede seguir apuntando a los repositorios originales. Es decir, tu merged/pool puede estar vacío y usar reglas de reescritura (rewrite) en el servidor web para redirigir las peticiones de los paquetes a los repos de Debian, Devuan, etc.

Con Nginx o Apache esto se resuelve con reglas de rewrite o redirecciones 302 en un .htaccess si trabajas en un hosting compartido. Desde el punto de vista del cliente APT, sigue viendo un único repositorio central, aunque internamente cada paquete venga de un origen diferente.

Este enfoque es el que utilizan algunas distribuciones como Devuan para superponer paquetes propios sobre los de Debian, reemplazando algunos (como initramfs-tools adaptado a su sistema) y dejando otros intactos. Cuando dos paquetes tienen el mismo nombre pero distinta versión, amprolla y APT decidirán cuál ofrecer en función de la configuración y las prioridades.

Repositorios remotos “llave en mano” con Launchpad (PPA)

Otra vía muy popular, sobre todo en el mundo Ubuntu, es usar Launchpad para crear PPAs (Personal Package Archives). En lugar de montar tu propio servidor y pelearte con reprepro, dejas que la infraestructura de Canonical se encargue de compilar, firmar y servir tus paquetes para Ubuntu y derivadas.

Launchpad es una plataforma de desarrollo colaborativo que ofrece seguimiento de errores, alojamiento de código (ahora también con Git), herramientas de traducción, sistema de propuestas de mejoras y, lo que nos interesa aquí, repositorios personales para paquetes. Cada PPA es, en la práctica, un repositorio APT mantenido por ti.

Para usar Launchpad necesitas primero una cuenta de Ubuntu One, que hoy en día actúa como sistema de autenticación único para varios servicios de Canonical. Creas tu cuenta en Ubuntu One, validas el correo y después entras en Launchpad usando esas mismas credenciales.

Dentro de Launchpad, lo primero es completar tu perfil: puedes ajustar tu nombre visible, tu nick, tu avatar e incluso configurar detalles públicos de tu cuenta. Lo más importante desde el punto de vista de los repositorios es subir tus claves SSH, que Launchpad usará para autenticarse cuando empujes código o sesiones de empaquetado.

Si no tienes ya una clave SSH generada en tu máquina, la creas con:

ssh-keygen

y sigues el asistente, que te preguntará dónde guardar la clave (por defecto ~/.ssh/id_rsa) y si quieres protegerla con passphrase. Luego copias el contenido del archivo .pub (la parte pública) y lo pegas en el apartado SSH Keys de tu perfil de Launchpad.

Una vez está todo listo, crear un PPA es tan sencillo como usar el enlace “Create a new PPA”, indicar un nombre corto, una descripción y activar el archivo. A partir de ese momento dispones de una URL del estilo:

ppa:tu-usuario/tu-ppa

que los usuarios podrán añadir con herramientas como add-apt-repository. Cada vez que subas una nueva versión empaquetada de tu software al PPA, Launchpad la compilará para las versiones soportadas y la pondrá a disposición de los usuarios con el mismo mecanismo de actualizaciones de siempre.

Esta opción tiene la ventaja de que no necesitas mantener un servidor propio, ni configurar Apache/Nginx, ni pelearte con reprepro. A cambio, estás limitado al ecosistema Ubuntu y a las reglas de Launchpad, pero para muchísimos proyectos de escritorio es más que suficiente.

En definitiva, ya sea con un simple directorio local, con un repositorio completo gestionado por reprepro, con un mega-repo fusionado vía amprolla o a través de un PPA en Launchpad, crear tu propio repositorio de software para Linux te da una flexibilidad brutal para distribuir, actualizar y controlar tus paquetes .deb, y es una pieza clave si quieres llevar tu distribución o tus aplicaciones un paso más allá.