This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 131803 - Bind replace /etc/sysconfig/named during upgrade
Bind replace /etc/sysconfig/named during upgrade
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
Ben Levenson
: 133028 (view as bug list)
Depends On:
Blocks: 123574
  Show dependency treegraph
Reported: 2004-09-04 18:08 EDT by Milan Kerslager
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version: bind-9.2.4rc7-11_EL3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-08 13:09:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:

Attachments (Terms of Use)

  None (edit)
Description Milan Kerslager 2004-09-04 18:08:59 EDT
Even I tryed latest development version (9.2.4rc7-10) I went to the
trouble because /etc/sysconfig/named has been replaced nad CHROOT line
was lost during update.

I have caching-nameserver and bind-chroot installed.

The bugs in init scripts and disappearing od named.conf and rndc.key
has been resolved but this bug is still here (RHEL3 U3 troubles).
Comment 1 Milan Kerslager 2004-09-04 18:16:12 EDT
The second problem is that after removing bind-* packages my config
/var/named/chroot/etc/named.conf and /var/named/chroot/etc/rndc.key
has been removed (not saved as *.rpmsave).

This is really broken package...
Comment 2 Milan Kerslager 2004-09-05 02:02:26 EDT
Also the scripts make named.conf.rpmsave and on the second run
named.conf.rpmsave.rpmsave and then named.conf.rpmsave.rpmsave.rpmsave
and so on. The same with rndc.key.
Comment 3 Zenon Panoussis 2004-09-06 06:26:08 EDT
Same problems with the recently released bind-9.2.4-EL3_10. The moment
you upgrade, DNS is broken. 
Comment 4 Zenon Panoussis 2004-09-06 06:44:23 EDT
The script /etc/rc.d/init.d/named is broken too (on 9.2.4-EL3_10). 
After fixing /etc/sysconfig/named by adding ROOTDIR=/var/named/chroot,
the new init script fails to chroot anyway. Using the init script from
RHEL bind-9.2.2-21 on 9.2.4-EL3_10 works just fine. 
Comment 5 Milan Kerslager 2004-09-07 13:23:38 EDT
It has been reported as bug #131553 and closed as fix in FC Devel tree.
Comment 6 Jason Vas Dias 2004-09-07 14:18:57 EDT
These problems will be fixed in bind-9.2.4rc7-10_EL3:
 1. On upgrade from earlier bind-chroot releases (eg. bind-9.2.2),
    which list /etc/{named.conf,rndc.key} and other files in their
    %files list, after upgrade to the later version RPM does an
    erase of the previous version, removing these files. These files
    are now %ghost-ed, which fixes issues about missing named.conf
    files. This was fixed in bind-chroot-9.2.4rc7-10 (latest version
    in development).
 2. The initscript should be invoking named-checkconf with the 
    "-t $ROOTDIR" option if ROOTDIR is in /etc/sysconfig/named.
    This was also fixed in the current bind-9.2.4rc7-10 version.
 3. The bind-chroot package's '%preun' (uninstall) script removes
    'ROOTDIR=' from /etc/sysconfig/named, which is added by the 
    %post script. During an upgrade, RPM executes the old package's
    %preun script AFTER the new package's %post script, wiping out
    'ROOTDIR=' - this seems like an RPM bug to me, but I am trying
    to develop a workaround. 
    No package replaces /etc/sysconfig/named . 

    Interestingly, this does NOT happen if you do an 
    'rpm -Uvh --force' of the new bind-chroot-9.2.4-EL3_10 package .
    which is the current best workaround.
