Configuration management

Terry Lambert · *nix forums Guru Joined: 19 Mar 2002 Posts: 434

Mike Makonnen wrote:

Hiroharu Tamaru · *nix forums beginner Joined: 19 Jun 2002 Posts: 2

Hi,

At Wed, 19 Jun 2002 03:15:33 -0700,
Mike Makonnen wrote:

Sheldon Hearn · *nix forums beginner Joined: 03 May 2002 Posts: 34

On Wed, 19 Jun 2002 03:15:33 MST, Mike Makonnen wrote:

Mike Makonnen · *nix forums beginner Joined: 17 Jun 2002 Posts: 29

Hello,

From time to time, I've seen threads on various mailing-lists about
creating a gui tool for configuring the system (basically /etc/rc.conf).
The assumption is that providing some sort of point-and-click interface
will make it easier to configure FreeBSD. The problem with this, among
other things, is that it requires developer buy-in because the configuration
tool has to be updated everytime a new knob is added, which makes it more
tedious and error prone for the developer.

I am of a different opinion. I happen to like plain-text configuration files.
The problem is not that we need an easier way to _edit_ the files,
but rather we need a better way to manage all those files and the changes
we make to them. For example, I have a haphazard collection of rcs files
for files I have edited in /etc. Most times I do co/ci when I edit them
but sometimes I'm in a hurry and I don't bother or I just plain forget. Not all
the files are in rcs. I don't have a standard tagging scheme. I also don't
generally tag them all before or after a mergemaster. However, I believe these
things should be done for all my files on a consistent basis, but I'm
generally too lazy and don't bother Sad

so an automated system that did
all these things for me would be nice. I also have a love-hate
relationship with mergemaster (no offense, Doug Cool

and would
much rather have a completely automated way of updating
my configuration files after an installworld that would easily allow
me to back out a certain change if it b0rked my system.

To address this, I would like to develop a set of scripts, for inclusion in
the base system, that manage the files in /etc as a set of rcs files.
It would not introduce any changes to the files themselves, but it would
allow the creation of a separate repository to handle versioning and
a set of wrapper scripts for editing and updating the actual configuration
files. For example, an admin would be able to do the following things:
- create a configuration repository from the files in /etc (or any other
directory, for that matter)
- add a file to the repository
- add a pre-existing rcs file to the repository
- edit the file through a wrapper script that checks out
the file from the configuration repo, starts
and editor, and checks-in the modified version before
saving it to etc.
- tag the current versions of files in /etc
- revert all/some of the files to a previous revision/tag

I would also like to then add optional support for this in mergemaster so that
it can do something like:
- notice that the repository does not contain the latest version of a
file in /etc
- update the repository
- tag the current version of the files in use in etc with a pre-mm<date>
tag
- update /etc as usual
- add any new files to the repository

This way if you screwed up the mergemaster you could get back the
same exact files you had before the update and retry. An additional
benefit is that when you backup your machine you will have a complete
history of all changes made, all apropriately tagged, by you by the FreeBSD
project.

In short, I want to make it easier for people to manage their FreeBSD system
by automating those tasks that a good sysadmin should do, but that most of
us don't have the time or discipline to do, without in any way impacting those
who already have a configuration versioning scheme that works for them and
without moving away from text configuration files.

Comments?

Cheers,
Mike Makonnen

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message

Google