14

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?

1
  • As a Linux/Unix systems administrator who deals with the deeper aspects of how Linux/Unix systems work, I cannot imagine what kind of changes one would need to make to their system to require a Git-like revision system. The main thing that gets changes on these systems are software installs and config files. Config files are easy to manually backup and keep track of. And it falls into a “set it and forget it” mindset. – Giacomo1968 Jan 30 '15 at 20:54
12

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.

0
12

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.

6
  • I already used puppet in vagrant, but I don't remember ever being able to undo some messy thing I did in my OS... – Patrick Villela Jan 13 '15 at 21:44
  • 4
    Configuration management tools generally do not provide "rollback" functionality. The "rollback" is blowing away the system and using the configuration management tool to reconfigure the system. For example, you might use a bare metal provisioning tool like Razor to format and reinstall the OS. Then, it hands off to a tool like Chef to apply the configuration. – ctc Jan 14 '15 at 1:38
  • 2
    Is the witch intended? :) – Ruslan Jan 14 '15 at 5:14
  • Is cfengine dead? I remember trying to get something I was happy with to use on my small cluster back when I was the sysadmin. But I never ended up deploying it. – Peter Cordes Jan 14 '15 at 11:17
  • With any of these tools, you get version control by keeping your master config files in git. What you get from them is centralizing and reducing configuration of a whole system to one of a few text files. – Peter Cordes Jan 15 '15 at 8:45
10

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/

2
  • 2
    Another option is btrfs, which BTW has official enterprise support from Ubuntu, SUSE >= 11, Oracle. Although it is still being developed and blahblahblah, it is reliable for everyday desktop usage and performs damn well. – ignis Jan 14 '15 at 11:11
  • 1
    @ignis: I've recently encountered an inconsistent and non-recoverable Btrfs despite a RAID 5 underneath, and heard about two more instances at work. So I wouldn't lightly disregard those warnings about it not being ready for production use. I didn't want to beleive it myself before I encountered it. Might have been due to bad RAM, perhaps, which is one of the reasons why ZFS people strongly advise the use of ECC memory. I guess the same might apply to Btrfs. – MvG Jan 14 '15 at 17:36
6

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.

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).

2

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.

1

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.

0

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.
4
  • 3
    This approach would most likely fail horribly, since git wont be handling permissions properly. Assuming you do all that as root, you'd essentially chown entire file system to root, and that, in turn, will disrupt write operations. For instance, you take a snapshot, restore it, apache log directory owner becomes root (instead of http), apache cant write to directory, fails to start. I know that, because I tried a similar thing, but on a much smaller scale, and even on that, there were problems. – Tuncay Göncüoğlu Jan 14 '15 at 11:43
  • Take a look at Nix, as suggested in another answer ;) – Michael Pankov Jan 14 '15 at 11:48
  • Good to know! I thought it did handle permissions, at least the octet, as my scripts retain the x flag on clone, but I didn't think about file and group ownership – Ehryk Jan 14 '15 at 14:52
  • It does appear that there are additional tools that will retain full permissions and ownerships, if you did require doing so. One such tool is git-cache-meta, and Here's a list – Ehryk Jan 14 '15 at 15:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.