[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [augeas-devel] httpd.conf and beyond



On Sun, 2010-01-03 at 00:15 +0100, Marc Fournier wrote:
> > This series of patches adds support for context-free lenses, which
> > means that Augeas can now process funky stuff like the Apache config.
> 
> Just wondering: would it make sense to have a lens which could edit
> well-formed XML ? Many config files are in XML nowdays, and it would be
> convenient to be able to use augeas to manage every config file on the
> system, not only the non-xml ones.

Yes, that would indeed be very useful. There's two aspects to this: for
(most) XML formats, you can write a lens that processes that format
without the context-free support in these patches - it's rare for XML
formats used for config files to support arbitrary nesting. One thing
that would be very nice for this would be a module that makes writing
such lenses easy, so that you can easily express that your format has a
toplevel <foo> tag, which can contain any number of <bar> or <baz> tags
etc.

For a generic XML lens, i.e. something that can parse and edit any XML
well-formed XML, you do need the context-free support. By necessity, the
resulting tree will look a little funky, I'd imagine for a snippet like

        <tag1 attr1="v1" attr2="v2">
          <tag2>some text</tag2>
        </tag1>

that you'd construct a tree like
        { "tag1"
          {  "@attr1" = "v1" }
          {  "@attr2" = "v2" }
          {  "tag2"
             { "text" = "some text" } } }

> > - I'd appreciate any help on getting the lens into shape. The two main
> > things that need to change about the Apache lens are (1) make sure we
> > cover all directives and (2) make sure the directives it knows about
> > wind up in a tree structure that is useful.
> 
> A problem I see is that older Apache versions have other/fewer
> directives, Another is that 3rd party modules usually add more
> directives to the available ones.
> 
> An idea how this could be handled ? Should we expect a "mod_security"
> lens which extends httpd.aug, for example ? 

Yes, that's come up, too. Clearly, we can't have a single Apache lens
that knows every possible directive in great detail. The general idea is
to provide some sort of 'catch all' parts for those directives.

To account for that, the overall Apache lens would loke something like

        let rec lns = (directive | fallback)* | sections lns
        
Ordinarily, you could construct a fallback lens by matching on /.*/ -
directive_names (where directive_names is a regexp matching the names of
known directives) Since Apache has a ton of those, building that regexp
explicitly is very inefficient - one way around that, and most likely
the one we'll take, is to provide some sort of fallback combinator, so
that you can say something like 'fallback l1 l2' where l1 and l2 are
lenses; the behavior would be to use l1 if it matches, and l2 otherwise.

David




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]