Création d’un dépôt de paquets privé pour Debian

Pour une utilisation personnelle et une administration facilitée

Bonjour, aujourd’hui un article expliquant comment j’ai réussi à mettre en place un dépôt Debian privé sur deb.microjoe.org, afin de pouvoir distribuer des paquets entre mes différentes machines utilisant cette distribution.

Une histoire de polices...

Tout commence lorsque je réussi avec succès a écrire mon premier paquet pour Debian et à réussir à le faire publier dans la liste NEW de l’équipe ftp-masters de Debian, sous le nom de fonts-jetbrains-mono.

En cette qualité, le paquet semble OK du point de vue du mainteneur qui m’a aidé à le mettre en place et il faut maintenant que cette équipe accepte le paquet pour permettre son entrée dans l’archive. Cette acceptation semble consister à vérifier que les informations de copyright du paquet sont bonnes. Ce processus n’est nécessaire que pour les nouveaux paquets, les paquets existants n’étant pas concerné par cette procédure.

Cependant, ce travail étant effectué par des bénévoles, rien ne garanti que quelqu’un de l’équipe ftp-masters ne jette un œil à votre paquet pour l’accepter. À l’heure où j’écris ces lignes, le paquet est en attente depuis plus d’un mois sans aucune nouvelle.

Photographie d’un insecte "gendarme" seul sur un bout de bois

Une fois le paquet en attente dans NEW, on se sent un peu seul.

Toute cette policy autour de la vérification du copyright des paquets dans NEW mériterait selon moi d’être revue, car il est inexplicable que les membres privilégiés d’une certaine équipe puisse avoir un tel impact sur les contributions de par leur absence ; mais j’arrêterai ma critique à ce paragraphe.

Décidant d’aller de l’avant pour ne pas avoir à trimbaler mon .deb entre mes différentes machines, je pars donc avec l’idée en tête de créer mon propre dépôt Debian.

À la recherche du bon outil

Debian est une distribution suffisament connue — et le fait que ce soit la base de Ubuntu aidant — il existe de nombreux outils permettant de créer son propre dépôt de paquets .deb. Trop d’outils.

Si on regarde sur la page dédiée du wiki Debian sur la construction de dépôt de paquets personnalisé, on y compte à l’heure où ses lignes sont tapées 12 méthodes différentes pour créer un dépôt personnalisé. Après avoir essayé des commandes obscures à base de dpkg, mon choix s’est arrêté sur reprepro.

L’inconvénient de cet outil listé sur le wiki est — je cite : « [that] lots of different options and commands, difficult to use for beginners ». L’outil est effectivement un peu alambiqué, mais suivre un tutoriel puis lire les pages de man en complément s’avère suffisant pour un usage assez basique. Je pars avec l’avantage suivant : toute ma partie GPG est déjà configurée et opérationnelle. Elle m’a servie à signer le paquet, elle peut donc également me servir pour signer mon dépôt privé.

Si vous rencontrez des problèmes avec reprepro — dont je ne détaillerai pas plus l’usage ici — je vous conseillerai alors de regarder aptly qui a l’air d’être une alternative viable et accessible. Je tire cette conclusion hâtive de ce que j’ai pû voir sur le site web, ce sera à vous de vous construire un avis plus éclairé.

Mise en ligne du dépôt

Je génère le dépôt de paquets avec reprepro sur ma machine locale, or je souhaite que ce dépôt soit déployé sur mon modeste serveur — qui vous a également servi cette page de blog — afin de pouvoir accéder à mes paquets depuis n’importe où.

Pour cela, j’ai mis en place un petit Makefile afin de pouvoir effectuer les trois opérations courantes : télécharger le dépôt localement, le pousser, et le pousser en supprimant tous les autres fichiers (utile en cas de bétise, on y reviendra).

REMOTE=ssh-http-upload@scw:/var/www/deb.microjoe.org/

.PHONY: pull
pull:
        rsync -avz $(REMOTE) .

