+++ This bug was initially created as a clone of Bug #202012 +++ Description of problem: A custom named.conf contains include "/etc/rndc.key" rndc.conf prior to the U8 update also contained include "/etc/rndc.key" The U8 update changes rndc.conf to include a hardcoded key statement instead of /etc/rndc.key. This results in rndc nolonger being able to authenticate itself to named. Version-Release number of selected component (if applicable): 9.2.4-14_EL3 How reproducible: Consistently Steps to Reproduce: 1. Existing named.conf must contain include "/etc/rndc.key" 2. Existing /etc/rndc.conf must be unmodified (so it will be updated during the upgrade) 3. Upgrade from 9.2.4-7_EL3 to 9.2.4-14_EL3 4. service named status Actual results: rndc: connection to remote host closed This may indicate that the remote server is using an older version of the command protocol, this host is not authorized to connect, or the key is invalid. Expected results: rndc status output Additional info: Checking a clean install of bind-9.2.4_14_EL3 on a pristine machine that's never seen bind before also produces a non-working config. That is one where the default named.conf includes /etc/rndc.key but /etc/rndc.conf hardcodes a different key. -- Additional comment from stransky on 2006-08-10 08:10 EST -- Thanks for the report. -- Additional comment from tis on 2006-08-16 03:19 EST -- from bind.spec file: #%patch1 -p1 -b .key # This patch now in 'bind-9.2.4-5.backport.patch' This might be true but there is no bind-9.2.4-5.backport.patch in spec. There is: Patch9: bind-9.2.4-5_backport.patch which doesn't include necessary bits for rndc.conf patching. Enabling Patch1 again fixes this problem. -- Additional comment from tis on 2006-08-16 03:22 EST -- Oh. and this same bug affects rhel-4U4 users.
Created attachment 134429 [details] proposed patch
bind-9.2.1-key.patch really fixes this problem, unfortunately it isn't included in 4.4
So does that mean there will be an update to fix this soon?? Essentially this has broken all of the previously working bind configs for el3 and el4. Yes, I know once you understand what happened, it is easy to fix but that is not the point.
It seems that the real cause is that the key in chroot /var/named/chroot/etc/rndc.key differ from one provided in /etc/rndc.conf. This may be caused by a bug in pre or post scripts. They are really ugly and very complicated.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Fixed srpm packages (for RHEL3 and RHEL4) are here: http://people.redhat.com/stransky/bind/
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2006-0711.html
The RPM package for the errata does not seem to be available. Can someone push this to RHN? Thanks. Shawn.
Nevermind it's under 'Fastrack'
For those who has broken config: copy secret from /etc/rndc.conf (this could be a symlink to /var/named/chroot/etc/rndc.key if you have bind-chroot installed) to the secret in /etc/rndc.conf.
For those who has broken config: copy secret from /etc/rndc.conf (this could be a symlink to /var/named/chroot/etc/rndc.key if you have bind-chroot installed) to the secret in /etc/rndc.key (TYPO FIX).
bind-9.2.4-20.EL4 worked. But why was this fix put into the Fastrack channel? Shouldn't it be a normal bug fix update? This involves a relatively severe problem for BIND administrators, especially if dynamic and static updates are used together: when terminating named with `service named stop', /usr/sbin/rndc doesn't work and failsafing killproc is actually used in the /etc/init.d/named script. So .jnl dynamic update caches won't be flushed and zone files are still obsolete after the termination.
Will be fixed in bind-9.2.4-24.EL4 and it's on the way.
Hello Uwe, this will be fixed in bind-9.2.4-24.EL4 and it's fixed in an errata on RHN https://rhn.redhat.com/network/software/packages/details.pxt?pid=382408 Hence closing this issue. Kind regards, Steffen Internal Status set to 'Resolved' Status set to: Closed by Client Resolution set to: 'RHEL 4.5' Ticket type set to: 'Problem' This event sent from IssueTracker by smann issue 100769