[Olsr-users] multiple domains in olsrv2
nemesis
(spam-protected)
Thu Oct 4 15:45:01 CEST 2018
On Wed, 3 Oct 2018 10:01:02 +0200, Henning Rogge <(spam-protected)>
wrote:
> On Wed, Oct 3, 2018 at 9:45 AM Gabriel <(spam-protected)> wrote:
>> So i think we have two problems:
>> 1:
>> the acl should be 'default accept' as you said, otherwise you always
>> have to explicitly allow something.
>
> This should be easy...
>
>> 2:
>> the UCI parser in OONF have problems with named sections:
>> I tryied the 4 possibilities w and w\o section name and option name
>> and
>> OONF doesn't work if you specify the section name without specifyin
>> an
>> option name.
>> IMHO the option name is redundant and we should only use the section
>> name.
>
> OONF uses libuci... which does (as far as I know) not support section
> names well... to be specific, it doesn't allow two section of
> different types with the same name. I had to work around this, I
> don't
> remember any better solution.
>
> I do NOT want to implement a parser for a configuration format
> without
> a good specification myself.
>
> If you have a good suggestion, feel free to post it here. OONF
> implement configuration formats as plugins, so it would be easy to
> implement something different.
Hi guys,
permit me to step-in in the conversation.
I think it's better to avoid using section names to determine software
configuration.
In my understanding the names of UCI section are a kind of ID which is
designed
to allow updating specific configuration objects by referring to them
via this ID.
That means we shouldn't use the UCI ID in place of the name config
option because that's
not how that internal feature of UCI is meant to be used.
Yes it means to have a bit of redundancy if you want the section to
have the same name you use,
for the option name, but it's not a big deal if this redundancy is
managed by an automated system.
Non automated systems can do without the UCI name entirely.
That said, Henning, why is the code not working if the section is
named?
That doesn't sound like something which is meant to happen and I think
it would surely help OLSRd2 if this is avoided.
I am not using the C bindings to manipulate UCI configurations, I'm
only using lua and shell to do that,
but in my understanding the lua bindings are using the C library under
the hood.
With the lua bindings I am still able to loop over configuration types,
even if they do have a name.
Can we do something similar in this case?
Could you share the piece of code that deals with this part so we can
take a look at it?
Best
Federico
More information about the Olsr-users
mailing list