I am currently looking for a more powerful solution to backup system configuration files. Currently I am rsyncing the most relevant directories such as /etc and others through a cronjob on a regular basis. This is fine for mere backup requirements and covers the recovery scenario well.

However, it is not so convenient if you do frequent reinstalls or play around with different distros. Certainly you can use these backups as a source for inspiration and copy-paste most of the configuration files, but it stays a somewhat manual process to apply the backup to a new install.

So what I am looking for is a somewhat more declarative state of the current configuration, which at the same time is restricted to the files I actually modified myself with respect to their default state. By declarative I mean that it should not be a patch type of solution that replays diffs on a given initial state. It should be something that I can use to reach the desired target state irrespective of what the original state was.

At the same time it should not create too much additional overhead while actually modifying the current config.

The first idea was to create a git repo of the rootfs and track everything relevant
Problems:
- Lots of noise due to irrelevant files, or need to gitignore a lot of stuff
- Need to actively commit changes and sometimes add previously untracked files
- Need to maintain a git server => additional overhead

My current train of thought is a self-built solution (probably a script) that is a wrapper to vim along the following lines:
Whenever I use it to modify a file it would first call vim and let me do the modifications. When I am done it will place a copy of the new file at a dedicated isolated location in my system (which in turn gets backed up through the standard way).
I could probably build in some conflict resolution checks, like when the config file I am about to edit has diverged from the copy since the last time because some package maintainer rolled out a new config or similar.

The advantage would be a clean backup directory with only the files I am actually interested in. I'd probably also want to save their respective original state so that when applying the config to a new system, the following logic could apply:
- System default file looks like .orig file in my backup? => roll out my version of the config. Otherwise enforce conflict resolution through user interaction.

Now before I start putting something together I'd be interested to hear your thoughts on the above, especially with respect to the following questions:
1) Are you aware of better approaches to address the issue?
2) Does anything like the proposed solution exist already?
3) Any opinions on the proposed approach?

I can tell you what I do, which is both a kludge, but effective.

Take a file like /etc/samba/smb.conf for example. I created a directory in /usr/local, called (amazingly enough), /usr/local/config. I will move the file to that directory, and create a symlink to the 'real' location. So banging in "vi /etc/samba/smb.conf" will pull up that file, and let me edit it. Same with any OTHER configs/system files I change...symlinks all around. I also have a shell script in that directory, which I modify as I go, which re-does the configs after a reload...nothing but removing the existing file, and creating the symlink.

That way, as long as I have the /usr/local/configs directory backed up, I can re-do my service configurations in seconds. Yes, it's clunky, but effective. Also, if you're working with other admins, they don't have to know/do anything special to edit a config. The symlink does the heavy lifting. I experimented with creating an RPM of my configs, but that was a HUGE pain, for very little return.

1 members found this post helpful.

Hi TBOne, thanks a lot for your reply. In fact in the meanwhile I have put something together which pretty much already does what I want, but your way sounds like a very smart solution that could be a useful source for inspiration. Can you expand a bit on
Would you mind posting the script? I am assuming that over time you have accumulated a couple of tweaks that handle problematic situations, and it would be interesting to see those.

Do you actually recreate the whole directory structure in /usr/local/config? I.e. would your samba config sit in /usr/local/config/etc/samba/smb.conf or /usr/local/config/smb.conf?

How much trouble do you have with system updates removing your symlinks and replacing them with the config file version the package/distro maintainers thought where right for you?

The 'script' is actually trivial. All it consists of is something along the lines of:
Repeat for each file you put in there. The hard part is being diligent about putting things in there after you make changes. I've not had anything be problematic thus far, and the things I have had issue with were simple permissions issues/ownership issues. The restores will sometimes write those files back as root, and some services squawk about it. Nothing that's not fixed with a chown and restart.
I will typically build out the /usr/local/configs/samba directory, and put the files/directories FROM /etc/samba in it, but that's just preferences. This way, each service I have modified a config for, is in something intuitive, at least for me. Your mileage may vary.
None, really, because all it does is over-write the symlink with a 'real' file, or move it to a .bak/rpmnew filename. My original is safe in /usr/local/configs. So, a quick re-link puts it back like it was. If it DOES overwrite my file by following the symlink, it's nothing to restore that directory from backup...small text files, come back in seconds.

1 members found this post helpful.

Thanks a lot for these clarifications.
Ok I see, I thought you had built more automation into that whole process but I guess it's good to be forced to do some manual review, too.

Will have to think this through a bit, but as I said before, now that I have already written something which seems to work I guess I'll stick with that for the time being. But if it turns out to be unsatisfying I'll give your idea a try, too, so thanks again!