Hide Forgot
Description of Problem: The default /etc/rndc.conf, which is supposed to make it possible for rndc to control named on the localhost out of the box, has an error: (lines 33-36) key "rndckey" { algorithm hmac-md5; secret "@KEY@"; }; I suppose "@KEY@" is a variable that was supposed to be replaced by an rpm post-install script that creates the rndckey secret. However, that doesn't seem to work :) If you run 'rndc -c somebogusconfig -k /etc/rndc.key' the key is read from the key file and connection to named works. 'somebogusconfig' can be a valid config or even a file that doesn't exist, as long as you bypass the defaults from the misconfigured rndc.conf. '-k /etc/rndc.key' is also not needed, because it is the default. Another easier solution is to just copy the correct key from rndc.key in the config (rndc.conf). ***Please pay attention that this problem only affects the version of the bind package currently in RawHide, i.e. bind-9.2.0-1. The default package in RHL 7.2 is not affected. Version-Release number of selected component (if applicable): bind-9.2.0-1 How Reproducible: Always Steps to Reproduce: 1. service named start 2. rndc status 3. Actual Results: Expected Results: Additional Information:
This could be related to the updating process... Do you still see this if you uninstall and reinstall the package? What happens is the following: @KEY@ is replaced with a random key if /etc/rndc.conf.rpmnew doesn't exist (we don't want to touch an edited /etc/rndc.conf, so if /etc/rndc.conf.rpmnew exists, we assume /etc/rndc.conf was left over from your previous config and the new sample file is /etc/rndc.conf.rpmnew). I can't see anything else that would cause this to fail. Please confirm this is the problem; then I'll have to think of a new way of detecting whether or not we should mess with /etc/rndc.conf.
bero@redhat.com wrote: @KEY@ is replaced with a random key if /etc/rndc.conf.rpmnew doesn't exist (we don't want to touch an edited /etc/rndc.conf, so if /etc/rndc.conf.rpmnew exists, we assume /etc/rndc.conf was left over from your previous config and the new sample file is /etc/rndc.conf.rpmnew). According to this, and afaik, a modified config file shouldn't be touched at all. Instead it's written to .rpmnew. Let's assume /etc/rndc.conf was modified since I don't remember anymore if it was, so the new sample config should be written ton /etc/rndc.conf.rpmnew. If I understand right, you mean my modified /etc/rndc.conf contained this "@KEY@" string as the secret in the key "rndckey" statement. That just can't be right for two reasons. First of all I don't remember finding any /etc/rndc.conf.rpmnew after upgrading to this rawhide package, but OK maybe I don't remember right. Second and most important though, rndc used to work before the upgrade (without the workarounds I noted in my original posting). So I find it rather unlikely I could have left this by accident in that file, because rndc would then also fail before the upgrade, which I am rather sure was not happenning. In any case I will uninstall bind after backing up config files and zones and reinstall; then I can answer your question.
Hrm well unfortunately I can't get a copy of bind-9.2.0-1.i386.rpm anymore, or any of the other required packages in the same version, since it has been replaced in rawhide by bind-9.2.0-2. The changelog says 9.2.0-2 is just an automated rebuild so the reported behavior shouldn't have changed, but I really can't be sure about that. In any case, I uninstalled 9.2.0-1, wiped .rpmsave configs and installed bind-9.2.0- 2, and it doesn't create any erroneous rndc.conf like the one I reported. Anyway I recognize it could have been some mistake on my end, although it certainly didn't seem so at the time I reported this bug. If I did not make some mistake, I really don't know what else to think anymore. But I guess it doesn't matter anymore because the current package from rawhide installs correctly. I hope and expect it also does upgrade and freshen installations (from the bind-9.1.3-4 RHL 7.2 package) without problems too, but again I can't say for sure. I suggest you close this bug, unless you feel it requires further investigation. I would close it myself, but I am not sure which resolution is appropriate.
On a final note, I noted that /etc/rndc.conf contains a key statement which is duplicated from /etc/rndc.key. /etc/named.conf includes /etc/rndc.key. I suggest that if rndc config file syntax allows include statements, then /etc/rndc.conf should also use that instead, because that would be more efficient: you would only need to change the key in one file, then both named and rndc would be instantly aware of the new key. It doesn't look like file permissions could break such a setup, since in the current setup both /etc/rndc.conf and /etc/rndc.key are only readable by users of the group named and root. I won't open a new bug for this suggestion, since it's such a minor issue. If you wanna consider it for future builds, fine, if not, np :) Again, thanks for your help.
What might have happened is the following: You installed the system. You upgraded bind, which created a rndc.conf.rpmnew file You upgraded bind again, it noticed the rndc.conf.rpmnew file from the previous installation (even though it replaced rndc.conf itself), so didn't make any changes to rndc.conf after that. I agree that ideally, rndc.conf would just include rndc.key - unfortunately, at least last time I checked (9.1.2) rndc.conf didn't support include statements. I'll try again with 9.2.0.
Ok, rndc.conf supports include statements in 9.2.0. Changed to use that in 9.2.0-3, making further breakages like this one impossible.
OK that's right, the scenario you suggested could have happened indeed during such an upgrade process, however I only upgraded once and not twice: bind- 9.1.3-4 (RHL 7.2) to bind-9.2.0-1 (rawhide) so I still don't know how it would be possible for rpm to act like that. Nevertheless, wouldn't such a behavior be a problem in rpm? I mean the way you said it replaces /etc/rndc.conf but it doesn't proceed with variable substitutions if .rpmnew already exists? I would expect it to simply replace /etc/rndc.rpmnew and do all substitutions in that file. Thanks again for accepting my suggestion. This is my last posting here, promise :)