Debian 13 : Le pinning de paquets m’a sauvé le serveur — utiliser apt preferences sans chaos

Ce qu’est réellement le pinning (et ce que ce n’est pas)

Le apt de Debian n’« upgrade » pas tout vers la chose la plus récente qu’il trouve de façon simpliste. Il classe les versions selon un ensemble de règles et métadonnées (origines, archives, priorités), puis tente de produire une solution cohérente. Le pinning permet de contourner le classement par défaut.

Le problème que résout le pinning

En production, vous voulez deux propriétés qui s’opposent :

• Réactivité en matière de sécurité : obtenir rapidement les versions corrigées.
• Contrôle des changements : éviter les nouvelles versions majeures surprises ou les chaînes de dépendances inédites.

Le pinning vous permet de dire « prendre les mises à jour de sécurité, mais ne pas sauter sur cette nouvelle version fournisseur » ou « récupérer exactement un paquet depuis les backports, pas toute sa famille étendue. »

Ce que le pinning n’est pas

• Pas un substitut à la lecture d’une mise à jour proposée. Si vous appliquez des mises à jour à l’aveugle, le pinning n’est qu’un bandeau plus sophistiqué.
• Pas un hack du solveur de dépendances. Si deux dépôts fournissent des stacks incompatibles, le pinning ne peut pas négocier la paix ; il ne peut que choisir un camp.
• Pas équivalent à un « hold », même s’ils peuvent fonctionner ensemble. Un hold fige un paquet par nom. Le pinning biaise la sélection de version en fonction de l’origine/archive/version.

Où vit le pinning

Sur Debian 13, vous utiliserez :

