Re: [knot-dns-users] Knot DNS 2.0.0 (final release)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 26/06/15 15:25, Jan Včelák wrote: Hi Jan! 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? 3. I really, really like the template concept :) 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. 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? Regards, Anand