.PHONY: push
push:
        rsync -avz . $(REMOTE)

.PHONY: force-push
force-push:
        rsync -avz --delete . $(REMOTE)

Parfois ça ne fait pas ce que je veux et ça crée un dossier deb.microjoe.org/ dans le dossier courant qui est celui de l’archive locale, mais globalement ça fonctionne.

Après avoir ajouté l’entrée DNS CNAME qui va bien pour ce sous-domaine, j’ai configuré nginx pour servir simplement le contenu de ce dossier.

Une autre histoire de polices…

Jusqu’à présent nous avions un dépôt public fonctionnel, accessible par tout le monde sur la toile modulo la bonne configuration du fichier /etc/apt/sources.list dans Debian.

Me prend alors l’envie de mettre en paquet une autre police de caractères nommée Caractères. Cette police est utilisée pour les mentions de circulation routière en France.

Un copyright est présent dans le fichier de fonte TTF, mais les sites distribuant la police semblent indiquer que celle-ci est libre d’utilisation pour un usage personnel. Il est également possible que la police soit tombée dans le domaine public depuis sa création pour les panneaux français, mais cela n’est pas spécifié dans le document officiel.

Afin d’éviter tout problème légal en me mettant moi-même à distribuer cette police sur deb.microjoe.org avec un paquet accessible à tous, j’ai donc décidé de privatiser mon dépôt. Cela m’évite les ennuis niveau copyright et me réserve l’exclusivité de l’utilisation du dépôt (personne ne pourra s’en servir pour télécharger les paquets que j’y héberge).

Panneau « visibilité réduite » recouvert de feuilles

Une situation de droits d’auteurs pas claire, illustrée avec la police en question.

À titre de comparaison, ce problème ne se poserai pas en utilisant AUR de la distribution Archlinux, car les fichiers PKGBUILD vont chercher la police à la source. Cela veut dire que l’on peut distribuer ce fichier de construction librement car ce n’est pas nous qui distribuons la police, mais le site internet duquel le script va la télécharger. Dans le cas de Debian, la source doit être présente dans le paquet, ce qui ne permet pas ce genre d’astuce légale utile quand les modalités de distributions ne sont pas clairement énoncées.

Si vous souhaitez vous aussi construire un paquet Debian contenant cette police, ou mieux que vous savez quel est le statut légal de cette œuvre et si il est possible de la distribuer librement, voici le fichier debian/control que j’ai rédigé pour ce paquet si ça peut vous être utile :

Source: fonts-caracteres-l
Section: non-free/fonts
Priority: optional
Maintainer: aaa <aaa@aaa.com>
Uploaders: aaa <aaa@aaa.com>
Build-Depends: debhelper (>= 12), debhelper-compat (= 12)
Standards-Version: 4.5.0
Homepage: https://fonts.simplythebest.net/font/367/caracteres-font.font
Rules-Requires-Root: no

Package: fonts-caracteres-l
Architecture: all
Multi-Arch: foreign
Depends: ${misc:Depends}
Description: fonts of french road signs in truetype format for PC
   - Caracteres L1: black typeface on white background; used on road signs
     which hint at nearer places.
   - Caracteres L2: white typeface on green background (Routes Nationales) or
     blue backgrounds (Autoroutes); used on road signs which hint at distant
     places.
   - Caracteres L4: black typeface on white background, italic; used on road
     signs inside cities to hint at near places and public facilities.

Les adresses mail ont été changées pour éviter le spam.

J’imagine que le plus simple est de me contacter si vous êtes en possession de cette information. Cela dit, étant donné que le titre de l’article traite principalement de Debian et non pas de la distribution de cette police de caractères, je ne porte pas de grand espoir sur cette requête.

Activation de HTTPS

Nous voilà parti dans la seconde partie de cet article : la privatisation du dépôt Debian pour n’autoriser que certaines machines à y accéder. Mais avant, un petit rappel concernant HTTPS et l’usage que nous allons en faire.

