Première rédaction de cet article le 4 octobre 2025
Bon, c'est un article d'ultra-niche. Mais, comme j'ai eu du mal à faire fonctionner cette configuration, je me dis que je peux la décrire, et que peut-être quelqu'un·e trouvera cet article un jour via un moteur de recherche, et que cela lui servira. Donc, le problème était : soit un ensemble de machines Debian configurées via Ansible. Un paquetage dont j'avais besoin n'était que dans la version Debian unstable. Comment l'installer via le module Ansible apt ?
D'abord, je détaille le problème. Pour une formation DNSSEC, je gère N machines virtuelles tournant sous Debian. Le paquetage d'OpenDNSSEC, qui était dans les précédentes versions de Debian, a été retiré de l'actuelle version stable, la version 13, alias « trixie ». La configuration que j'utilisais d'habitude avec Ansible et son module apt n'est donc pas utilisable telle quelle pour installer OpenDNSSEC.
Il y a bien sûr plusieurs solutions à ce problème (mais pas celle des backports, OpenDNSSEC n'y est pas) :
dpkg -i
. À la réflexion,
c'est sans doute ce que j'aurais dû faire, mais il n'est pas
garanti que cela aurait bien marché.
J'ai finalement choisi une autre voie : utiliser
stable mais permettre l'installation de
paquetages qui existent dans unstable. Bien que
déconseillée
par Debian, cette méthode est assez banale et on trouve en
ligne plein d'instructions sur comment la réaliser. Une
configuration simple est, dans
/etc/apt/sources.list.d/unstable.sources
:
Types: deb deb-src URIs: mirror+file:///etc/apt/mirrors/debian.list Suites: sid Components: main Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
(sid
est le petit nom de la version
unstable. Si vous avez vu Toy
Story, vous savez pourquoi.)
Avec cela, vous pouvez maintenant installer des paquetages
d'unstable mais attention, vous ne voulez pas que
ces paquetages remplacent vos paquetages stable
existants ! Il faut donc aussi donner une basse priorité à
unstable, avec un /etc/apt/preferences.d/99unstable
:
Package: * Pin: release a=unstable Pin-Priority: 1
Désormais, après le prochain apt update
, un apt install quelquechose
installera bien la version stable du paquetage
« quelquechose », qui a une priorité supérieure. Et apt
install opendnssec
installera la version
d'unstable puisqu'il n'y en a pas dans stable.
Tout cela est classique et bien connu, et ça marche. Mais depuis Ansible, patatras. Le module apt d'Ansible prétend qu'il n'existe pas d'OpenDNSSEC, alors que ça marche en ligne de commande avec apt. Voici la configuration du module :
tasks: … - name: install packages apt: # https://docs.ansible.com/ansible/latest/collections/ansible/builtin/apt_module.html name: [truc, machin, opendnssec] state: present
C'est apparemment parce que Ansible ajoute à apt une option qui lui dit de n'utiliser que stable et je n'ai pas trouvé le moyen de couper cette option.
La solution est donc de faire deux tâches Ansible, une pour
stable et une pour unstable,
en utilisant le paramètre
default_release
. Voici ma configuration
complète et qui marche :
tasks: … - name: "Copy apt sources" copy: src: apt-unstable.sources dest: /etc/apt/sources.list.d/unstable.sources - name: "Copy apt preferences" copy: src: apt-preferences.txt dest: /etc/apt/preferences.d/99unstable - name: "Update Repository cache" apt: # https://docs.ansible.com/ansible/latest/collections/ansible/builtin/apt_module.html update_cache: true upgrade: dist cache_valid_time: 3600 force_apt_get: true - name: install packages apt: name: [truc, chose, machin] state: present - name: install unstable packages apt: name: [opendnssec, softhsm2] default_release: sid state: latest
Notez le state: latest
. Si on laisse à la
valeur par défaut, present
, Ansible produit un
message d'erreur incohérent prétendant que sid
n'est pas dans les sources.
Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)
Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)