ANNOUNCE: Augeas - a configuration API
David Lutterkort
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
David Lutterkort
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
Martin Marcher
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
--
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.
David Lutterkort
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
Blake Barnett
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
David Lutterkort
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
Luke Kanies
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