Comment 7 Jason Vas Dias 2004-09-07 16:52:42 EDT
  Unfortunately, versions of bind-chroot prior to 9_2_2_P3-5 
  ( Oct 8 2003 , of which bind-chroot-9.2.2-21 is one)
  did not protect their '%preun' script with 
  'if [ "$1" = "0" ]; then...{remove ROOTDIR line}'
  which all versions since have done.

  This means that upgrading from any bind release earlier than
  bind-chroot-9_2_2_P3-5 will result in the 'ROOTDIR=' line being 
  removed from /etc/sysconfig/named ;  no problems will occur
  upgrading from subsequent releases. There is nothing that 
  the RPM scripts of current bind-chroot releases can do to 
  rectify this.

  The workaround is, after upgrading from a a bind-chroot version
  earlier than bind-chroot-9_2_2_P3-5 to a later version, to 
  reinstall the later version with 'rpm -U --force bind-chroot-*.rpm'.
  I will add this to the release notes for bind.

  All other issues mentioned in this bug are fixed by the new bind
  release: bind-9.2.4rc7-10_EL3, submitted to 3.0E-U4 and which will
  be available for download (tomorrow onwards) at: 

  Hence, this bug is being closed .

Comment 8 Zenon Panoussis 2004-09-08 07:05:14 EDT
> will be available for download (tomorrow onwards) at:

Thank you. But, since the latest bundle of RHEL updates is still very
recent, you coul perhaps consider releasing the fixed rpm as an
official update on ftp/rhn. 
Comment 9 Jason Vas Dias 2004-09-08 10:04:25 EDT
Unfortunately the RHEL-3-U3 release is now closed. The new
bind-9.2.4rc7-10_EL3 release is now at: 
and will be in RHEL-3-U4 .
Comment 10 Jason Vas Dias 2004-09-08 13:08:46 EDT
It turns out there was something the new bind-chroot version's 
RPM scripts could do about the broken %postun script in 
bind-chroot-9.2.2-21 : bind-chroot now contains a 
"%triggerpostun" that will replace the "ROOTDIR=" if removed
by bind-chroot-9.2.2-21's %postun.
This is now in bind-9.2.4rc7-11_EL3.
Comment 11 Jason Vas Dias 2004-09-10 16:45:09 EDT
This bug is now fixed in bind-9.2.4rc7-11_EL3, that will be in 
RHEL-3-U4 - meanwhile, you can download it from : 
You may need to do a 'service named restart' after downloading
(bug 132303).
Comment 12 Zenon Panoussis 2004-09-10 19:13:35 EDT
On the machine where the update from 9.2.2-21 to 9.2.4-EL3_10 caused
the problems described above, I now updated to 9.2.4rc7-11_EL3. After
that, named would not start at all, nor put any error message in the
logs. So I forced a re-installation of bind-chroot, and that revealed
the cause of the problem:

# rpm -Uhv --force bind-chroot-9.2.4rc7-11_EL3.i386.rpm
########################################### [100%]
   1:bind-chroot            warning: group named does not exist -
using root
warning: group named does not exist - using root%)
warning: group named does not exist - using root%)
warning: group named does not exist - using root%)
warning: group named does not exist - using root%)
warning: user named does not exist - using root5%)
warning: group named does not exist - using root
warning: user named does not exist - using root4%)
warning: group named does not exist - using root
warning: group named does not exist - using root%)
warning: user named does not exist - using root3%)
warning: group named does not exist - using root
warning: user named does not exist - using root3%)
warning: group named does not exist - using root
########################################### [100%]
chown: `root:named': invalid group
chown: `root:named': invalid group
chown: `root:named': invalid group
chown: `named:named': invalid user
chown: `named:named': invalid user

How could that happen? 

Instead of re-creating the user and group manually, I run 
 rpm -Uhv --force bind-9.2.4rc7-11_EL3.i386.rpm
Now the named UID:GID existed and bind attempted to start, but failed
because the chroot wasn't working. 
 rpm -Uhv --force bind-chroot-9.2.4rc7-11_EL3.i386.rpm
corrected that too and bind got back to service. 

Something is still fishy with those rpms. 

Comment 13 Jason Vas Dias 2004-09-20 19:13:33 EDT
*** Bug 133028 has been marked as a duplicate of this bug. ***
Comment 15 Jason Vas Dias 2004-10-19 09:49:19 EDT
 This bug is fixed in RHEL3 with bind-9.2.4-1_EL3 .
Comment 16 John Flanagan 2004-12-21 14:49:55 EST
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.

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