On Sat, 07 Jun 2003 15:13:11 +0200, Luca Berra wrote:
> I would personally like a single framework for configuration, but all
> frameworks i found in 13 years working on unix systems do suck far
> more than vi.

The reason they all suck worse than vi is because they all aim far too
low.  They all aim to simply replace vi with a click'n'drool gui.  Look at
Webmin for example.  It is pretty rich in the number of packages that it
will configure, but the problem is that you still have to know what each
of the packages' config options do.

Some modules in Webmin do a pretty good job of linking a clickable help
paragraph with each configurable item (Postfix is a great example), but
you still have to sift through all of the items, understand them and then
configure the right ones as per your intended functionality.

If you are proficient at understanding how to configure Postfix (for
example) to the level that you need to be to use Webmin, you likely are a
sysadmin anyway and prefer the speed of vi.

Webmin does nothing to ease the configuration of Postfix, or most of any
of the other packages it supports.  This is where a new configuration
framework should aim higher.

The focus of a newly designed configuration system should be about
configuring "services" not packages.  Frequently it takes many packages to
provide a "service".  Let's use e-mail for example.  The packages involved
(at a minimum) are an MTA, and authentication/authorization system and
(possibly) a message store.

So in a newly designed framework, the admin should simply have to
configure an e-mail account, giving the particulars of the account, which
then updates the authentication/authorization (/etc/password, or LDAP, or
some SQL system, etc.), creates the message store for the account,
initializes any system files, etc.

This could be coupled with creating login accounts, or it could be
stand-alone in the case of a "sealed-server" situation (i.e. mail accounts
!= login accounts).

> I never asked for another web frontend,

The actual gui part (front-end) should be built with interfaces to the
configuration backend through an API, akin to the way DrakX works with
GTK/newt/(minimally, http/html)

> i am just stating that their
> existance is caused by repeated failures of creating a decent framework,
> or agreing on the need of one, we have tons of linux distros each with
> it's own config framework, plus a good number of non distro related
> tools.

Right.  And none of them are "service-centric", but rather each tool is
built to administer one "package".

> M$ did not have this problem, and did not even have to deal with 100+
> different configuration syntaxes, and 10+ different gui frameworks,
> hence the better result.

No, the better result is solely to do with building the tools with the
right goal -- configuring complete services, not individual tools for each
component of a service.

Libconf _could_ achieve this if it keeps the goal in mind.  From what
little documentation I have found about it (is there anything more than
what's in the wiki?), it could be on the right track, creating
abstraction layers.

The key will be to keep the goal of configuring "services" in sight.  To
continue on the example of e-mail, the sysadmin should be able to choose
which MTA he wants to use as well as which message store he wants to use,
as well as which authentication/authorization mechanism.  Each component
of a service should have a common API and each type of each component will
need to write interfaces to that API.

So for example, when the "e-mail" service is designed, an API for the MTA
component could include _standard_ interfaces to specify "who-can-relay"
permissions, message store hand-off specifications, "local delivery"
domains, etc.  Each type of each component (Postfix, Sendmail, Qmail MTAs
for example) would need to have a module that implemented the API as per
it's own configuration files.

To complete the example, the API would include interfaces to configure the
message store of choice, to create/change/delete accounts/folders, etc
(some of which could be NOOPs if there was nothing additional that needed
to be done).

I could go on, but I think you get the idea.



Reply via email to