Bug 131803

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...

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.

Same problems with the recently released bind-9.2.4-EL3_10. The moment
you upgrade, DNS is broken. 

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. 

It has been reported as bug #131553 and closed as fix in FC Devel tree.

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.

  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:
  http://people.redhat.com/~jvdias/bind/RHEL-3 

  Hence, this bug is being closed .


  
   
  
   

> will be available for download (tomorrow onwards) at:
> http://people.redhat.com/~jvdias/bind/RHEL-3 

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. 

Unfortunately the RHEL-3-U3 release is now closed. The new
bind-9.2.4rc7-10_EL3 release is now at:
    http://people.redhat.com/~jvdias/bind/RHEL-3 
and will be in RHEL-3-U4 .

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.

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 :
 http://people.redhat.com/~jvdias/bind/RHEL-3 
You may need to do a 'service named restart' after downloading
(bug 132303).

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
Preparing...               
########################################### [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. 

*** Bug 133028 has been marked as a duplicate of this bug. ***

 This bug is fixed in RHEL3 with bind-9.2.4-1_EL3 .

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-2004-567.html