From owner-freebsd-arch Wed Jun 19 3:10:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by hub.freebsd.org (Postfix) with ESMTP id D399237B407 for ; Wed, 19 Jun 2002 03:10:16 -0700 (PDT) Received: from kokeb.ambesa.net ([64.166.84.56]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GXY00JV96X48Q@mta6.snfc21.pbi.net> for freebsd-arch@freebsd.org; Wed, 19 Jun 2002 03:10:16 -0700 (PDT) Received: from kokeb.ambesa.net (tanstaafl@localhost [127.0.0.1]) by kokeb.ambesa.net (8.12.3/8.12.3) with ESMTP id g5JAFXeU013621 for ; Wed, 19 Jun 2002 03:15:33 -0700 (PDT envelope-from mikem@kokeb.ambesa.net) Received: (from mikem@localhost) by kokeb.ambesa.net (8.12.3/8.12.3/Submit) id g5JAFXt8013620; Wed, 19 Jun 2002 03:15:33 -0700 (PDT envelope-from mikem) Date: Wed, 19 Jun 2002 03:15:33 -0700 From: Mike Makonnen Subject: Configuration management To: freebsd-arch@freebsd.org Message-id: <20020619031533.2c302e68.makonnen@pacbell.net> MIME-version: 1.0 X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; i386--freebsd5.0) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 :-( 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 8-) 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 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