Existe-t-il une distribution qui prend en charge la restauration des packages mis à jour?

23

Existe-t-il un outil ou même une distribution entière qui prend en charge la restauration des packages modifiés après une mise à jour?

À titre d'exemple: j'ai mis à niveau les packages A, B et C. Après avoir travaillé avec ces packages pendant plusieurs jours, je rencontre un bogue dans B qui brise la donne.

Pendant que je soumettais un rapport de bogue, je devrais également rétrograder B vers la version précédente afin de pouvoir terminer ce que j'allais faire. Pendant ce temps, A dépend de B, il devrait donc être rétrogradé également, mais C est indépendant des deux, il pourrait donc rester à sa version actuelle.

Existe-t-il un outil ou une distribution qui prend en charge cela?

Je sais que la plupart des distributions ont un moyen de rétrograder un paquet mais c'est généralement un peu sommaire ou même pas possible parce que le paquet précédent a été supprimé des référentiels et dans certains cas (par exemple après la mise à niveau du serveur X et de Mesa) ça devient vraiment .. . désordonné.

package-management distribution-choice

— Steffen Winkler
source

3

Chose à noter: si le changement de version du package était mineur, les réponses ci-dessous peuvent s'appliquer; cependant, notez que des modifications de package plus importantes peuvent mettre à niveau les données sur disque qui ne fonctionneront pas correctement par la suite dans les anciennes versions. Par exemple, la mise à niveau majeure de mysql-server (ou joomla) ajoutera et modifiera des champs et mettra à niveau les tables SQL, la mise à niveau inn2 peut changer le type de base de données, ou une mise à niveau du noyau de distribution peut mettre à niveau le système de fichiers ext3 vers ext4, ou une mise à niveau du package convertira les fichiers de configuration, etc. La seule protection contre ces changements "incontrôlables" sont les instantanés LVM / btrfs / etc (ou la sauvegarde / restauration beaucoup plus lente).

— Matija Nalis

@MatijaNalis +1 pour avoir mentionné cela!

— Steffen Winkler

21

NixOS prend en charge les annulations de mise à niveau, bien que si je comprends bien, cela ne va pas aussi loin que vous le souhaitez: si vous mettez à niveau A, B et C en une seule opération, vous pouvez annuler cette opération en entier, mais pas seulement A et B. (Vous devriez pouvoir annuler A, B et C, puis mettre à niveau C ...) Cela a du sens d'un point de vue transactionnel.

Debian (en combinaison avec l'archive d'instantanés si vous n'avez plus les anciens paquets) vous permettra de rétrograder B, et des outils comme aptou aptitudedans de nombreux cas détermineront que A doit également être rétrogradé (une fois que vous les avez convaincus que vous ne veulent pas simplement mettre à niveau B). Mais comme vous le dites, cela a tendance à être un peu compliqué, et les rétrogradations de paquets ne sont de toute façon pas prises en charge dans Debian (ce qui signifie que la plupart du temps elles fonctionnent, mais si elles se cassent, ce n'est pas un bogue).

— Stephen Kitt
source

1

ça a l'air intéressant! La communauté semble active et en bonne santé. Je vais certainement essayer, merci! Si vendredi soir il n'y a pas de meilleure réponse / différente, je marquerai votre réponse.

— Steffen Winkler

Les rollbacks sur NixOS sont impressionnants, mais la vraie puissance vient de l'approche déclarative: la description des packages (et du système) peut être prise à partir d'un référentiel git, ainsi vous pouvez gérer votre système de la même manière que vous géreriez un projet logiciel, y compris les branches et fusionne etc. (et en raison des mises à niveau atomiques et de la pureté, vous ne cassez jamais des choses)

— Daniel Jour

Le gestionnaire de packages Nix peut également être exécuté sur d'autres distributions Linux, côte à côte avec leur gestionnaire de packages «natif». Il fonctionne également sur OSX, et j'ai vu des affirmations selon lesquelles cela pourrait fonctionner sous Windows. Vous pouvez également dire à Nix d'utiliser des versions «natives» de certains packages, plutôt que d'installer ses propres doublons, bien que vous perdiez ainsi certaines de ses garanties (par exemple, il peut ne pas remarquer que vous avez échangé certaines dépendances).

— Warbo

