[augeas-devel] [Puppet Users] Augeas lens dependency on valid config file parsing

[Dominic Cleal]

On 22/03/13 04:02, Gonzalo Servat wrote:
> Hi All,
> 
> I just ran into a frustrating Augeas problem, which I thought I'd share
> with you all.
> 
> We run a cron every morning to fetch the latest RPMs (for the packages
> we're interested in) from various places such as rpmforge, EPEL, etc.
> 
> This morning I tried to build a VM and it failed. What happened was that
> last night, a new version of nagios-nrpe was downloaded so the VM that
> was built had this latest version. The RPM includes nrpe.cfg which had a
> new option added to it:
> 
> allow_bash_command_substitution=0
> 
> In the manifest, I have an augeas block to modify the allowed_hosts line
> in the nrpe.cfg file. Puppet was failing giving a "Save failed" error
> message, so I went in via augtool to see what's going on.
> 
> I noticed that it could not parse nrpe.cfg (i.e. ls /files/etc/nagios
> returned nothing). I had the previous config file saved for NRPE
> somewhere, so I diff'ed them and noticed the only new option is the
> option I mentioned above. After removing this new option, augtool could
> parse the file again and Puppet was happy.
> 
> After having a quick read of the nrpe.lns file inside augeas-libs, I
> noticed it actually lists each of the options that it will recognise
> from the config file, and evidently fails if it finds new options that
> it doesn't recognise.
> 
> Anyway, it hit me that there is quite a big dependency between config
> files and augeas lenses. A change in one config file can affect Augeas
> which affects Puppet runs. Or is this just a poorly written lens?

You might better off directing this at augeas-devel at redhat.com (CCed).

Lenses can be written either to match a file format very specifically
(as in this case) or quite loosely.  There are pros and cons to each.

Clearly writing a fairly loose definition for the file which accepts
something like [a-z_]+ for the name of a setting is useful when new
settings are added, as then the lens doesn't stop parsing when it comes
across the new name.

The downside is if the new setting has data that requires a different or
more complex representation in the Augeas tree.  A loose lens might
interpret a setting that's made up of multiple space-separated values as
a single value, meaning it's not as useful to people as they can't alter
a single value using Augeas (which is the point of the library).  This
situation is worsened when somebody goes to fix it, as they will likely
to have to change the format of the tree for that entry, which is an
incompatible change between Augeas versions.

A recent example of this is the Postfix main.cf lens, which treats
everything as a simple value, but then don't split up settings like
virtual_user_maps which are made up of multiple values:
https://www.redhat.com/archives/augeas-devel/2012-November/msg00049.html

Some lenses are of the former type and some of the latter, depending on
the original contributor's viewpoint and the type of file they're
parsing, how the format is being developed etc.

I think on balance we're preferring the former type in Augeas, so if you
wanted to change this to a regex that matches all key names except for
include and command (which have special formats in the lens), a patch
would probably be accepted.  At the very least, a bug report would be
appreciated:

https://fedorahosted.org/augeas/

Perhaps ideally, lenses could be bundled with the software responsible
for the config file formats themselves so they're more easily kept in
sync.  There are a small number of projects that do this (libvirt,
libguestfs, corosync), but it needs a supportive upstream.

Regards,

-- 
Dominic Cleal
Red Hat Engineering