SEUL: Configuration Tool(s)

[Nick Mathewson <nickm@mit.edu>]

[Replies to seul-dev-admin.]

One of the purposes of the seul-dev-admin group is to find a set of
configuration tools suitable for the typical SEUL user, yet powerful
enough for the experienced Linux user.

We have three options in this regard:
   (1) Use someone else's tool.
   (2) Write our own tool.
   (3) Modify someone else's tool.

Our decisions will be relevant to, and affected by, the decisions of
many other groups.  Whatever tool we use must have a suitable UI, so
seul-dev-ui's decisions will be relevant.  If our tools are
lightweight and general enough, they may be relevant to the install
process -- and the install process will certainly be relevant to our
tools.  

If you don't want to know my philosophy about configuration tools, please
skip down past the second bar of ===='s...

========================================
In my opinion, any system we use should have _at least_ the following
properties: 
? (1) It should be intuitive to use.
+ (2) It should log all changes it makes to configuration files,
      and provide the option to undo any changes.
+ (3) It should support internationalization.
+ (4) It should not force the user to destroy comments or formatting 
      in the files it processes.
+ (6) It should be sufficiently multilithic that new modules can
      be added with little knowledge of its internals, and that GUI
      frontends can be written for _at least_ text and X modes.
- (7) Module-writing should be _very easy_ for developers, and not
      (in most cases) require heavy coding.
- (8) It should also be easy for developers to insert new widgets into
      the user interface.  (Color selectors, font selectors, URL
      selectors, preview windows, and so forth.)      
+ (9) The API should be versatile enough to handle even the most baroque
      configuration files, such as sendmail.cf.
+(10) It should, if possible, tell daemons, wm's, &tc to re-read
      their configuration files when the changes are applied.
-(11) It should not require any destabilizing changes in the
      system.  (I.e., it should work well with all existing utilities,
      and require a minimum of changes to the filesystem, start-up
      process, daemons and so forth.)
-(12) It should present clean backend API's for _several_ common
      languages, so that developers can write their backends in C, C++,
      Perl, Tcl, or Python -- or in some high-level, markup-language 
      format.
?(13) It must be capable of being invoked as a stand-alone tool, or
      as a control-panel by an application.

Earlier today, tim.thomson@softhome.net mentioned the Linuxconf
project. The main Linxconf home page is at
          "http://www.solucorp.qc.ca/linuxconf/",
but I'd suggest the mirror at "http://linuxconf2.compiled.com/".

Assuming the publicity on their pages is accurate, Linuxconf does
several things well.  Specifically, it looks as though it has the
proper hooks to handle those requirements marked with "+" above.  I
haven't investigated the source enough yet, but I have my doubts as to
how well it handle the "-"'s:
(--> The following comments are _only_ my impression from skimming the
     Linuxconf documentation, and I have yet to confirm them! <--)
  * It seems to want to be called at bootup, and to replace
    the standard sysv init scripts with something else.
  * Its module format requires C++, and knowledge of several API's.
  * The group seems to have committed to having an interface that
    can run over HTML, so (unless they add Java or something), the
    difficulty of adding a new widget may be great.
  * The C++ API is the only one out there -- no hooks for other languages
    are provided, and no high-level file description format seems to
    exist.

Other projects, such as Debian's Dotfile program, and Avery Pennarun's
Figurine (http://www.imada.ou.dk/~blackie/dotfile/ and
http://www.foxnet.net/~apenwarr/figurine/ideal.html) also seem to me
to be limited, but in different ways.  Dotfile (IIRC) does not
preserve formatting or comments, and Figurine's model seems (IMO) to
be a bit immature.  The most damning aspect of these projects, to me,
is that Dotfile requires modules to be written in Tcl, and Figurine
requires them to be written in Python.  While I have nothing against
these languages, Tcl is IMO inappropriate for heavy-duty text-processing, 
and requiring our developers to all learn Python is probably not wise.

Phil Berry's LASS is a dialog-based tool, written in sh.  It's very
well-done, but I don't feel that sh is extensible enough to handle
our needs for the general case, let alone the X interface.  He _does_
write very clean code, however, and his backends seem to be well-
written.  He sent me a copy by email, which I've temporarily put at
ftp://frunobulax.mit.edu/pub/nickm/lass-0.1a.tar.gz, in case anybody
wants to check out his code.
========================================

It seems to me that our best bet (unless someone tells me of a better
tool) is either to fix Linuxconf to do what we want, or to write our
own configuration tool, possible using some code from Linuxconf.  Over
the next week or so, I'm going to read through the Linuxconf source,
and try it out on a test partition.  (I won't install it on my main
system, as it seems to want to overrun my sysvinit setup.)

If you have any spare time, please also check out Linuxconf (on a test
partition), and decide whether you like it.  Please also (if you're a
developer with free time), read the documentation, and decide whether
the API's reasonable.  If you have a _lot_ of free time, then read
the source with me, and decide whether we should base our tool on
Linuxconf, or start afresh.

Within a few days or so, I'll summarize our findings, and post a
preliminary to-do list for this project.

Many thanks,

--
Nick Mathewson \\   (seul-dev-admin group leader)
nickm@mit.edu  //