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

Dominique Dumont dominique.dumont at hp.com
Fri Sep 12 12:01:35 UTC 2008


Hello David

David Lutterkort <lutter at redhat.com> writes:

>> That's why I thought about masking the 1st index ("[1]") and use the
>> 2nd index ("/2") with the square brackets syntax (I.e. "[2]")
>> 
>> This would completely hide from the API user the implementation detail
>> relative to "seq" usage in the lens specification.
>> 
>> Is this possible ?
>
> No, I can't think of a way to do that that wouldn't be a terrible
> hack(tm).

Understood. After all, Augeas has 2 types of lists, and hiding that
fact from the API is not good.

> I am still confused about how Config::Model stores information about
> what the user is allowed to enter: don't you need to specify at some
> point that 'X11Forwarding' can only be listed once, but 'AcceptEnv'
> multiple times ?

Yes. In Config::Model, X11Forwarding is a simple leaf (you can store
only one value) and AcceptEnv is a list of leaves. Here's the relevant
extract from Sshd model:

'X11Forwarding' => {
                     'type' => 'leaf',
                     'value_type' => 'enum',
                     'built_in' => 'no',
                     'choice' => ['yes', 'no']
                   },

'AcceptEnv' =>     {
                     'type' => 'list',
                     'cargo' => {
                                  'value_type' => 'uniline',
                                  'type' => 'leaf'
                                },
                     'experience' => 'advanced',
                   },

If, by mistake, a user specifies twice X11Forwarding in sshd_config,
the first value is discarded. Only the 2nd value will be stored in
Config::Model. This behavior probably matches sshd behavior (although
I have not verified)

On the other hand, Augeas will keep track of both X11Forwarding values
and will keep potentially ambiguous informations 
(ie. X11Forwarding[0] = "no" and X11Forwarding[1] = "yes")

> And couldn't you add to that specification some metadata that helps
> you decide where to put that data in the Augeas tree ?

Yes, I've been thinking about declaring the label of lenses that
contains seq. But this hack (admittedly not so terrible ;-) ) will
require the designer of the model (à la Config::Model) a quite good
knowledge of Augeas lens. And it will break if a lens containing a seq
and a lens not containing a seq have the same label.

If I could query Augeas API the content type of a lens (e.g. 'lens',
'value' or 'seq lens'), I could avoid this possible breakage.

In fact, I would implement the "terrible hack(tm)" in
Config::Model<->Augeas bridge. ;-) But that's fine because
Config::Model only has one type of list.

All the best

-- 
Dominique Dumont 
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner




More information about the augeas-devel mailing list