Hi Anand,
On 2015-06-28 01:04, Anand Buddhdev wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 26/06/15 15:25, Jan Včelák wrote:
Hello everyone!
Hi Jan!
CZ.NIC Labs just released a final version of Knot
DNS 2.0.
Yay!! Thank you very much for this release. My experiences with it so
fa
r:
1. It builds properly under CentOS 6, with the caveat that one has to
find "gnutls3" and "nettle" packages from somewhere, because
they're
not in EPEL 6. For the time being, I'm using packages from:
https://copr.fedoraproject.org/coprs/jvcelak/gnutls3/
It would be good if gnutls were officially added to EPEL 6.
2. I like the new YAML config file format. My one slight complaint is
that you've chosen to implement a subset of YAML, so it has taken away
some of the usefulness of this format. For example, I can do:
listen: [ addr1, addr2 ]
but not:
listen:
- addr1
- addr2
In YAML those two are equivalent, but Knot's parser only accepts the
first form. Is there any reason for not just reading the full YAML
forma
t?
The reason is the YAML format is quite complex so I didn't manage to
implement
some features yet.
On the other hand, you can use nonYAML variant:
listen: addr1
listen: addr2
This works for all multivalued items.
3. I really, really like the template concept :)
+1
4. In the template definition, %s translates to the
zone name, with
the exception of the root zone. If I use the default for the "file"
parameter, then I get file names like:
zone1.zone
zone2.zone
but:
..zone
It tickles the purist in me, but it's not really a problem.
Yes, we already discussed this case but without a better solution.
I think, the root zone use case requires special care (explicit
zonefile specification).
5. I haven't loaded all our zones in it yet, but
it appears to be
running just fine on our test server with a subset of zones.
6. I'm trying to figure out whether RPM can tell me it's upgrading
from 1.x to 2.x, so that I can trigger the knot1to2 utility on 1.x
config files. But I don't yet know how to get this info from RPM.
7. Talking about the knot1to2 utility, I have a suggestion. The
current way it works, by taking an input file and an output file, it's
not idempotent. Let's say I write a post-install script to invoke
knot1to2 during a package upgrade, then when upgrading the first time
from 1.x to 2.0.0, it will work. Of course, I would probably want to
keep the post-install script in the 2.x series package. But now,
upgrading from 2.0.0, to say 2.0.1, would probably make it throw
errors if the config file is already in the v2 format.
It might be better if knot1to2 works like this:
knot1to2 <config>
Now, if config is v1, then it should rename it to config.v1, and then
create config in v2 format. However, if it is already v2 format, then
it should do nothing and just exit silently. This way, I can keep
knot1to2 in the post-install script of the package, and it would not
throw errors. Is it too late to change this behaviour?
Ok, we will think it over.
Thanks,
Dan
Regards,
Anand
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools -
http://gpgtools.org
iQIcBAEBCAAGBQJVjyvuAAoJEBXgoyUMySoFYPYP/jbnf7bBTUDy+Zow6vuwYgjB
aUz9GCGHx8M7JkVsEuoVKY8Ab4tTiNzRwLcaP94ObgbamuyKdMC3DNbBxBYq8CB2
THiazD8Xp+KH3F6vxU5JenJWC6XHZ6kyloYstk48TfoSN5gwPKMfg8PoyrB915MD
aezvQ5mInNcEEjcBehxcFUoIlOFcNhrGG/xuVPNBKYDF7Oh8Z2q/afWQE0FlzbGa
xWIun1vzWyzNlE8FyK79hOvjG0Xda5aFO2rbxr/oXwiuyrRA5keXiSI+/pFrsB9X
5HJQ8j+L8uhQEQK2MmeGkTHDuDCQBvWmiluqYlT5AzmhQNVclsLoIxys8jvZaP87
6AKpZMXiZS9HKMM0LGsWc7VzKjxpn5s1yhtusmM6B5Ek2qNHP0K/EmVQGaBV9ZZ0
ruOFwBkbVJZOjk4O6rnc9oiD3tH3caECINUxT/GnDiR35Bojkcwdq9lY2TXxhalg
35lejP33wR3le5NoIUSatmRJhk8RcCJU8r5ieGDZrIAtqk07QpXQlK0fOvxFs3q4
4uqCEWAotIBDYJQ0brdcGvqGfJhyvpbYuDX6XicsZ/eS05Dww0sKJnrM74syaG4U
xO70KudB1Cp1WPFc7ud7vM1evzlXJz+P5SkKvt+eCnApEfKIgkiQLdgkxRhhuTVM
tvF7UVOmYzRRLiErSSTb
=thMp
-----END PGP SIGNATURE-----
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users