Bug 173963

The modification of the /etc/sysconfig/named file occurs when you install / 
de-install the bind-chroot package.

Because you have bind-chroot installed, anytime you upgrade the bind-chroot
package, it will ensure that you have ROOTDIR=/var/named/chroot in 
/etc/sysconfig/named. 

The whole purpose of the bind-chroot package is to make named run in the 
chroot environment; if it did not ensure that ROOTDIR is set in the 
/etc/sysconfig/named file, it would be unable to ensure that named ran 
in a chroot.

At least this modification of the /etc/sysconfig/named file lets you quickly
find out the named configuration in an obvious manner, unlike some alternative
solutions, such as silently running named in a chroot if the bind-chroot 
package was installed. It is also the solution all Red Hat bind users are
familiar with over many years, since the first bind-chroot package
was shipped, and it is documented in RedHat manuals and in the
/etc/sysconfig/named file.

SOLUTION: if you don't want to run named in a chroot, 
          uninstall the bind-chroot package:
# rpm -e bind-chroot

Running named in a chroot is not necessary with SELinux in Enforcing mode, and
adds no extra security to that provided by SELinux in Enforcing mode. If you 
do not run SELinux in Enforcing mode, then you are recommended to run named
in a chroot. 

The bind-chroot package used to be installed by default when you selected 
the DNS Server during installation, so it will remain after upgrades - 
but I believe it no longer is installed by default, but is optional .

But surely if an install is going to modify a config file then it should save a
copy as named.rpmsave with appropriate message during the installation?
Rather than edit it.

You have to make allowance for people upgrading with bind-chroot installed but
disabled.

I don't like it when config files get automatically and silently edited without
any backup copy being made.

So, to stay on the main point - it isn't about whether bind-chroot should exist
or not - it is about whether installs should silently edit config files or
replace them verbosely.

The problem is that the install adds a extra ROOT= line to /etc/sysconfig/named
when there is already an entry that has been deliberately commented out (which
is the only way to disable chroot behaviolr).

The named install MUST conform to standard rpm behavior by saving and existing
configuration file as named.rpmsave or create named.rpmnew.

Why do RPM installs provide this behavior for installation of configuration
files if it isn't to protect users from DAMAGING destruction of configuration
files without warning.

Also, can I ask why you, Jason, consider that SeLinux obsoletes chrooted named,
yet you still allow installation to force named into chrooted behavior by
appending a ROOT= line to /etc/sysconfig/named?

If in fact SeLinux does obsolete chrooted named, then why isn't this munging of
a configuration file considered to be a bug?

Why has the spec file got this stupid bit of code, and similar, in it:

    if /usr/bin/test -r /etc/sysconfig/named && /bin/egrep -q '^ROOTDIR='
/etc/sysconfig/named; then 
        :;
    else 
        echo ROOTDIR="%{prefix}" >>/etc/sysconfig/named;
    fi

It this sort of hackery really up there with redhat standards?
At least you could drop the ^ from the '^ROOTDIR='.
You have had so many bug reports about this nonsense yet you create even bigger
mess in spec file with adhoc (bad) fixes. Goodness me!

The bind-chroot package has ALWAYS inserted ROOTDIR in /etc/sysconfig/named
if the '^ROOTDIR=' match failed, since its very first version.
If bind-chroot did not do this, it could not ensure that the chroot environment
was activated for named, which is its whole purpose .
For packages such as bind-chroot and caching-nameserver, whose whole purpose
is to provide server configuration ,  rules about modifying server configuration
files must be relaxed .
The bind-chroot package is no longer selected by default when you select to
install a DNS server during anaconda installation .
If you do not want to run named in a chroot, do not install the bind-chroot
package.
By choosing to install the bind-chroot package, you are asserting that you
want named to run in a chroot environment; if the bind-chroot package did
not ensure that named is to be run in a chroot, it would not be doing its job.
Hence, this issue is not a bug. 

