Comment puis-je obtenir une gestion des mises à jour de type «Git» pour Linux?

Je veux gérer les mises à jour de mon système Linux de la même manière que Git le fait, en pouvant aller et venir dans les "révisions". Comment pourrais-je faire ça?

Vous devriez probablement regarder NixOS , qui utilise le gestionnaire de paquets Nix .

NixOS est une distribution GNU / Linux qui vise à améliorer l'état de l'art dans la gestion de la configuration du système. Dans les distributions existantes, les actions telles que les mises à niveau sont dangereuses: la mise à niveau d'un package peut entraîner la rupture d'autres packages, la mise à niveau d'un système entier est beaucoup moins fiable que la réinstallation à partir de zéro, vous ne pouvez pas tester en toute sécurité les résultats d'un changement de configuration, vous ne pouvez pas facilement annuler les modifications apportées au système, etc.

Ce que vous recherchez probablement s'appelle des outils de gestion de configuration . Il y en a plusieurs, mais c'est très subjectif lequel est le meilleur dans n'importe quelle situation.

Personnellement, j'ai trouvé Puppet assez facile à démarrer, mais d'autres choix populaires sont Salt et Ansible .

C'est probablement exagéré pour votre question, mais le moyen le plus simple de pouvoir annuler des modifications massives au niveau du système est le snapshot:

https://en.wikipedia.org/wiki/Snapshot_%28computer_storage%29

Vous n'avez pas mentionné les spécificités de votre plate-forme, mais étant donné que vous êtes familier avec git, il ne serait pas exagéré d'imaginer que vous pourriez être intéressé par l'utilisation d'un système de fichiers plus complexe. Si vous deviez utiliser un système de fichiers de nouvelle génération (ignorer le nom click-bait-y), vous seriez en mesure de «rembobiner» complètement votre système entier avec une simple commande insérée dans votre terminal. Toutes les modifications apportées seraient annulées avec très peu de retard / effort. ZFS serait votre meilleur pari et vous pouvez vous référer à cet article Ars étonnant pour voir si cela pourrait en valoir la peine (il existe de nombreuses autres fonctionnalités intéressantes):

http://arstechnica.com/information-technology/2014/02/ars-walkthrough-using-the-zfs-next-gen-filesystem-on-linux/

Selon ce que vous entendez par «mises à jour», vous pouvez être intéressé par des outils de gestion de configuration comme etckeeper , qui vous permettent d'enregistrer automatiquement les modifications de la configuration du système et de revenir aux configurations antérieures.

Si Git est un outil familier, et si par "mises à jour" vous voulez dire "mises à jour de la configuration du système" par opposition à "mises à jour des packages système" ou "mises à jour de tous les fichiers stockés sur le serveur", c'est peut-être ce que vous cherchez pour.

• site web et github etckeeper
• Introduction d'Ubuntu à etckeeper

