Bug 176388 - named.conf should be marked 'noreplace'
Summary: named.conf should be marked 'noreplace'
Alias: None
Product: Fedora
Classification: Fedora
Component: caching-nameserver
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jason Vas Dias
QA Contact: David Lawrence
Depends On:
Blocks: FC5Blocker
TreeView+ depends on / blocked
Reported: 2005-12-22 01:09 UTC by David Woodhouse
Modified: 2013-01-10 03:40 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-03-09 03:44:05 UTC
Type: ---

Attachments (Terms of Use)

Description David Woodhouse 2005-12-22 01:09:12 UTC
Both my ISP's primary nameservers stopped working yesterday after a yum update
scribbled on named.conf.

If the caching-nameserver package is going to be installed as part of a default
installation (which it is), then the shipped named.conf _really_ ought to be

Comment 1 Jason Vas Dias 2005-12-22 02:02:34 UTC
I'm very sorry for any problems caused by caching-nameserver updates.

The named.conf file is a %config file, so an existing, modified named.conf 
is backed up to named.conf.rpmsave.

caching-nameserver should NOT be a package installed by default; if it is,
I'll have a word with the anaconda maintainers about this - checking.
The caching-nameserver package consists ONLY of the bind configuration files
to provide a caching-only nameserver. 

It should ONLY be installed if the user wants to run a caching-only nameserver,
and do not want to maintain their own modified bind configuration files.

If users want only default named configuration files which they intend to 
modify, they should remove any existing named.conf and run 'system-config-bind'
- this will install a default configuration, and not end up owning the
configuration files - plus making it easy to set up and maintain a modified 
bind configuration.

Users need to be able to rely on a caching only nameserver being in place after
installation of caching-nameserver; caching-nameserver needs to be able to ship
updated named configuration files, and not have them saved as .rpmnew files .
Sorry, but for the reasons given above, this has to be NOTABUG.

Comment 2 David Woodhouse 2005-12-22 02:09:44 UTC
I believe NetworkManager depends on caching-nameserver, and there's definitely a
case for NetworkManager being part of a normal installation (although it doesn't
seem to be present in a default rawhide install I did a few days ago). 

Users who haven't manually edited /etc/named.conf _can_ rely on the caching
nameserver being in place after installing the package. Users who _have_
manually edited it really shouldn't have their changes stomped on. I really
think it should be 'noreplace'.

Comment 3 Bryce 2006-01-08 12:44:57 UTC
*sigh* THIS is a bug guv

[root@emerald ~]# rpm -q --whatrequires caching-nameserver

ok so caching-nameserver does get dragged in without anyone really noticing

[root@emerald ~]# rpm -q --scripts caching-nameserver
postinstall scriptlet (using /bin/sh):
if  grep ^nameserver /etc/resolv.conf >/dev/null 2>&1 ; then
    echo "nameserver" >> /etc/resolv.conf;
if test -r /etc/sysconfig/named ; then
        . /etc/sysconfig/named
        if [ ! -z $ROOTDIR ]; then
           for f in /etc/named.conf

              if [ ! -L $f ]; then
                 if [ -f $ROOTDIR$f ]; then
                    mv $ROOTDIR$f $ROOTDIR$f.rpmsave;
                 /bin/mv $f $ROOTDIR$f
                 ln -s $ROOTDIR$f $f;

NOTE no attempt to restart the service is made

Person sets up named.conf and populates it
person restarts named  all great nothing  bad is happening

This goes on and the named.conf is populated with X number of zones and after a
few trial runs everyone is happy and the config is left set in stone.
Meanwhile a while later 'yum update' sneaks in an updated copy of

what happens is that because named is running in memory with a memory copy of
named.conf the caching-nameserver update changes are NOT loaded so no indication
has been given that named.conf has been moved out of the wa. No one checks
because named s running from the memory copy.....

Tim goes on and another set of updates comes out  with caching-nameserver in the
midst. What happens now is that the previously saved copy of named.conf is
overwritten and al those details are LOST but the in memory copy os name is
still happy since it only read the file at startup and has not been required to
go reread the named.conf file.

For whatever reason (viro discovers kernel root hole exploit) we now have to
reboot the box....
now lo and behold WTF is our named.conf and our DNS definitions????
oh in the rpmsave you say? WRONG!


