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.
On 28 November 2017 at 13:48, Mark Haney mark.haney@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.
On 11/28/2017 08:20 AM, James Hogarth wrote:
On 28 November 2017 at 13:48, Mark Haney mark.haney@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.
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.
On 28 November 2017 at 16:06, Johnny Hughes johnny@centos.org wrote:
On 11/28/2017 08:20 AM, James Hogarth wrote:
On 28 November 2017 at 13:48, Mark Haney mark.haney@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.
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.
On 11/29/2017 05:14 AM, James Hogarth wrote:
On 28 November 2017 at 16:06, Johnny Hughes johnny@centos.org wrote:
On 11/28/2017 08:20 AM, James Hogarth wrote:
On 28 November 2017 at 13:48, Mark Haney mark.haney@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.
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.
That is indeed correct and it is on every errata released from Red Hat:
"Before installing an update, make sure all previously released errata relevant to the system have been applied."
Therefore the only real difference in recommendations is that EUS is available in RHEL packages.
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@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.
On Tue, Nov 28, 2017 at 8:06 AM Joseph L. Casale jcasale@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@centos.org] On Behalf Of Joseph L. Casale Sent: den 28 november 2017 14:06 To: 'centos@centos.org' centos@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)
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of Nicolas Kovacs Sent: den 29 november 2017 08:31 To: centos@centos.org Subject: Re: [CentOS] Admins supporting both RHEL and CentOS
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)
LOL!! Awesome! Better living through technology, right? :-D
-- //Sorin
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of Sorin Srbu Sent: Wednesday, November 29, 2017 12:26 AM To: CentOS mailing list centos@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?
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of Joseph L. Casale Sent: den 30 november 2017 01:25 To: CentOS mailing list centos@centos.org Subject: Re: [CentOS] Admins supporting both RHEL and CentOS
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of Sorin Srbu Sent: Wednesday, November 29, 2017 12:26 AM To: CentOS mailing list centos@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?
No, it's Varian/Agilent. A big player in lab instruments.
Funny thing, just googled them and apparently they've opensoured the culprit software, and according to the below link, it's not locked to a particular point release anymore!
http://openvnmrj.org/Downloading/
It does however still require the original software - which _is_ locked to a particular point release. Dammit', so close!
-- //Sorin
No, it's Varian/Agilent. A big player in lab instruments.
Funny thing, just googled them and apparently they've opensoured the culprit software, and according to the below link, it's not locked to a particular point release anymore!
http://openvnmrj.org/Downloading/
It does however still require the original software - which _is_ locked to a particular point release. Dammit', so close!
Yes, our spectrometers that run VNMRJ are not allowed directly on the network. They are tucked away safely behind a NAT'd firewall with very few ports open and access is only allowed by proxy ssh from a few IP addresses (for some reason the users want to retrieve their data from it!). The extra cost of a firewall is nothing compared to the cost of the instrument.
P.
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of Pete Biggs Sent: den 30 november 2017 09:50 To: centos@centos.org Subject: Re: [CentOS] Admins supporting both RHEL and CentOS
No, it's Varian/Agilent. A big player in lab instruments.
Funny thing, just googled them and apparently they've opensoured the
culprit
software, and according to the below link, it's not locked to a
particular
point release anymore!
http://openvnmrj.org/Downloading/
It does however still require the original software - which _is_ locked
to a
particular point release. Dammit', so close!
Yes, our spectrometers that run VNMRJ are not allowed directly on the network. They are tucked away safely behind a NAT'd firewall with very few ports open and access is only allowed by proxy ssh from a few IP addresses (for some reason the users want to retrieve their data from it!). The extra cost of a firewall is nothing compared to the cost of the instrument.
Same setup here. It's the SOP for these systems I guess. We were even able to find that specific consumer grade Zyxel router!
We solved the user access to the spectra with a script that pulled in the data-folders from the instrument boxes via rsync to a Processing computer, to which they could connect with eg WinSCP, after first having plugged a hole in the firewall/router.
For some reason the users don't like going down three or four stairs to the basement to pick up the spectra on a usb-stick, then dumping it to their own computers and do a more detailed processing.
-- //Sorin
Hi Joseph,
On 28. Nov 2017, at 14:06, Joseph L. Casale jcasale@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@centos.org] On Behalf Of Peter Eckel Sent: Wednesday, November 29, 2017 5:21 AM To: CentOS mailing list centos@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
-
James Hogarth -
Johnny Hughes -
Joseph L. Casale -
Lamar Owen -
m.roth＠5-cent.us -
Mark Haney -
Nicolas Kovacs -
Pete Biggs -
Peter Eckel -
Sorin Srbu -
Steven Tardy