Il vaut la peine de considérer que si vous utilisez des outils tels que Puppet, Ansible, Etckeeper, etc., il n'est pas toujours possible de "revenir en arrière" proprement sans perte de données, à moins que vous n'ayez à faire tout le porc (par exemple, les instantanés, comme mentionné dans une autre réponse). La bonne approche dépendra de votre situation (par exemple, les instantanés ne seraient pas appropriés pour un système de production où vous pourriez perdre des commandes clients lors d'un retour en arrière).

J'ai utilisé OpenVMS dans le passé, il est livré par défaut avec un système de fichiers de version .

Si des outils comme les marionnettes ne vont pas assez loin, un système de fichiers de version est peut-être ce que vous recherchez.

Si vous voulez vraiment gérer tout votre système (y compris la version du noyau) comme git, vous recherchez NixOS .

Pour une version moins impliquée, vous pouvez utiliser le gestionnaire de paquets de NixOS, nix, à partir de presque n'importe quel unix. Nix peut être installé en tant qu'utilisateur simple, mais il est plus facile de l'installer en tant que root. Une fois que nix est installé, vous pouvez l'utiliser pour installer des packages en tant qu'utilisateur non privilégié, et il fonctionne correctement avec votre gestionnaire de packages existant, sans conflits. Il est également très facile de supprimer complètement nix de votre système, il n'y a donc vraiment aucune excuse pour ne pas l'essayer. ;-)

Pour répondre directement à votre question, Nix définit votre système installé complet comme un environnement, qui est, tout comme un commit git, un pointeur vers un ensemble de pointeurs vers des versions très spécifiques de tous les packages installés.

Lorsque Nix met à niveau un package, il crée un nouvel environnement, qui pointe vers un nouvel ensemble de pointeurs vers les packages (principalement vers ceux existants, pour les packages qui n'ont pas été mis à jour; encore une fois, cela est très similaire à un nouveau git commit, qui la plupart du temps pointe vers les fichiers inchangés précédents et quelques nouvelles versions de fichiers modifiés).

Il est, bien sûr, trivial de passer à une version précédente de l'environnement et, je crois, à fork (c'est-à-dire à créer un nouvel environnement basé sur un plus ancien que le dernier). Un environnement peut être chargé pour un shell spécifique (il s'agit en fait de l'ensemble des variables d'environnement disponibles pour un shell, d'où le nom), vous pouvez donc également avoir assez facilement différents environnements pour différents projets sur la même machine. Plus de problèmes de dépendances car un projet indépendant a besoin d'une autre version d'une bibliothèque!

NixOS prend cela au niveau supérieur et gère l'ensemble de votre ordinateur, y compris le noyau, d'une manière similaire, permettant des mises à niveau à très faible risque de l'ensemble de la machine.

Je n'ai pas fini de les lire tous, mais je recommande les comprimés Nix de Lethalman comme introduction à Nix.

Si vous êtes du type expérimental, vous pouvez essayer de simplement archiver l'intégralité de votre système de fichiers dans un référentiel git local. Ce serait ... intéressant, je pense.

1. git init dans le répertoire racine /
2. Construisez un .gitignore pour la racine qui ignore les répertoires dont le contenu change souvent ou ne devrait pas être archivé:
   • / dev
   • /courir
   • / tmp
   • / proc
   • / perdu + trouvé
   • ...
3. Ajoutez aux types de fichiers spécifiques .gitignore que vous souhaiterez peut-être exclure:
   • * .tmp
   • *.Journal
   • ...
4. Ajoutez votre contenu initial avec git add -A .
5. Validez l'instantané avec git commit -m "Initial Snapshot"
6. Utilisez votre ordinateur
7. Ajouter périodiquement des instantanés git commit -Am "Snapshot X"ou similaires

Certains avantages seraient:

• Outils familiers pour l'historique des révisions, comme gitketgit diff
• Tout livecd ou autre système d'exploitation avec git pourrait restaurer vos sauvegardes
• Vous pouvez pousser votre système entier vers github et le restaurer sur d'autres machines ou le partager avec des gens ...?
• La ramification serait rapide et intuitive
• /, le répertoire git dans votre racine inspirerait la confiance pour abuser de votre système et être plus aventureux, similaire au code source
• Chaque instantané suivant serait relativement petit par rapport à certaines autres solutions de sauvegarde
• Serait génial pour examiner et suivre les modifications de configuration dans / etc
• Vous pourriez être pionnier et l'appeler linit - linux dans git.
• Infamie

Certaines bizarreries peuvent inclure:

• Il est peu probable que vous puissiez restaurer / extraire des branches ou des révisions avec des modifications importantes ou des modifications des fichiers utilisés lors de l'exécution du système - peut-être avoir un USB de démarrage minimal avec git à cet effet
• Commits initiaux assez importants
• Vérifié dans les répertoires .git suivants -?
• gitsi tout va bien comme prévu lorsque vous êtes dans un répertoire de code source imbriqué dans le gitconteneur racine .
• / etc / passwd et / etc / shadow devraient être inclus dans le référentiel pour maintenir et suivre les utilisateurs et les restaurer sur d'autres machines, mais maintenant quiconque ayant un accès à la vue (peut-être sur github) peut voir des informations sensibles comme le contenu, les autorisations, et les hachages de mot de passe de vos utilisateurs.