How can I achieve "Git"-like update management for Linux?

Question

I want to manage the updates of my Linux system in a similar fashion as Git does it, by being able to move back and forth within "revisions". How could I do that?

Answer 1

What you probably are looking for are called configuration management tools. There are several to choose from but and it's very subjective which one is best in any situation.

I personally found Puppet to be quite easy to get started with, but other popular choices are Salt and Ansible.

Answer 2

You probably should look at NixOS, which uses the Nix package manager.

NixOS is a GNU/Linux distribution that aims to improve the state of the art in system configuration management. In existing distributions, actions such as upgrades are dangerous: upgrading a package can cause other packages to break, upgrading an entire system is much less reliable than reinstalling from scratch, you can’t safely test what the results of a configuration change will be, you cannot easily undo changes to the system, and so on.

Answer 3

This is likely overkill for your question, but the easiest way to be able to revert system-level / massive changes is snapshotting:

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

You have not mentioned the specifics of your rig, but seeing as you are familiar with git, it wouldn't be too much of a stretch to imagine you might be interested in using a more complex file system. If you were to use a next-gen file system (ignore the click-bait-y name) you would be able to completely "rewind" your entire system with a mere command punched into your terminal. Any and all changes made would be reverted with very little delay / effort. ZFS would be your best bet and you could refer to this amazing Ars article to see if it might be something worth it for you (there are many many many other great features too):

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

Answer 4

Depending on what you mean by "updates", you may be interested in configuration management tools like etckeeper, which permit you to record changes to the system configuration automatically, and to revert to earlier configurations.

If Git is a familiar tool, and if by "updates" you mean "updates to system configuration" as opposed to "updates to system packages" or "updates to all files stored on the server" then this may be what you're looking for.

• etckeeper website and github
• Ubuntu intro to etckeeper

It's worth considering that whether you're using tools like Puppet, Ansible, Etckeeper etc, it's not always possible to "roll back" cleanly without loss of data, unless you go the whole hog (eg snapshotting, as mentioned in another answer). The right approach will depend on your situation (eg snapshotting would not be appropriate for a production system where you might lose customer orders when rolling back).

Answer 5

I have used OpenVMS in the past, it comes by default with a versioning file system.

If tools like puppet do not go far enough maybe a versioning file systems is what you are looking for.

Answer 6

If you really want to manage your whole system (including kernel version) like git, you're looking for NixOS.

For a less-involved version you can use NixOS's package manager, nix, from almost any unix. Nix can be installed as a simple user, though it is easier to install it as root. Once nix is installed, you can use it to install packages as a non-privileged user, and it runs fine alongside your existing package manager, with no conflicts. It is also very easy to completely remove nix from your system, so there's really no excuse not to try it out. ;-)

To directly address your question, Nix defines your complete installed system as an environment, which is, much like a git commit, a pointer to a set of pointers to very specific versions of all of the installed packages.

When Nix upgrades a package, it creates a new environment, which points to a new set of pointers to packages (mostly to existing ones, for packages which have not been updated; again, this is very similar to a new git commit, which mostly points to previous unchanged files and a few new versions of modified files).

It is, of course, trivial to switch to a previous version of the environment and, I believe, fork (i.e. create a new environment based on an older-than-last one). An environment can be loaded for a specific shell (it is, in fact, the set of environment variables available to a shell, hence the name), so you can also quite easily have different environments for different projects on the same machine. No more dependency problems because an unrelated project needs another version of a library!

NixOS takes that to the next level and manages your whole computer, including the kernel, in a similar fashion, allowing for very low risk upgrades of the whole machine.

I haven't finished reading all of them, but I recommend lethalman's Nix pills as an introduction to Nix.

Answer 7

If you're the experimental type, you might try just checking in your entire file system into a local git repository. This would be... interesting, I think.

1. git init in the root directory /
2. Construct a .gitignore for the root that ignores directories whose contents change often or shouldn't be checked in:
   • /dev
   • /run
   • /tmp
   • /proc
   • /lost+found
   • ...
3. Add to the .gitignore specific file types you might wish to exclude:
   • *.tmp
   • *.log
   • ...
4. Add your initial contents with git add -A .
5. Commit the snapshot with git commit -m "Initial Snapshot"
6. Use your computer
7. Periodically add snapshots git commit -Am "Snapshot X" or similar

Some benefits would be:

• Familiar tools for revision history, like gitk and git diff
• Any livecd or other operating system with git could restore your backups
• You could push your entire system up to github and restore it to other machines or share it with people... ?
• Branching would be fast and intuitive
• /,git directory in your root would inspire the confidence to abuse your system and be more adventurous, similar to source code
• Each subsequent snapshot would be relatively small compared to some other backup solutions
• Would be awesome for reviewing and tracking configuration changes in /etc
• You could pioneer this and call it linit - linux in git.
• Infamy

Some oddities might include:

• Unlikely that you could restore/checkout branches or revisions with significant changes, or changes to the files that are in use while running the system - perhaps have a minimal boot USB with git for this purpose
• Rather large initial commits
• Checked in subsequent .git directories - ?
• git hopefully working as expected when you're in a source code directory nested in the root git container.
• /etc/passwd and /etc/shadow would need to be included in the repository to maintain and track users and restore them to other machines, but now anyone with view access (perhaps on github) can see sensitive information like the contents, permissions, and password hashes of your users.