Re: Admins supporting both RHEL and CentOS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On 28 November 2017 at 16:06, Johnny Hughes <johnny@xxxxxxxxxx> wrote:
> On 11/28/2017 08:20 AM, James Hogarth wrote:
>> On 28 November 2017 at 13:48, Mark Haney <mark.haney@xxxxxxxxxxx> wrote:
>>> On 11/28/2017 08:06 AM, Joseph L. Casale wrote:
>>>>
>>>> With a few exceptions, I see most admins treat CentOS as a single
>>>> rolling release and rely on the ABI commitment assuming things
>>>> just work between point releases. On the other hand I see the
>>>> opposite with RHEL where admins constrain installations to the
>>>> point release.
>>>>
>>>> What is the case with users on this list who support both?
>>>
>>>
>>> I can't really speak for anyone else, but for me, a lot depends on the use
>>> of the systems.  I typically treat RHEL and CentOS the same way as far as
>>> updating to the latest point release.  It's never bit me in the past that I
>>> am aware of.
>>>
>>> The only exception to that is with the SGI Altix 4300/4400s I used to
>>> manage.  We migrated from SLES to RHEL and in those cases, barring a serious
>>> enough bug, those boxes were left alone until time came to refresh them,
>>> such as the move from RHEL5 to RHEL6.
>>>
>>>
>>
>>
>> Note that RHEL is a special case as there's some situations companies
>> will pay out for the Extended Update Support (EUS)[0] in order to stay
>> on a particular milestone for longer.
>>
>> In addition there is the slight bonus of access to beta of the next
>> milestone or major release which may affect your workflow if you have
>> a suitable test environment, and of course you'll get the milestone
>> quicker on release so that needs to be paid attention to for testing.
>>
>> Outside of this area the two can be, and should be, treated
>> identically in terms of update policies.
>>
>>
>>
>> [0] https://access.redhat.com/support/policy/updates/errata
>
> And also note that Red Hat does not publicly release the SRPMs for their
> EUS packages.  The CentOS Project therefore can not build those, so
> there is NO EUS in CentOS Linux.  The only way to get Security updates
> in CentOS Linux is to be on the current (latest) point release.
>
> Also, since all updates are built against the current (latest) release
> as they are released, there is no way to get only security updates in
> CentOS Linux.  You could TRY to only install security updates on your
> own .. however, since there are rebases during point releases, things
> that are built against the newer openssl will not work with older ssl's
> OR things build against the newer gnome will not work with older
> gnome's, etc.
>
> The only tested way to run CentOS Linux is with all the updates
> installed together.
>
>
>

Even Red Hat technically on RHEL doesn't "support" only installing
updates marked security as they always have an assumption all previous
errata are applied.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos



[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]


  Powered by Linux