Hi Daniel and Jan, Thank you for your suggestions and acknowledgements.
Regards, Anand On 21/07/2017 10:35, Daniel Salzman wrote: > Hello Anand and Jan, > > You are right. This case cannot be handled easily. We will extend the > zone-purge command > to be able to purge a specific unknown zone or all unknown zones from the > databases > (journal, timer, and kasp). Since Knot 2.5.0 it is easy because the databases > are common > for all zones, so there is no zone-specific configuration for them. > > Daniel > > On 07/21/2017 10:18 AM, Jan Včelák wrote: >> Hey, >> >> I think your arguments make sense, Anand. I would just suggest >> slightly different solution: Add control command that removes all >> orphaned zones from the journal (knotc journal-gc). It will be more >> practical as you wouldn't have to call it for each zone you have >> removed. It will be idempotent and less error prone in the end. >> >> Jan >> >> On Thu, Jul 20, 2017 at 5:30 PM, Anand Buddhdev <ana...@ripe.net> wrote: >>> Hello Knot DNS developers, >>> >>> I have an observation about newer versions of Knot which use the new >>> single LMDB-based journal. >>> >>> Suppose I have 3 slave zones configured in my knot.conf. Let's call them >>> zone1, zone2 and zone3. Knot loads the zones from the master and writes >>> data into the journal. Now suppose I remove one zone (zone3) from the >>> config, and reload knot. The zone is no longer configured, and querying >>> knot for it returns a REFUSED response. So far all is according to my >>> expectation. >>> >>> However, if I run "kjournalprint <path-to-journal> -z", I get: >>> >>> zone1. >>> zone2. >>> zone3. >>> >>> So the zone is no longer configured, but its data persists in the >>> journal. If I run "knotc -f zone-purge zone3." I get: >>> >>> error: [zone3.] (no such zone found) >>> >>> I'm told that I should have done the purge first, *before* remove the >>> zone from the configuration. However, I find this problematic for 2 reasons: >>> >>> 1. I have to remember to do this, and I'm not used to this modus >>> operandi; and >>> >>> 2. this is impossible to do on a slave that is configured automatically >>> from template files. On our slave servers, where we have around 5000 >>> zones, the zones are configured by templating out a knot.conf. Adding >>> zones is fine, but if a zone is being deleted, it will just disappear >>> from knot.conf. We keep no state, and so I don't know which zone is >>> being removed, and cannot purge it before-hand. >>> >>> Now, the same is kind of true for Knot < 2.4. But... there is one major >>> difference. Under older versions of Knot, zone data was written into >>> individual files, and journals were written into individual .db files. I >>> can run a job periodically that compares zones in knot.conf with files >>> on disk, and delete those files that have no matching zones in the >>> config. This keeps the /var/lib/knot directory clean. >>> >>> But in newer versions of Knot, there is no way to purge the journal of >>> zone data once a zone is removed from the configuration. For an operator >>> like me, this is a problem. I would like "knotc zone-purge" to be able >>> to operate on zones that are no longer configured, and remove stale data >>> anyway. >>> _______________________________________________ >>> knot-dns-users mailing list >>> knot-dns-users@lists.nic.cz >>> https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users >> _______________________________________________ >> knot-dns-users mailing list >> knot-dns-users@lists.nic.cz >> https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users > > _______________________________________________ > knot-dns-users mailing list > knot-dns-users@lists.nic.cz > https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users > _______________________________________________ knot-dns-users mailing list knot-dns-users@lists.nic.cz https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
