From Bugzilla Helper: User-Agent: Mozilla/5.0 (compatible; MSIE 6.0; Windows; U; AIIEEEE!; Win98; Windows 98; en-US; Gecko masquerading as IE; should it matter?; rv:1.8b) Gecko/20050217 Description of problem: Install of bind destructively overwrites /etc/named.conf without saving a copy. So you have set up named.conf with your localized changes, reinstall bind, and you lose everything. Thanks a lot! Version-Release number of selected component (if applicable): bind-9.3.1-14_FC4 How reproducible: Always Steps to Reproduce: 1.Create a customised /etc/named.conf 2.Upgrade bind 3. Actual Results: Hello! Where has my special /etc/named.conf gone? Expected Results: Either /etc/named.conf saved as /etc/named.rpmsave, or installed conf created as /etc/named.rpmnew. Additional info: I wonder why don't people like RedHat/Fedora any more?
No, the bind package NEVER 'Provides:' / replaces named.conf . The caching-nameserver package 'Provides:' named.conf. If you install the caching-nameserver package, which consists entirely of the named configuration files to provide a caching-only nameserver, then a caching-only nameserver must be in place after installation / upgrade. If you want to customize the named configuration files, do not install the caching-nameserver package.
Oh, really? Then what is this in bind.spec? if [ -f /etc/named.boot -a ! -f /etc/named.conf ]; then if [ -x /usr/sbin/named-bootconf ]; then cat /etc/named.boot | /usr/sbin/named-bootconf > /etc/named.conf chmod 644 /etc/named.conf fi fi
That clause has been in every Red Hat BIND 8+ .spec file version, and exists to convert the named.boot configuration files used by BIND 4 to that used by BIND 8+ . BIND 4 configuration files are unreadable by BIND 8+ and vice-versa. We could probably just take it out - not many people use BIND 4 anymore - but you never know - someone might be upgrading from RHL 6.2 - in which case this named.boot conversion would be the least of their problems.
(In reply to comment #3) > We could probably just take it out - not many people use BIND 4 anymore - but you > never know - someone might be upgrading from RHL 6.2 - in which case this > named.boot conversion would be the least of their problems. But why doesn't it look at the goddam config first to see if it needs converting?! And why does it convert it by converting named.boot! Surely it should convert named.conf if what you say is true. Good grief!
BIND 4 named its default configuration file 'named.boot', while BIND 8+ named its default configuration file 'named.conf' . If the named.boot consisted only of a BIND 4.9+ 'options { }' clause with options still supported in BIND 8+, there would be no way of telling if the named.boot was in BIND 4 or BIND 8 syntax. In any case, the clause is only activated if named.boot exists and named.conf does not - so it never overwrites the current configuration file, it merely converts an old (defunct) configuration file to one recognized by BIND 9. I will consider removing named-bootconf and the clause above from a future release (no-one should be using BIND 4 anymore) . But as no-one has ever complained about this issue before, and the BIND 4 conversion functionality could potentially help people upgrading from BIND 4, I think it should still stay in for now.
But my system doesn't have a /etc/named.boot anyhow. The new named.conf got generated all the same. Could there be some other mechanism which created the new /etc/named.conf?
Yes, as I said in my previous comment, you probably had the caching-nameserver package installed, which consists entirely of named configuration files, and will overwrite named.conf on installation / upgrade. What does 'rpm -qf /etc/named.conf' say ?
No, I only upgraded bind. The caching-nameserver was already installed ("Install Date: Sun 13 Nov 2005 20:16:36 EST") and I upgraded bind ("Install Date: Sun 04 Dec 2005 16:51:52 EST").
Well, neither bind nor bind-chroot 'Provides:' named.conf at all . I can't explain how the /etc/named.conf file could have been overwritten - I upgrade bind on my machines several times a week and named.conf has never been overwritten . Installation of bind-chroot could replace /etc/named.conf with a link to /var/named/chroot/etc/named.conf - is your old named.conf there ? What are the contents of the /etc/named.conf file ? Are there any /etc/named.conf.rpm* files ? What is the output of # rpm -qf /etc/named.conf ?
(In reply to comment #9) > Well, neither bind nor bind-chroot 'Provides:' named.conf at all . > I can't explain how the /etc/named.conf file could have been overwritten - > I upgrade bind on my machines several times a week and named.conf has never > been overwritten . > Installation of bind-chroot could replace /etc/named.conf with a link to > /var/named/chroot/etc/named.conf - is your old named.conf there ? No, it is in /etc/named.conf > What are the contents of the /etc/named.conf file ? Sorry, but I am not prepared to reveal the contents in a public discussion. Suffice it to say it contains named configuration settings, including zone definitions. > Are there any /etc/named.conf.rpm* files ? No. > What is the output of > # rpm -qf /etc/named.conf > ? caching-nameserver-7.3-3
As stated in previous comments, the caching-nameserver package must replace any existing named.conf - it does save any existing named.conf to named.conf.rpmsave, however . Hence, this is NOTABUG.
(In reply to comment #11) > As stated in previous comments, the caching-nameserver package must > replace any existing named.conf - it does save any existing named.conf > to named.conf.rpmsave, however . Hence, this is NOTABUG. But should it save anything it destroys? Isn't that why rpm has mechanism to save old as .rpmsave? Or was that a design mistake?
I came in to this dicsussion because I upgraded caching-nameserver-7.3 to caching-nameserver-7.3-4.FC4. In the process I noticed that my named.conf was over-written. Fine. But my /etc/named.conf.rpmsave now points to /var/named/chroot/etc/named.conf, not to /var/named/chroot/etc/named.conf.rpmsave, thereby obliterating the contents of the old named.conf. This is a bug. The /etc/named.conf.rpmsave symlink should point to /var/named/chroot/etc/named.conf.rpmsave. [root@teckla ~]# ll /etc/named.conf* lrwxrwxrwx 1 root root 32 Dec 30 09:45 /etc/named.conf -> /var/named/chroot/etc/named.conf lrwxrwxrwx 1 root root 32 Nov 12 08:35 /etc/named.conf.rpmsave -> /var/named/chroot/etc/named.conf [root@teckla ~]# ll /var/named/chroot/etc/named.conf* -rw-r--r-- 1 root root 1323 Dec 19 14:30 /var/named/chroot/etc/named.conf -rw-r--r-- 1 root named 1323 Aug 25 2004 /var/named/chroot/etc/named.conf~ -rw-r--r-- 1 root named 1662 Dec 20 15:02 /var/named/chroot/etc/named.conf.rpmsave /var/named/chroot/etc/named.conf.rpmsave preserved my customizations (contrary to comment 11, above). JW might find that this allows him to recover his. Questions for Mr. Vas Dias. You state above (comment #1) "If you want to customize the named configuration files, do not install the caching-nameserver package." * Where is this documented? * I do not see any such advice in the output of "rpm -qi caching-nameserver", which is the summary one sees when selecting packages for installation. Please add it to the summary. I use caching-nameserver as a starting point for my customizations. Where should one get certain standard files, such as named.ca? named.ca is not provided by any other package, so far as I can tell ("yum provides named.ca | less"). (I know I can go to the appropriate servers and FTP them in. But shouldn't some package or other provide them?)
I agree with comment #13: this is a problem. I had both bind-chroot and caching-nameserver installed (which is explained below), and when I did a recent yum -y update, my /etc/named.conf (or more specifically, /var/named/chroot/etc/named.conf) was renamed to named.conf.rpmsave and replaced by the updated caching-nameserver's version. It's easy to say "well, don't install caching-nameserver then!". The problem is that the caching-nameserver package is part of the "System Environment/Daemons" installation group, and not to mention is a required package if you want to install the NetworkManager package (which I haven't installed, but I'm sure people do). I usually just install the entire "Daemons" group, as it has everything I need to get a working server up and running. With the current ambiguous named.conf situation, doing a yum update will cause serious problems on a production server that is running bind. As Charles states above, this behaviour is not documented and should be considered a bug.
This bug also hit me. It's really quite scary and serious. I had caching-nameserver installed (no particular idea how/why - quite probably the FC3 default install, or maybe I installed it explicitly because I initially setup bind to be just a cache). Then, I added various entries to named.conf for local domains. This should have been safe, since I was editing a conf file, which typically don't get trashed on rpm updates. Then, I innocently run "yum update" the other day, and my named.conf is replaced by the content from caching-nameserver, completely over-writing my changes. This is definitely not how RPMs are supposed to work! Note that I was left with: /etc/named.conf -> /var/named/chroot/etc/named.conf /etc/named/conf.rpmsave -> /var/named/chroot/etc/named.conf and the file /var/named/chroot/etc/named.conf contained the newly installed content - no sign of my old configuration, which I had to restore from a backup. Note that I'm running FC3, and updated to caching-nameserver-7.3-4.FC3
Ah. Looking at comment #13, I was prompted to look at /var/named/chroot/etc/named.conf.rpmsave. This does contain my old configuration, so I didn't actually need to restore from backup. However, as also mentioned in #13, the /etc/named.conf.rpmsave link does point to the wrong file, which is why I thought the old configuration hadn't been saved. Isn't typical behaviour for config files to save the new version to a .rpmnew if the user has edited the original config file, so as to avoid this situation? When I update, I should be responsible for merging the new updates to the config file into my custom version, rather than having my config trashed and having to merge my modifications back in. Also, I see from the "yum update" log on a second machine where this happened that there is a warning that the /etc/named.conf file is being replaced. However, if yum picks up e.g. 50 updates at once, I might easily miss this warning as the log scrolls by. The warning should really be the very last thing yum prints when updating, so it's really obvious, not hidden... Even better, send root mail in a postinstall hook or something!
This issue is now fixed in FC-5 / Rawhide with bind-9.3.2-6, which replaces the caching-nameserver package entirely with a 'bind-config' subpackage, that does not provide named.conf at all, only /etc/named.caching-nameserver.conf, which is used by the initscript if /etc/named.conf does not exist . No package should touch /etc/named.conf anymore. I don't think it is a good idea to backport this change to FC-4 - it would cause too much churn . The problem only occurs when the caching-nameserver package is updated - and I will ensure that it is not updated again for FC-4 .
Sounds like a great solution. Thanks for the work!
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.