Bug 143558 (IT_59355)

Summary: Up2date'ing from RHEL update3 to update4 turns named off in init.d/rc?.d
Product: Red Hat Enterprise Linux 3 Reporter: Anthony Rumble <ox23fgu02>
Component: bindAssignee: Jason Vas Dias <jvdias>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: eparis, herrold, otaylor, plankers, tao
Target Milestone: ---Keywords: Regression
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-12-23 20:34:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Anthony Rumble 2004-12-22 10:45:44 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
I have had 2 seperate machines now that have upgraded from RHEL update
3 to RHEL update 4 with up2date.
And after the update, named was not running any more.

On inspection, the links in /etc/rc.d/rc3.d were missing!

I had to "chkconfig --add named" to get it back in again.



Version-Release number of selected component (if applicable):
9.2.4-1_EL3

How reproducible:
Always

Steps to Reproduce:
1. Take an RHEL system at update 3
2. up2date -u to get it to update 4
3. check the links in /etc/rc.d/rc?.d (whatever is appropriate)
    

Actual Results:  named will not appear in "ntsysv" anymore

Expected Results:  It should not have removed the init links.

Additional info:

This happened on two RHEL machines.
One being ix86 based, the other being PPC64 based (iSeries), and did
the same thing.

Comment 1 joaquin romero 2004-12-22 13:19:10 UTC
Ditto on x86 RHEL 3 on 12-22-04!

Comment 2 Jason Vas Dias 2004-12-22 15:34:10 UTC
 The problem occurred because of bind-9.2.4-EL3_10's broken 
 %postun (uninstall) script, which incorrectly did a 'chkconfig --del'
 for bind . 
 Now that bind-9.2.4-EL3_10 is removed from your system, the problem
 will never reoccur with bind upgrades .
 This problem will be fixed in the next upgrade release of bind.

Comment 7 Jason Vas Dias 2004-12-22 18:49:18 UTC
The new bind-9.2.4-5_EL3 version that fixes this problem is now 
submitted and undergoing testing . QA/PM will try to roll this 
out into RHEL-3-U4 ASAP.

Comment 8 Bob Kenney 2004-12-22 19:39:21 UTC
I also noticed this problem, plus the fact that
it shuts down the server(which may or may not
be necessary for further up2date network access),
and it overwrites the config file(after moving
the original to named.conf_rpmsave, of course).

I'd like to vote for the opposite approach -
put the new config in named.conf_rpmnew, and
leave the original in place. The bind config
format hasn't really changed all that much since
bind4, so unless the format changes radically,

a) the original config should be left in place,
b) the server should be left running, and
c) the service shouldn't be removed from the
   chkconfig database(which presumably gets
   fixed by the new patch you're testing).

Comment 9 Jason Vas Dias 2004-12-22 19:51:54 UTC
RE: Comment #8:
The problem about shutting down the server / removing the service from
the chkconfig database is fixed in bind-9.2.4-5_EL3 (now be pushed to
RHEL-3-U4).

Existing named configuration files are not touched in any way by 
installation / upgrade of the bind package by itself.
If there are no existing configuration files, installation of the
bind package will create named.conf, rndc.conf, and rndc.key files
sufficient only to run the nameserver.

The caching-nameserver package, which exists to provide a caching
only nameserver configuration, does always back-up any existing
named configuration files to _rpmsave files and installs 
configuration files to provide a caching only nameserver .
If it supplied the files as %config(noreplace), so that they'd
be installed as .rpmnew files, then after installation, there'd
be no way of guaranteeing that a caching only nameserver was in place,
and it would be impossible to upgrade the package . By installing
caching-nameserver, users are saying 'I want a caching-only
nameserver', so any existing configuration that may or may not
also provide a caching nameserver must be backed-up and replaced. 



  

Comment 10 Bob Kenney 2004-12-22 22:43:07 UTC
Thanks for the comment about the caching-nameserver package.
After poking around, it's apparent that that was the rpm
that monkeyed with our /etc/named.conf file. An easy fix!

Comment 11 Jason Vas Dias 2004-12-23 16:32:40 UTC
*** Bug 143626 has been marked as a duplicate of this bug. ***

Comment 12 John Flanagan 2004-12-23 20:34:54 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2004-696.html


Comment 13 Tim Powers 2005-05-19 12:30:07 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2005-001.html