15.3. Créer une archive de paquets pour APT

Les administrateurs de Falcot SA maintiennent désormais un certain nombre de paquets Debian modifiés ou créés par eux et qui leur servent à diffuser des données et programmes internes.

Pour faciliter leur déploiement, ils souhaitent les intégrer dans une archive de paquets directement utilisable par APT. Pour des raisons évidentes de maintenance, ils désirent y séparer les paquets internes des paquets officiels recompilés. Les entrées qui correspondraient à cette situation dans un fichier /etc/apt/sources.list.d/falcot.list seraient les suivantes :

deb http://packages.falcot.com/ updates/
deb http://packages.falcot.com/ internal/

Les administrateurs configurent donc un hôte virtuel sur leur serveur HTTP interne. La racine de l'espace web associé est /srv/vhosts/packages/. Pour gérer ces archives, ils ont décidé d'employer le programme mini-dinstall (du paquet éponyme). Celui-ci scrute un répertoire d'arrivée incoming/ (en l'occurrence, il s'agira de /srv/vhosts/packages/mini-dinstall/incoming/) pour y récupérer tout paquet Debian déposé et l'installer dans une archive Debian (dont le répertoire est /srv/vhosts/packages/). Ce programme fonctionne en traitant les fichiers .changes créés lors de la génération d'un paquet Debian. Un tel fichier contient en effet la liste de tous les autres fichiers associés à cette version du paquet (.deb, .dsc, .diff.gz/debian.tar.gz, .orig.tar.gz ou fichiers équivalents utilisant d'autres outils de compression) et indique donc à mini-dinstall quels fichiers installer. Accessoirement, ce fichier reprend le nom de la distribution de destination (c'est souvent unstable) indiquée en tête du fichier debian/changelog, information utilisée par mini-dinstall pour décider de l'emplacement d'installation du paquet. C'est la raison pour laquelle les administrateurs doivent systématiquement modifier ce champ avant la génération d'un paquet et y placer internal ou updates, selon l'emplacement souhaité. mini-dinstall génère alors les fichiers indispensables au bon fonctionnement d'APT, par exemple Packages.gz.

ALTERNATIVE apt-ftparchive, aptly, and reprepro

Si l'emploi de mini-dinstall semble trop complexe par rapport à vos besoins de création d'une archive Debian, il est possible d'utiliser directement le programme apt-ftparchive. Ce dernier inspecte le contenu d'un répertoire et affiche sur sa sortie standard le contenu du fichier Packages correspondant. Pour reprendre le cas de Falcot SA, les administrateurs pourraient directement déposer les paquets dans /srv/vhosts/packages/updates/ ou /srv/vhosts/packages/internal/ et exécuter les commandes suivantes pour créer les fichiers Packages.gz :

$ cd /srv/vhosts/packages
$ apt-ftparchive packages updates >updates/Packages
$ gzip updates/Packages
$ apt-ftparchive packages internal >internal/Packages
$ gzip internal/Packages

La commande apt-ftparchive sources crée de manière similaire les fichiers Sources.gz.

reprepro and aptly are more advanced tools for the same purpose. They can produce, manage and synchronize a number of package repositories, mirror other repositories, even cherry-pick packages from official repositories and provide them locally, create signatures of the generated package indices and thus provide signed repositories. reprepro stores packages and checksums in a Berkeley DB database file, so no database server is needed. aptly provides the same functionality, but it can be easier in handling. Unfortunately, both projects, although probably the most feature-rich solutions, are not actively developed at the moment.

reprepro comes with a lot of documentation and examples in /usr/share/doc/reprepro/, while aptly has a vast online documentation.

→ https://www.aptly.info/

La configuration de mini-dinstall nécessite de mettre en place un fichier ~/.mini-dinstall.conf, que les administrateurs de Falcot SA ont renseigné comme suit :

[DEFAULT]
archive_style = flat
archivedir = /srv/vhosts/packages

verify_sigs = 0
mail_to = admin@falcot.com

generate_release = 1
release_origin = Falcot SA
release_codename = stable

[updates]
release_label = Recompiled Debian Packages

[internal]
release_label = Internal Packages

Il est intéressant d'y remarquer la décision de générer des fichiers Release pour chacune des archives. Cela permettra éventuellement de gérer les priorités d'installation des paquets à l'aide du fichier de configuration /etc/apt/preferences (voir Section 6.2.5, « Gérer les priorités associées aux paquets » pour les détails).

SÉCURITÉ mini-dinstall et droits

Since mini-dinstall has been designed to run as a regular user, there is no need to run it as root. The easiest way is to configure everything within the user account belonging to the administrator in charge of creating the Debian packages. Since only this administrator has the required permissions to put files in the incoming/ directory, we can deduce that the administrator authenticated the origin of each package prior to deployment and mini-dinstall does not need to do it again. This explains the verify_sigs = 0 parameter (which means that signatures need not be verified). However, if the contents of packages are sensitive, we can reverse the setting and elect to authenticate with a keyring containing the public keys of persons allowed to create packages (configured with the extra_keyrings parameter); mini-dinstall will then check the origin of each incoming package by analyzing the signature integrated to the *.changes file.

L'exécution de mini-dinstall démarre en fait le démon en arrière-plan. Tant qu'il fonctionne, il vérifie toutes les demi-heures si un nouveau paquet est disponible dans le répertoire incoming/, le place dans l'archive et régénère les différents fichiers Packages.gz et Sources.gz. Si la présence d'un démon constitue un problème, il est possible de l'invoquer en mode non interactif (ou batch), à l'aide de l'option -b, à chaque fois qu'un paquet aura été déposé dans le répertoire incoming/. Découvrez les autres possibilités offertes par mini-dinstall en consultant sa page de manuel mini-dinstall(1).

COMPLÉMENTS Générer une archive signée

Les outils APT effectuent par défaut une vérification d'une chaîne de signatures cryptographiques apposées sur les paquets qu'ils manipulent, avant de les installer, dans le but de s'assurer de leur authenticité (voir la Section 6.6, « Vérification d'authenticité des paquets »). Les archives APT privées posent alors problème, car les machines qui doivent les utiliser vont sans arrêt afficher des messages d'avertissement pour signaler que les paquets que ces archives contiennent ne sont pas signés. Il est donc souvent judicieux de s'assurer que même les archives privées bénéficient du mécanisme secure APT.

mini-dinstall propose pour cela l'option de configuration release_signscript, qui permet de spécifier un script à utiliser pour générer la signature. On pourra par exemple utiliser le script sign-release.sh fourni par le paquet mini-dinstall dans /usr/share/doc/mini-dinstall/examples/, après l'avoir éventuellement adapté aux besoins locaux.