exec of rndc reload fails

[exptom]

If a domain is in 2 or more views the rndc exec fails because it has a duplicate name.

[exptom]

I've hit another problem with this. I have zones in multiple views but the rndc exec just does rndc reload <domain>, what it needs to do is rndc reload <domain> in <view> for each of the views that the zone is a part of.

[exptom]

Ok, I've had another attempt at making this work. Now when a managed zone config is created/updated rndc dumpdb -zones is run to create a file containing a list of zones and their views.
Then when a managed zone does an rndc reload is uses that dump to reload the zone in each of it's zones.

[inkblot]

I think the reload command probably just needs the class and view parameters supplied in that case. E.g. rndc reload example.com IN public. All of my split zones are dynamic, and reload doesn't work for dynamic zones, but I do see different error messages:

[inkblot@dorothy:~]$ sudo rndc reload movealong.org
rndc: 'reload' failed: not found
[inkblot@dorothy:~]$ sudo rndc reload movealong.org IN internet
rndc: 'reload' failed: dynamic zone
[inkblot@dorothy:~]$ sudo rndc reload movealong.org IN movealong
rndc: 'reload' failed: dynamic zone

[inkblot]

Now that I think about it, that would actually be quite hard to do, since the zones are included in a view post-definition rather than being defined in the view.

[exptom]

@inkblot Yes, specifying the class and view of the zone allows the reload to work. My second attempt at a fix uses the rndc dumpdb command to find which views a zone is part of. This is quite hacky but could not figure out a cleaner way to do this because as you point out the zones are included in a view post-definition.

[inkblot]

I'm going to take a look at what would be necessary to flip that around so that it doesn't have to be hacky.

[inkblot]

Short of a breaking API change, I can't think of any other way.

[inkblot]

Only slightly less hacky:

/bin/grep "; Zone dump of '${_domain}/" ${cachedir}/named_dumb.db | /bin/sed -e "s#^.*'\\(.*\\)/\\(.*\\)/\\(.*\\)'\$#\\1 \\2 \\3#" | while read Z; do /usr/sbin/rndc reload $Z; done

Key differences:

1. It's a little shorter.
2. The initial grep matches all the way to the first /. This prevents extraneous reloads in cases like, e.g. collaterally reloading exmaple.com and example.co.uk in addition to an intentional reload of example.co.
3. Rather than extract the view as a shell variable, just feed the tuple from the dump back into the rndc command as parameters.

[exptom]

One problem that I have just hit with my method (and will also affect your version) is that sometimes this fails when adding a brand new zone.
Because calling rndc dumpdb -zones is asynchronous (it returns instantly and leaves bind creating the dump in the background) then sometimes if it doesn't complete quickly enough so the rndc reloadstep will fail because it can't find that zone in the dump.

I'm not sure how to resolve this - adding an artificial sleep XX before the reload exec is all I could think of but that is horrible as depending on the size of your bind setup the dump time is going to vary considerably.

Any ideas?

[inkblot]

I kind of had an idea that I spent an hour on yesterday that I couldn't get to work. The idea I had was to have puppet drop hints onto the system separate from the BIND configuration that the exec resource could use to construct correct rndc invocations. I tried a couple of different strategies.

The first approach I tried was to add formatted comments to the views.conf file that the exec could match and format into an rndc reload sort of how your original solution gets it out of a db dump. We mortals have a habit of naming things consistently, but the view doesn't actually know what the domain in a "zone" is, it's just including an arbitrarily name file that happens to declare a zone. So that won't work because the right information still isn't available.

The second approach I tried might be made to work, but I didn't have the energy yesterday to think it all the way through. It was to use a concat file to build up a rndc-helper script. The idea was to have a script that would take the bind::zone name as a final parameter, replace it with the domain/class/view tuple that rndc wants and then invoke rndc with all of the leading parameters and the tuple. The view would have to add the information it knows and the zone would add the information it knows (the zone name to view name mapping) and the zone would add the information it knows (the zone name to domain name mapping). I got hung up on structuring the data in the script.

Now that I'm back at the keyboard I'm inclined to try the script idea again, but instead of templating the data into the script, just write a script that can read mappings that are written out to some other simple mapping. ini_setting may be useful here.

[exptom]

I too was thinking about possible solutions last night and I am wondering if it might be possible to do something with puppet virtual resources to collect the relevant information from the view declarations then realize the updated zones in the form of the rndc reload. If I get some time later this week I will try playing around with the idea.

[inkblot]

Ok. I have a thing that I think works, but none of my zones anywhere have $zone_file_mode set to managed. I went with the /usr/local/bin/rndc-helper and mappings files output by bind::zone and bind::view as configuration. Using this script I was able to freeze and thaw one of my dynamic zones by its zone name instead of its domain. Could you try out the rndc-helper branch and let me know how it works out?

[exptom]

Thanks for your work on this. It looks to be working well once the 2 fixes in #98 are applied.