Red Hat Bugzilla – Bug 143786
Several problems with bind-9.2.4-5_EL3 errata
Last modified: 2007-11-30 17:07:05 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Description of problem:
While upgrading from bind-9.2.4-EL3_10 to bind-9.2.4-5_EL3 several bad
things happened on my RHES3 system:
1. named.conf is now named.conf.rpmsave. The newly created named.conf
is completely useless as all local changes are now in named.conf.rpmsave.
2. named does not start anymore automatically after system reboot.
Running ntsysv shows that the named service is set to off. I thought
exactly this should have been fixed with this errata. Quote from the
"Previously, upgrading from bind-9.2.4-EL3_10 stopped the named server
and removed the named service. This update preserves the named service
state across upgrades."
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. update named to bind-9.2.4-5_EL3
Firstly, the bind package does not touch named.conf or any named
The caching-nameserver package always does replace named.conf and
saves any existing named.conf as named.conf.rpmsave - this packages
consists entirely of the named configuration files and could not
install / update itself if it did not provide these files.
Upgrade from bind-9.2.4-EL3_10 to bind-9.2.4-5_EL3 was thorougly
tested, and the state of the named service was always preserved
after upgrade. Which version of bind were you upgrading from?
As already stated above I upgraded from bind-9.2.4-EL3_10 to
Wouldn't it make more sense for caching-nameserver to provide its
config files as *.rpmnew files during update instead of replacing all
the previously working files and leaving named in an unusable state?
Named should never have been left in an unusable state - this is the
core problem of this bug and will be remedied.
Possibly there are problems upgrading from previous releases of
caching-nameserver which have not been caught during testing.
caching-nameserver HAS to backup and replace the BIND configuration
files - it consists entirely of them .
By installing caching-nameserver, users are requesting that a
caching only nameserver configuration be installed. If the caching
nameserver RPM did not replace the configuration files, there would
be no way for it to guarantee that after installation, a caching
nameserver was in place; nor could it be upgraded.
If this is not what you want, backup the BIND configuration files
and remove the caching-nameserver RPM from the system.
Please, if anyone is reading this bug before upgrading from
bind-9.2.4-EL3_10 to bind-9.2.4-5_EL3, do:
2>&1 | tee /tmp/bind-upgrade.log
and append the /tmp/bind-upgrade.log to this bug report or send it
I've run the above command on all the RHEL-3 platforms available to
me with no errors or problems observed.
It seems the only reproducible problem from this bug report is that
the named service is still off after upgrade from bind-9.2.4-EL3_10
to bind-9.2.4-5_EL3 .
The caching-nameserver package does back up and replace the user's
customized configuration files, but always does leave in place the
default "caching-only-nameserver" configuration that does allow
named to run and function as a caching-only-nameserver - see the
points made in comment #3 above - and this is "not a bug" .
Reviewing the CVS versions, I've found the sysv-init problem:
From the very first version of the /etc/init.d/named script
(named.init), no default chkconfig levels were specified:
# named This shell script takes care of starting and stopping
# named (BIND DNS server).
# chkconfig: - 55 45
These lines have remained unchanged since version 8.2.3-1 of
Red Hat BIND.
That means that it was up to administrators to do something like :
# chkconfig --level=345 named on
# chkconfig --level=0126 named off
So, what happens during upgrade is:
1. bind-9.2.4-5_EL3 is installed
2. bind-9.2.4-EL3_10 (brokenly) does "chkconfig --del named" when
it is erased during upgrade.
3. bind-9.2.4-5_EL3 does restart the server if it was running before
upgrade, and does " chkconfig --add named " - but this is not
enough, because /etc/init.d/named does not specify default
So what needs to happen is to record the current runlevels of named
in bind-9.2.4-EL3_10's '%triggerpreun' and restore them in its
'%triggerpostun' . bind-9.2.4-6_EL3 will do so, and will be available
while being pushed to RHEL-3 updates .
bind-9.2.4-6_EL3 is now available at:
and will be pushed to RHEL-3 updates .
bind-9.2.4-7_EL3 will be in RHEL-3-U5 and fixes all remaining problems
with upgrades from previous BIND releases.
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.