dwmw2's ISP folk are not the only people to have hit this


Comment 4 Warren Togami 2006-03-06 15:46:01 UTC
This issue has the potential to bite us hard during FC5+.  Any suggestions about
what to do?

(Adding folks vaguely related to NetworkManager, which is pulling in the
problematic package.)

Comment 5 Jason Vas Dias 2006-03-06 15:53:16 UTC
I am fixing this with bind-9.3.2-6 today.

Now, there will be a new 'bind-config' bind sub-package, which will both:
 'Obsoletes: caching-nameserver
  Provides:  caching-nameserver
and which will NOT provide $ROOTDIR/etc/named.conf, but which will provide
$ROOTDIR/etc/named.caching-nameserver.conf . No package will provide 
named.conf at all.

The named initscript will be changed to invoke named with the
  '-c named.caching-nameserver.conf'
argument IFF $ROOTDIR/etc/named.conf does not exist and 
$ROOTDIR/etc/named.caching-nameserver.conf does.

I'm still testing this, but so far it looks OK - caching-nameserver gets
removed, and NetworkManager picks up the new dependency on bind-config .

Comment 6 Dan Williams 2006-03-06 16:02:25 UTC
Sounds good to me, thanks Jason.

Comment 7 Warren Togami 2006-03-06 16:04:43 UTC
- caching-nameserver is to be removed from the distro entirely?  Note that
NetworkManager is not enabled by default and caching-nameserver itself is useful
functionality standalone.  

- caching-nameserver is something we have had for a long time now, it seems
rather big of a change to make right before the final devel freeze without peer
review and community testing & feedback.

- What really is the problem in making named.conf noreplace?

Comment 8 Warren Togami 2006-03-06 16:08:02 UTC
> The named initscript will be changed to invoke named with the
>   '-c named.caching-nameserver.conf'
> argument IFF $ROOTDIR/etc/named.conf does not exist and 
> $ROOTDIR/etc/named.caching-nameserver.conf does.

Oops, I missed this part.  Nice design, and I suppose this is OK.

Comment 9 Jason Vas Dias 2006-03-07 16:37:31 UTC
This bug is now fixed with bind-9.3.2-6 in Rawhide/FC-5 .
caching-nameserver is now replaced by bind-config, which only provides

No package provides named.conf anymore, and named.conf should never be
modified during any package upgrade.

bind and bind-config do still "own" named.conf as a '%ghost %config(noreplace)'
file, to prevent it being removed when previous versions of the packages that
did Provide: it are removed .

Comment 10 Warren Togami 2006-03-08 16:58:17 UTC
Jeremy and I are not comfortable with this level of changes so late, especially
without community testing.  Notting also noted, "warren: obsoleted a sub package
that other packages depend on, even. in a package with %post, %triggers, etc...
not now."

The simple alternative to avoid the "oh crap, named.conf was blown away" problem
in FC5 is to make it noreplace.  It might be ugly, but it is the right thing to
do for now.  We can revisit the feasibility of doing this in a long-term nice
way for FC6.

Are there any other issues with noreplace?  If nobody can think of any, we need
to go ahead with this ASAP, we are out of time.

Comment 11 David Woodhouse 2006-03-08 17:01:47 UTC
Noreplace isn't ugly. It is the correct thing to do for config files. Even if
I'm using a config based on the caching-nameserver config but have edited it
myself, I don't want it to be thrown away.

Go ahead and make it 'noreplace' for FC-5, by all means.

Comment 12 Warren Togami 2006-03-08 20:26:52 UTC
The decision from discussion is to leave this as-is for FC5 release and deal
with it in the proper way in FC5 updates after the new package has had peer
review and exposure in the community.  We must take into account all
implications of scriptlets and triggers upgrading from all previous supported
releases of bind in analyzing it before releasing it as an official update.

Comment 13 Jesse Keating 2006-03-09 03:44:05 UTC
We've updated caching-nameserver to use config(noreplace).  This resolves the
issue in a clean way.  Major package rearrangements can be done in the FC6
developmen time.

Comment 14 Fedora Update System 2006-03-21 17:54:11 UTC
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.

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