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? Thanks, Joseph L. Casale
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. -- Mark Haney Network Engineer at NeoNova 919-460-3330 option 1 mark.haney at neonova.net www.neonova.net
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:06 AM, Joseph L. Casale wrote:> What is the case with users on this list who support both [rolling releases like the normal CentOS model and 'constrain to the point releases' as is possible with RHEL]?I personally run RHEL just like my CentOS installs, as a rolling release. If you want to get more input on this idea, you might want to also ask the Scientific Linux mailing list, since SL can be run in a 'constrain to the point release' mode with full security updates maintained, and you're likely to get a broader response base as to why this is done.
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? >Only time we use CR is on *some* servers during the upgrade to a new subrelease. Otherwise, nope. mark
On 11/28/2017 10:20 AM, m.roth at 5-cent.us wrote:> 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? >> > Only time we use CR is on *some* servers during the upgrade to a new > subrelease. Otherwise, nope.When I was a sysadmin for a living, I used CR in my test/staging area to see if everything worked. After I worked out all the kinks, I then either used CR on my production servers and/or waited until the actual point release, based on how close the release was going to be after I finished evaluating in testing/staging. In general, for CentOS Linux 6 and before .. CR takes 3 or 4 days and final release is usually 14 to 21 days. For CentOS Linux 7 (because of more rebases to newer versions that are much less conservative than EL6 and before) CR usually takes 10-14 days and final point release 35 to 42 days. So, the delta in both cases (from CR done to final point release) is 2 to 4 weeks after CR rpms are released. -------------- 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/f8aaca19/attachment-0001.sig>
On Tue, Nov 28, 2017 at 8:06 AM Joseph L. Casale <jcasale at activenetwerx.com> wrote:> On the other hand I see the > opposite with RHEL where admins constrain installations to the > point release.This is most commonly due to 3rd party support stipulations (I?m looking at you Oracle/SAP) who haven?t/won?t/lag test a fully patched version of the OS. It also has a lot to do with the admins and the admins competence and ability to call 1-800-$vendor when something doesn?t work. . . . Two ends of the same spectrum.>
> -----Original Message----- > From: CentOS [mailto:centos-bounces at centos.org] On Behalf Of Joseph L. > Casale > Sent: den 28 november 2017 14:06 > To: 'centos at centos.org' <centos at centos.org> > Subject: [CentOS] Admins supporting both RHEL and CentOS > > 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 treat them as rolling releases. Except for those I don't. :-) Seriously, some of the RHEL-boxes we use, require a particular point release as well as not allowing any updates to the OS. At all. Yeah, I know... If updated, the instrument software will break, like in an atomic mushroom cloud, rendering critical hardware non-working and lab people standing outside my office with torches, pitch-forks and all the shebang. Yupp, unfortunately that's the current state of some lab equipment manufacturers that use RHEL as a base... -- //Sorin
Le 29/11/2017 ? 08:26, Sorin Srbu a ?crit?:> If updated, the instrument software will break, like in an atomic mushroom > cloud, rendering critical hardware non-working and lab people standing > outside my office with torches, pitch-forks and all the shebang. > Yupp, unfortunately that's the current state of some lab equipment > manufacturers that use RHEL as a base...ProMAX/SeisSpace, a geophysical calculation software edited by Halliburton and costing roughly $ 50.000 / workstation still requires RHEL 5.x to run. :o) -- Microlinux - Solutions informatiques durables 7, place de l'?glise - 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info at microlinux.fr T?l. : 04 66 63 10 32
Hi Joseph,> On 28. Nov 2017, at 14:06, Joseph L. Casale <jcasale at activenetwerx.com> 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.I concur with the latter: I also often see RHEL installations where the admins assume they are running "RHEL 7.3" rather than "RHEL 7". In some cases there isn't even an upgrade mechanism in place: Systems are installed from ISO images (usually by the solution vendor) and there are no upgrades whatsoever until the system gets decommissioned. While that may seem a bit strange insofar as the upgrade mechanism with RHEL works quite the same as with CentOS by default (running updates regularly will make RHEL cross .x boundaries when they are reached), the different behaviour might come from three facts: 1. some vendors restrict their support to specific .x releases, 2. RHEL systems tend to run in production environments more often than CentOS systems, so they are subject to stricter rules regarding testing and clearance of updates, and 3. maintaining a RHN satellite or allowing internet access for RHN-registered systems is not part of the enterprise's IT strategy (don't laugh).> What is the case with users on this list who support both?I for my part treat RHEL and CentOS basically the same with respect to upgrades wherever possible: The test stages are quite near to the current bleeding-edge release (if that expression is not too far-fetched for an enterprise distribution), and after successful testing (usually a couple of weeks to a month, with the exception of security updates which are higher prioritised) they go into production. Cheers, Pete.
-----Original Message----- From: CentOS [mailto:centos-bounces at centos.org] On Behalf Of Peter Eckel Sent: Wednesday, November 29, 2017 5:21 AM To: CentOS mailing list <centos at centos.org> Subject: Re: [CentOS] Admins supporting both RHEL and CentOS> While that may seem a bit strange insofar as the upgrade mechanism with > RHEL works quite the same as with CentOS by default (running updates > regularly will make RHEL cross .x boundaries when they are reached), the > different behaviour might come from three facts: 1. some vendors restrict > their support to specific .x releases, 2. RHEL systems tend to run in > production environments more often than CentOS systems, so they are > subject to stricter rules regarding testing and clearance of updates, and 3. > maintaining a RHN satellite or allowing internet access for RHN-registered > systems is not part of the enterprise's IT strategy (don't laugh).So at the current shop I am in, they have updates provided by Satellite and the channel is locked on the point release. I just wondered how common this was. Thanks for all insight everyone. jlc
-----Original Message----- From: CentOS [mailto:centos-bounces at centos.org] On Behalf Of Sorin Srbu Sent: Wednesday, November 29, 2017 12:26 AM To: CentOS mailing list <centos at centos.org> Subject: Re: [CentOS] Admins supporting both RHEL and CentOS> Seriously, some of the RHEL-boxes we use, require a particular point release > as well as not allowing any updates to the OS. At all.Any of the vendors on those boxes happen to be Oracle or Netcracker?