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
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
rawhide
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:
Environment:
Last Closed: 2004-09-08 13:09:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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:
  http://people.redhat.com/~jvdias/bind/RHEL-3 

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

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.

http://rhn.redhat.com/errata/RHBA-2004-567.html

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