Re: Configuration Tool(s)

[Rick Jones <rickya@siservices.net>]

Nick Mathewson wrote:
> 

I have used Linuxconf off and on for over a year now.

I'll tell you if the following applies to Linuxconf.
> In my opinion, any system we use should have _at least_ the following
> properties:
> ? (1) It should be intuitive to use.

Pretty much.

> + (2) It should log all changes it makes to configuration files,
>       and provide the option to undo any changes.

It logs, but no undo button.  You can re-enter the appropriate menu and
change it back.  Most changes don't take effect until you exit and
answer yes to initiate the changes.

> + (3) It should support internationalization.

Yes.

> + (4) It should not force the user to destroy comments or formatting
>       in the files it processes.

It makes backups.

> + (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.

It supports Linuxconf modules.

> - (7) Module-writing should be _very easy_ for developers, and not
>       (in most cases) require heavy coding.

I haven't look yet.

> - (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.)

I haven't used the new GUI interface yet.

> + (9) The API should be versatile enough to handle even the most baroque
>       configuration files, such as sendmail.cf.

Sendmail is natively suppoted.  i.e. not a module.

> +(10) It should, if possible, tell daemons, wm's, &tc to re-read
>       their configuration files when the changes are applied.

This is one of it's strong points.

> -(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.)

I would say it is minimul.  It has to make some changes to monitor the
status of the daemons etc.

> -(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.

Not sure about this.

> ?(13) It must be capable of being invoked as a stand-alone tool, or
>       as a control-panel by an application.

Yes.

> 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.

Yes, and no.  It is sysv compatable.  It will use a modified rc but
/etc/rc#.d directories are untouched and used.

>   * 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 Java GUI is done, alpha, I haven't used it in a while so don't know
if it's in a final useable state yet.  I plan to look into it tonight.

>   * 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.

Dot-file seems to be more of a user utility than a system utility. 
Maybe a combination of it and Linuxconf?

> 
> 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.)

Modification of the sysv setup is optional to give Linuxconf more
controle.  It can be used as a config-only tool without modifying sysv
or any other system files.

Linuxconf isn't perfect but IMHO it's the closest we have in an existing
tool.

-- 
Out here,

Rick Jones
rickya@siservices.net