Puppet users - Apr 2008 - ANNOUNCE: Augeas - a configuration API

I am pleased to announce a new configuration management project: Augeas,
a low-level configuration API and editing tool.

Augeas'' main goal is to make programmatic changes of configuration data
on Linux/Unix systems simple and safe. The main stumbling stone for this
is that configuration data is stored in numerous files in widely varying
formats. This is both next to impossible to change and is valuable in
many situations. Rather than demanding a radical change, Augeas adapts
to this reality.

Augeas parses configuration files in their native formats and transforms
them into a tree. Configuration changes are made by manipulating this
tree and saving it back into native config files
(/etc/hosts, /etc/grub.conf, ...). 

The tree abstracts away all the pesky details that make editing config
files with grep/sed/awk so challenging, and exposes config data
uniformly, regardless of the format in which it is actually stored. With
this approach, the programs/daemons relying on config files continue to
work as they do today, and editing config files with Augeas can be
interleaved with changing them by other means, from vi to existing perl
scripts.

What is it ?
===========
Augeas consists of a C library and API, a command line tool to
manipulate configuration from the shell, and language bindings for Ruby
and Python. The file <-> tree transformations are driven by schema
descriptions, one for each file format. Schemas essentially consist of
regular expressions describing the file structure and instructions on
how to map matches into the tree. The hope is that over time, the set of
schemas becomes both complete and sufficiently widespread to provide a
canonical tree view of common configuration data.

Where can I find Augeas
======================
Augeas'' website is http://augeas.net/
Downloads can be found at http://augeas.net/download/ 
To learn more, start with the introductory tour at http://augeas.net/tour.html
Discussions around Augeas happen on augeas-devel,
https://www.redhat.com/mailman/listinfo/augeas-devel

Help wanted
==========
Augeas is a reasonable proof-of-concept as of now; there are lots of
things that need to be done, and that I would love for others to pitch
in. Some of them are listed in the todo list at
http://augeas.net/todo.html

The most pressing issues right now though are

      * Enable your favorite config mgmt tool to use Augeas as the
        low-level config editing tool
      * Cover more config files and write schemes for them; even without
        writing actual schema, a discussion on augeas-devel on how
        config file X would best be mapped into the tree would be really
        useful.
      * Anything to improve the quality of the current implementation; I
        know I cut some corners in the initial implementation, and any
        review/patches to improve it would be useful.

David


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Thu, 2008-04-17 at 13:07 -0700, David Lutterkort
wrote:
> The most pressing issues right now though are
> 
>       * Enable your favorite config mgmt tool to use Augeas as the
>         low-level config editing tool
For puppet, I envision that integration could mean several things:

      * A fairly generic ''augeas'' resource/provider that
exposes
        individual config settings, and would make it possible to
        replace lots of templates with targeted editing instructions.
      * Changing the existing resources/providers that directly edit
        config files (like the hosts and yumrepo providers) to use
        Augeas instead
      * Exposing more config files as resources, using Augeas as the
        backend to actually make changes.

I hope to provide patches for all three of these at some point, but am
not sure when I''ll be able to work on them. In the meantime,
I''d love it
if somebody beat me to any of them ;)

David



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi,

What about electra?

seems they have been there for quite some time, so how does this compare to it?


"""
Elektra is a universal hierarchical configuration store, with related
goals like GConf and the Windows Registry. It allows programs to read
and save their configurations with a consistent API, and allows them
to be aware of other applications'' configurations, leveraging easy
application integration. The whole point of it is to tie applications
together, so that they can co-operate and share their
user-preferences.

The developers are associated to unix philosophy and the very
practical point consists of writing a configuration library. Every
software needs this functionality, it is not easy to do it right and
performant and we want to avoid any unnecessary code duplication.
"""

http://elektra.g4ii.com/Main_Page

/martin

On Thu, Apr 17, 2008 at 10:15 PM, David Lutterkort <dlutter@redhat.com>
wrote:
>
>
>  On Thu, 2008-04-17 at 13:07 -0700, David Lutterkort wrote:
>  > The most pressing issues right now though are
>  >
>  >       * Enable your favorite config mgmt tool to use Augeas as the
>  >         low-level config editing tool
>
>  For puppet, I envision that integration could mean several things:
>
>       * A fairly generic ''augeas'' resource/provider that
exposes
>         individual config settings, and would make it possible to
>         replace lots of templates with targeted editing instructions.
>       * Changing the existing resources/providers that directly edit
>         config files (like the hosts and yumrepo providers) to use
>         Augeas instead
>       * Exposing more config files as resources, using Augeas as the
>         backend to actually make changes.
>
>  I hope to provide patches for all three of these at some point, but am
>  not sure when I''ll be able to work on them. In the meantime,
I''d love it
>  if somebody beat me to any of them ;)
>
>
>
>  David
>
>
>
>  >
>


-- 
http://tumblr.marcher.name
https://twitter.com/MartinMarcher
http://www.xing.com/profile/Martin_Marcher
http://www.linkedin.com/in/martinmarcher

