Bug 7757 - bind-8.2.2_P3-0.5.2 is instable!
bind-8.2.2_P3-0.5.2 is instable!
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: bind (Show other bugs)
5.2
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-12-11 16:55 EST by van der Kooij, Hugo
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-01-18 15:09:54 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 van der Kooij, Hugo 1999-12-11 16:55:22 EST
Hi,

It seems that bind-8.2.2_P3-0.5.2 is very unstable.

I was able to run my server for weeks and now I need to shutdown named at
least once a day. As this behaviour will also influence sendmail it is
becoming rather annoying and a real pain in the butt.

Basically it makes a mission critical machine rather unreliable. Some
sources already indicated that the P3 version of bind is NOT to be used but
one should use P5 as indicated on: http://www.isc.org/products/BIND/

Hugo.
Comment 1 van der Kooij, Hugo 1999-12-22 18:44:59 EST
Found some more about the issue.

It seems named is not started by default in runlevel 3 anymore. It used to do
before the security update. But apparantly the update broke this.

I suggest you create a fix for this and make sure you don't change the runlevel
settings of a package while you upgrade.
Comment 2 Bernhard Rosenkraenzer 2000-01-18 15:09:59 EST
The runlevels change is a security feature, not a bug. We now default to turning
everything off before it's configured.
As for stability, I've been running a test box ever since you originally
reported the bug, and haven't had to restart named at all - do you get anything
in syslog when your named crashes?

As for using 8.2.2P5 instead of P3, the page you quoted says you should update
to at least 8.2.2P3 (P5 does NOT have any new security fixes), and if you're
using a vendor-provided 8.2.2P3, you should confirm the named-xfer bug has been
patched. We have patched it in 8.2.2P3-0.*, so there's no reason to go 8.2.2P5.
Comment 3 Michael CorbeilMlution.com 2000-04-14 06:34:59 EDT
It is not only unstable, but running rpm -K --nopgp also reports

	size md5 GPG NOT OK

This also occurs for a number of RH 5.2 upgrade packages, namely:

(from http://www.redhat.com/support/errata/rh52-errata-general.html)

bind-8.2.2_P3-0.5.2.i386.rpm
bind-devel-8.2.2_P3-0.5.2.i386.rpm
bind-utils-8.2.2_P3-0.5.2.i386.rpm
groff-1.15-0.5.2.i386.rpm
groff-gxditview-1.15-0.5.2.i386.rpm
libtiff-3.5.4-0.5.2.i386.rpm
libtiff-devel-3.5.4-0.5.2.i386.rpm
lpr-0.48-0.5.2.i386.rpm
nfs-server-2.2beta47-1.i386.rpm
sharutils-4.2.1-1.5.2.i386.rpm
sysklogd-1.3.31-1.5.i386.rpm
sysklogd-1.3.31-14.i386.rpm
wu-ftpd-2.6.0-0.5.x.i386.rpm
wu-ftpd-2.6.0-1.i386.rpm
ypserv-1.3.9-0.5.2.i386.rpm

All of these RPMs give the "size md5 GPG NOT OK" message, and according to
documentation I read on rpm, people should not install such RPMs.

What I find curious is what such packages are doing in the download directory.
Why would this condition not be verified before making RPMs available for
download?

Note You need to log in before you can comment on or make changes to this bug.