redhat package versions [ was Re: 9.8.2 Assertion Failures ]

Michael Hoskins (michoski) michoski at cisco.com
Tue Jul 17 18:28:57 UTC 2012


turning a dead horse into a wet spot on the ground (in-line)...


-----Original Message-----
From: Oscar Ricardo Silva <osilva at scuff.cc.utexas.edu>
Date: Tuesday, July 17, 2012 7:13 AM
To: "'bind-users at lists.isc.org'" <bind-users at lists.isc.org>
Subject: Re: 9.8.2 Assertion Failures

>Bailey, Morgan [BT] wrote:
>> Hi all
>> 
>>  
>> 
>> We have recently made some major changes to our DNS infrastructure.
>> This involved consolidating servers and standardizing on a single RHEL6
>> platform.  We currently running the latest RHEL6 packaged BIND release
>> of 9.8.2 (9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6).  Lately on one of our
>> busier names servers the named daemon has been crashing with assertion
>> errors.  Here is a recent log snippet:
>> 
>>  
>This appears to be the same problem we're experiencing on RHEL6.  This
>bug WAS fixed in bind 9.8.2rc2 AND the final 9.8.2 BUT Redhat decided to
>use 9.8.2rc1 as the base for their bind package.  I can't shake my head
>enough trying to figure out why they would use a release candidate but
>that's what was done.
>
>Anyway, Redhat is working on a patch for this and it should be released
>"soon".
>
><https://bugzilla.redhat.com/show_bug.cgi?id=837165>

just to ensure it's clear for posterity (i've seen it mis-stated a few
times)...  and to point out another common frustration with RHEL -- the
package version itself of "9.8.2rc2" is no real indication of what version
you're running on this platform.  you have to dig through the errata on
RHN to figure out what patches your sub-package (e.g. -0.10) actually
contains.  within the RHEL community you can find lots of vehement
advocacy for this approach, and i really don't want to be involved in that
argument, but for the most part it makes RHEL version numbers meaningless
to the larger community.

i am glad to see there's an official fix in the pipeline...but this
frustration is one reason we maintain our own packages.  with the tarballs
and easy build process from ISC, generating the required spec file is
easy...and lets you control pre/post-install steps.  it's also easy to
host your own yum repo, and tie that into cfengine, puppet, etc.




More information about the bind-users mailing list