[Libconf-dev] Generic services API

[Brian J. Murrell]

I sent a message buried deep in a thread on the Mandrake Cooker list
about a "services" management tool/API.  I want to echo that here, as
this is something that should fall under the Libconf project.

The reason (IMHO) that every Linux/UNIX GUI config tool so far has
failed is because they all stop at addressing single packages of
software.  The comparison in the thread was to Windows' system
configuration tools and why they are so much more used/useful and
UNIX/Linux tools are so useless.

I used Webmin as my example of a UNIX/Linux configuration tool (it's
just one of many of it's breed).  I chose Webmin as my example because
it addresses _a_lot_ of software out there that one might run on one's
systems.  However it only addresses them at the individual package
level.  At that level, Webmin is no better than a click'n'drool
interface to "vi foo.conf".

In order to be able to use Webmin to configure (for example) Postfix,
you still need to understand the plethora of configuration options for
Postfix, and understand how Postfix works.  This is what holds
UNIX/Linux back when compared to the (apparent) ease of administering a
Linux/UNIX system. 

What I think needs to be done to deal with this situation is to provide
tools to configure "services" rather than software packages.  To achieve
this we need to define a common configuration API for the components of
a given service.  Each software package that can be used as a component
of a service then needs to have a module which implements the API.

Let's use an e-mail service as an example.  What exactly is an e-mail
service?  At a minimum it's an MTA, AAA (authentication, authorization
and access) and a message store.  Beyond that it can be virus scanning,
spam control and so on.

For the MTA component, one could use Sendmail, Postfix, Exim, or one of
many others.  For AAA, one could use PAM, LDAP, NIS or one of many
others.  For a message store, one could use the Cyrus IMAP server,
Courier server, UW imap server, etc.

But in terms of a configuration tool, it should not matter what package
is used to provide the component function as long as an API module has
been written to configure the component.

So to continue the example of an e-mail server, the front-end
configuration tools call API functions such as
"allow_relay(relay_specifications)", "local_domain(domains)", etc. to
configure the MTA, and the package-specific MTA module hooks into these
API calls and does it's specific configuration.

To continue the example in terms of the message store, perhaps for each
added mail account, the message store needs to create the mailboxes for
the account.  There should be a hookable API call for adding mail
accounts.  Some message stores may only need to NOOP those calls because
they don't have any preparation steps needed to store mail for an
account.

Of course, the AAA component of choice would also need to hook into the
add_account() API call to create the account, set the password, etc.

But the goal should be a complete "service" configuration interface for
the user, not 3 different interfaces each needing overlapping
information, and each different depending on which implementation of the
component is used.

Thots?

b.

-- 
Brian J. Murrell <address@hidden>

signature.asc
Description: This is a digitally signed message part