Recommendations for config file revision control

[Maxim Khitrov]

On 6/2/07, Thierry Lacoste <lacoste at miage.univ-paris12.fr> wrote:
> > I did just think of another thing I could do. What if I create a new
> > directory on the server, and move all configuration files from their
> > original location to this directory. I then make then make it into an
> > svn working directory, and in place of the original files put symlinks
> > that point to the corresponding file in the working directory. This
> > would mean that I no longer have .svn directories all over the file
> > system, there is just one working directory that is separate from
> > everything else. Instead of an export operation I could have the hook
> > script do an update, and this would also give me a rather simple way
> > of editing the files locally on the server (plus it has the advantage
> > of quick access to all important files without having to constantly
> > move from /etc to /usr/local/etc).
> >
> > Does this seem like a decent idea to try and do? Might some software
> > have a problem with its configuration file being a symlink to some
> > other location?
> Sorry for my previous top-posting.
> Will a chrooted named work if you make files in /var/named/etc/namedb/
> symlinks to the working directory ?
>
> Regards,
> Thierry.

I'm not sure I understand your question. A symlink will work if you
can get to the target inside the chrooted environment. You can't
symlink to a file that's outside of the root.

Here's an update on what I ended up going with. I decided to go with
my idea of moving all configuration files to a common directory, but
with a bit of a change. I created /config and under it base/ and
user/. Everything in base/ comes from /etc and /boot, and the rest
goes under user/. I didn't want to mix the two. So then I created a
new subversion repository, but I set permissions such that only root
can read or write to it. Basically I decided to forbid anyone on the
outside from getting their hands on the repository contents, since it
will be storing things like master.passwd and other sensitive data.

Once all this was in place I moved all configuration files to their
appropriate locations in /config and created symlinks in their
original location. Everything under /config was then imported into the
subversion repository using the file:// method. Since I forbid anyone
from doing a check-out of the repository to some external location, I
don't need to worry about file updates except when they are updated in
/config. This simplifies things. What I did to keep the repository up
to date was create a simple sh script that is run by cron every 10
minutes. The script simply issues 'svn ci --non-interactive --message
"Automatic commit"' command in the /config directory. So any changes
made to the configuration files are automatically recorded every 10
minutes.

This works well, but does have a few flaws. First of all, when I edit
files from sftp I have no way to add a meaningful message to the
commit. Not a big deal, and I can always do a manual commit if I had
to. The other thing is that this script will not auto-add files to the
repository. Any new configuration file that I'd like to have monitored
first gets moved to /config, then has a link created in the original
place, then is added to the repository via 'svn add'. A bit more work,
but I think it's fine. Technically I can automate the process of
adding and removing files from the repository by using svn status
output, but at this point the extra work isn't worth it. The bigger
problem is the fact that subversion does not store owner and
permission settings. That means that if I ever want to delete the
/config directory and recreate it, I lose all permissions on things
like master.passwd. What I did was add chown and chmod commands to the
monitor script for all files that had non-standard permissions. So
those get run along with the svn ci command every 10 minutes. The
alternative was to use subversion properties, have the script parse
those and apply the appropriate settings. However, since the
permissions have to be set manually anyway there is no advantage to
this over the monitor script, which is also versioned.

So that's my solution to this problem, for anyone else who is
interested. I took a look at all the recommended version control
systems, including the list on wikipedia. A few looked interesting,
but I decided against them for one reason or another. I think this
subversion solution is a good compromise, but I'm always open to
better ideas if you have any.

- Max