Being annoyed by YAST munging the system configuration all the time, i came up with an idea:

Anyone of you tried to put the whole /etc directory (including sysconfig) under version control, with for example CVS?


That would be golden to solve issues where automatic configurations due to openSUSE YAST or updates or whatever doing its best to overwrite the wanted system configuration with something disfunctional and potentially disastrous.

If there is a diff in any file in /etc to the known working state stored in the repository, then it is rather easy to get things back to working (safe) state again.

Are there any pitfalls when doing this?

Well, no, but...

When updates are released that affect configuration files in /etc/, it's usually a good idea to, you know, actually look at them and see what's different (and might be important).

If you put /etc into CVS, yes, that'll work -- you can merge new with old and so on and keep track of changes. Another option (which is what I do) is I simply copy /etc to a directory on a partition that does not get fiddled with during installation or update; e.g.,
(/spares is a mounted partition). Pretty easy to diff that way.

Pretty much works for me.

Hope this helps some.

Yes, it is important that security patches and newer syntax also comes through in the config files.

But looking at openSUSE12... most of the changes to config files by updates are munging the files so the services break. A perfectly good example is the recent updating of bind. The "needed security updates" garbled up the syntax of named.conf as well as threw out my local forwarders along with some local lan domains, while making a frantic syntactical leap on the rest of the local domain declarations in effect making them to be master on all slaves nodes, while being almost not human readable. There should be a drivers license to be allowed to put out mandatory update patches.

That's how i've been doing it too.

Wether it's "cp -pR" or "rsync -av", keeping an offline copy of the config has become more and more essential.

I guess the basic idea with openSUSE Yast was to have a means to manage this in a controlled manner. But looking at how Yast works today, it is more of a problem than a helper. (Oops. Flamebait! Sorry).


Going back a couple of years with linux it was enough to have a look through in /etc for changes. If there where changes, then the replaced config lines where commented out in the config file, and the syntax/ordering was mostly intact. So a simple "ls -ltrasF /etc" show what was changed, and then look through those files with an editor and merge old/new settings. Done.

Today one can find several variants of the changed config files with file endings like .netconfig .YaST-backup .YaST2.save .YaST2save ... and i'll bet you that some or all of the previous configs are garbled or completely gone from the modified files. Reckless patching should give jailtime.

Worth to mention is that some configuration is also happening in the /proc directory.
And maybe we should also mention /sys which has become more and more important to keep an eye on.
There's lots of tweekabilities in the /sys directory tree to keep an eye on.

Maybe a revision control system approach can give back some order in the config mayhem?
Say i have /etc in CVS repository and then du an update. It is easy to see what is changed and how. Then one can do the config merge, and after that commit the changes tagged by the updates.

It is also possible to have a large number of computers running the same linux distribution in different branches and that could make it easier to maintain since the common changes with the update patch can be merged between the branches, while maintaining the individualities of the different systems.
To set up a new system one can install/update the linux and thenafter make a new config branch from a similar system setup.


I don't think having a CVS directory in each directory under /etc would be a problem. Or will there be issues in some cases?
I'm quite tempted to try it.

But i guess attempts to put the configurations done in /proc and /sys in a repository may be quite ludicrus?


But what we really wanted was a homogenous structured system configuration. And update patches that propose system changes, that can be commited after review, rather than just munging it out on a live system.

---
Here follows some offtopic ranting about keeping things together and sticking to the original UNIX idea of backward compatibility and controlled evolution:

"Once upon a time" there was the well comprehencible unix/linux system where things could be split up in partition so that usr could be mounted readonly, all config was in a small etc catalog which could be easily maintained. One could simply clone the system by editing a few files in etc.

The linux of today is a totally mental buzzcloud of systemd services, lib/lib64, local libs, Gtk++++variants, hal's & udev's and /sys variables. Auto this, and fiddle that... Guys! We're loosing it to the tweekers!

I call for better systemisation and quality management for linux.
Take a look at FreeBSD. Quality thinking makes reliable systems. Maybe software audits before releases is not such a bad idea?

One of the (many, many) things I like about Slackware is the way updates are handled.

When an update comes along it's in the form of a package that is installed with a utility upgradepkg, if there is a configuration file in /etc, the old file is not overwritten -- the new version is written to file.new; e.g., /etc/php-fpm.conf.new. You simply diff the old and new and see what you need to edit (if anything other than, say, the version number or date-stamp). Saves a lot of time and trouble, that. The control that gives me is worth the price of two minutes diffing.

But I still make a complete copy of /etc before I do a new Slackware version install (like from 13.37 to 14.0); also saves a lot of time and trouble.

I'm revitalising this thread with an idea i came up with:

Wouldn't it be nice to have a tool in Linux that handled changes in configuration with something like an egrep approach with a file change history, (some RCS, cvs...).

That way the sysadmin could do the updates, and then verify every change with an egrep view comparing to previous settings.
It could also be boosted by help text/links for certain changes. And having a RCS history makes it easier (and safer) to revert updates that did not work as expected.

Don't know if there is such a system anywhere. Updates, (wether it is Windows, Linux or any other), comes installed with a mumble of comment about what the update is for, and to often rather drastic changes happen without sysadmin having the ability to opt out of modify the change.

Does anyone know of some existing system configuration tool like the above today?