juste pour info, j'ai réussi à installer NixOS sur mon ordinateur portable (l'image KDE4 m'a donné une panique du noyau, mais la petite image (~ 390 Mo) a bien démarré. Pour quelqu'un qui n'a jamais installé que des distributions basées sur Debian, c'était assez intéressant / amusant. Cependant , Je ne comprends pas encore certaines choses sur le gestionnaire de paquets, surtout en ce qui concerne les environnements de bureau. J'ai installé gdm / gnome-shell mais cela ne fonctionnerait pas. J'ai ensuite activé gnome3 / gdm dans le fichier configuration.nix et lors de la reconstruction , les paquets et leurs dépendances ont été téléchargés à nouveau. Cela a fonctionné après un redémarrage mais je ne comprends pas pourquoi.

— Steffen Winkler

@SteffenWinkler Lorsque vous utilisez NixOS, vous n'installez pas normalement les choses avec nix-env, au lieu de cela vous spécifiez des choses dans configuration.nixpuis exécutez nixos-rebuild switch. Cela a l'avantage que toute la configuration de votre système est en un seul endroit, et il est facile de sauvegarder la configuration complète de votre système (il suffit de sauvegarder le configuration.nixfichier).

— Pauan

15

Sur toute yumdistribution basée (par exemple Red Hat EL , CentOS , etc.), vous pouvez:

examiner l'historique des modifications apportées au système à l'aide sudo yum history list

Loaded plugins: fastestmirror
ID     | Login user               | Date and time    | Action(s)      | Altered
------------------------------------------------------------------------------
    10 | Administrator <admin>    | 2016-03-08 09:08 | Install        |   11   
     9 | Administrator <admin>    | 2016-03-03 16:48 | Install        |    1   
     8 | Administrator <admin>    | 2016-03-03 16:09 | Install        |    5   
     7 | Administrator <admin>    | 2016-02-26 18:13 | Install        |    1   
     6 | Administrator <admin>    | 2016-02-26 15:12 | Install        |   27   
     5 | Administrator <admin>    | 2016-02-26 15:07 | Install        |    1   
     4 | Administrator <admin>    | 2016-02-26 15:05 | Install        |    3  <
     3 | Administrator <admin>    | 2016-02-26 15:03 | Install        |    1 > 
     2 | Administrator <admin>    | 2016-02-26 15:01 | I, U           |   49   
     1 | System <unset>           | 2016-02-26 14:38 | Install        |  296   
history list

vérifier les détails, en utilisant sudo yum history info 10
revenir à un point précédent de l'historique, en utilisant sudo yum history rollback 9

Attention

Il y a quelques mises en garde évidentes:

Si l'ancien paquet n'est plus disponible, vous êtes toast (pour citer @vonbrand),
Si vous installez quelque chose en dehors de miam, vous pourriez casser l'historique.

Dans mon exemple, cela <dans la ligne avec ID 4(dans la dernière colonne), signifie que je ne peux pas revenir en arrière au-delà de ce point.

sudo yum history rollback 2
Loaded plugins: fastestmirror
Transaction history is incomplete, before 4.
 You can use 'history rollback force', to try anyway.
Error: Failed history rollback, incomplete

— andcoz
source

3

caractéristique intéressante! Mais en raison du «toast» ne correspond pas à ma facture.

— Steffen Winkler

AFAIK cela n'est possible que dans RHEL / CentOS 6 ou supérieur. Si vous utilisez toujours RHEL / CentOS 5, vous êtes SOL.

— Wildcard

Et en passant, dans un environnement d'entreprise avec des référentiels gérés, cette approche est tout à fait réalisable car vous avez toujours les anciens packages autour, même si vous devez utiliser un --enablerepoindicateur pour activer un ancien référentiel autrement désaffecté pour la rétrogradation.

— Wildcard

Quel est l'avantage de revenir en arrière par rapport à la simple réinstallation de l'ancienne version?

— Bratchley

@Bratchley automation! prend yum simplement soin de garder la liste des packages et des versions installés et vérifie les dépendances lors de la réinstallation des anciennes versions. De toute évidence, vous pouvez le faire à la main .

— andcoz

7

Sur OpenSUSE, vous pouvez facilement utiliser Snapper avec le système de fichiers Btrfs .

Si vous utilisez la configuration standard du système de fichiers pendant l'installation, elle est activée par défaut .

Une fois Snapper activé, il est entièrement intégré à yast2et zypper. Il créera un instantané du système de fichiers chaque fois que vous installez ou mettez à niveau quelque chose (ou créez un utilisateur, etc.).

Pour ramener le système à une condition précédente, il vous suffit d'exécuter yast2 snapper.

— andcoz
source

