[ale] RHEL 6 rngd issue

[Leam Hall]

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
>