Bug 57460 - rndc.conf has an error
Summary: rndc.conf has an error
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: bind   
(Show other bugs)
Version: 7.2
Hardware: i386 Linux
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-12-13 01:46 UTC by Zenon Mousmoulas
Modified: 2007-04-18 16:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-01-23 10:46:36 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Zenon Mousmoulas 2001-12-13 01:46:29 UTC
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):

How Reproducible:

Steps to Reproduce:
1. service named start
2. rndc status

Actual Results:

Expected Results:

Additional Information:

Comment 1 Bernhard Rosenkraenzer 2002-01-22 12:37:48 UTC
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.

Comment 2 Zenon Mousmoulas 2002-01-23 00:12:24 UTC
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.

Comment 3 Zenon Mousmoulas 2002-01-23 02:36:09 UTC
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 

Comment 4 Zenon Mousmoulas 2002-01-23 02:47:34 UTC
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.

Comment 5 Bernhard Rosenkraenzer 2002-01-23 10:46:30 UTC
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.

Comment 6 Bernhard Rosenkraenzer 2002-01-23 10:49:33 UTC
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.

Comment 7 Zenon Mousmoulas 2002-01-23 13:15:46 UTC
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 :)

Note You need to log in before you can comment on or make changes to this bug.