[config-model-users] [augeas-devel] Re: Semantic problem in augeas sshd lens ?

[David Lutterkort]

On Wed, 2008-09-03 at 14:56 +0200, Dominique Dumont wrote:
> David Lutterkort <lutter at redhat.com> writes:
> 
> > One general note on tests (and I know that you've just followed examples
> > in mercurial): I _much_ prefer it if the tests are short and succinct,
> 
> Agreed. I also use a lot of short consecutive tests for my perl
> modules (all the *.t files)
> 
> > Here you're much better off if you map multiple 'HostKey' lines into
> > separate nodes, i.e.
> >
> >         { "HostKey" = "/etc/ssh/ssh_host_rsa_key" }
> >         { "HostKey" = "/etc/ssh/ssh_host_dsa_key" }
> >         
> > No need to treat HostKey special. If you need all host keys, you can
> > call aug_match with the path '/files/etc/ssh/sshd_config/HostKey' -
> > that will list all entries with a host key.
> >
> > The problem is that HostKey lines don't need to be consecutive, and
> > you the order of entries in the tree must follow the order in the
> > file.
> 
> No problem (well, for now. Mapping Augeas philosophy with
> Config::Model will probably be more challending :o) )
>  
> Where will land a new HostKey entry added through Augeas ?

If there are no HostKey entries yet and you say
'set /files/etc/ssh/sshd_config/HostKey foo', it will be added as the
last node under /files/etc/ssh/sshd_config, which may violate the schema
if you have 'Match' sections.

So you need to insert the entry explicitly, for example with
        insert HostKey before /files/etc/ssh/sshd_config/Match[1]
        set /files/etc/ssh/sshd_config/HostKey[last()] foo

> > I would map that into
> >
> >         { "Match"
> >           { "Condition" { "User" = "sarko" }}
> >           { "Condition" { "Group" = "pres.*" }}
> >           { "Banner" = "/etc/bienvenue.txt" }
> >           { "X11Forwarding" = "no" } }
> 
> Which is fine unless a future version of OpenSSH defines a Condition
> keyword that can be used within a Match block. Such a change would
> break the lens. And changing the lens would break the API as seen by
> sshd lens users.
> 
> So should we be more future proof at the expense of a slightly more
> complicated sshd lens ?

Or use a label that can't be a valid keyword for sshd config, like
'.Condition' instead of 'Condition'

David