Hello,
I encountered a problem when upgrading from 3.3 to 3.4 on i386.
The machine is a production name server running bind. Looks like the new rpm moved my named.conf to .rpmsave and chkconfig'ed bind to off.
That's really bad. A more gentle behavior would have been to save the new named.conf to .rpmnew and not mess with initscripts.
Anyone else notice that?
Francois Caen
Yes. Happened on 20 of the servers we updated. It has to do with the caching-nameserver I believe. But yes, it caused some extra scrambling during the updates.
-----Original Message----- From: centos-bounces@caosity.org [mailto:centos-bounces@caosity.org] On Behalf Of Francois Caen Sent: 12 January 2005 15:45 To: centos@caosity.org Subject: [Centos] bind and 3.4
Hello,
I encountered a problem when upgrading from 3.3 to 3.4 on i386.
The machine is a production name server running bind. Looks like the new rpm moved my named.conf to .rpmsave and chkconfig'ed bind to off.
That's really bad. A more gentle behavior would have been to save the new named.conf to .rpmnew and not mess with initscripts.
Anyone else notice that?
Francois Caen _______________________________________________ CentOS mailing list CentOS@caosity.org http://lists.caosity.org/mailman/listinfo/centos
On Wed, 2005-01-12 at 16:32 +0800, Ho Chaw Ming wrote:
Yes. Happened on 20 of the servers we updated. It has to do with the caching-nameserver I believe. But yes, it caused some extra scrambling during the updates.
-----Original Message----- From: centos-bounces@caosity.org [mailto:centos-bounces@caosity.org] On Behalf Of Francois Caen Sent: 12 January 2005 15:45 To: centos@caosity.org Subject: [Centos] bind and 3.4
Hello,
I encountered a problem when upgrading from 3.3 to 3.4 on i386.
The machine is a production name server running bind. Looks like the new rpm moved my named.conf to .rpmsave and chkconfig'ed bind to off.
That's really bad. A more gentle behavior would have been to save the new named.conf to .rpmnew and not mess with initscripts.
Anyone else notice that?
Francois Caen
Here too. Fortunately, I just did my tertiary dns first to test. I've been bit before by this kind of behavior before with centos/redhat/fedora. The latest being with the freeradius update. The pamauth module got renamed and no one could get authenticated. I have also been bit by postfix config renames.
Timothy
CentOS mailing list CentOS@caosity.org http://lists.caosity.org/mailman/listinfo/centos
CentOS mailing list CentOS@caosity.org http://lists.caosity.org/mailman/listinfo/centos
On Wed, 2005-01-12 at 06:43 -0600, Timothy Sandel wrote:
On Wed, 2005-01-12 at 16:32 +0800, Ho Chaw Ming wrote:
Yes. Happened on 20 of the servers we updated. It has to do with the caching-nameserver I believe. But yes, it caused some extra scrambling during the updates.
-----Original Message----- From: centos-bounces@caosity.org [mailto:centos-bounces@caosity.org] On Behalf Of Francois Caen Sent: 12 January 2005 15:45 To: centos@caosity.org Subject: [Centos] bind and 3.4
Hello,
I encountered a problem when upgrading from 3.3 to 3.4 on i386.
The machine is a production name server running bind. Looks like the new rpm moved my named.conf to .rpmsave and chkconfig'ed bind to off.
That's really bad. A more gentle behavior would have been to save the new named.conf to .rpmnew and not mess with initscripts.
Anyone else notice that?
Francois Caen
Here too. Fortunately, I just did my tertiary dns first to test. I've been bit before by this kind of behavior before with centos/redhat/fedora. The latest being with the freeradius update. The pamauth module got renamed and no one could get authenticated. I have also been bit by postfix config renames.
Timothy
I forgot to mention. All the boxes I updated got this in the logwatch:
--------------------- Connections (secure-log) Begin ------------------------
New Users: named (25)
Deleted Users: named
Deleted Groups: named
**Unmatched Entries** groupadd[29917]: new group: name=named, gid=25
---------------------- Connections (secure-log) End -------------------------
CentOS mailing list CentOS@caosity.org http://lists.caosity.org/mailman/listinfo/centos
CentOS mailing list CentOS@caosity.org http://lists.caosity.org/mailman/listinfo/centos
CentOS mailing list CentOS@caosity.org http://lists.caosity.org/mailman/listinfo/centos
On Wed, 12 Jan 2005, Ho Chaw Ming wrote:
Yes. Happened on 20 of the servers we updated. It has to do with the caching-nameserver I believe. But yes, it caused some extra scrambling during the updates.
I have now removed caching-nameserver from the core os repo of 3.4 and moved it to the testing repo.
It would appear that there is a problem with it as I have seen similar reports elsewhere.
It shouldnt bite anyone else now.
It is still in the .isos but is safe for new installs.
I dont seem to be able to find anything in RH bugzilla which is strange.
Anyway - sorry for the problem and thanks for the reports.
Lance
-----Original Message----- From: centos-bounces@caosity.org [mailto:centos-bounces@caosity.org] On Behalf Of Francois Caen Sent: 12 January 2005 15:45 To: centos@caosity.org Subject: [Centos] bind and 3.4
Hello,
I encountered a problem when upgrading from 3.3 to 3.4 on i386.
The machine is a production name server running bind. Looks like the new rpm moved my named.conf to .rpmsave and chkconfig'ed bind to off.
That's really bad. A more gentle behavior would have been to save the new named.conf to .rpmnew and not mess with initscripts.
Anyone else notice that?
Francois Caen _______________________________________________ CentOS mailing list CentOS@caosity.org http://lists.caosity.org/mailman/listinfo/centos
CentOS mailing list CentOS@caosity.org http://lists.caosity.org/mailman/listinfo/centos
On Wed, January 12, 2005 6:56 am, Lance Davis said:
On Wed, 12 Jan 2005, Ho Chaw Ming wrote:
Yes. Happened on 20 of the servers we updated. It has to do with the caching-nameserver I believe. But yes, it caused some extra scrambling during the updates.
I have now removed caching-nameserver from the core os repo of 3.4 and moved it to the testing repo.
It would appear that there is a problem with it as I have seen similar reports elsewhere.
It shouldnt bite anyone else now.
It is still in the .isos but is safe for new installs.
I dont seem to be able to find anything in RH bugzilla which is strange.
Anyway - sorry for the problem and thanks for the reports.
Lance
I also looked at the RedHat bugzilla and found:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143558
It is supposed to be fixed with this:
http://rhn.redhat.com/errata/RHBA-2004-696.html
This is an upstream issue ... AND ... according to redhat, you shouldn't have caching-nameserver installed on a DNS server that is anything other than a caching-nameserver :). It is indeed the caching-nameserver package that is causing the issue.
-----Original Message----- From: centos-bounces@caosity.org [mailto:centos-bounces@caosity.org] On Behalf Of Francois Caen Sent: 12 January 2005 15:45 To: centos@caosity.org Subject: [Centos] bind and 3.4
Hello,
I encountered a problem when upgrading from 3.3 to 3.4 on i386.
The machine is a production name server running bind. Looks like the new rpm moved my named.conf to .rpmsave and chkconfig'ed bind to off.
That's really bad. A more gentle behavior would have been to save the new named.conf to .rpmnew and not mess with initscripts.
Anyone else notice that?
Francois Caen
On Wed, January 12, 2005 7:14 am, Johnny Hughes said:
On Wed, January 12, 2005 6:56 am, Lance Davis said:
On Wed, 12 Jan 2005, Ho Chaw Ming wrote:
Yes. Happened on 20 of the servers we updated. It has to do with the caching-nameserver I believe. But yes, it caused some extra scrambling during the updates.
I have now removed caching-nameserver from the core os repo of 3.4 and moved it to the testing repo.
It would appear that there is a problem with it as I have seen similar reports elsewhere.
It shouldnt bite anyone else now.
It is still in the .isos but is safe for new installs.
I dont seem to be able to find anything in RH bugzilla which is strange.
Anyway - sorry for the problem and thanks for the reports.
Lance
I also looked at the RedHat bugzilla and found:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143558
It is supposed to be fixed with this:
http://rhn.redhat.com/errata/RHBA-2004-696.html
This is an upstream issue ... AND ... according to redhat, you shouldn't have caching-nameserver installed on a DNS server that is anything other than a caching-nameserver :). It is indeed the caching-nameserver package that is causing the issue.
As further clarification, I point exactly to the post:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143558#c9
I think you should put the new caching-nameserver back into the U4 directories ... this will happen anytime redhat issues an update to caching-nameserver and is exactly by design.
If you have DNS zones, remove caching-nameserver from that box...it is not a caching-nameserver any longer
-----Original Message----- From: centos-bounces@caosity.org [mailto:centos-bounces@caosity.org] On Behalf Of Francois Caen Sent: 12 January 2005 15:45 To: centos@caosity.org Subject: [Centos] bind and 3.4
Hello,
I encountered a problem when upgrading from 3.3 to 3.4 on i386.
The machine is a production name server running bind. Looks like the new rpm moved my named.conf to .rpmsave and chkconfig'ed bind to off.
That's really bad. A more gentle behavior would have been to save the new named.conf to .rpmnew and not mess with initscripts.
Anyone else notice that?
Francois Caen
On Wed, 12 Jan 2005, Johnny Hughes wrote:
This is an upstream issue ... AND ... according to redhat, you shouldn't have caching-nameserver installed on a DNS server that is anything other than a caching-nameserver :). It is indeed the caching-nameserver package that is causing the issue.
As further clarification, I point exactly to the post:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143558#c9
I think you should put the new caching-nameserver back into the U4 directories ... this will happen anytime redhat issues an update to caching-nameserver and is exactly by design.
If you have DNS zones, remove caching-nameserver from that box...it is not a caching-nameserver any longer
Well I am also going by a post from parsley to the tao mailing list :-
http://mailman.taolinux.org/pipermail/tao-i386/2005-January/000104.html
I dont think it is right for it to kill a working nameserver on an update, whether or not people have it installed by mistake - ie if it is already installed and the config files have been changd and the thing is running, they should not be removed and the thing stopped - IMHO
Lance
On Wed, January 12, 2005 7:51 am, Lance Davis said:
On Wed, 12 Jan 2005, Johnny Hughes wrote:
This is an upstream issue ... AND ... according to redhat, you
shouldn't
have caching-nameserver installed on a DNS server that is anything
other
than a caching-nameserver :). It is indeed the caching-nameserver
package
that is causing the issue.
As further clarification, I point exactly to the post:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143558#c9
I think you should put the new caching-nameserver back into the U4 directories ... this will happen anytime redhat issues an update to caching-nameserver and is exactly by design.
If you have DNS zones, remove caching-nameserver from that box...it is not a caching-nameserver any longer
Well I am also going by a post from parsley to the tao mailing list :-
http://mailman.taolinux.org/pipermail/tao-i386/2005-January/000104.html
I dont think it is right for it to kill a working nameserver on an update, whether or not people have it installed by mistake - ie if it is already installed and the config files have been changd and the thing is running, they should not be removed and the thing stopped - IMHO
Lance
--
I agree, _BUT_ the guy at RedHat is right ... The purpose of caching-nameserver is to setup a "caching-only-DNS" box ... the only way to setup a "caching-only-DNS" box is to remove the current named.conf file and replace it with a new one that defines it as a "caching-only-DNS" box :)
The lesson learned is ... once you setup your box as a DNS zone control box, backup the named.conf file and remove the package caching-nameserver ... OR ... don't install it in the first place.
My guide has been updated to remove the caching-nameserver package after finishing zone setup :).
On Wed, January 12, 2005 8:02 am, Johnny Hughes said:
On Wed, January 12, 2005 7:51 am, Lance Davis said:
On Wed, 12 Jan 2005, Johnny Hughes wrote:
This is an upstream issue ... AND ... according to redhat, you
shouldn't
have caching-nameserver installed on a DNS server that is anything
other
than a caching-nameserver :). It is indeed the caching-nameserver
package
that is causing the issue.
As further clarification, I point exactly to the post:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143558#c9
I think you should put the new caching-nameserver back into the U4 directories ... this will happen anytime redhat issues an update to caching-nameserver and is exactly by design.
If you have DNS zones, remove caching-nameserver from that box...it is not a caching-nameserver any longer
Well I am also going by a post from parsley to the tao mailing list :-
http://mailman.taolinux.org/pipermail/tao-i386/2005-January/000104.html
I dont think it is right for it to kill a working nameserver on an update, whether or not people have it installed by mistake - ie if it is already installed and the config files have been changd and the thing is running, they should not be removed and the thing stopped - IMHO
Lance
--
I agree, _BUT_ the guy at RedHat is right ... The purpose of caching-nameserver is to setup a "caching-only-DNS" box ... the only way to setup a "caching-only-DNS" box is to remove the current named.conf file and replace it with a new one that defines it as a "caching-only-DNS" box :)
The lesson learned is ... once you setup your box as a DNS zone control box, backup the named.conf file and remove the package caching-nameserver ... OR ... don't install it in the first place.
My guide has been updated to remove the caching-nameserver package after finishing zone setup :).
Since RedHat is probably not going to change the behavior of the caching-nameserver package...what do you want to do with that package now?
The options are: (1) put it back as is ... this is an upstream issue (and put an entry about not using caching-nameserver on DNS Zone controller boxes in the FAQ).
(2) File a bug report against caching-nameserver at RedHat and see what they say, leaving the current caching-nameserver update in testing.
(3) Change the package specfile so that it behaves the way we think it should.
Personally, I think we should do #1 ... or maybe #2, which will probably be result in RedHat saying "Don't use caching-nameserver on a DNS Zone controller box" ... which they already said in the comment that I pointed to.
That would leave us with options #1 and #3 ...
Thanks, Johnny Hughes
On Wed, 12 Jan 2005, Johnny Hughes wrote:
Since RedHat is probably not going to change the behavior of the caching-nameserver package...what do you want to do with that package now?
The options are: (1) put it back as is ... this is an upstream issue (and put an entry about not using caching-nameserver on DNS Zone controller boxes in the FAQ).
3 emails today re broken nameservers doesnt make that a good option IMHO
(2) File a bug report against caching-nameserver at RedHat and see what they say, leaving the current caching-nameserver update in testing.
Yes - a. If config edited it shouldnt splat on upgrade - ok on install (can rpm tell the diff).
b - shouldnt stop if running
(3) Change the package specfile so that it behaves the way we think it should.
again - if we can tell the diff between install and upgrade then yes ...
Regards Lance
Here is another issue: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143786
This one specifically addresses the named daemon not restarting (which is a broken bind-9.2.4-5_EL3, not caching-nameserver)... it also says that they will not be fixing the caching-nameserver issue, because it is not a bug, it is by design.
On Wed, 12 Jan 2005, Johnny Hughes wrote:
Here is another issue: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143786
This one specifically addresses the named daemon not restarting (which is a broken bind-9.2.4-5_EL3, not caching-nameserver)... it also says that they will not be fixing the caching-nameserver issue, because it is not a bug, it is by design.
It may well be - but if the design is wrong it is still a bug.
Lance
On Wednesday, 12 January 2005, at 16:28:25 (+0000), Lance Davis wrote:
It may well be - but if the design is wrong it is still a bug.
The fact that people are using a package improperly does not make its design wrong. The package information is quite clear:
The caching-nameserver package includes the configuration files which will make BIND, the DNS name server, act as a simple caching nameserver. Many users on dialup connections use this package along with BIND for such a purpose.
If you would like to set up a caching name server, you'll need to install the caching-nameserver package; you'll also need to install bind.
Note the "simple caching nameserver" part. Those using it for something different are simply wrong.
Michael
On Wed, January 12, 2005 10:47 am, Michael Jennings said:
On Wednesday, 12 January 2005, at 16:28:25 (+0000), Lance Davis wrote:
It may well be - but if the design is wrong it is still a bug.
The fact that people are using a package improperly does not make its design wrong. The package information is quite clear:
The caching-nameserver package includes the configuration files which will make BIND, the DNS name server, act as a simple caching nameserver. Many users on dialup connections use this package along with BIND for such a purpose.
If you would like to set up a caching name server, you'll need to install the caching-nameserver package; you'll also need to install bind.
Note the "simple caching nameserver" part. Those using it for something different are simply wrong.
Michael
Exactly .... and a quote from one of the bugs is this:
"caching-nameserver HAS to backup and replace the BIND configuration files - it consists entirely of them. By installing caching-nameserver, users are requesting that a caching only nameserver configuration be installed. If the caching nameserver RPM did not replace the configuration files, there would be no way for it to guarantee that after installation, a caching nameserver was in place; nor could it be upgraded. If this is not what you want, backup the BIND configuration files and remove the caching-nameserver RPM from the system."
Think about it ... you install caching-nameserver BECAUSE you want a name server but don't want to setup zones. If you do setup zones, you have to remove caching-nameserver. The only way that they can ensure you have what you asked for (a caching-nameserver) is to backup your old files and use new ones...if they don't, then you don't have a caching-nameserver.
As to the other problem of named not restarting, that specific issue can be addressed with this file ... which is not yet officially released, but which I verified did work on my DNS server:
http://people.redhat.com/~jvdias/bind/RHEL-3/9.2.4-7_EL3/SRPMS/
On Wed, 12 Jan 2005, Johnny Hughes wrote:
Think about it ... you install caching-nameserver BECAUSE you want a name server but don't want to setup zones. If you do setup zones, you have to remove caching-nameserver. The only way that they can ensure you have what you asked for (a caching-nameserver) is to backup your old files and use new ones...if they don't, then you don't have a caching-nameserver.
I agree totally - but disagree that an 'upgrade' should trash files that you have edited, and remove your configuration just because you have something installed that you shouldnt.
If you choose to install it that is a separate matter.
Lance
On Wednesday, 12 January 2005, at 17:19:03 (+0000), Lance Davis wrote:
I agree totally - but disagree that an 'upgrade' should trash files that you have edited, and remove your configuration just because you have something installed that you shouldnt.
Nobody's files got "trashed." They were renamed for backup purposes.
Think about it: If you're running a cache-only nameserver, there's nothing you could or should reasonably do to named.conf or any of the /var/named/* files. RedHat wants to make sure that the old-and-busted cache data is replaced by the new-hotness cache data, so they backup your old stuff and install their new stuff. This is a perfectly sane, reasonable, and expected course of action.
We can argue about %config vs. %config(noreplace) till the cows come home, but the bottom line is that the decision isn't ours, and it has already been made. Those who wish to debate the decision are free to post comments on the RH bug. Barring a change of heart from RedHat, this matter should be closed. (And I am definitely opposed to changing this package in CentOS; for better or worse, we stay close to the Mother Ship.)
Michael
On Wed, 12 Jan 2005, Michael Jennings wrote:
On Wednesday, 12 January 2005, at 17:19:03 (+0000), Lance Davis wrote:
I agree totally - but disagree that an 'upgrade' should trash files that you have edited, and remove your configuration just because you have something installed that you shouldnt.
Nobody's files got "trashed." They were renamed for backup purposes.
Think about it: If you're running a cache-only nameserver, there's nothing you could or should reasonably do to named.conf or any of the /var/named/* files. RedHat wants to make sure that the old-and-busted cache data is replaced by the new-hotness cache data, so they backup your old stuff and install their new stuff. This is a perfectly sane, reasonable, and expected course of action.
Yes - but the people who have edited the files are not running cache-only nameservers - they have mistakenly got that rpm installed and then edited their stuff.
If they were running cache-only nameservers then there would not be a problem.
Lance
On Wednesday, 12 January 2005, at 18:12:23 (+0000), Lance Davis wrote:
Yes - but the people who have edited the files are not running cache-only nameservers
And thus, they are wrong. See previous post.
This is not a CentOS issue.
Michael
Lance Davis wrote:
On Wed, 12 Jan 2005, Michael Jennings wrote:
Nobody's files got "trashed." They were renamed for backup purposes.
Think about it: If you're running a cache-only nameserver, there's nothing you could or should reasonably do to named.conf or any of the /var/named/* files. RedHat wants to make sure that the old-and-busted cache data is replaced by the new-hotness cache data, so they backup your old stuff and install their new stuff. This is a perfectly sane, reasonable, and expected course of action.
Yes - but the people who have edited the files are not running cache-only nameservers - they have mistakenly got that rpm installed and then edited their stuff.
If they were running cache-only nameservers then there would not be a problem.
Lance
Ah... no, that didn't happen here. The only machine that was hit by this "user error"/BUG was one that I had built from the Centos 3.3 ISO disks from scratch. The machines that I had upgraded from RH 9 did NOT have this problem. All the upgraded machines are running Webmin/Usermin/Vitrualmin and have non-caching nameservers running.
If I had paid more attention to the installation and not specified the "Caching Nameserver" then I would not have seen this "problem". While I'd like to blame someone else, it was my mistake that caused the problems here. The machine that I built from scratch is the master nameserver for everything else...
I have to say that I've not experienced this problem on any of the machines that I manage. Each one handles DNS for clients sites ( yeah I know, don't be hatin, but we're not talking about that atm ). Before I set a server live into production, one of my first priorities is of course to remove any program thats installed that I will not need. Its inevitable that if you have programs installed that you don't need you'll end up with problems either via as providing a vulnerable entry point, or a situation such as this, and much else, its a given. That said, I don't even remember seeing this package installed on any of our centos boxes to begin with. So whether it was selected to begin with or its included in a later version of CentOS / RHEL i'm not sure ( I still install with 3.1 ). Either way, it should be the sys admin's responsibility to audit the system before hand, and if possible install only whats needed, if not remove whats not afterwards. I don't think the blame should be on redhat for this one, not centos, but those of our kind that take a more "relaxed" approach to handling their systems.
Just my 2 cents
Beau Henderson http://www.justmanaged.com
seth vidal wrote:
It may well be - but if the design is wrong it is still a bug.
sure but it's not OUR bug.
Fix the bug and release it into CentOSplus. If people don't want the RH bugs then they can choose to use plus.
I assume the problem people are complaining about is a simple spec file change (noreplace) ?
As for the delete & recreate the user, I don't know if that is a problem, if so it might be harder but probably not too hard.
Also, I always do a backup of all my config files before installing any upgrade. I also check with rpm -V to see if I have modified any non config files. I also test on a test/non core box first as well.
John.
-sv
CentOS mailing list CentOS@caosity.org http://lists.caosity.org/mailman/listinfo/centos
On Wed, Jan 12, 2005 at 07:24:14AM -0600, Johnny Hughes wrote:
If you have DNS zones, remove caching-nameserver from that box...it is not a caching-nameserver any longer
Except I didn't have caching nameserver installed. and I got done anyway.
Zebee
On Fri, 2005-01-14 at 11:03 +1100, Zebee Johnstone wrote:
On Wed, Jan 12, 2005 at 07:24:14AM -0600, Johnny Hughes wrote:
If you have DNS zones, remove caching-nameserver from that box...it is not a caching-nameserver any longer
Except I didn't have caching nameserver installed. and I got done anyway.
Zebee
Which error did you have ... that named failed to start after rebooting your machine?
On Thu, Jan 13, 2005 at 06:08:21PM -0600, Johnny Hughes wrote:
Except I didn't have caching nameserver installed. and I got done anyway.
Which error did you have ... that named failed to start after rebooting your machine?
named.conf being overwritten, and chkconfig turning everythign off.
Zebee
Lance Davis wrote:
On Wed, 12 Jan 2005, Ho Chaw Ming wrote:
Yes. Happened on 20 of the servers we updated. It has to do with the caching-nameserver I believe. But yes, it caused some extra scrambling during the updates.
I have now removed caching-nameserver from the core os repo of 3.4 and moved it to the testing repo.
I dont think this is really a problem / issue. This is by-design how RPM works.
- K
Karanbir Singh wrote:
Lance Davis wrote:
On Wed, 12 Jan 2005, Ho Chaw Ming wrote:
Yes. Happened on 20 of the servers we updated. It has to do with the caching-nameserver I believe. But yes, it caused some extra scrambling during the updates.
I have now removed caching-nameserver from the core os repo of 3.4 and moved it to the testing repo.
I dont think this is really a problem / issue. This is by-design how RPM works.
Of-course, the update should not ( as has already been said here ) stop a running proces.
Yes, it did the same thing to me. This is NOT a good thing at all. The default should be to make the new named.conf as named.conf.rpmnew, not move the old one out of the way. And turning OFF a service is really bad.
Ed Clarke
Francois Caen wrote:
Hello,
I encountered a problem when upgrading from 3.3 to 3.4 on i386.
The machine is a production name server running bind. Looks like the new rpm moved my named.conf to .rpmsave and chkconfig'ed bind to off.
That's really bad. A more gentle behavior would have been to save the new named.conf to .rpmnew and not mess with initscripts.
Anyone else notice that?
Francois Caen _______________________________________________ CentOS mailing list CentOS@caosity.org http://lists.caosity.org/mailman/listinfo/centos
-
Beau Henderson -
Ed Clarke -
Francois Caen -
Ho Chaw Ming -
John Newbigin -
Johnny Hughes -
Karanbir Singh -
Lance Davis -
Michael Jennings -
seth vidal -
Timothy Sandel -
Zebee Johnstone