Hi I often run named outside of the system default directories so that amongst other things a mergemaster fumble doesn't break my name servers. This however breaks rndc because it is not imbued with the clue of where to find its key. /etc/rc.d/named does create the key file in the correct place according to the configured chroot directory. The reload section just doesn't tell rndc where to find it. Can I suggest for a minimal change: --- /usr/src/etc/rc.d/named 2013-04-15 20:17:58.000000000 +0200 +++ /etc/rc.d/named 2013-04-24 16:16:52.000000000 +0200 _at__at_ -109,7 +109,7 _at__at_ named_reload() { - ${command%/named}/rndc reload + ${command%/named}/rndc -k ${named_confdir}/rndc.key reload } find_pidfile() A more invasive change: The bind9 reference suggests that named loading rndc.key is for backwards compatibility. "Since the rndc.key feature is only intended to allow the backward-compatible usage of BIND 8 configuration files, this feature does not have a high degree of configurability. You cannot easily change the key name or the size of the secret, so you should make a rndc.conf with your own key if you wish to change those things. So, I 'include "path/to/rndc.key";' in named.conf, add a controls section that uses this named key and I use the following rndc.conf: ---named.conf--- include "/etc/namedb/rndc.key"; controls { inet 127.0.0.1 allow { 127.0.0.1; } keys { "rndc-key"; }; }; ---named.conf--- ---rndc.conf--- include "/etc/namedb/rndc.key"; options { default-server localhost; default-key rndc-key; }; server localhost { key rndc-key; }; ---rndc.conf--- And the following version of the above patch: --- /usr/src/etc/rc.d/named 2013-04-15 20:17:58.000000000 +0200 +++ /etc/rc.d/named 2013-04-24 16:16:52.000000000 +0200 _at__at_ -109,7 +109,7 _at__at_ named_reload() { - ${command%/named}/rndc reload + ${command%/named}/rndc -c ${named_confdir}/rndc.conf reload } find_pidfile() this will allow the rc system to reload and stop named (without a kill) no matter what the configured chroot is. Ian -- Ian FreislichReceived on Wed Apr 24 2013 - 12:36:03 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:36 UTC