Re: Propersel for standerd configuration system.
After writing this I realized that I did not give any good reason for
while it is needed so here it is.
The Standard Configuration System solves the problem of the difficulty
in managing unix (and especially linux) machines forever.
Although there are many front end for configuring various parts of the
linux system they rarely control all of the little features of a
program. And in some cases they make it even more difficult to use
features not support by the front end.
The Standard Configuration System (SCS) doesn't have this problem
because it will control every aspect of the configuration. Unlike front
ends which are often time consuming to write all the SCS requires is the
a template file describe what is valid and for older programs a
translation utility that will convert it to and from the old fashion
configuration file. In most cases this utility can very easily be
written with a simple perl script. (Some more tricky configurations like
bind will take a little more doing, However.)
However the SCS will (eventually) also support a basic language for
describing a front-end for configuring a particular subcatagory (see
below) there for also having the ease of use of a graphical front end.
(However I hope to design the SCS in a such a way that a front end will
rarely be needed).
Kevin Atkinson wrote:
>
> Although this is really a broader issue than just linux or debian
> I thought I would present it to you guys and girls first.
>
> One of the major problems with unix is that, for new users,
> it is a bear to configure.
>
> I was thinking about this this afternoon an an idea struck me
> on a great way to solve this problem: A standard confutation system.
> Part of the problem with this is that every program has their own
> format for the configuration files. This idea would solve that
> problem for ever.
>
> It would consist of these parts:
>
> - A server back end which would manage the master and users
> registry of configuration
> - A server/watchdog that will manage the translation of the
> registry to the old fashion configuration files. It will
> also watch the configuration files for changes and update the
> registry appropriately
> - An easy to use API in C, C++, Perl, Java, Sh, and just about
> another other language that a unix program or script can be
> written in.
> - A command line based front end to manage the registry
> - A ncurses based front end to manage the registry
> - A X based front end to manage the registry
>
> The actual data will be store in a binary format that is specific
> to the server. However the server will be able to export and import
> configurations in a standard text based format.
>
> The layout of the registry will be similar to Microsoft's windows
> registry however it will be far more powerful.
>
> Configurations will be stored with key/value pairs which will then
> be stored under a sub category which will be stored under another
> sub category etc....
>
> There will also be a template data file which will contain information
> about how the configuration should look like such as: what keys are
> valid
> under a subcategory, what subcategories are under a certain
> subcategory,
> and what format the key's value should look like.
>
> The template data will also contain a detailed description of what
> exactly a
> certain subcatagory is and what each of the key/value pairs under it do.
> It will also contain information that will warn the user if he/she is
> modifying something which should really be modified by some other
> utility.
>
> Also, the template data file will contain event information. These
> events
> will tell the server what else it has to doing the event that data was
> modified. Events can include information such as:
> - restarted a demean
> - updating the old fashion configuration file
> - running a program to modify system resources based on the new
> configuration (such as mounted drives, etc.)
>
> So what do you think of this idea?
>
> If people think it is worthwhile of pursing I will work on a formal
> draft
> standard which will lay things out in more detail than this.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: