Question Comment puis-je réaliser une gestion de mise à 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?


14
2018-01-13 20:19


origine


En tant qu'administrateur de systèmes Linux / Unix qui traite des aspects les plus profonds du fonctionnement des systèmes Linux / Unix, je ne peux pas imaginer le type de modifications à apporter à leur système pour exiger un système de révision de type Git. Les principales modifications apportées à ces systèmes sont les installations de logiciels et les fichiers de configuration. Les fichiers de configuration sont faciles à sauvegarder manuellement et à suivre. Et cela tombe dans un état d'esprit "le mettre et l'oublier". - JakeGould


Réponses:


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 la technique en matière de gestion de la configuration des systèmes. Dans les distributions existantes, les actions telles que les mises à niveau sont dangereuses: la mise à niveau d'un package peut provoquer la rupture d'autres packages, la mise à niveau d'un système complet est beaucoup moins fiable que la réinstallation. vous ne pouvez pas facilement annuler les modifications apportées au système, etc.


12
2018-01-13 23:49





Ce que vous recherchez probablement s'appelle outils de gestion de configuration. Il y en a plusieurs à choisir mais il est très subjectif de savoir lequel est le meilleur dans toutes les situations.

J'ai personnellement trouvé Fantoche être assez facile pour commencer, mais d'autres choix populaires sont Sel et Ansible.


12
2018-01-13 21:12



J'ai déjà utilisé la marionnette dans le vagabondage, mais je ne me souviens pas avoir jamais réussi à défaire quelque chose de désordonné que j'ai fait dans mon système d'exploitation ... - Patrick Villela
Les outils de gestion de la configuration ne fournissent généralement pas de fonctionnalité de «restauration». La "restauration" fait sauter le système et utilise l'outil de gestion de la configuration pour reconfigurer le système. Par exemple, vous pouvez utiliser un outil de provisionnement nu comme Razor pour formater et réinstaller le système d'exploitation. Ensuite, il passe à un outil comme Chef pour appliquer la configuration. - ctc
La sorcière est-elle destinée? :) - Ruslan
Est-ce que cfengine est mort? Je me souviens d'avoir essayé d'utiliser quelque chose avec lequel j'étais content d'utiliser mon petit cluster lorsque j'étais administrateur système. Mais je n'ai jamais fini par le déployer. - Peter Cordes
Avec l'un de ces outils, vous obtenez un contrôle de version en conservant vos fichiers de configuration maîtres dans git. Ce que vous obtenez d'eux est la centralisation et la réduction de la configuration de tout un système à l'un des quelques fichiers texte. - Peter Cordes


