Pourquoi les versions précédentes des paquets Debian disparaissent-elles dans les référentiels de paquets? (très pertinent pour la configuration de système sous contrôle de version)

Scénario: dans la configuration de système contrôlée par la version et basée sur Puppet, Chef, etc., il est nécessaire de reproduire un certain état du système. Ceci est fait en spécifiant explicitement les versions de package système.

Récemment, nous avons rencontré un problème où certaines versions de paquet manquaient dans les référentiels Debian. Un exemple: le package "patch" était requis dans la version 2.7.5-1 + deb9u1, mais seul 2.7.5-1 + deb9u2 était disponible. Un autre exemple encore plus sévère: "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 la reproduction d'un certain état d'un système.

Les packages ci-dessus ne sont que des exemples (que j'ai en fait rencontrés). Je suis intéressé à comprendre et à résoudre le problème général.

Quelle est l'idée derrière ces mises à jour, packages "disparus" et versions de packages?

Où puis-je obtenir les versions précédentes (pas vraiment les anciennes versions, mais des versions vieilles de quelques semaines) de paquets Debian? Il devrait être possible d'automatiser le processus d'installation de manière générale.

debian package-management

— Flo
source

Cela dépend un peu du logiciel utilisé pour configurer le référentiel. Reprepro, iirc, n'autorise qu'une seule version de chaque paquet

— muru

stablereste cohérent, au moins jusqu'à la prochaine publication. stable-updates, testing et unstable ne contiennent que la dernière version d'un paquet donné. Pour toute autre chose, vous devrez regarder sur archive.debian.org (ou snapshot.debian.org comme mentionné dans la réponse de SK)

— cas

Y a-t-il une raison pour laquelle vous n'exécutez pas votre propre référentiel sur lequel vous pouvez contrôler les versions de stratégie et de code confidentiel de remplacement (ce qui présente l'avantage de rendre les installations automatiques futures locales)?

— Eric Towers

Le nouveau linuxnom pkg est une exception: en général, les paquets de Debian stable portent le même nom et changent seulement de numéro de version. linux-image-amd64ne change jamais de nom et dépend toujours du dernier linux-image-4.9.0-*. Le nouveau linux-image-4.9.0-*nom pkg marque les modifications ABI du noyau incompatibles requises pour sauvegarder certaines corrections de bugs et permet de gérer la recompilation nécessaire des modules personnalisés (dkms, etc.). De même pour linux-headers-*.

— Ignis

Quelle est l’idée derrière ces mises à jour apt-get changelog packagename

— Ignis

Réponses:

Etre capable de reproduire une configuration spécifique, jusqu’à la version exacte, est votre exigence, pas celle de Debian.

Debian ne prend en charge qu'une seule version de chaque paquet binaire dans une version donnée. La contrepartie est que nous prenons grand soin de veiller à ce que les mises à jour de paquetages dans une version donnée n'introduisent pas de régressions, et lorsque de tels soins ne sont pas possibles, de documenter ce fait. Conserver plusieurs versions d'un paquet donné ne ferait qu'augmenter la charge de support et les exigences de test: par exemple, les responsables de paquet devraient tester les paquets 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-à - direpour corriger un bug sérieux (y compris des problèmes de sécurité). Dans le cas du noyau, cela signifie parfois que l’ABI du noyau change et que le nom du paquet change par la suite (pour forcer la reconstruction de paquets dépendants); il y a des méta-paquets que vous pouvez tirer au lieu de coder en dur l'ABI ( linux-image-amd64, linux-headers-amd64, etc.).

Il existe toutefois une solution de contournement à votre situation: chaque source publiée et chaque package binaire sont archivés sur snapshot.debian.org . Lorsque vous créez une configuration versionnée, vous pouvez sélectionner l'instantané correspondant (par exemple, l'un des 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, par exemple Apt-Cacher NG . Cela réduira non seulement la charge sur le serveur d'instantanés, mais garantira également que vous disposez d'une copie locale de tous les packages dont vous avez besoin.

