This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 451450 - bind-chroot update overwrites user supplied ROOTDIR setting
bind-chroot update overwrites user supplied ROOTDIR setting
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: bind (Show other bugs)
5.2
All Linux
medium Severity urgent
: rc
: ---
Assigned To: Adam Tkac
:
: 452843 (view as bug list)
Depends On: 227600
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-14 13:21 EDT by Axel Thimm
Modified: 2014-11-21 12:13 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-20 17:16:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Axel Thimm 2008-06-14 13:21:20 EDT
+++ This bug was initially created as a clone of Bug #227600 +++

Description of problem:
The bind update overwrites any settings like

ROOTDIR=/some/other/path

with the default ROOTDIR

Version-Release number of selected component (if applicable):
9.3.4-x

How reproducible:
3/3 on FC6, 1/1 on FC5

Steps to Reproduce:
1.Use a custom ROOTDIR
2.upgrade bind packages
3.
  
Actual results:
ROOTDIR gets reset

Expected results:
Should not touch uncommented ROOTDIR setting

Additional info:
Hit me on FC5/FC6 alike and for consistency (?) filed under devel.

If the ROOTDIR is not to be changed by the user it should be hardcoded and not
part of sysconfig files. Otherwise the user's choice needs to be preserved.

Together with bug #226982 this bind update causes lots of grief on
(semi-advanced) bind/ldap server setups.

-- Additional comment from atkac@redhat.com on 2007-02-07 06:58 EST --
Could you tell me if this problem is caused by replacement of
/etc/sysconfig/named? And if old configfile is saved as .rpmnew? Thanks much, Adam

-- Additional comment from pnasrat@redhat.com on 2007-02-07 07:11 EST --
Also the full output of rpm -Uvv bind-*rpm would be helpful, is this 100%
reproducible?

-- Additional comment from axel.thimm@atrpms.net on 2007-02-07 08:06 EST --
(In reply to comment #2)
> Also the full output of rpm -Uvv bind-*rpm would be helpful, is this 100%
> reproducible?

I found the bug, see below. It is 100% reproducable, and is not related to rpm
mechanics.

(In reply to comment #1)
> Could you tell me if this problem is caused by replacement of
> /etc/sysconfig/named? And if old configfile is saved as .rpmnew?

After the update there is only the "new" /etc/sysconfig/named with the wrong
ROOTDIR in place, no *.rpmsave, *.rpmnew etc.

I took a closer look and found the bug (or feature): If bach-chroot is installed
on each upgrade of bind (which of course updates the bind-chroot subpackage) the
ROOTDIR is always reset to /var/named/chroot by

/usr/sbin/bind-chroot-admin --enable

The script seems to want to preserve ROOTDIR if found in /etc/sysconfig/named,
but fails due to setting BIND_CHROOT_PREFIX to the default value early in the
script and later only looking at ROOTDIR if BIND_CHROOT_PREFIX is empty, e.g. never.

The easiest fix is probably simply unconditionally calling rootdir at the top of
check_dirs.

bind-chroot-admin is going on with monopolizing ROOTDIR by removing it
completely when uninstalled. That should probably only happen iff ROOTDIR was
still the default.

Bottom line is: If one installs the current bind-chroot one is tied to
ROOTDIR=/var/named/chroot for as long as bind-chroot is installed. If this is
indended behaviour it should be loudly commented as such in
/etc/sysconfig/named. But I think the intended behaviour is to honour user
suppied ROOTDIR.

I suggest to source /etc/sysconfig/named at the very top and eliminate
BIND_CHROOT_PREFIX in favour of ROOTDIR everywhere.


-- Additional comment from atkac@redhat.com on 2007-02-07 11:49 EST --
Perfect catch. I've improved bind-chroot-admin script in fedora devel. Could you
tell me if problem is now solved, please? (with bind*-9.3.4-5.fc7, package will
be avaliable during day)

Regards, Adam

-- Additional comment from atkac@redhat.com on 2007-02-26 08:04 EST --
This could be fixed in bind-*9.3.4-3.fc6 . If this problem still exists, please
reopen.

Regards, Adam
Comment 1 Axel Thimm 2008-06-14 13:22:34 EDT
Looks like this fix didn't make it into RHEL. I got all my RHEL servers silently
knocked out by this upon upgrading from 5.1 -> 5.2.
Comment 2 Adam Tkac 2008-06-23 07:16:12 EDT
You are right, fix is in Fedora but currently not in RHEL
Comment 4 Adam Tkac 2008-06-26 05:36:21 EDT
*** Bug 452843 has been marked as a duplicate of this bug. ***
Comment 6 RHEL Product and Program Management 2008-07-03 16:25:11 EDT
This bugzilla has Keywords FutureFeature and thus does not meet the
release criteria for FasTrack. This FasTrack request has been denied.
This bugzilla must be addressed in a minor release.
Comment 9 RHEL Product and Program Management 2008-08-14 09:01:38 EDT
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Comment 10 Axel Thimm 2008-08-16 04:36:45 EDT
(In reply to comment #9)
> This request was evaluated by Red Hat Product Management for
> inclusion, but this component is not scheduled to be updated in
> the current Red Hat Enterprise Linux release. If you would like
> this request to be reviewed for the next minor release, ask your
> support representative to set the next rhel-x.y flag to "?".

My developer licenses do not include support or a support representative.

Still I think that if a package malfunctions on upgrades due to the user having done allowed customizations to the config files and when this package is as crucial as a domain name server it should be fixed in RHEL5 and not RHEL6.

Note that this behaviour has affected production systems that serve name zones. The failure is silent and asynchronous to the upgrade, which makes for access denials to the zone in question after the TTLs expire, which can be up to several days. So adding to the high impact this bug has you also have a lengthy diagnosis as cause and effect are separated.
Comment 15 errata-xmlrpc 2009-01-20 17:16:23 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 therefore 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-2009-0246.html

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