• /etc/apt/preferences (fichier unique legacy)
• /etc/apt/preferences.d/*.pref (la façon sensée : modulaire, auditable)

Je préfère preferences.d avec une intention par fichier : « backports opt-in », « dépôt fournisseur limité », « pas de paquets testing », etc. Ça se lit comme une politique, pas comme du folklore.

Une citation pour rester honnête : « L’espoir n’est pas une stratégie. » — idée paraphrasée couramment utilisée en ingénierie/exploitation.

Blague #1 : Le pinning de paquets, c’est comme mettre des glissières sur une piste de bowling. Vous pouvez toujours faire tomber la boule dans le canal, mais il faudra y mettre du sien.

Faits et contexte qui changent votre manière de pinner

Voici quelques éléments concrets d’histoire et de comportement qui comptent quand vous concevez une politique apt. Peu romantiques, mais lourds de conséquences.

1. Le pinning APT date d’avant les conteneurs. Avant « juste livrer son image », le pinning était la manière pour les admins de mixer correctifs de sécurité et systèmes conservateurs.
2. « FrankenDebian » n’est pas un terme sans raison. Mélanger stable/testing/unstable (ou des dépôts fournisseurs au hasard) sans politique produit souvent des incompatibilités ABI silencieuses et une instabilité des dépendances.
3. Le stable-updates de Debian existe pour réduire la pression sur les sorties point. Il est pensé pour des corrections sensibles au temps qui ne devraient pas attendre la prochaine release majeure.
4. backports est conçu pour être opt-in. Debian donne volontairement aux backports une priorité par défaut plus basse afin que stable reste le choix par défaut.
5. Les priorités de pin ont des bords tranchants par conception. Des priorités >1000 peuvent forcer des rétrogradations ; en dessous de 0 peuvent bloquer l’installation. Vous pouvez vous tirer dans le pied avec une précision mathématique.
6. Apt n’est pas seulement conscient des versions ; il connaît aussi l’origine. Les champs de release comme o= (Origin) et a= (Archive) importent souvent plus que les chaînes de version.
7. Les métadonnées signées du dépôt sont la racine de confiance, pas le fichier de paquet. Si vous autorisez un dépôt, vous faites confiance à sa clé de signature et à son index ; le pinning contrôle la préférence, pas l’authenticité.
8. Des transitions arrivent. Les transitions majeures de bibliothèques (pensez SSL, libc++, Python) se propagent dans les graphes de dépendances ; le pinning peut empêcher des transitions surprises… mais peut aussi bloquer des mises à jour de sécurité nécessaires si vous êtes imprudent.

Le moteur de décision d’apt : un modèle mental exécutable

Quand apt choisit quoi installer, il fait essentiellement trois choses :

1. Collecter les versions candidates depuis toutes les sources configurées (/etc/apt/sources.list, /etc/apt/sources.list.d/*.list).
2. Attribuer une Pin-Priority à chaque version en utilisant les valeurs par défaut + vos préférences.
3. Choisir la version installable « meilleure » (priorité la plus haute ; en cas d’égalité, version la plus élevée), puis résoudre les dépendances.

Règles de Pin-Priority à retenir

Ce sont les seuils qui modifient le comportement. Mémorisez-les ; elles font la différence entre politique et chaos.

• > 1000 : peut forcer l’installation même si cela implique une rétrogradation.
• 990–1000 : préférer cette version même par rapport aux versions installées (typique pour « target release »).
• 500 : priorité normale pour des releases non ciblées.
• 100 : inférieure à l’installé ; la version installée gagne généralement.
• 0 : essentiellement « ne pas installer » (sauf si explicitement demandé, et même là cela peut être bloqué selon la correspondance exacte).
• < 0 : jamais installer.

Target release : le piège discret

Si vous définissez APT::Default-Release sur stable (ou le nom de code de Debian 13), vous dites à apt « cette release vaut 990 ». C’est généralement bon. Mais cela signifie aussi que toute autre release à 500 peut encore être sélectionnée si le candidat stable n’est pas installable (conflit de dépendances) ou si vous demandez explicitement -t.

Le pinning n’est pas juste « mettre un nombre ». C’est choisir le plus petit nombre qui atteint l’objectif sans forcer de rétrogradations ou une divergence permanente.

Mode opératoire de diagnostic rapide

Ceci est ce que je fais quand une proposition de mise à jour semble incorrecte ou qu’un système dérive déjà. Vous voulez du signal rapidement, pas un débat philosophique avec apt.

Première étape : confirmer ce qu’apt considère comme candidat

• Choisissez un paquet problématique (souvent celui avec un saut de version majeur).
• Exécutez apt-cache policy et regardez : version installée, version candidate, et quel dépôt la fournit.

Deuxième étape : demander « pourquoi » avec une simulation

• apt -s dist-upgrade est votre détecteur de mensonges.
• Recherchez les suppressions et les paquets « kept back ». Ce sont des signaux d’alerte précoces.

Troisième étape : identifier le dépôt qui tire le graphe

• apt-cache madison montre les versions entre dépôts.
• apt-get -o Debug::pkgProblemResolver=yes -s dist-upgrade explique les choix de dépendances.

Quatrième étape : vérifier que vos règles de pin correspondent réellement

• La plupart des échecs de pinning ne viennent pas d’une « mauvaise priorité », mais d’une « non-correspondance ». Origin incorrect. Nom de release erroné. Label faux.
• Validez via la sortie de apt-cache policy : les priorités doivent refléter vos préférences.

Cinquième étape : décider si vous corrigez la politique ou faites un sauvetage ponctuel

• Si le système est déjà mixte, vous pourriez devoir faire une rétrogradation/alignement contrôlé.
• Si c’est un besoin ponctuel de paquet, pinner uniquement ce paquet (ou ce dépôt à faible priorité) et passer à autre chose.

Tâches pratiques (commandes + signification des sorties + décisions)

Voici les actions réelles que j’exécute sur des serveurs Debian. Chaque tâche inclut : une commande exécutable, un extrait réaliste de sortie, ce que cela signifie, et la décision que j’en tire.

Task 1: List your configured APT sources (spot surprise repos)

cr0x@server:~$ grep -Rhs '^[^#]' /etc/apt/sources.list /etc/apt/sources.list.d/*.list
deb http://deb.debian.org/debian trixie main contrib non-free non-free-firmware
deb http://security.debian.org/debian-security trixie-security main contrib non-free non-free-firmware
deb http://deb.debian.org/debian trixie-updates main contrib non-free non-free-firmware
deb http://deb.debian.org/debian trixie-backports main contrib non-free non-free-firmware
deb [signed-by=/etc/apt/keyrings/vendor.gpg] https://packages.vendor.example/debian stable main

Ce que cela signifie : Vous mélangez stable, security, updates, backports et un dépôt fournisseur. C’est normal… si vous avez une politique. Sinon, apt va s’en inventer une.

Décision : Si un dépôt inattendu apparaît, désactivez-le avant toute autre action. Si le dépôt fournisseur existe, prévoyez de le pinner bas.

Task 2: Verify Default-Release (avoid accidental targeting)

cr0x@server:~$ apt-config dump | grep -E 'APT::Default-Release|Acquire::'
APT::Default-Release "trixie";
Acquire::Retries "3";

Ce que cela signifie : Le système préfère Debian 13 (nom de code affiché) comme release cible.

Décision : Gardez-le réglé sur le nom de code stable (ou stable). S’il est vide, vous êtes plus susceptible de dériver quand plusieurs dépôts sont présents.

Task 3: Update package lists and watch for repo errors

cr0x@server:~$ sudo apt update
Hit:1 http://deb.debian.org/debian trixie InRelease
Hit:2 http://security.debian.org/debian-security trixie-security InRelease
Hit:3 http://deb.debian.org/debian trixie-updates InRelease
Hit:4 http://deb.debian.org/debian trixie-backports InRelease
Get:5 https://packages.vendor.example/debian stable InRelease [3,215 B]
Reading package lists... Done
Building dependency tree... Done
All packages are up to date.

Ce que cela signifie : Les métadonnées ont été récupérées proprement. Si vous voyez des erreurs de signature, réparez la confiance d’abord ; le pinning ne vous sauvera pas d’un dépôt cassé.

Décision : Si un dépôt échoue de façon intermittente, envisagez de l’isoler ou d’utiliser un miroir. Des métadonnées instables mènent à des candidats incohérents entre hôtes.

Task 4: Inspect candidate versions and priorities for a package

cr0x@server:~$ apt-cache policy openssl
openssl:
  Installed: 3.2.2-1
  Candidate: 3.2.3-1~deb13u1
  Version table:
     3.2.3-1~deb13u1 990
        990 http://security.debian.org/debian-security trixie-security/main amd64 Packages
 *** 3.2.2-1 100
        100 /var/lib/dpkg/status
     3.2.2-1+vendor1 500
        500 https://packages.vendor.example/debian stable/main amd64 Packages

Ce que cela signifie : Le dépôt de sécurité a la priorité 990 (probablement à cause de Default-Release). Le dépôt fournisseur est présent mais ne l’emporte pas.

Décision : C’est sain. Si le fournisseur avait une priorité supérieure à 990, vous le pinneriez immédiatement.

Task 5: Show all available versions across repos

cr0x@server:~$ apt-cache madison linux-image-amd64
linux-image-amd64 | 6.12.9-1 | http://deb.debian.org/debian trixie/main amd64 Packages
linux-image-amd64 | 6.12.12-1~deb13u1 | http://security.debian.org/debian-security trixie-security/main amd64 Packages
linux-image-amd64 | 6.13.5-1~bpo13+1 | http://deb.debian.org/debian trixie-backports/main amd64 Packages

Ce que cela signifie : Les backports proposent un noyau plus récent. Tentant pour l’activation matérielle, et dangereux si ce n’était pas prévu.

Décision : Décidez si les noyaux sont autorisés depuis backports. Sinon, pinner backports bas ou pinner uniquement le paquet noyau que vous souhaitez contrôler.

Task 6: Dry-run an upgrade and read the removals like a crime report

cr0x@server:~$ sudo apt -s dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Calculating upgrade... Done
The following packages will be upgraded:
  libc6 openssl systemd
The following packages will be REMOVED:
  vendor-storage-agent
3 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Inst libc6 [2.40-1] (2.40-2~deb13u1 Debian-Security:13/stable-security [amd64])
Remv vendor-storage-agent [2.1.0-4] [vendor-storage-agent:amd64 ]
Inst systemd [257-1] (257-2~deb13u1 Debian-Security:13/stable-security [amd64])
Inst openssl [3.2.2-1] (3.2.3-1~deb13u1 Debian-Security:13/stable-security [amd64])

Ce que cela signifie : Une mise à jour de libc centrale va supprimer un agent fournisseur. Ce n’est pas une « mise à jour », c’est une demande de changement.

Décision : Stop. Pinner soit la pile de dépendances de l’agent fournisseur (ou le dépôt fournisseur) ou planifier le remplacement de l’agent. N’acceptez pas de suppressions silencieuses sur des serveurs critiques.

Task 7: Turn on the resolver debug to see the “why”

cr0x@server:~$ sudo apt-get -o Debug::pkgProblemResolver=yes -s dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Starting pkgProblemResolver with broken count: 0
Investigating (0) vendor-storage-agent:amd64 < 2.1.0-4 @ii mK Ib >
  Conflicts: libc6 (>= 2.40-2~deb13u1)
  Removing vendor-storage-agent:amd64 rather than change libc6:amd64
Done

Ce que cela signifie : L’agent fournisseur est en conflit avec la libc de sécurité. Apt préfère garder la libc à jour et supprimer l’agent.

Décision : Vos choix : mettre à jour le dépôt fournisseur pour fournir un agent compatible, pinner temporairement libc (risqué), ou supprimer/remplacer l’agent délibérément.

Task 8: Check what pins are currently in effect

cr0x@server:~$ ls -1 /etc/apt/preferences.d
00-default-release.pref
10-backports-optin.pref
20-vendor-low.pref

Ce que cela signifie : Vous avez une politique structurée, pas un fichier mystérieux unique.

Décision : Si vous ne les avez pas, créez-les. Si vous les avez, ouvrez-les et confirmez qu’ils reflètent la réalité.

Task 9: Create a sane “backports are opt-in” pin

cr0x@server:~$ sudo tee /etc/apt/preferences.d/10-backports-optin.pref >/dev/null <<'EOF'
Package: *
Pin: release a=trixie-backports
Pin-Priority: 100
EOF

Ce que cela signifie : Les paquets backports ne seront pas sélectionnés automatiquement plutôt que les versions installées de stable. Vous pouvez toujours installer depuis backports explicitement.

Décision : Utilisez cela en production sauf raison forte contraire. « On aime les nouveautés » n’est pas une raison ; c’est un trait de personnalité.

Task 10: Pin a vendor repository low so it can’t take over

cr0x@server:~$ sudo tee /etc/apt/preferences.d/20-vendor-low.pref >/dev/null <<'EOF'
Package: *
Pin: origin "packages.vendor.example"
Pin-Priority: 50
EOF

Ce que cela signifie : Les paquets fournisseur sont disponibles, mais apt ne les choisira pas à moins que vous ne le demandiez explicitement ou que stable n’offre pas de candidat installable.

Décision : C’est la position par défaut pour les dépôts fournisseurs. Augmentez la priorité seulement pour des paquets spécifiques que vous voulez réellement depuis eux.

Task 11: Pin a single package to backports (surgical adoption)

cr0x@server:~$ sudo tee /etc/apt/preferences.d/30-zfs-from-backports.pref >/dev/null <<'EOF'
Package: zfs-dkms zfsutils-linux
Pin: release a=trixie-backports
Pin-Priority: 990
EOF

Ce que cela signifie : Seuls les éléments ZFS sont privilégiés depuis les backports. Tout le reste reste prioritairement stable.

Décision : Faites cela lorsque vous avez besoin d’une nouvelle fonctionnalité de pilote/système de fichiers sans vouloir dériver tout le système.

Task 12: Validate the pin worked using policy output

cr0x@server:~$ apt-cache policy zfsutils-linux
zfsutils-linux:
  Installed: 2.2.4-1
  Candidate: 2.2.6-1~bpo13+1
  Version table:
     2.2.6-1~bpo13+1 990
        990 http://deb.debian.org/debian trixie-backports/main amd64 Packages
 *** 2.2.4-1 100
        100 /var/lib/dpkg/status
     2.2.4-1 990
        990 http://deb.debian.org/debian trixie/main amd64 Packages

Ce que cela signifie : Pour ce paquet, backports a la priorité 990 et devient le candidat. Bien : c’est ce que vous avez demandé.

Décision : Poursuivez l’installation si vous avez vérifié la compatibilité noyau/module et que vous avez un plan de retour arrière.

Task 13: Install from backports explicitly (even without pins)

cr0x@server:~$ sudo apt -t trixie-backports install zfsutils-linux
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  libnvpair3linux libuutil3linux libzfs5linux libzpool5linux zfsutils-linux
The following packages will be upgraded:
  zfs-dkms
Need to get 4,812 kB of archives.
After this operation, 18.2 MB of additional disk space will be used.
Do you want to continue? [Y/n]

Ce que cela signifie : Apt récupère un ensemble cohérent de paquets depuis backports pour ZFS.

Décision : Sur des serveurs de stockage, planifiez cela. Les recompilations de modules DKMS et les redémarrages ne sont pas des « tâches d’arrière-plan », peu importe ce que dit votre calendrier.

Task 14: Hold a package when you need a hard freeze

cr0x@server:~$ sudo apt-mark hold linux-image-amd64
linux-image-amd64 set on hold.

Ce que cela signifie : Apt n’autorisera pas la mise à jour automatique de ce paquet.

Décision : Utilisez les holds avec parcimonie et suivez-les. Les holds sont une dette : elles accumulent des intérêts sous forme de correctifs de sécurité manqués.

Task 15: Audit holds so you don’t forget what you froze

cr0x@server:~$ apt-mark showhold
linux-image-amd64

Ce que cela signifie : Vous avez un hold sur un noyau en place.

Décision : Décidez si le hold est toujours justifié. Si c’est « temporaire », fixez-vous un rappel plus contraignant que votre futur vous.

Task 16: Show packages from a specific origin already installed (drift check)

cr0x@server:~$ apt-cache policy | sed -n '1,120p'
Package files:
 100 /var/lib/dpkg/status
     release a=now
 990 http://security.debian.org/debian-security trixie-security/main amd64 Packages
     release o=Debian,a=trixie-security,n=trixie-security,l=Debian-Security,c=main,b=amd64
 990 http://deb.debian.org/debian trixie/main amd64 Packages
     release o=Debian,a=trixie,n=trixie,l=Debian,c=main,b=amd64
 100 http://deb.debian.org/debian trixie-backports/main amd64 Packages
     release o=Debian Backports,a=trixie-backports,n=trixie-backports,l=Debian Backports,c=main,b=amd64
  50 https://packages.vendor.example/debian stable/main amd64 Packages
     release o=Vendor,a=stable,n=stable,l=Vendor,c=main,b=amd64
Pinned packages:

Ce que cela signifie : Vos priorités de pin sont visibles au niveau des dépôts : security et stable à 990, backports à 100, fournisseur à 50.

Décision : Si ces chiffres ne correspondent pas à votre politique voulue, corrigez preferences avant de faire une mise à jour.

Task 17: Confirm a pin match using “origin” and “release” fields

cr0x@server:~$ apt-cache policy | grep -E 'release o=|release a='
     release o=Debian,a=trixie-security,n=trixie-security,l=Debian-Security,c=main,b=amd64
     release o=Debian,a=trixie,n=trixie,l=Debian,c=main,b=amd64
     release o=Debian Backports,a=trixie-backports,n=trixie-backports,l=Debian Backports,c=main,b=amd64
     release o=Vendor,a=stable,n=stable,l=Vendor,c=main,b=amd64

Ce que cela signifie : Ces chaînes sont celles que vos règles de pin doivent matcher. Deviner, c’est la manière dont les pins échouent silencieusement.

Décision : Utilisez ces valeurs exactes (surtout origin et a=) dans vos préférences.

Task 18: Simulate installing a vendor package without letting it cascade

cr0x@server:~$ sudo apt -s install vendor-storage-agent
Reading package lists... Done
Building dependency tree... Done
The following packages will be installed:
  vendor-storage-agent
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Inst vendor-storage-agent (2.1.3-1 Vendor:stable [amd64])

Ce que cela signifie : Avec le dépôt fournisseur pinner bas, apt n’installe que ce que vous avez demandé ; il ne remplace pas opportuniste les bibliothèques cœur.

Décision : C’est le résultat souhaité. Si la simulation montre une pile de mises à niveau depuis le fournisseur, baissez encore la priorité du fournisseur ou pinner uniquement le paquet fournisseur spécifique.

Trois mini-récits d’entreprise issus du terrain

1) Incident causé par une mauvaise hypothèse : « Les mises à jour de sécurité ne changeront pas les dépendances »

Une entreprise de taille moyenne exploitait une flotte de serveurs Debian gérant des artefacts de build internes et des images de conteneurs. Le backend de stockage était ennuyeux : RAID, ext4, et un agent de surveillance fournisseur qui jurait qu’il était « léger ». L’équipe avait une fenêtre de patch hebdomadaire et une règle : appliquer rapidement les mises à jour de sécurité, parce que les auditeurs aiment la conformité calendaire.

Un jour, une mise à jour de sécurité a tiré une nouvelle révision mineure d’une bibliothèque centrale. Ce n’était pas un saut de version majeur, donc ça a passé la revue humaine. La mauvaise hypothèse était subtile : « le dépôt de sécurité ne cassera pas l’espace utilisateur ». Debian est conservateur, mais « conservateur » n’est pas « jamais de changements de dépendances », surtout quand des correctifs de sécurité nécessitent une recompilation contre des libs mises à jour.

L’agent fournisseur avait une contrainte de dépendance stricte et n’avait pas été reconstruit pour la bibliothèque mise à jour par la sécurité. Apt a fait ce qu’apt fait : il a proposé de supprimer l’agent. Quelqu’un a vu « 1 to remove » et a pensé que cela concernait un ancien paquet noyau. C’était l’élément qui alimentait les métriques du NOC.

Après la mise à jour, rien n’était « down ». C’était le problème. Le NOC avait un angle mort : les disques se sont remplis, la pression d’inodes a augmenté, et quelques nœuds de build ont commencé à échouer lors de pushs. L’incident a été découvert par les développeurs, pas par la supervision. C’est un échec culturel ayant une racine technique.

La correction n’a rien d’héroïque. L’équipe a pinner le dépôt fournisseur bas, puis a pinner le paquet agent fournisseur assez haut pour rester installable sans tirer les libs du fournisseur sur Debian. Ils ont aussi ajouté une règle de revue : la sortie d’une simulation d’upgrade doit montrer zéro suppression sauf approbation explicite. Ils ont cessé de traiter les mises à jour de sécurité comme neutres vis-à-vis des dépendances.

2) Optimisation qui a mal tourné : « Pin everything to backports for speed »

Une équipe plateforme d’entreprise avait un problème de performance. Leur couche de terminaison TLS était limitée par le CPU, et quelqu’un a remarqué une bibliothèque crypto plus récente dans les backports offrant de meilleures performances sur CPU modernes. L’idée semblait raisonnable : récupérer la bibliothèque plus récente, obtenir des handshakes plus rapides, et admirer des graphes de latence plus bas.

Ils ont créé un pin large : backports à haute priorité pour tous les paquets. Ça semblait propre et cohérent : un dépôt, une direction, moins de surprises. Ça a aussi tranquillement transformé stable en « majoritairement ignoré », ce qui est l’opposé de la raison pour laquelle on exécute stable en production.

La première semaine a semblé bien. Puis une réaction en chaîne s’est produite : une bibliothèque plus récente a tiré un composant toolchain plus récent, qui a tiré un runtime plus récent, qui a tiré un service système plus récent. Le système démarravaIt encore, mais des bugs de régression sont apparus dans des endroits que personne n’associait à la « performance TLS ». Un problème particulièrement pénible impliquait un changement d’ordre de redémarrage des services qui interagissait avec le timing des montages de stockage. Un faible pourcentage de nœuds a démarré sans montages critiques, et des applications ont écrit sur le système racine. Ce sont le type d’erreurs qui créent des couches archéologiques dans /.

Le rollback a été pire que le changement. Rétrograder un système largement mis à jour est possible, mais plus lent et plus risqué que d’empêcher la dérive dès le départ. Ils ont fini par reconstruire des nœuds plutôt que de les « réparer » sur place, ce qui est honnête mais coûteux.

La leçon : le pinning n’est pas un bouton de performance. C’est un outil de politique. Si vous avez besoin d’une nouvelle bibliothèque crypto, pinner cette bibliothèque (et seulement l’ensemble nécessaire) ou utiliser une installation ciblée -t backports avec une revue stricte. Les backports peuvent être excellents ; « tout depuis backports » revient à adopter une autre piste de distribution.

3) Pratique ennuyeuse mais correcte qui a sauvé la mise : « Un fichier de pin par intention, plus un audit de dérive »

Une équipe de services financiers exploitait Debian sur des systèmes orientés stockage : services de fichiers, passerelles d’objets et coordinateurs de sauvegarde. Leur environnement était l’opposé de la mode : hôtes longue durée, mises à jour prudentes, et une culture documentée du « ce qui a changé ». Ils avaient aussi une règle peu glamour : aucun hôte n’obtient un dépôt sans un fichier de pin correspondant dans /etc/apt/preferences.d.

Ils ont pinne les backports à 100 globalement, puis ont pinne une courte liste blanche de paquets à 990 quand ils avaient besoin d’activation matérielle ou de correctifs de système de fichiers. Les dépôts fournisseurs étaient pinnés à 50 par origine, avec des exceptions explicites pour deux paquets. Ils ont aussi défini Default-Release sur le nom de code stable et intégré cela à leur configuration de base.

Le moment où cela a sauvé la mise est survenu lors d’une réponse de sécurité urgente. Une nouvelle mise à jour de sécurité est arrivée, et un dépôt fournisseur a simultanément publié un ensemble de paquets qui, par numéro de version, paraissait « plus récent ». Sur un système moins discipliné, apt aurait pu dériver vers des paquets fournisseur. Sur ces hôtes, le dépôt fournisseur n’était pas autorisé à l’emporter par défaut. La mise à jour est restée dans l’écosystème Debian, et les paquets fournisseur sont restés disponibles seulement sur demande explicite.

Ils ont quand même travaillé : ils ont exécuté une simulation d’upgrade, confirmé qu’il n’y avait pas de suppressions, et déployé en canary par étapes. C’était presque ennuyeux. C’est le but. Leur outil de réponse aux incidents le plus précieux n’était pas une plateforme sophistiquée ; c’était une politique de sélection de paquets prévisible et une habitude d’audit.

Erreurs courantes : symptômes → cause → correctif

1) Symptom: apt wants to remove half your system during an upgrade

Root cause: You have a conflicting package source (often vendor) with incompatible dependencies, or you’re pulling from backports/testing unintentionally.

Fix: Identify the package that triggers removals via apt -s dist-upgrade, then check apt-cache policy for that package. Pin the offending repo lower (e.g., 50) and re-run the simulation.

2) Symptom: backports packages install even when you didn’t ask

Root cause: Backports is pinned too high, or Default-Release is unset and apt picks the newer version when priorities tie.

Fix: Set backports to Pin-Priority: 100 for Package: *, and set APT::Default-Release to the stable codename.

3) Symptom: your pin file “does nothing”

Root cause: The Pin: selector doesn’t match the actual repo metadata. Common mistakes: wrong origin string; confusing a= (Archive) with n= (Codename).

Fix: Copy the exact values from apt-cache policy release lines and use them in your pin rule.

4) Symptom: apt refuses to downgrade when you need to revert

Root cause: Your pins don’t allow downgrades (priority not > 1000), or you’re missing the older version in any available repo.

Fix: Ensure the desired older version exists in stable/security and set a temporary pin for that package at 1001 to permit downgrade, then remove the temporary pin afterwards.

5) Symptom: you can’t install a vendor package because Debian packages “win”

Root cause: You pinned vendor low (good), but you didn’t explicitly request vendor versions and Debian provides a valid candidate.

Fix: Install explicitly by version or by target release (if vendor repo has a distinct release), or create a narrow pin for that vendor package only.

6) Symptom: security updates are blocked (“kept back”) after you pinned something

Root cause: You pinned a dependency (like libc, openssl, systemd) too aggressively, preventing the security repo from upgrading it.

Fix: Remove the pin for core components. If you must freeze, use a time-boxed hold with a ticket and a rollback plan. Then unfreeze.

7) Symptom: different servers select different candidates

Root cause: Repo configuration differs (sources files), pin files differ, or one host missed apt update and is using stale metadata. Sometimes a proxy/cache is serving different views.

Fix: Compare /etc/apt/sources.list* and /etc/apt/preferences.d across hosts; ensure consistent metadata updates; standardize with configuration management.

Listes de vérification / plan étape par étape (sécurisé pour la production)

Baseline de politique (faites-le avant d’en avoir besoin)

1. Définir Default-Release sur votre nom de code stable dans une configuration gérée (ou vérifier qu’il existe et reste en place).
2. Diviser les pins par intention dans /etc/apt/preferences.d, pas un fichier monolithique.
3. Pinner backports à 100 globalement sauf si vous avez une raison spécifique de le laisser plus haut.
4. Pinner les dépôts fournisseurs à 50 par origine comme posture défensive par défaut.
5. Whitelist d’exceptions avec des pins étroits : seuls des paquets spécifiques obtiennent 990 depuis backports/fournisseur.
6. Écrire une règle « pas de suppressions sans approbation » pour les upgrades, et l’appliquer dans la revue de changement.

Avant toute fenêtre de mise à jour

1. Exécutez sudo apt update et assurez-vous de métadonnées propres.
2. Exécutez sudo apt -s dist-upgrade et inspectez les suppressions et les grosses expansions de dépendances.
3. Pour tout candidat surprenant, exécutez apt-cache policy pkg et confirmez que la source et la priorité ont du sens.
4. Si vous tirez depuis backports, confirmez que c’est délibéré et limité aux paquets visés.

Quand vous devez installer depuis backports (schéma sûr)

1. Gardez backports à 100 globalement.
2. Ajoutez un pin étroit pour le(s) paquet(s) dont vous avez besoin à 990 depuis backports.
3. Simulez l’installation/mise à jour et vérifiez les mises à niveau collatérales.
4. Installez d’abord sur un nœud canari. Confirmez la santé des services et le comportement du démarrage (surtout pour les changements noyau/module).
5. Déployez progressivement.

Quand un dépôt fournisseur est requis (schéma sûr)

1. Pinnez l’origine du fournisseur à 50 pour Package: *.
2. Pinnez uniquement le(s) paquet(s) fournisseur dont vous avez réellement besoin plus haut (990), et gardez leurs chaînes de dépendances visibles.
3. Testez explicitement que les libs cœur restent issues de Debian sauf si vous avez un contrat de support exigeant le contraire.
4. Prévoyez une voie de désinstallation propre. Les agents fournisseurs ont tendance à traîner d’une façon étrange.

Blague #2 : APT résoudra volontiers votre problème de dépendances en désinstallant votre application. C’est comme virer le client pour améliorer les métriques de satisfaction client.

FAQ

1) Dois-je utiliser le pinning ou apt-mark hold ?

Utilisez le pinning pour la politique (« préférer la sécurité Debian au fournisseur », « backports opt-in »). Utilisez les holds pour des gels courts et explicites (« ne pas changer le noyau cette semaine »). Les holds doivent être limités dans le temps.

2) Quels numéros Pin-Priority devrais-je réellement utiliser ?

Valeurs saines courantes : stable/security par défaut (souvent 990 avec Default-Release), backports à 100 globalement, fournisseur à 50 globalement. Utilisez 990 pour des paquets spécifiques que vous voulez depuis backports/fournisseur. Utilisez >1000 seulement pour des rétrogradations forcées temporaires.

3) Puis-je pinner par nom de code ou par archive ?

Oui, mais soyez cohérent. Pinner par release a=trixie-backports est généralement stable. Pinner par n= peut convenir, mais vérifiez ce que vos métadonnées de dépôt contiennent via apt-cache policy.

4) Pourquoi apt choisit-il parfois un dépôt de « priorité inférieure » ?

Parce que le candidat de priorité supérieure peut être non installable à cause des dépendances. Apt choisira une solution installable. C’est pourquoi la sortie debug du résolveur est précieuse : elle montre quelles contraintes ont forcé la décision.

5) Comment éviter de créer par erreur un FrankenDebian ?

N’ajoutez pas testing/unstable aux serveurs stable. Si vous devez ajouter un dépôt non-Debian, pinner-le bas par origine et whitelist seulement des paquets spécifiques. Et simulez toujours les upgrades avant de les appliquer.

6) Le pinning suffit-il pour sécuriser les dépôts tiers ?

Non. Le pinning contrôle la préférence, pas la confiance. Vous avez toujours besoin d’une gestion correcte des keyrings, d’une hygiène des dépôts et d’une raison valable d’inclure le dépôt.

7) Quelle est la différence entre apt upgrade et apt full-upgrade avec des pins ?

apt upgrade évite les suppressions et changements complexes, laissant souvent des paquets « kept back ». apt full-upgrade (ou dist-upgrade) autorise les suppressions pour satisfaire les dépendances. Les pins affectent les deux, mais full-upgrade révèle le coût réel de votre politique actuelle.

8) Puis-je pinner des ensembles de dépendances entiers en toute sécurité ?

Vous pouvez, mais c’est facile d’en abuser. Préférez des pins étroits : le paquet dont vous avez besoin plus l’ensemble minimal requis. Si vous pinnez un ensemble large, vous optez en fait pour une autre piste de release pour ce sous-système.

9) Comment récupérer si j’ai déjà installé depuis le mauvais dépôt ?

Stoppez d’abord les mises à jour. Ajoutez des pins pour re-préférer Debian stable/security, puis simulez une voie de rétrogradation. Si la rétrogradation est chaotique, envisagez de reconstruire l’hôte (souvent plus sûr) plutôt que d’effectuer des rétrogradations complexes en place de bibliothèques cœur.

10) Dois-je pinner les noyaux ?

Si vous avez besoin d’un contrôle strict du noyau (pilotes, DKMS, modules de stockage), oui — soit hold du paquet méta temporairement soit pinner les sources du noyau. Mais n’oubliez pas les implications de sécurité : les gels de noyau doivent être courts et délibérés.

Prochaines étapes à réaliser réellement

Si vous administrez des serveurs Debian 13 importants, faites ceci dans l’ordre :

1. Inventoriez les dépôts sur la flotte et supprimez tout ce que vous ne pouvez pas justifier.
2. Réglez APT::Default-Release sur le nom de code Debian 13 de façon cohérente.
3. Créez /etc/apt/preferences.d/10-backports-optin.pref et maintenez backports à 100 globalement.
4. Pinnez tout dépôt fournisseur à 50 par origine, puis whitelist seulement les paquets dont vous avez réellement besoin.
5. Faites de apt -s dist-upgrade une étape pré-flight requise. Aucune suppression sans approbation.
6. Une fois par mois, auditez les holds (apt-mark showhold) et supprimez ceux qui ont perdu leur justification.

La récompense est ennuyeuse de la meilleure façon : les mises à jour deviennent routinières, la dérive devient visible, et apt cesse de vous surprendre à 02:13. Vos serveurs planteront encore parfois — c’est la nature des serveurs — mais ce ne sera pas parce que vous avez laissé le gestionnaire de paquets improviser.