Creating a Git repo at / (root) for tracking settings?

Question

So I use Git mostly for development purposes, but I just realized that I could use it for storing versions of the settings files I have on my Ubuntu installation.

My proposed setup is:

• git init a repo at /

• Add a .gitignore at / that ignores any files except specific settings I want to track.

  For example, the .gitignore could contain (source):

  ## Ignore everything...
  *
  
  ## Except...
  !/etc/default/tlp
  !/etc/crontab
  

• Whenever I change these low-level settings, I can track them.

Is there anything that could go wrong with this setup? Does the kernel always need / to only have certain folders? Will it mess up the functioning of any applications?

Solution 1

The answer to both of your questions is no, you can create any directory you want in the /. the only thing that could happen is some permission issues with some spacial paths I guess.

However it's better to store the .git directory somewhere else, something look like:

git --git-dir=/home/user/backup-root --work-tree=/

Read here.

Solution 2

Actually, you probably want to version control configuration files in /etc/ (you don't care about the entries of the root directory /, notably directories like proc or usr or bin in /) so you may want to install the etckeeper package

And you could also version control some selected subdirectories (like /usr/share/applications/ that you mentioned).

However, don't mess with the Ubuntu package management system. Perhaps you mostly should backup the current list of installed packages.

Solution 3

Having a git repo in / works fine, except that it does make it hard to notice when you have a lower level git repo with problems as it will answer for all of them.

Note: It is less work and probably more useful to use 'debsums'

sudo apt-get install debsums

Which will allow you to quickly detect (most) changes in binaries or in configuration files.

As an example from the installed packages here are the ones that differ from the upstream packages.

$ sudo debsums -c
/boot/vmlinuz-4.10.0-19-generic

And you can get a list of changed configuration files with:

$ sudo debsums -ec
debsums: missing file /etc/default/chromium-browser (from chromium-browser package)
 /etc/libvirt/libvirt.conf
 <snip>

Note how the chromium-browser is improperly packaged and and has a file listed in the the package file list that doesn't exist.

/var/lib/dpkg/info/chromium-browser.list

This uses the dpkg data and avoids a large /.git directory and workflow.

Solution 4

So I've been exploring the other answers and I've found a procedure which works for me:

• Make a .gitignore at /. This was much more complicated than I thought it would be, because of the way Git handles whitelisting files in subfolders. I used this and this link to help me.

  ## Source: https://stackoverflow.com/a/29932318/4900327
  ## Comments are on new lines because trailing whitespace matters in Git (stackoverflow.com/a/8865858/4900327)
  
  # Blacklist all files, folders and subfolders in the same directory as the .gitignore file.
  /*
  # Do not blacklist the .gitignore file.
  !.gitignore
  
  # Now whitelist certain files.
  # For files in subfolders, some hoops must be jumped through (stackoverflow.com/a/16318111/4900327):
  
  ## Whitelisting files in /etc/ folder:
  # Whitelist the /etc/ folder (the git repo folder is whitelisted always)
  !/etc/
  # Blacklist all files in /etc/ folder.
  /etc/*
  # Whitelist specific file(s) in /etc/ folder.
  !/etc/crontab
  
  
  ## Whitelisting files in /etc/default/ folder:
  # /etc/ is already whitelisted, and its contents blacklisted.
  # Whitelist /etc/default/ folder.
  !/etc/default/
  # Blacklist all files in /etc/default/ folder.
  /etc/default/*
  # Whitelist specific file(s) in /etc/default/ folder.
  !/etc/default/tlp
  
  
  ## Whitelisting files in /home/USERNAME/ folder:
  # Whitelist /home/ folder.
  !/home/
  # Blacklist all files in /home/ folder.
  /home/*
  # Whitelist /home/USERNAME/ folder.
  !/home/USERNAME/
  # Blacklist all files in /home/USERNAME/ folder.
  /home/USERNAME/*
  # Whitelist specific file(s) in /home/USERNAME/ folder
  !/home/USERNAME/.bash_profile
  !/home/USERNAME/.bashrc
  

• Go to / and run git init . So far, I have been unable to store the .git/ folder in another directory using the link mentioned by @Ravexina.

• Run git add . and git status. You should get a listing of all the settings files Git is tracking.

  If you used the above `.gitignore`, it should track `/etc/crontab`, `/etc/default/tlp`, `/home/USERNAME/.bash_profile`, and `/home/USERNAME/.bashrc`.
  

• Commit with git commit -m "Initial settings files".

• You can track changes with git log -p -- path/to/fileor gitk path/to/file. More discussion on this here.

Solution 5

If you are going to store sensitive stuff (like /etc/shadow) in the git repo, you should make sure it's not readable by all users, since by default the objects will have the permission 444 and directories will have the permission 0755. You can change the permission of .git to 700 or put it in /root

Another problem is that git doesn't store file permissions like the file system, and it doesn't store extended attributes. For files, git only stores whether they are executable. So if you want to restore a deleted file, its owner and group will be root (if you do it as root), and its permission will be 644 or 755. It may be problematic for services' configuration files whose owner is not root.

View more solutions

Comments

[Michael Durrant]

Perhaps you should consider your ~ home directory settings files rather than / files

[Joshua]

The old grex SunOS public server had all of its rc files and who knows what else in some old source control (not sure if it was SCCS or RCS, but definitely older than CVS). I don't see a problem with this.

[Abhishek Divekar]

@Mike Durrant: stuff like /etc/crontab on my personal laptop is definitely mine, but I see what you mean.

[Martin Schröder]

Use etckeeper and make backups.

[quetzalcoatl]

Just be careful to not accidentally to stage/commit i.e. /dev/sda or similar :D

[Abhishek Divekar]

@quetzalcoatl If you see my answer below, I've taken great trouble to prevent exactly that :)

[Michael Burr]

I use a "dotfiles" repository placed wherever (I use ~/dotfiles) then either 'include' or create links to those config files in the repo's workspace.

[Academiphile]

Slack for lazy sysadmins is a great tool for this as well: github.com/jeviolle/slack

[Abhishek Divekar]

Very interesting, I didn't actually know you could do this in git! Thanks for the suggestion.

[Abhishek Divekar]

Could you explain "except that it does make it hard to notice when you have a lower level git repo with problems as it will answer for all of them." a bit more? I'm not understanding how it could cause a problem if the .gitignore only tracks a few files.

[George Udosen]

I believe @abhidivekar OP is saying when you create another git repo in say /home/$USER then the .git in / will answer for any git command given for the repo in /home$USER rather than for that [.gir file ] in /home/$USER...

[Abhishek Divekar]

Ah I see. I think I should just keep it in a separate folder then. Or /

[Abhishek Divekar]

I actually do care about files in /usr/share/applications as I occasionally mess around with them.

[cat]

@George But that's not even correct -- git always looks at the bottommost git directory it can find, so you can have git directories in git directories

[George Udosen]

@cat I didn't know that, so how will one call the git at the top then?

[cat]

@George To access the .git directory higher in the tree, you just cd to it, or a subdirectory of it which does not have a .git folder (a normal directory that is)

[gdahlm]

The main problem I was talking about was mkdir new_project; cd new_project; vim file; git commit git will walk up .. until it finds a repo or the end or the tree. I was using the git method a few years back and we would always end up with random files in the config repo.

[Abhishek Divekar]

@gdahlm So you're saying that trying to git commit on a non-git-repo directory should fail, but doesn't, because there's a git repo at the root?

[gdahlm]

@abhidivekar Correct, it is not a problem if the benefits outweigh the problems but it is unexpected behavior. Not a blocker, just a caveat.

[Daniel Jour]

That's the same feature which lets you track only setting files under /home/user btw. Adding an shell alias additionally makes this very convenient.