outil intéressant en effet. Bien que j'aime beaucoup ext4. Cherchera cela! Ai-je raison de supposer que Snapper n'est pas «lié» à OpenSUSE mais à btrfs?

— Steffen Winkler

Snapper est développé par SUSE. Il s'agit d'une collection d'outils qui automatisent la création des instantanés Brtfs sur les "événements". Je suppose que vous pouvez l'utiliser sur d'autres distributions mais je ne suis pas sûr. Dans tous les cas, vous pouvez créer manuellement des instantanés Brtfs sur n'importe quelle distribution.

— andcoz

3

Gardez à l'esprit que si votre volume contient des données, pas seulement des binaires et des scripts, le fait de restaurer un instantané restaurera également vos propres données. Cette option semble risquée, mieux adaptée à ceux qui connaissent vraiment la disposition de leur système de fichiers. Pour moi, les instantanés ont toujours été pour des sauvegardes cohérentes, la réplication et des situations de récupération totale.

— jimp

1

Notez également que de nombreux packages contiennent des fichiers et / ou des répertoires /var, il doit donc être annulé, /même s'il s'agit d'un fs ou d'un sous-volume distinct. Il est de loin préférable de tester soigneusement une mise à niveau avant de l'appliquer aux serveurs de production que de s'appuyer sur des fonctionnalités telles que la restauration de la mise à niveau du système d'exploitation (ce qui est très facile à faire de manière semi-arsée mais est un problème extrêmement difficile à résoudre correctement ).

— cas

1

@Jimp Un bon conseil. Dans tous les cas, OpenSuSE n'active pas le snapper, sauf s'il se /hometrouve dans un système de fichiers distinct sans snapshot .

— andcoz

6

AIX est très bon pour annuler les mises à jour. Eh bien - nous sommes sur le site Unix / Linux et vous n'avez jamais spécifié que vous vouliez Linux :)

Chaque mise à jour AIX enregistre tous les fichiers modifiés dans un sous-répertoire distinct à l'intérieur du système de fichiers / var. La mise à jour peut être annulée avec une simple commande native, et le retour n'a pas besoin que le réseau soit actif, il n'a besoin d'aucun support / package, il ne réinstalle rien et ne dépend d'aucun technologie d'instantané - l'effet est simplement que les fichiers réapparaissent tels qu'ils étaient avant la mise à jour.

En prime, il existe une commande native triviale mksysbpour créer une sauvegarde système autonome amorçable. Le fichier qui peut être simplement démarré sur un système complètement dysfonctionnel qui ne démarre pas en raison d'un dysfonctionnement / d'une corruption.

Et c'est une technologie éprouvée avec des décennies d'histoire :)

— kubanczyk
source

