31

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?

Community
  • 1
Abhishek Divekar
  • 724
  • 1
  • 7
  • 17

5 Answers5

43

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.

Ravexina
  • 57,426
  • 8
    Very interesting, I didn't actually know you could do this in git! Thanks for the suggestion. – Abhishek Divekar May 19 '17 at 19:33
  • 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. – Daniel Jour May 21 '17 at 12:25
  • this command doesn't work for me (ubuntu 22.04), when i run it git just list its commands and flags, just like in "git help" – N. Joppi Aug 20 '22 at 21:08
  • Does it matter what the working directory is when you issue this? eg / versus /home/user/backup-root? – Tomachi Jun 09 '24 at 09:39
19

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.

Basile Starynkevitch
  • 672
  • 1
  • 4
  • 16
6

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.

gdahlm
  • 469
  • 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. – Abhishek Divekar May 19 '17 at 19:55
  • 2
    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... – George Udosen May 19 '17 at 20:17
  • Ah I see. I think I should just keep it in a separate folder then. Or / – Abhishek Divekar May 19 '17 at 20:19
  • @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 – cat May 20 '17 at 18:42
  • @cat I didn't know that, so how will one call the git at the top then? – George Udosen May 20 '17 at 18:57
  • 1
    @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) – cat May 20 '17 at 19:21
  • 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.

     – gdahlm May 20 '17 at 19:26
  • @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? – Abhishek Divekar May 20 '17 at 19:49
  • 2
    @abhidivekar Correct, it is not a problem if the benefits outweigh the problems but it is unexpected behavior.

    Not a blocker, just a caveat.

     – gdahlm May 20 '17 at 21:06
5

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.

Community
  • 1
Abhishek Divekar
  • 724
  • 1
  • 7
  • 17
3

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.

yt7b97q-
  • 31