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 %config(noreplace)
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.
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 NetworkManager-0.5.1-1.FC4.4 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 :; else echo "nameserver 127.0.0.1" >> /etc/resolv.conf; fi; if test -r /etc/sysconfig/named ; then . /etc/sysconfig/named if [ ! -z $ROOTDIR ]; then for f in /etc/named.conf /var/named/{named.ca,named.local,named.ip6.local,named.broadcast,named.zero,localhost.zone,localdomain.zone}; do if [ ! -L $f ]; then if [ -f $ROOTDIR$f ]; then mv $ROOTDIR$f $ROOTDIR$f.rpmsave; fi; /bin/mv $f $ROOTDIR$f ln -s $ROOTDIR$f $f; fi; done; fi; fi; NOTE no attempt to restart the service is made Consider: 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 caching-nameserver'... 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! FIX THIS dwmw2's ISP folk are not the only people to have hit this Phil =--=
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.)
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 .
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 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?
> 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 {,$ROOTDIR}/etc/named.caching-nameserver.conf. 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... 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.
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 developmen time.
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.