C'est probablement exagéré pour votre question, mais le moyen le plus simple de pouvoir rétablir des modifications système / massives est la capture instantanée:

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 utilisiez un système de fichiers de nouvelle génération (ignorez le nom du clic-appât), vous seriez en mesure de "rembobiner" complètement votre système avec une simple commande dans votre terminal. Tous les changements apportés seraient annulés avec très peu de retard / effort. ZFS serait votre meilleur pari et vous pourriez vous référer à cet article Ars étonnant pour voir si cela pourrait valoir quelque chose pour vous (il y a aussi beaucoup d'autres fonctionnalités intéressantes):

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


10
2018-01-13 22:06



Une autre option est btrfs, pour laquelle BTW a le support officiel d’Ubuntu, SUSE> = 11, Oracle. Bien qu'il soit encore en développement et blahblahblah, il est fiable pour une utilisation de bureau quotidienne et fonctionne très bien. - ignis
@ignis: J'ai récemment rencontré un Btrf incohérent et non récupérable malgré un RAID 5 en dessous et j'ai entendu parler de deux autres instances au travail. Je ne négligerais donc pas à la légère ces avertissements selon lesquels ils ne seraient pas prêts pour une utilisation en production. Je ne voulais pas le croire moi-même avant de le rencontrer. Peut-être était-ce dû à une mauvaise RAM, ce qui est l’une des raisons pour lesquelles les gens de ZFS fortement  conseiller l'utilisation de la mémoire ECC. Je suppose que la même chose pourrait s'appliquer aux Btrfs. - MvG


Selon ce que vous entendez par "mises à jour", vous pouvez être intéressé par des outils de gestion de configuration tels que etckeeper, qui vous permet d’enregistrer automatiquement les modifications apportées à la configuration du système et de revenir aux configurations précédentes.

Si Git est un outil familier, et si "mises à jour" signifie "mises à jour de la configuration système" par opposition aux "mises à jour des packages système" ou "mises à jour de tous les fichiers stockés sur le serveur", alors pour.

Cela vaut la peine de penser que si vous utilisez des outils comme Puppet, Ansible, Etckeeper, etc., il n'est pas toujours possible de revenir en arrière sans perte de données, sauf si vous utilisez des snapshots. 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 risqueriez de perdre les commandes des clients en cas de retour en arrière).


6
2018-01-13 23:14





j'ai utilisé OpenVMS dans le passé, il est livré par défaut avec un système de fichiers de gestion des versions.

Si des outils tels que la marionnette ne vont pas assez loin, peut-être que vous recherchez un système de fichiers de gestion des versions.


2
2018-01-14 10:53





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

Pour une version moins impliquée, vous pouvez utiliser le gestionnaire de paquets de NixOS, nix, à partir de presque tous les Unix. Nix peut être installé en tant qu'utilisateur simple, bien qu'il soit plus facile de l'installer en tant que root. Une fois nix 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 aucun conflit. Il est également très facile de supprimer complètement nix de votre système, donc il n'y a 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 sur un ensemble de pointeurs vers des versions très spécifiques de tous les packages installés.

Lorsque Nix met à jour un paquet, il crée un nouvel environnement, qui pointe vers un nouvel ensemble de pointeurs vers des paquets (principalement vers des paquets existants, pour les paquets qui n'ont pas été mis à jour; encore une fois, pointe vers les fichiers précédents inchangés et quelques nouvelles versions de fichiers modifiés).

Bien entendu, il est trivial de passer à une version antérieure de l’environnement et, je crois, à une version antérieure (c.-à-d. Créer un nouvel environnement basé sur un environnement plus ancien que le précédent). 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ù son nom), vous pouvez donc facilement disposer d’environnements différents pour différents projets sur la même machine. Plus de problèmes de dépendance, car un projet sans rapport nécessite une autre version d'une bibliothèque!

NixOS passe au niveau supérieur et gère tout votre ordinateur, y compris le noyau, de manière similaire, ce qui permet des mises à niveau très peu risquées de la machine entière.

Je n'ai pas fini de tous les lire, mais je recommande Lethalman's Nix Pills en guise d'introduction à Nix.


1
2018-01-14 22:58





Si vous êtes du type expérimental, vous pouvez simplement essayer d’enregistrer tout 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 doit pas être archivé:
    • / dev
    • /courir
    • / tmp
    • / proc
    • / perdu + trouvé
    • ...
  3. Ajoutez aux types de fichiers spécifiques à .gitignore que vous souhaitez peut-être exclure:
    • * .tmp
    • *.bûche
    • ...
  4. Ajoutez votre contenu initial avec git add -A .
  5. Commencez la capture avec git commit -m "Initial Snapshot"
  6. Utilisez votre ordinateur
  7. Ajouter périodiquement des instantanés git commit -Am "Snapshot X" ou similaire

Certains avantages seraient:

  • Des outils familiers pour l'historique des révisions, comme gitk et git diff
  • Tout système d'exploitation ou autre système d'exploitation avec git pourrait restaurer vos sauvegardes
  • Vous pourriez pousser tout votre système à github et le restaurer sur d'autres machines ou le partager avec des personnes ...?
  • Le branchement serait rapide et intuitif
  • /, 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 comparé à d'autres solutions de sauvegarde
  • Serait génial pour examiner et suivre les changements de configuration dans / etc
  • Vous pouvez le faire et appeler cela linit - linux in git.
  • Infamie

Certaines bizarreries pourraient inclure:

  • Il est peu probable que vous puissiez restaurer / extraire des branches ou des révisions avec des modifications significatives ou des modifications apportées aux fichiers utilisés lors de l'exécution du système. Peut-être avez-vous une clé USB de démarrage minimale avec git à cet effet.
  • Placements initiaux plutôt importants
  • Vérifié dans les répertoires suivants .git -?
  • git en espérant travailler comme prévu lorsque vous êtes dans un répertoire de code source imbriqué dans la racine git récipient.
  • / etc / passwd et / etc / shadow devraient être inclus dans le référentiel pour conserver et suivre les utilisateurs et les restaurer sur d'autres machines, mais désormais toute personne ayant un accès en vue (peut-être sur github) peut voir des informations sensibles et les mots de passe de vos utilisateurs.

0
2018-01-14 08:28



Cette approche échouera très probablement, car git ne traitera pas correctement les autorisations. En supposant que vous fassiez tout cela en tant que root, vous devez essentiellement convertir le système de fichiers entier en root, ce qui, à son tour, perturbera les opérations d'écriture. Par exemple, vous prenez un instantané, le restaurez, le propriétaire du répertoire apache devient racine (au lieu de http), apache ne peut pas écrire dans le répertoire, ne parvient pas à démarrer. Je le sais, car j'ai essayé une chose similaire, mais à une échelle beaucoup plus petite, et même là, il y avait des problèmes. - Tuncay Göncüoğlu
Regardez Nix, comme suggéré dans une autre réponse;) - Michael Pankov
Bon à savoir! Je pensais qu'il gérait les permissions, au moins l'octet, car mes scripts conservent l'indicateur x sur le clone, mais je n'ai pas pensé à la propriété des fichiers et des groupes - Ehryk
Il semble qu'il existe des outils supplémentaires qui conservent les autorisations et les droits de propriété complets, si vous en aviez besoin. Un tel outil est git-cache-meta, et Voici une liste - Ehryk