[augeas-devel] Similar model based configuration manager

[David Lutterkort]

On Wed, 2008-04-23 at 17:35 +0200, Dominique Dumont wrote:
> Hello
> 
> For you information, I know of 2 other model based configuration
> managers which have similar goal than Augeas:
> 
> - Config::Model project [1] (which I'm the author)
> - MountManager [2] (Сергей is the author and he will correct me if I
>   make mistake in describing his project)

Cool .. I hadn't heard of either of them before.

> MountManager main points are:
> - dedicated to /etc/fstab configuration
> - user oriented: users are offered a nice QT GUI
> - has no external API (AFAIK). 

That's probably the biggest difference to Augeas: Augeas provides an API
for changing config data; a nice UI on top of that (in the spirit of
gconf-editor) would be really nice. I also don't have a schema
for /etc/fstab yet, though it would be very easy to write.

> Config::Model main points are:
> - provides a generic approach to configuration management.
> - Configuration structures (aka configuration models) are also tree
>   based (like Augeas).
> - is user oriented: users are offered a Perl/Tk GUI (or Curses or
>   shell like UI)
> - has an API (perl API or simple STDIN/STDOUT ASCII interface)

I am a little lower with Augeas ;) It's written in C to be 'runtime
neutral', i.e. usable from as many languages as possible. There are
bindings for Python and Ruby, but none for Perl (hint, hint)

> - Configuration elements can:
>   * be typed (string int, number, enum, boolean)
>   * have constraints (min max...)

Everything in Augeas is a string; not sure if the complication of
additional data types is really worth it at Augeas' level. Since it's
pretty close to the actual files, it seems reasonable.

>   * be classified in "permission" (intermediate, advanced, master)

I'd like to have something similar with Augeas one day, so that you
could use it to delegate responsibility for certain aspects of the
config, but that's a little ways off. I'd imagine that that would come
in the form of a dbus-enabled daemon that has some sort of policy
attached to each file.

Right now, Augeas does nothing for permission enforcement, and they are
strictly based on filesystem permissions. I am not sure if that should
ever be built into Augeas or be something that's layered on top.

> - The configuration structure is modified depending on "main"
>   parameters. For instance, the structure ext2 options when
>   file_system parameter is set to 'ext2'. These ext2 specific options
>   will vanish from the model) if the user selects another fs type.
>   The UI will reflect these structural changes (morphing mechanism)

Nice. When you go from one parameter to another, do you preserve any
values or does the user start with empty values for the new
parameter-dependent values ?

> - Currently, Config::Model does not yet support many files:
>   * /etc/fstab model is an example
>   * /etc/X11/xorg.conf is alpha (and not complete)
>   * /etc/ssh/sshd-config is under development (but should be complete
>     on first release)

Augeas doesn't support all that many files either, yet; but it does
handle sshd_config ;)

> >From what I understood of Augeas, your software main points are:
> - generic approach to configuration management (but can it apply also
>   to more complex configuration like Xorg ?)

Yes; I don't think that xorg.conf would be too hard to describe. The
main issue would be that entries are case insensitive (Augeas has no
direct support for that, and treats everything as case sensitive)

In terms of expressiveness, the biggest limitation of Augeas is that it
can not deal with file formats that are context free (roughly: can have
some elements nested arbitrarily deep) Luckily, truly context-free
config files are few and far between. That will keep Augeas from
becoming a full-fledged XML processor, though generally, you can
describe specific XML formats with a regular grammar that Augeas
understands. Even for formats with arbitrary nesting, you can do some
approximations of the format that will likely be "good enough" in
practice, for example only support nesting to a fixed depth.

> - More script or program oriented than user oriented (no help,
>   requires lot of knowledge from user, only shell UI)

Yeah; that's kinda on purpose. I envision Augeas as the Swiss Army knife
for config editing, that can be used in lots of ways to build useful
config-related tools on top of it. Augeas focusses on the things that
are guaranteed to be common across many (if not all) config-editing
tools, so that they can focus on what's really important to them.

> - Something like grammar based parser which extract the structure from
>   the config file.

The parser is based on a grammar, just that I don't use the word
'grammar' a lot, and talk more about lenses - the lenses turn the file
into structured data (the tree)

>  (What if the config file is wrong from the start ?)

Not something I'd loose much sleep over - if a config file can't be
processed it's (a) because the config file is not syntactically correct,
in which case I'd never dream of trying to fix that automatically or (b)
the file format description (lens) is incorrect. Either way, you'll need
a human to figure out what went wrong.

> The second point is to trigger a discussion on how our project are
> overlapping or how could they work together.
> 
> For instance, I think I could interface Config::Model to Augeas
> API. (but I don't know if I could extract the structural informations
> from Augeas and feed them to Config::Model). 

I think it would be very worthwhile for you to see if you could use
Augeas as the low-level editing API. I imagine that, beyond what it
gives you today, you'd want some sort of schema for the that Augeas
constructs for every file - I'd be very interested in finding a way to
generate that from the lenses. The main issue is what the best way to
describe the schema is. For example, it wouldn't be very hard to
generate Relax-NG to describe the tree. Would that be useful for you ?

You'd probably also need metadata to support the UI with labels,
descriptions, help texts etc. I would imagine that that would be
particular to Config::Model and somehow keyed off the schema
description.

thanks for pointing those two projects out to me,
David