(In reply to comment #5)
> By choosing to install the bind-chroot package, you are asserting that you
> want named to run in a chroot environment; if the bind-chroot package did
> not ensure that named is to be run in a chroot, it would not be doing its job.
> Hence, this issue is not a bug. 

It is the regular bind package that zaps the /etc/sysconfig/named badly, not the
bind-chroot package.  Maybe you need to put that silly stuff in the bind-chroot
package.

It really is a bug. You have a bind-chroot package that determines whether one
runs chrootedly yet the regular bind packages adds a variable that determines
whether named runs chrootedly.

bind-chroot is a sub-package of the main bind package.
The only places where the /etc/sysconfig/named ROOTDIR= setting may be modified
by the .spec file is in %post bind-chroot, where it may be added if not present, 
or in  %preun bind-chroot, where it may be removed if the last bind-chroot 
instance is being removed. The idea of bind-chroot is to give people a package 
to enable them to run named in a chroot environment (install bind-chroot) or 
run named outside the chroot (erase bind-chroot) without them ever having to
modify configuration files, and as such, it works quite well.

(In reply to comment #7)

> The only places where the /etc/sysconfig/named ROOTDIR= setting may be modified
> by the .spec file is in %post bind-chroot, where it may be added if not present, 


That simply is not true!
It adds it if it is present, albeit commented out.

Please, what could possibly wrong with changing the "^ROOTDIR=" to "ROOTDIR="?

> The only places where the /etc/sysconfig/named ROOTDIR= setting may be modified
> by the .spec file is in %post bind-chroot, where it may be added if not present, 

To clarify :


$ egrep -n '(^%.*chroot)|ROOTDIR' bind.spec
137:%package chroot
143:%description chroot
566:%files chroot
635:%post chroot
673:if /usr/bin/test -r /etc/sysconfig/named && /bin/egrep -q '^ROOTDIR='
/etc/sysconfig/named; then
676:  echo ROOTDIR="%{prefix}" >>/etc/sysconfig/named;
715:%preun chroot
725:    if test -r /etc/sysconfig/named && grep -q '^ROOTDIR='
/etc/sysconfig/named; then
727:      grep -v '^ROOTDIR='%{prefix} /etc/sysconfig/named > $named_tmp
735:%triggerpostun -n bind-chroot -- bind-chroot
738:   if test -r /etc/sysconfig/named && grep -q '^ROOTDIR='
/etc/sysconfig/named; then
741:      echo 'ROOTDIR='%{prefix} >> /etc/sysconfig/named


So the only places in the bind.spec file where the ROOTDIR= setting of
/etc/sysconfig/named may be modified are :
 1. In the bind-chroot %post script, if bind-chroot is being installed, 
    ROOTDIR MAY be added IF it is not already in /etc/sysconfig/named .
 2. In the bind-chroot %preun script, where if the last bind-chroot instance
    is being erased, ROOTDIR may be removed from /etc/sysconfig
 3. In the bind-chroot %triggerpostun, to invoke %preun logic for a previous
    release that did not test $1 properly.

Why not change "^ROOTDIR=" to "ROOTDIR=" ? 
 A) Then the ROOTDIR= may not be applied if /etc/sysconfig/named contained
    a '#ROOTDIR=' setting; this would defeat the purpose of bind-chroot.
 B) The default /etc/sysconfig/named contains comments such as:
'# ROOTDIR="/some/where"  --  will run named in a chroot environment.
'  
    Comments containing ROOTDIR= should not be removed if the bind-chroot
    package is erased.

Maybe you could add a line in spec file that would print on stderr:

    "Warning: this spec file has taken the liberty of modifying
/etc/sysconfig/named by adding the line ROOTDIR=/var/named/chroot even although
there was already a deliberately commented-out instance of that exact same line,
and because of circumstances beyond our control we have decided that it is
inappropriate to create this new file as named.rpmnew or to even kindly save
your carefully crafted file as named.rpmsave.  Thank you for using RedHat's
Fedora and we hope you wont feel inclined to move to Ubuntu or similar because
of our decidely impoverished coding practices".

As said in earlier comments, the bind-chroot package MUST ensure that 
the ROOTDIR= setting is in /etc/sysconfig/named - this is intentional
behavior, and not a bug .

(In reply to comment #11)
> As said in earlier comments, the bind-chroot package MUST ensure that 
> the ROOTDIR= setting is in /etc/sysconfig/named - this is intentional
> behavior, and not a bug .

Ok, but why cannot the old file be saved as named.rpmsave?
Isn't that the normal way of doing things?

/etc/sysconfig/named is marked %config(noreplace), so any new file that gets 
installed by the RPM is installed as /etc/sysconfig/named.rpmnew - so you
always have a default version of the file to refer to. 
If you do not want the bind-chroot environment to be enabled, then erase
the bind-chroot RPM .
For FC-5/Rawhide, bind-9.3.2-6 now provides the /usr/sbin/bind-chroot-admin
script, which can be run outside of the RPM upgrade/install process to enable 
or disable the bind-chroot environment - this script can be downloaded from:
  http://people.redhat.com/~jvdias/bind/bind-chroot-admin .
We won't be changing the way the bind-chroot package operates in FC-4.

bind-9.3.2-10.FC5 has been pushed for FC5, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.