9 Srp
2013
9 Srp
'13
10:51
On 8 August 2013 22:10, Johan Ihrén <johani(a)johani.org> wrote:
On Aug 8, 2013, at 12:56 , Marek Vavruša wrote:
Right, this is parsed in a wrong way. Not cool at all, I'll fix it promptly.
https://gitlab.labs.nic.cz/knot/issues/137
But it also shows that it could be avoided if we differentiated
between quoted strings/unquoted tokens-identifiers in the first place,
good.
The addresses are parsed as a different token, so
it shouldn't be allowed.
My point was that if it is either strict or relaxed, you don't have to
think about how to write it out.
If there are exceptions, it may work well but it also might be
annoying to configure, if you are not
able to guess whether it should or shouldn't be quoted instinctively.
I think if we require quoted string for values, it is a good compromise.
Things where it is obvious like paths, TSIG secret, CH TXT + NSID
related strings and I can't think
of what else. So this change would touch only several parameters, to
which most of the people use quoted strings anyway?
So I agree this seems like a reasonable compromise. However, as we're discussing
parsing the conf file I have two more observations:
1. If I declare a TISG key without the quotes:
keys {
foo. hmac-sha256 secret;
}
Then checkconf claims that the config is valid, but starting the server will lead to a
segmentation fault when trying to do the TSIG protected zone transfer. I'm aware that
I should use quotes, but checkconf didn't catch that (and regardless of format,
segmentation faults are not cool). 2. I'm a bit confused regarding the syntax for
"lists":
remotes {
foo { address ...; port ...; }
bar { address ...; port ...; }
}
To me, the {...} after "foo" is a list. The elements of this list are
terminated by a ";". This is all fine and a standard notation known from many
other places.
However, what about the {...} after "remotes", isn't that also a list (of
remotes)? If so, why are the elements not terminated by a ";"?
And it gets worse, see groups:
groups {
self { me, myself }
}
I think that the {...} after "self" is a list, but now we have a third
notation: comma as a separator, instead of semicolon as a terminator, (or space as a
separator, as in the "remotes" case).
Am I missing anything here or is this really a bit inconsistent?
Regards,
Johan
Hmm, it may be so. The remote declaration is not a list per-se, it is
a nested structures requiring named attributes, just like it is with
'system {}' or 'keys {}' or any other. But the truth is, that for
example interfaces are named only for the 'via' keyword, not much
useful and could be reduced to list.
Lists are used for groups and ACLs only.
That being said, it could be confusing, yes. I think most of of the
configuration could be converted to a list-like notation, separated
with ';'. That change however would be very hardly backwards
compatible, so
if we break it for some next major version, we might as well put in as
many improvements as possible.
I don't fancy the repetition of "address" keyword in remote/interface
for example, naming of the interfaces is probably superfluous, 0.0.0.0
could mean ANY without prefix spec, zone ACLs are not always clear,
like "xfr-in" does not imply strongly that the following remote will
be used as a master and others.
I have created a small page on our wiki to collect bits and pieces
https://gitlab.labs.nic.cz/knot/wikis/config-changes
This probably won't happen in the 1.4, but it is a very good idea to
collect ideas at this point and if we're going to break things, I'd
rather make it worthwhile :)
Johan, many thanks for the input. This is exactly the honest feedback
I value so much.
Marek