Scénario: Dans une configuration système contrôlée par version basée sur Puppet, Chef etc., il est nécessaire de reproduire un certain état du système. Cela se fait en spécifiant explicitement les versions des packages système.
Récemment, nous avons rencontré un problème où certaines versions de paquets manquaient dans les référentiels Debian. Un exemple: le package "patch" était requis dans la version 2.7.5-1 + deb9u1, mais seulement 2.7.5-1 + deb9u2 était disponible. Un autre exemple encore plus grave: "linux-headers-4.9.0-9-common" est requis (en raison de l'installation du noyau associé) et seul "linux-headers-4.9.0-11-common" est disponible.
Cela rend impossible de reproduire un certain état d'un système.
Les packages ci-dessus ne sont que des exemples (que j'ai en fait rencontrés). Je souhaite comprendre et résoudre le problème général.
Quelle est l'idée derrière ces mises à jour, ces packages "disparaissants" et leurs versions?
Où puis-je obtenir les versions précédentes (pas vraiment des anciennes versions, mais des versions vieilles de quelques semaines) des paquets Debian? Il devrait être possible d'automatiser le processus d'installation de manière générale.
Être capable de reproduire une configuration spécifique, jusqu'à la version exacte, est votre exigence , pas Debian.
Debian ne prend en charge qu'une seule version de chaque paquet binaire dans une version donnée; en contrepartie, un grand soin est apporté pour garantir que les mises à jour de packages dans une version donnée n'introduisent pas de régressions et, lorsque cela n'est pas possible, pour documenter ce fait. Conserver plusieurs versions d'un package donné ne ferait qu'augmenter la charge de support et les exigences de test: par exemple, les responsables de packages devraient tester les packages mis à jour par rapport à toutes les versions disponibles des bibliothèques qu'ils utilisent, au lieu des seules versions actuellement prises en charge ... Les packages ne sont mis à jour dans une version stable que lorsque cela est vraiment nécessaire, c'est-à-dire pour corriger un bug sérieux (y compris les problèmes de sécurité). Dans le cas du noyau, cela signifie parfois que le noyau ABI change et que le nom du package change en conséquence (pour forcer la reconstruction des packages dépendants); il existe des méta-packages que vous pouvez extraire au lieu de coder en dur l'ABI (linux-image-AMD64
, linux-headers-AMD64
, etc.).
Il existe cependant une solution de contournement pour votre situation: chaque source publiée et package binaire est archivé sur snapshot.debian.org . Lorsque vous créez une configuration versionnée, vous pouvez choisir l'instantané correspondant (par exemple, l'un des les instantanés de septembre 2019 ) et l'utiliser comme URL de référentiel:
deb https://snapshot.debian.org/archive/debian/20190930T084755Z/ buster main
Si vous finissez par vous en remettre à cela, veuillez utiliser un miroir de mise en cache d'une certaine sorte, par exemple Apt-Cacher NG . Cela permettra non seulement de réduire la charge sur le serveur d'instantanés, mais également de disposer d'une copie locale de tous les packages dont vous avez besoin.
(La situation en ce qui concerne les packages source est légèrement plus complexe, et les archives contiennent plusieurs versions de certains packages source dans une version donnée, en raison de la licence dépendances. Mais ce n'est pas pertinent ici. À strictement parler, Debian fournit plusieurs versions de certains binaires dans les versions prises en charge: la version actuelle dans la version ponctuelle actuelle, ainsi que les mises à jour dans les référentiels de sécurité et les référentiels de mise à jour; ces derniers sont repliés dans la prochaine version de points. Il est donc possible de maintenir une configuration système reproductible et contrôlée par version sans recourir à des instantanés, à condition de la mettre à jour à chaque fois qu'une version de point est effectuée.)
Ne comptez pas sur des serveurs qui ne sont pas sous votre contrôle pour reproduire un état système spécifique. Même si les serveurs Debian sont assez fiables, vous ne savez jamais ce qui pourrait arriver à l'avenir. Ceci est particulièrement pertinent avec d'autres référentiels que vous pourriez utiliser.
Vous devez conserver votre propre miroir pour obtenir des états système capables de se reproduire. De cette façon, vous pouvez même avoir un état de production pour vos systèmes normaux et plusieurs états de test pour de nouvelles configurations.
L'outil de gestion de référentiel à juste titre est capable de créer des miroirs de référentiels. Vous pouvez choisir les packages à mettre en miroir, créer des instantanés du contenu du référentiel à des moments spécifiques et combiner plusieurs miroirs ou instantanés dans un même référentiel. De cette façon, vous pouvez reproduire complètement les états du système.
Alors que réponse de Stephen Kitt est certainement une solution possible, je pense qu'il serait plus sûr pour vous de conserver vos propres copies des packages nécessaires.
Lors de l'enregistrement d'une configuration système, veillez à enregistrer des copies de .deb
- fichiers de /var/cache/apt/archives/
. Vous pouvez aussi utiliser apt-get download
.
Lors de la restauration d'une configuration système, vous devez être très strict avec apt
pour éviter de déclencher des actions automatiques potentiellement dangereuses.
Il sera probablement plus facile d'utiliser directement dpkg
pour installer exactement ce que vous voulez.