Bug 174925 - bind install destructively overwrites existing /etc/named.conf
bind install destructively overwrites existing /etc/named.conf
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: caching-nameserver (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-04 05:21 EST by JW
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-07 11:49:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description JW 2005-12-04 05:21:14 EST
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?
Comment 1 Jason Vas Dias 2005-12-05 14:05:30 EST
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.

 
Comment 2 JW 2005-12-05 17:41:50 EST
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

Comment 3 Jason Vas Dias 2005-12-05 17:49:20 EST
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.
Comment 4 JW 2005-12-05 17:52:48 EST
(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!
Comment 5 Jason Vas Dias 2005-12-05 18:12:14 EST
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.
Comment 6 JW 2005-12-05 18:31:40 EST
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?
Comment 7 Jason Vas Dias 2005-12-05 18:37:41 EST
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 ? 
Comment 8 JW 2005-12-05 19:02:33 EST
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").
Comment 9 Jason Vas Dias 2005-12-05 19:15:44 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
?
Comment 10 JW 2005-12-05 19:24:40 EST
(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
Comment 11 Jason Vas Dias 2005-12-20 16:32:03 EST
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.
Comment 12 JW 2005-12-20 17:45:42 EST
(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?
Comment 13 Charles Curley 2005-12-30 12:27:01 EST
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?)
Comment 14 Antony Nguyen 2006-01-12 19:10:56 EST
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.
Comment 15 Stephen Warren 2006-01-15 22:18:00 EST
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
Comment 16 Stephen Warren 2006-01-15 22:26:43 EST
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!
Comment 17 Jason Vas Dias 2006-03-07 11:49:28 EST
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 .

Comment 18 Stephen Warren 2006-03-07 11:57:15 EST
Sounds like a great solution. Thanks for the work!
Comment 19 Fedora Update System 2006-03-21 12:53:44 EST
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.