On 28 November 2017 at 13:48, Mark Haney <mark.haney at neonova.net> 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
On 11/28/2017 08:20 AM, James Hogarth wrote:> On 28 November 2017 at 13:48, Mark Haney <mark.haney at neonova.net> 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/errataAnd 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20171128/8e1e7096/attachment-0001.sig>
On 28 November 2017 at 16:06, Johnny Hughes <johnny at centos.org> wrote:> On 11/28/2017 08:20 AM, James Hogarth wrote: >> On 28 November 2017 at 13:48, Mark Haney <mark.haney at neonova.net> 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.