Avez-vous souvent des problèmes avec des programmes restaurés de cette manière dans un état et une restauration incohérents (c'est-à-dire une base de données dont le moteur de stockage a changé ou un service qui est passé à un nouveau format de fichier de configuration), ou existe-t-il de bonnes façons de travailler cette?

— Josh Rumbut

1

C'est le modèle que j'ai utilisé lorsque j'ai construit un système de gestion de packages rudimentaire pour des logiciels qui étaient traditionnellement distribués dans des tarballs compressés / compressés. Chaque fois qu'il installait des mises à jour, il construisait d'abord un «package de restauration» de tout ce qui devait être modifié. Ce package de restauration pouvait ensuite être utilisé pour revenir en arrière, à condition qu'aucun autre package de mise à jour n'ait été appliqué dans l'intervalle. Je me suis souvent demandé si les gestionnaires de paquets appropriés pouvaient le faire, mais étant donné les contraintes de revenir en arrière uniquement dans l'ordre inverse ... nous devrions peut-être simplement utiliser git à la place.

— Monty Harder

bon sang. J'aurais dû spécifier que je voulais dire les distributions GNU / Linux. Mais il est intéressant de noter qu'AIX semble être capable d'exécuter des «programmes» GNU / Linux de nos jours, je suppose que je vais y regarder de plus près.

— Steffen Winkler

5

Dans Fedora (et je suis sûr que dans d'autres distributions aussi), vous pouvez demander à revenir à une version précédente:

dnf downgrade <packages>

vous obtient l'avant-dernière version des packages, et vous pouvez en demander une spécifique en:

dnf downgrade <package>.<version>

Cela ne fonctionne que si le ou les packages sont toujours disponibles dans les référentiels. La fonctionnalité n'est pas du tout inconnue. Il a ses inconvénients, si une partie de la mise à niveau consistait à modifier les configurations, le retour en arrière ne sera pas nécessairement à la version antérieure exacte.

— vonbrand
source

Vous pouvez également utiliser l'annulation de l'historique dnf #thing to undo

— Clearer

This only works if the package(s) are still available in the repositories. yup, c'est exactement le problème. Je suis un peu surpris qu'il ne semble pas y avoir de solution «plus large» pour cela, en particulier avec le nombre de distributions à diffusion continue. À l'heure actuelle, il semble que NixOS soit ma meilleure option, ou j'aurais besoin d'une sorte d'outil de création d'image système qui ne fonctionne que sur les différences et peut restaurer le système à un moment précis au cours des 20 dernières mises à jour.

— Steffen Winkler

@SteffenWinkler, si l'ancien paquet n'est plus disponible, vous êtes grillé. Évidemment. Sauf si vous avez une sorte de sauvegarde locale.

— vonbrand

2

@MTilsted, car il est déjà trop vieux? Les référentiels ne contiennent pas toutes les versions depuis la nuit des temps.

— vonbrand

1

Dans dnf.conf (comme yum.conf) a keepcache = true Anciens packages disponibles, car le cache lond n'est pas effacé manuellement. Mais il est allé dans le cache du paquet "ballonnement".

— mmv-ru

2

Arch Linux prend également en charge la mise à niveau des packages et du noyau. Vous pouvez également installer les outils downgraderet downgradepour automatiser le processus. La solution btrfs fonctionne également, je l'ai déjà utilisée pour faire une restauration manuelle.

Comment je fais reculer mon système:

sudo -i
mount /dev/sda3 /mnt/hd #mount the top btrfs subvolume
ls #find the version you want
mv @ @-old #move the '/' subvolume (I named mine '@')
btrfs sub snap @-<date> @ #replace @ with the backup from <date>
sync
reboot #the changes will take effect once the system restarts

Un des avantages de btrfs est que vous pouvez utiliser des sous-volumes et des "partitions" dynamiques. Par exemple, j'ai un sous-volume pour / (appelé @), / tmp (@tmp) et / home (@home). Il est ensuite facile de sauvegarder et de restaurer n'importe lequel de ces éléments. J'ai / tmp dans un sous-volume séparé car le sauvegarder avec le reste du système semble inutile, car il est effacé à presque chaque redémarrage.

— Caleb Reister
source

J'ai suivi un lien dans le wiki et je suis arrivé ici . Cela a l'air plutôt cool et après avoir vérifié le référentiel, il y a des fichiers qui remontent à 2013! Pourquoi utiliser la méthode btrfs quand cela existe? En raison de fichiers «mis à niveau»? Ou y a-t-il une autre raison?

— Steffen Winkler

Je suis maintenant passé définitivement à Arch Linux après avoir rendu une courte visite à NixOS. Il (Arch Linux) n'est pas aussi instable que je l'ai toujours pensé et il a une communauté saine.

— Steffen Winkler

@SteffenWinkler C'est exact. De plus, les options de rétrogradation Arch ne sont pas "officiellement" prises en charge et la rétrogradation ignorera probablement les dépendances (ce qui peut devenir assez compliqué en cas de problème).

— Caleb Reister

2

J'utilise Arch Linux et il stocke tous les packages téléchargés sur /var/cache/pacman/pkg/afin que vous puissiez rétrograder n'importe quel package à tout moment (vous ne pouvez pas démarrer, utilisez une clé USB en direct). De Arch Wiki :

pacman -U <file_name_of_the_package>

Pour empêcher la mise à niveau du package, incluez le nom du package dans /etc/pacman.conf, par exemple:

IgnorePkg=linux

Pour économiser de l'espace, vous pouvez effacer le dossier de cache avec:

pacman -Sc

Ce qui supprimera tous les anciens paquets et conservera le plus récent, ou utilisera -Sccpour tout supprimer.

— Alko
source

Notez que cela (en ignorant les packages) équivaut à une mise à niveau partielle, qui n'est pas prise en charge ...

— jasonwryan

J'ai suivi un lien dans le wiki et je suis arrivé ici . Cela a l'air plutôt cool et après avoir vérifié le référentiel, il y a des fichiers qui remontent à 2013! Pourquoi utiliser la méthode btrfs quand cela existe? En raison de fichiers «mis à niveau»? Ou y a-t-il une autre raison?

— Steffen Winkler