You are not free to read this message,
by doing so, you have violated my licence
and are required to urinate publicly. Thank you.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Thu, 2008-04-17 at 22:19 +0200, Martin Marcher wrote:
> Hi,
> 
> What about electra?
> 
> seems they have been there for quite some time, so how does this compare to
it?
Yes, Elektra has a long and checkered history; the biggest differences
between Augeas and Elektra are

      * Augeas does not require _any_ changes to daemons/whatever
        actually uses the config files being edited; up until very
        recently, Elektra wanted to be the canonical store for config
        data, and store that in its own backend. Using Elektra required
        that daemons etc. are patched to use Elektra''s API''s
      * Recently, Elektra added support for pluggable backends, so that
        it could edit config files in place. There''s no support though
        for writing the actual editing backends. In contrast, most of
        the work for Augeas has gone into making it easy to write the
        file <-> tree transformations; they are described in a
        domain-specific language that let''s you focus on describing the
        format of the files you want to change (through regular
        expressions) and how the file should be mapped to the tree
        (through ''lenses''[1])

David

[1] http://augeas.net/docs/lenses.html



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Apr 17, 2008, at 1:15 PM, David Lutterkort wrote:
>
>
> On Thu, 2008-04-17 at 13:07 -0700, David Lutterkort wrote:
>> The most pressing issues right now though are
>>
>>      * Enable your favorite config mgmt tool to use Augeas as the
>>        low-level config editing tool
>
> For puppet, I envision that integration could mean several things:
>
>      * A fairly generic ''augeas'' resource/provider that
exposes
>        individual config settings, and would make it possible to
>        replace lots of templates with targeted editing instructions.
I''m tempted to try this.  What sort of use case do you see this  
being?  Sort of a replacement for the ParsedFile provider?  Or would  
it be more like a Augeas native type with various config file  
providers based on Augeas schemas....   I''ll take a look at the ruby  
API and see what I can work out.

-Blake

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Thu, 2008-04-17 at 14:04 -0700, Blake Barnett wrote:
> >      * A fairly generic ''augeas'' resource/provider
that exposes
> >        individual config settings, and would make it possible to
> >        replace lots of templates with targeted editing instructions.
> 
> I''m tempted to try this.  What sort of use case do you see this  
> being?  Sort of a replacement for the ParsedFile provider?
Yeah, something along those lines. The right approach is to have a
dedicated resource/provider for all these things (like the host
provider) - Augeas would be useful there to help the provider writer to
make the actual change.
> Or would  
> it be more like a Augeas native type with various config file  
> providers based on Augeas schemas....   I''ll take a look at the
ruby
> API and see what I can work out.
As a "provder of last resort", a generic augeas provider would expose
the raw Augeas tree, so that you could say in your manifest something
like

        augeas { "/files/etc/ssh/sshd_config/UsePAM": value =>
"yes"}
        
        augeas { "/files/etc/ssh/sshd_config/X11Forwarding": value
=> "no" }
        
That''s of course less nice than having an actual sshd provider, but
it''s
nicer than having to template sshd_config (since you can still have
completely different classes set different entries in the same file)

One of the challenges with a generic augeas provider is making sure that
Puppet''s internals understand what is being managed and produce
conflicts if the above two statements appear in a manifest together with
a file resource for /etc/ssh/sshd_config.

More complicated uses would also require querying the Augeas tree to
figure out where to put a value; for example, to change the initdefault
in /etc/inittab with augtool, you''d first do

        augtool> match /files/etc/inittab/*/action initdefault
        /files/etc/inittab/1/action

and then based on that result

        augtool> set set /files/etc/inittab/1/runlevels 3
        augtool> save
        
Not sure if that needs to be possible with a generic augeas provider, or
if that shouldn''t be left to specific providers that use augeas in the
background (such as an inittab provider for this example)

David




--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Apr 17, 2008, at 4:04 PM, Blake Barnett wrote:
>
> On Apr 17, 2008, at 1:15 PM, David Lutterkort wrote:
>>
>>
>> For puppet, I envision that integration could mean several things:
>>
>>     * A fairly generic ''augeas'' resource/provider
that exposes
>>       individual config settings, and would make it possible to
>>       replace lots of templates with targeted editing instructions.
>
> I''m tempted to try this.  What sort of use case do you see this
> being?  Sort of a replacement for the ParsedFile provider?  Or would
> it be more like a Augeas native type with various config file
> providers based on Augeas schemas....   I''ll take a look at the
ruby
> API and see what I can work out.

When David and I talked about this a while ago, we definitely  
envisioned it as a much easier and more functional replacement for the  
ParsedFile base class -- an Augeas base provider class would need to  
be created, then it could just be subclassed as necessary.

-- 
My favorite was a professor at a University I Used To Be Associated
With who claimed that our requirement of a non-alphabetic character in
our passwords was an abridgement of his freedom of speech.
     -- Jacob Haller
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---