[augeas-devel] Similar model based configuration manager

[Dominique Dumont]

David Lutterkort <dlutter at redhat.com> writes:

> On Wed, 2008-04-23 at 17:35 +0200, Dominique Dumont wrote:
>> - 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.

Well, I announce updates on freshmeat, but freshmeat has a lot of
announces. :-D

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

Hmm, when you take into account all options for fs types, you get
quite a handfull of them.

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

Hint received 5/5 ;-)

I'll have a look once I've finished sshd_config model (for
Config::Model). If I use Inline::C, it should be straightforward.
(I don't work full time on config::model, so don't hold your breath)

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

That make sense for a low level API (not offense meant ;-) ). 

An upper layer to help user with average knowledge is another problem.
(which I try to tackle)

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

In my case, the granularity is not the file, but the element. The idea
is to present newbies with only a subset of the parameters. For
instance for sshd_config, PermitRootLogin can be 'intermediate' while
Cipher is definetely 'master'. (I'm beginning to think that
"permission" is a misnomer. I may need to change it to "skill"...  I'm
open to suggestions on alternative.)

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

I think filesystem permission is enough. 

Classifying elements according to their complexity is another matter.

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

I preserve all values if they are valid in the new "context". This
mechanism also works for more complex structural changes, e.g. if your
change from fglrx to radeon driver in xorg. Unvalid values in the new
context are discarded.

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

The nice thing I noticed about Augeas is that comments are preserved
in the config file. Nice trick. (I'm thinking about using Augeas to
read/write sshd_config file ...)

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

Uh oh. I focused on the semantic content of Xorg and I missed this
syntax problem. Major bug ahead :-(

Is Augeaus able to detect wrong keyword entered through Augeas shell ?

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

This makes sense. 

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

Unix style. Good point.

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

In "force" mode Config::Model drops unvalid data. (-force option of
config-edit program). Then the user will need to fill missing data.
That's a reasonable thing to do for an interactive editor.

But ignoring this case makes sense for Augeas (given its purpose and
scope).

> or (b) the file format description (lens) is incorrect. Either way,
> you'll need a human to figure out what went wrong.

Yes.

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

Agreed.

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

To be useful, config::model will need more data that what can be found
in the lenses (user help, level, permission/skill...)

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

I do not known much relax-ng, but I think it would be useful.  (either
to check that Augeas lenses match Config::model schema ot to generate
a skeleton of a Config::model schema from the lense)

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

More likely added manually on top of the schema extracted from the
lenses (with config-model-edit GUI)

> thanks for pointing those two projects out to me,

You're welcome. Thanks for the discussion.

Cheers

-- 
Dominique Dumont 
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner