Best way to keep config files under SVN ?

Question

What is the best way to keep your configuration files (e.g httpd.conf, my.cnf, .bashrc ...) under version control? In adition to the versioning benefit, I want the solution to work as backup as well, so that I can bring a brand new server and checkout (or export) the config files out of SVN directly

A good touch will be to store the config file`s original path as well.

Answer 1

I do this for several machines, ranging from old Solaris 8 boxes to Mac OS X, and I have a really simple layout:

In my repository I have the following:

<root>/common
  /.emacs.d
  /.bash_common
  /scripts # platform-independent binary tools

<root>/linux
  .bashrc
  .emacs
  ...

<root>/solaris
  .bashrc
  .emacs
  ...

<root>/osx
  .bashrc
  .emacs
  ...

Each of the OS homedirs has an svn:externals reference to .emacs.d, .bash_common, and scripts, so those are not duplicated.

In addition, I have a .bash_hostconfig in the linux and solaris directories with host-specific path configuration and such, because I have a very different setup at work than I do at home (FC5-8 and RHEL3-5, depending on where I am).

So, between these things, I have a pretty simple process for getting up and running on a new machine: I simply check out the /$platform into a temporary directory, and then overwrite everything in $HOME with those files. I don't need to store the original path, because it's always relative to $HOME this way.

Answer 2

I revision-control my configuration files, but I use git instead of svn (which is easier when you have multiple machines). I have a bash script (called install.sh), also under the repository, which either copies or symlinks the files to their appropriate location on a machine.

So if I need to set up on a new machine, I just do a git clone of the repository (which is equivalent to an svn checkout) and run my install.sh to set up my config files in the appropriate locations. Having install.sh around means that I'm also storing the config files' original path, as you indicated you'd like.

Answer 3

We use CVS to store the configs in a directory structure that is as flat as possible. This technique is easily extended to SVN.

Then we have a Makefile set up to use CVS export to:

1. create a copy of the CVS directory structure without the CVS components,
2. create the directory structure required for the target machine in your local directory as if you were in the root directory on the target machine, e.g. ./my_cvs_dir/etc/.. and ./my_cvs_dir/usr/local/newapp/..,
3. copy the files from the CVS structure to the target directory structure,
4. create a tarball for the target directory structure, and
5. deploy the tarball to the target machine.

We also have these tarballs set up in increasing specialisation, e.g. Sol10, Apache, specific app's, etc.

HTH

cheers,

Rob

Answer 4

Well you could store all configuration files under a specific directory tree, one sub-directory per application. Since most applications should have a directive to specify the config path, this is then the only thing to be changed (or if you have hard coded config files, maybe something like include is supported) per server.

And this tree could then be checked into whatever VCS you like.

For deploying you can write a shell script or such a thing which initializes everything to use your config file tree.

Answer 5

This is what I have implemented:

I have a server that does rsync of all the configs into one directory (say /data/configs/hostname/{etc,httpd}.

I have an rsync running every hour to transfer the changes. as soon as rsync is complete, there is an svnautocommit script that does autocommit of the changes. This way, I can roll back to any change or any version I want to.

You might need to plan the SVN directory structure based on your requirements.

Answer 6

As you want a central store anyway, you may go for something slightly more complicated like Slack. You administer and version control the files at a push server, then rsync it to the clients. The explanation of subroles has some examples on how to structure the tree.

Answer 7

working on the same problem. what about the issue of losing configuration file metadata, such as owner and permission info?