(La situation en ce qui concerne les paquets source est un peu plus complexe et les archives portent plusieurs versions de certains paquets source dans une version donnée, en raison des dépendances de licence. Mais ce n'est pas pertinent ici. À proprement parler, Debian fournit plusieurs versions de certains binaires dans les versions prises en charge: la version actuelle de la version ponctuelle actuelle, ainsi que les éventuelles mises à jour des référentiels de sécurité et des référentiels de mise à jour, ces derniers étant repliés lors de la prochaine publication ponctuelle. le recours à des instantanés, à condition de le mettre à jour chaque fois qu'une publication ponctuelle est faite.)

— Stephen Kitt
source

Notez que certaines versions antérieures sont parfois disponibles. apt-cache madison packagenameElles afficheront toutes les versions aptpouvant être visualisées via des référentiels configurés.

— ivanivan le

(Veuillez ne pas surcharger les serveurs de captures instantanées / d'archives en les utilisant inutilement, au lieu d'un miroir proche. Laissez donc votre miroir normal dans votre sources.list avec une priorité plus élevée que la capture instantanée, afin que les paquets toujours disponibles à partir de celui-ci puissent être récupérés de cette façon. .)

— Peter Cordes

Juste pour vérifier que j'ai bien compris: en pratique, il ne s'agit pas des versions que je spécifie lors de l'installation de packages (car les anciennes versions peuvent ne pas être disponibles), mais plutôt de l'état du ou des référentiels de packages que je suis en train d'utiliser. Donc, si je veux une «nouvelle» version 9.8 de Debian, j'ai besoin du référentiel de paquets dans cet état même (par exemple, un instantané ou un référentiel que j'ai créé moi-même), puis, bien sûr, le bon paquet linux-header- * reste disponible. . Si je souhaite migrer vers Debian 9.9, je récupère le référentiel de paquets à l'état associé et lance apt-get dist-upgrade. Est-ce correct?

— Flo

Oui c'est correct.

— Stephen Kitt

@Flo note, ces versions ponctuelles (comme debian X.9 ou X.8) sont uniquement destinées aux iso téléchargeables. Ainsi, les nouvelles installations ne téléchargent pas des tonnes de paquets. Dans les référentiels, il n'y a pas de distinction entre les versions ponctuelles, vous obtenez toujours le dernier package.

— Braiam

Ne comptez pas sur des serveurs qui ne sont pas sous votre contrôle pour reproduire un état spécifique du système. Même si les serveurs Debian sont assez fiables, vous ne savez jamais ce qui pourrait arriver dans le futur. Ceci est particulièrement pertinent avec les autres référentiels que vous pourriez utiliser.

Vous devez conserver votre propre miroir pour pouvoir reproduire les états du système. 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 du référentiel porte bien est capable de créer des miroirs de dépôts. Vous pouvez choisir les packages à mettre en miroir, créer des instantanés du contenu du référentiel à un moment donné et combiner plusieurs miroirs ou instantanés dans un référentiel. De cette façon, vous pouvez avoir une reproduction complète des états du système.

— Charleston
source

Bien que la réponse de Stephen Kitt soit certainement une solution possible, je pense qu’il serait plus prudent de conserver vos propres copies des paquets nécessaires.

Lorsque vous enregistrez une configuration système, veillez à enregistrer des copies des .debfichiers /var/cache/apt/archives/. Vous pouvez également utiliser apt-get download.

Lors de la restauration d'une configuration système, vous devez être très strict aptpour éviter de déclencher des actions automatiques potentiellement dangereuses.

Il sera probablement plus facile d’utiliser dpkgdirectement pour installer exactement ce que vous voulez.

— Stig Hemmer
source

Une approche encore meilleure serait d’utiliser un cache APT local. Cela évite les problèmes de votre troisième paragraphe et évite également de devoir récolter /var/cache/apt.

— Stephen Kitt

Il existe deux variantes de cette méthode: l’une consiste à utiliser quelque chose comme apt-mirror pour cloner un référentiel entier, l’autre consiste à télécharger uniquement des packages et des dépendances spécifiques . Puis capture le répertoire - par exemple avec btrfs en tant que pkgs-20190501, puis publiez le répertoire de capture sous forme de référentiel. Au moment de la construction, placez l’URL du référentiel versionné (par exemple http://debmirror/pkgs-20190501/...) dans le fichier sources.list, puis lancez apt-get update, apt-get install $ pkgs, etc.

— bain