Debian n’utilise pas HTTPS pour ses paquets mais lui préfère HTTP ainsi qu’un système de vérification de signatures basé sur OpenPGP. Pour preuve, voici le contenu de mon fichier /etc/apt/sources.list sur ma distribution testing :

deb http://debian.proxad.net/debian/ bullseye main contrib non-free
deb-src http://debian.proxad.net/debian/ bullseye main contrib non-free

deb http://security.debian.org/ testing-security main contrib non-free
deb-src http://security.debian.org/ testing-security main contrib non-free

Concrètement, cela veut dire que si vous téléchargez des paquets par la connexion Wi-Fi d’un hôtel douteux, le gérant malveillant qui analyse ce qui passe pourra voir quels paquets vous téléchargez depuis les dépôts HTTP de Debian — mais ne pourra pas les modifier car tout est sécurisé via des signatures OpenPGP.

Dans le cas de notre dépôt privé, un élément essentiel vient compliquer les choses : pour des raisons de simplicité, l’authentification au dépôt est faite par le mécanisme utilisateur et mot de passe fourni par le protocole HTTP. Cependant, ces données d’authentification vont transiter en clair si HTTP est le protocole final utilisé, et donc le gérant d’hotêl aura accès au combo identifiant et mot de passe permettant d’accéder au dépôt — et par extension aux paquets que je ne souhaite pas distribuer, comme cette police Caractères.

Photo d’une clé suspendue à un crochet

Évitons d’exposer nos identifiants à la vue de tous.

C’est pour cette principale raison que nous allons activer HTTPS au niveau du dépôt, afin que les identifiants permettant d’y accéder ne puissent pas fuiter entre le dépôt et la machine qui tente d’y accéder.

Notons qu’il est également possible de mettre en place un accès au dépôt par SSH, mais cela devient plus compliqué car on doit générer des clés sur les clients et copier chaque clé publique sur le serveur. De plus, dans le cas où le port 22 est bloqué en itinérance (merci les administrateurs qui bloquent tous les ports sauf le 53, 80 et 443) l’accès au dépôt devient alors plus compliqué.

Configuration d’apt

Mettre à dispositions les paquets en HTTPS est une chose, mais il faut également préparer les machines accédant à l’archive pour que apt puisse accéder au dépôt via HTTPS. Cela se limite simplement à installer le paquet apt-transport-https. Cependant il se trouve que même sans avoir installé ce paquet apt semble être déjà capable d’utiliser HTTPS.

Voici ce que j’ai mis dans /etc/apt/sources.list.d/microjoe.list :

deb https://deb.microjoe.org/ testing main contrib non-free
deb-src https://deb.microjoe.org/ testing main contrib non-free

Et pour l’authentification, il suffit de créer un nouveau fichier dans /etc/apt/auth.conf.d/microjoe.conf :

machine deb.microjoe.org login apt password not_a_chance

En se rapellant de passer ce fichier en chmod 600 afin que seul le superutilisateur puisse lire ce fichier en temps normal (et apt quand il est appelé avec la commande sudo).

L’avantage, maintenant que l’on a notre propre dépôt de paquets, c’est que l’on peut créer un paquet de configuration qui se chargera d’installer ces deux fichiers sur les systèmes qui en ont besoin. Il sera nécessaire au début d’installer le fichier .deb à la main, mais ensuite les mises à jour peuvent être effectuées par le dépôt lui-même !

Conclusion

Voilà qui conclu la fin de cet article, je ne suis volontairement pas rentré trop de détails pour privilégier des illustrations originales avec quelques photographies.

Je pense que ce dépôt me sera bien pratique à l’avenir, étant donné que je suis déjà en possession de 3 machines Debian à la maison. La prochaine étape que je vais essayer de mettre en place est un cache de paquets (déjà fait) qui puisse supporter HTTPS (là, ça se complique).

Portez vous bien d’ici là.

Une question ou remarque ? N'hésitez pas à me contacter en envoyant un mail à microjoe, suivi d'un arobase, puis encore microjoe et enfin un « point org ».