Re: [CentOS] Admins supporting both RHEL and CentOS

[Sorin Srbu]

> -Original Message-
> From: CentOS [mailto:centos-boun...@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
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Admins supporting both RHEL and CentOS

[Pete Biggs]

> 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.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Admins supporting both RHEL and CentOS

[Sorin Srbu]

> -Original Message-
> From: CentOS [mailto:centos-boun...@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-boun...@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
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Admins supporting both RHEL and CentOS

[Joseph L. Casale]

-Original Message-
From: CentOS [mailto:centos-boun...@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?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Admins supporting both RHEL and CentOS

[Joseph L. Casale]

-Original Message-
From: CentOS [mailto:centos-boun...@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
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Admins supporting both RHEL and CentOS

[Johnny Hughes]

On 11/29/2017 05:14 AM, James Hogarth wrote:
> On 28 November 2017 at 16:06, Johnny Hughes  wrote:
>> On 11/28/2017 08:20 AM, James Hogarth wrote:
>>> On 28 November 2017 at 13:48, Mark Haney  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.

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.



signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Admins supporting both RHEL and CentOS

[Peter Eckel]

Hi Joseph, 

> On 28. Nov 2017, at 14:06, 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.

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.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Admins supporting both RHEL and CentOS

[James Hogarth]

On 28 November 2017 at 16:06, Johnny Hughes  wrote:
> On 11/28/2017 08:20 AM, James Hogarth wrote:
>> On 28 November 2017 at 13:48, Mark Haney  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@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Admins supporting both RHEL and CentOS

[Sorin Srbu]

> -Original Message-
> From: CentOS [mailto:centos-boun...@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
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Admins supporting both RHEL and CentOS

[Nicolas Kovacs]

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 : i...@microlinux.fr
Tél. : 04 66 63 10 32
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Admins supporting both RHEL and CentOS

[Sorin Srbu]

> -Original Message-
> From: CentOS [mailto:centos-boun...@centos.org] On Behalf Of Joseph L.
> Casale
> Sent: den 28 november 2017 14:06
> To: '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

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Admins supporting both RHEL and CentOS

[Steven Tardy]

On Tue, Nov 28, 2017 at 8:06 AM Joseph L. Casale 
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.

>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Admins supporting both RHEL and CentOS

[Johnny Hughes]

On 11/28/2017 10:20 AM, m.r...@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.



signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Admins supporting both RHEL and CentOS

[m . roth]

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

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Admins supporting both RHEL and CentOS

[Johnny Hughes]

On 11/28/2017 08:20 AM, James Hogarth wrote:
> On 28 November 2017 at 13:48, Mark Haney  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.



signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Admins supporting both RHEL and CentOS

[Lamar Owen]

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.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Admins supporting both RHEL and CentOS

[James Hogarth]

On 28 November 2017 at 13:48, Mark Haney  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
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Admins supporting both RHEL and CentOS

[Mark Haney]

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.ha...@neonova.net
www.neonova.net
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos