CODEWITHSUNDEEP
gitversion-control
tooshel
tooshel

Reputation: 1564

Is it a good idea to store config files in a git repo that is at the root of the file system?

My sysadmin put a git repo at the root of the file system to store config files. That means I can be anywhere in the file system and add to THAT repository. It means "git status" doesn't tell me there is no repo if none exists for my project because the root one is always there.

This seems dangerous to me. Am I wrong?

To me, having a git repo is an implied contract that everything within this directory is in source control (except for object files and the like that are ignored thanks to .gitignore). Is this old school source control thinking?

Upvotes: 0

Views: 1062

Answers (2)

larsks
larsks

Reputation: 311605

This seems dangerous to me. Am I wrong?

I would argue that it is confusing, rather than dangerous. We've tried something like this where I work and ultimately abandoned it for exactly the reasons you describe. Our solution was to move most of our configuration into Puppet, so we're applying version control to the configuration management system and generally not making changes directly to systems.

One option your sysadmin has is to put the .git directory somewhere else, and then set the GIT_DIR environment variable appropriately when she needs to interact with the repository. E.g:

GIT_DIR=/etc/sysrepo.git git add /etc/someconfig.conf

This works around the problems associated with placing the .git directory in the filesystem root.

Update: 12 years later I would advocate even more strongly for the use of a configuration management tool for the purposes described in the question, rather than managing the files "in place".

Upvotes: 7

scphantm
scphantm

Reputation: 4543

Im of the school of run the least amount of software as necessary on the server. Running git to manage changes to configuration is not a bad idea, but having the repo sitting on the root of the server is potentially dangerous in terms of hard drive space. Imagine what accidently adding a 5gb database file to the repo and doing a few commits of config files without reading the screen will do to your hard drive space.

The safer route and one I'm currently implementing is find a central location and create a repo there. Create a subfolder for each server and a shell script that can scp the /etc and any other files to and from the server to that folder. Then track them with git from there.

Ive implemented this in a few locations and it worked well. You have the obvious security issues to work out, but they are not impossible to overcome.

Upvotes: 1

Related Questions