[ale] RHEL 6 rngd issue

Mon Aug 31 20:00:00 EDT 2015

Leam,

Again I'll point out that Red Hat's binary compatibility policy applies to APIs and ABIs.  Red Hat does not guarantee that every package will change in no discernible way during the lifespan of a RHEL release..  You should take a look at the article from the customer portal that I linked, it explains it.

If you give me your case number, I can look at it, but you're probably just abusing some poor guy in India.

-Scott

> On Aug 31, 2015, at 7:20 PM, Leam Hall <leamhall at gmail.com> wrote:
> 
> Uh...you do realize that's Red Hat's business model for RHEL, right? While not the only reason companies buy RHEL, it's one of the major ones.
> 
> Leam
> 
> 
>> On 08/31/15 17:17, Scott McBrien wrote:
>> That's the thing though.  Upgrading the package to a version that
>> obsoletes options you were using on the older version isn't 'broken',
>> it's different.  I know you don't feel that way about it.  But what's
>> the alternative?  Red Hat forks the newer version of rngd, hacks on it
>> to add back in the options that were taken out by the actual package
>> authors, then has to mangle updates into this forked, hacked together
>> code base from the upstream?
>> 
>> You think you had problems when they just updated the package to match
>> the upstream?  I don't want to see what happens if Red Hat addressed it
>> in the alternate method I outlined.
>> 
>> -Scott
>> 
>> On Aug 31, 2015, at 3:41 PM, leam hall <leamhall at gmail.com
>> <mailto:leamhall at gmail.com>> wrote:
>> 
>>> I can see breaking stuff if there's a big (Heartbleed) reason. But
>>> rngd in the last patch update, and last year it was one of the
>>> filesystem encryption methods. Can't remember if it was LUKS or
>>> ecryptfs. Either way, if you break stuff, aren't you supposed to be
>>> motivated to fix it?
>>> 
>>> 
>>> 
>>> On Mon, Aug 31, 2015 at 3:22 PM, Scott McBrien <smcbrien at gmail.com
>>> <mailto:smcbrien at gmail.com>> wrote:
>>> 
>>>    Red Hat doesn't guarantee to not break all the things, but rather
>>>    things like ABIs and APIs.
>>>    https://access.redhat.com/site/articles/rhel-abi-compatibility
>>> 
>>>    With the lifespan of a RHEL release growing from 5 to 7 to 10
>>>    years (plus extra years for those willing to pay for it), it's
>>>    just not feasible to expect that the OS will stay as static as one
>>>    might like.  There are times where a package just needs to get
>>>    refreshed to a newer version, where back porting may no longer be
>>>    an option.  Red Hat doesn't do this all the time, and there are
>>>    some packages (like gcc or the kernel) where updating the package
>>>    would violate the api/abi compatibility.  Other packages are fair
>>>    game though.
>>> 
>>>    Taking my Red Hat off.  I understand your frustration.  This
>>>    happened to me on RHEL 7 between 7.0 and 7.1 for one of the
>>>    packages I use, and it was more severe than a couple of option
>>>    changes.  When talking with Red Hat engineering about it, it was
>>>    obvious that they had no idea why I was miffed.  I should clarify,
>>>    the engineers had no idea why I would be miffed.  The Product
>>>    Managers understood, but figured out that there weren't a lot of
>>>    people using the package so that upgrading it would add features
>>>    and make it easier to use, and that it was worth the risk of
>>>    putting off a couple of atypical customers (internal) to improve
>>>    the product.
>>> 
>>>    It happens, it's painful sometimes, but the decisions aren't made
>>>    by random, there usually is a reason that it was decided to change
>>>    the package. Whether you agree with that reason or not is a
>>>    completely other thing ;-)
>>> 
>>>    -Scott
>>> 
>>>    On Aug 31, 2015, at 2:58 PM, leam hall <leamhall at gmail.com
>>>    <mailto:leamhall at gmail.com>> wrote:
>>> 
>>>>    If you're using rngd on RHEL 6, check to see if you're using the
>>>>    -i or -t options. RH did a major version upgrade, from 2.x to
>>>>    5.x, and dropped support for those options. Unfortunately, if you
>>>>    do have them in your /etc/sysconfig/rngd file it will preclude
>>>>    rngd from starting at all. I've sent RH a kludgy work-around. Or
>>>>    you could use {Puppet|Chef|Salt|Ansible}, etc. Lots of
>>>>    possibilities.
>>>> 
>>>>    I'm mostly frustrated because one of the RH standards is that
>>>>    they don't break stuff in the middle of an OS. This is the second
>>>>    time I've seen it in as many years, and the "we don't see that as
>>>>    a priority issue" tap dance is starting to bug me.
>>>> 
>>>>    Leam
>>>> 
>>>> 
>>>>    --
>>>>    Mind on a Mission <http://leamhall.blogspot.com/>
>>>>    _______________________________________________
>>>>    Ale mailing list
>>>>    Ale at ale.org <mailto:Ale at ale.org>
>>>>    http://mail.ale.org/mailman/listinfo/ale
>>>>    See JOBS, ANNOUNCE and SCHOOLS lists at
>>>>    http://mail.ale.org/mailman/listinfo
>>> 
>>>    _______________________________________________
>>>    Ale mailing list
>>>    Ale at ale.org <mailto:Ale at ale.org>
>>>    http://mail.ale.org/mailman/listinfo/ale
>>>    See JOBS, ANNOUNCE and SCHOOLS lists at
>>>    http://mail.ale.org/mailman/listinfo
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Mind on a Mission <http://leamhall.blogspot.com/>
>>> _______________________________________________
>>> Ale mailing list
>>> Ale at ale.org <mailto:Ale at ale.org>
>>> http://mail.ale.org/mailman/listinfo/ale
>>> See JOBS, ANNOUNCE and SCHOOLS lists at
>>> http://mail.ale.org/mailman/listinfo
>> 
>> 
>> _______________________________________________
>> Ale mailing list
>> Ale at ale.org
>> http://mail.ale.org/mailman/listinfo/ale
>> See JOBS, ANNOUNCE and SCHOOLS lists at
>> http://mail.ale.org/mailman/listinfo
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo