Red Hat Bugzilla – Bug 176388
named.conf should be marked 'noreplace'
Last modified: 2013-01-09 22:40:19 EST
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
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
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.
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'.
*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 127.0.0.1" >> /etc/resolv.conf;
if test -r /etc/sysconfig/named ; then
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
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
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:
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
argument IFF $ROOTDIR/etc/named.conf does not exist and
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 .
Sounds good to me, thanks Jason.
- caching-nameserver is to be removed from the distro entirely? Note that
NetworkManager is not enabled by default and caching-nameserver itself is useful
- 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?
> 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.
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 .
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...
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.
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.
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.
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
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.