CentOS will no longer follow RHEL, beginning at the end of 2021. It will become the upstream development branch of RHEL.

[Edward Ned Harvey (lopser)]

CentOS will no longer follow RHEL, beginning at the end of 2021. It will become the upstream development branch of RHEL.
https://lists.centos.org/pipermail/centos-announce/2020-December/048208.html

[Paul Heinlein]

On Wed, 9 Dec 2020, 'Edward Ned Harvey (lopser)' via LOPSA Tech Discussion list wrote:

> CentOS will no longer follow RHEL, beginning at the end of 2021. It will become the upstream development branch of RHEL.
> https://lists.centos.org/pipermail/centos-announce/2020-December/048208.html

This has led to much internal discussion at work, specific with regard
to HPC. We have a 250-node cluster running CentOS 7, but we're
unlikely to use CentOS Stream since there are no 8.x versions per se,
only random date-based snapshots.

I'd be interested to know what options others in the same situation
are considering for going forward.

--
Paul Heinlein
hein...@madboa.com
45°38' N, 122°6' W

[Patrick M Landry]

Meet Rocky Linux: New RHEL Fork by the Original CentOS Creator

https://news.itsfoss.com/rocky-linux-announcement

--
Patrick Landry
Director, UCSS
University of Louisiana at Lafayette
patrick...@louisiana.edu

---

From: Paul Heinlein <hein...@madboa.com>
Sent: Wednesday, December 9, 2020 5:11:59 PM
To: Edward Ned Harvey (lopser) <lop...@nedharvey.com>
Cc: 'te...@lopsa.org' <te...@lopsa.org>
Subject: Re: [lopsa-tech] CentOS will no longer follow RHEL, beginning at the end of 2021. It will become the upstream development branch of RHEL.

 

--
This list provided by the League of Professional System Administrators
http://lopsa.org/
---
You received this message because you are subscribed to the Google Groups "LOPSA Tech Discussion list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tech+uns...@lopsa.org.
To view this discussion on the web visit https://groups.google.com/a/lopsa.org/d/msgid/tech/alpine.OSX.2.23.455.2012091508380.32201%40kiki.local.

[WK]

Stream is a non-starter for us, even if it wasn't going to be the BETA
version of RHEL.

We are just as happy with Ubuntu 18/20, so will be mostly using that.
Ubuntu has paid support if something extra-ordinary occurs (such as a
driver issue) but that would be very limited and rare.

We used to like ScientificLinux.  It would be nice if they re-establish
themselves.

W Kern

[Yves Eynard]

What about Steam makes it a “non starter” for you?

-
Yves Eynard


> On Dec 9, 2020, at 19:27, WK <wkm...@bneit.com> wrote:
>
> 

> --
> This list provided by the League of Professional System Administrators
> http://lopsa.org/
> --- You received this message because you are subscribed to the Google Groups "LOPSA Tech Discussion list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to tech+uns...@lopsa.org.

> To view this discussion on the web visit https://groups.google.com/a/lopsa.org/d/msgid/tech/d1576622-09d6-030b-598a-1ff3f70cc998%40bneit.com.

[WK]

Forgot the group

On 12/9/2020 5:07 PM, Yves Eynard wrote:
> What about Steam makes it a “non starter” for you?
>
> -

Stream is a rolling release. That is problematic with a server.

We had bad luck with Gentoo years ago (though I personally liked it for
my own stuff).

With Gentoo sometimes the newer version of certain components would
break things as opposed to a 'patched' version which is otherwise
identical except for the fix.

So the idea that the distro would shift from say php 7.2 to 7.3/7.4
without overt action on our part is asking to break things.

The whole point of RHEL (and CentOS) was if the distro gave you php7.2
you stayed with php7.2 and didn't break the customers site.

Of course, with WordPress we have the opposite problem. WP now wants
php7.4 and Cent8 provide php7.2 so we have to go to alternate packages
(or move them to Ubuntu 20).

Now in the case of the new CentOS stream, the issue is compounded by
their intention to not only move you the newer version, but you are
testing it for them for later inclusion into RHEL8 if it works ok.

-wk

[Matt Lawrence]

There is always Oracle Linux.  I've had good success with it. Free to
use, you only pay if you want support.  None of the painful RedHat
Network stuff.

-- Matt

[Edward Ned Harvey (lopser)]

For me, the problem with CentOS Stream is: Supporting HPC users, we support a lot of commercial tools. Those tools publish that they are supported on RHEL. They don't test on an upstream, and the commercial tools cost a lot more than the servers or RHEL subscriptions. So we must follow what the tools dictate for compatibility. We've never had any problem supporting these tools on CentOS before; the compatibility is simply good enough that for all intents and purposes, they're a perfect binary compatible alternative to RHEL.

Interestingly, I've worked at places that primarily use centos, and I've worked at places that pay for RHEL. The main difference with RHEL is problems with subscriptions. Every support case I've ever needed to open with Red Hat have been to deal with RHEL specific problems, including either subscription problems, or satellite problems. I like paying for RHEL, just to support the upstream of CentOS, and actually using CentOS while ignoring the RHEL subscription. Like clicking the "Donate" button on your favorite podcast or whatnot.

[Brian J. Atkisson]

Use something like Katello or Red Hat Satellite to batch up the Stream 8
updates into weekly, monthly or quarterly releases. IIRC, you can allow
select only security updates to be promoted, while leaving general bug
fixes and enhancements for a larger update batch. It will more or less
mirror the dot releases.

The good news is CentOS 7 will be supported for many more years. Red Hat
is supposed to be announcing free or low cost RHEL subscriptions soon as
well. It is probably worth a phone call before freaking out.

In any case, Streams 8 is available to use now. I'd explore it more
before discounting it. Red Hat is aiming for it to have the same level
of stability as RHEL and CentOS classic.

Cheers,
Brian

[John Stoffel]

>>>>> "'Edward" == 'Edward Ned Harvey (lopser)' via LOPSA Tech Discussion list <te...@lopsa.org> writes:

Edward> For me, the problem with CentOS Stream is: Supporting HPC
Edward> users, we support a lot of commercial tools. Those tools
Edward> publish that they are supported on RHEL. They don't test on an
Edward> upstream, and the commercial tools cost a lot more than the
Edward> servers or RHEL subscriptions. So we must follow what the
Edward> tools dictate for compatibility. We've never had any problem
Edward> supporting these tools on CentOS before; the compatibility is
Edward> simply good enough that for all intents and purposes, they're
Edward> a perfect binary compatible alternative to RHEL.

*this* is the key for us too, at least it used to be.

Edward> Interestingly, I've worked at places that primarily use
Edward> centos, and I've worked at places that pay for RHEL. The main
Edward> difference with RHEL is problems with subscriptions. Every
Edward> support case I've ever needed to open with Red Hat have been
Edward> to deal with RHEL specific problems, including either
Edward> subscription problems, or satellite problems. I like paying
Edward> for RHEL, just to support the upstream of CentOS, and actually
Edward> using CentOS while ignoring the RHEL subscription. Like
Edward> clicking the "Donate" button on your favorite podcast or
Edward> whatnot.

Yeah, I echo this as well. I view this more as a naked grab from the
management for cash, when they *should* have setup a much cheaper
CentOS support cost, something like $10/year per server, so you've
giving back, but getting very little support. Which is what most
people want/need since RHEL/CentOS is so slow to evolve, that once you
get past X.1 or X.2 release, it's just going to work until the next
big jump.

So I'm annoyed at this, but it's still going to be the applications
which drive this for alot of people.

John

[Edward Ned Harvey (lopser)]

> On 12/9/20, 9:50 PM, "Brian J. Atkisson" <br...@atkisson.net> wrote:
>
> Use something like Katello or Red Hat Satellite

Oof, that's a nightmare all by itself. Satellite 5 was pretty good, but satellite 6 is so buggy and unstable, not to mention an unreasonable resource hog... About 1.5 years ago I sunk about a month into making it work, and eventually concluded to scrap it entirely, in favor of reposync with home-grown wrapper scripts. Just a lot of trading one nightmare for another nightmare.

[Brian J. Atkisson]

Yeah, Sat6 was pretty rough, but has gotten a lot better.

- Brian

[Tom Perrine]

 I started looking at alternatives - my company is heavy Centos - but maybe not in the future. As others have pointed out, the new Stream takes away pretty much everything that people wanted from a distro - stability, testing and compatibility with a commercial release.

I was thinking maybe Scientific Linux, but it is going away - Fermi and friends are going to ............ Centos 8 - but that was announced months ago. I wonder if their plans will change.

openSUSE seems like something to think about - it *did* have commercial - sorta - weight behind it with IBM, until they bought RedHat.

It feels like the demise of "classic Centos" will create a vacuum, and whomever can step into that successfully has the opportunity to win big

--tep

[Stephen Potter]

Maybe I misunderstood the plans for Stream, but I thought it was meant to be an upstream of a specific RHEL major release (ie RHEL8), unlike Fedora which is an upstream of RHEL "next".  So, since RHEL8 is tied to php7.2, Stream would remain php7.2 as well, while Fedora would get php7.3/7.4/7.5/7.6 until they decided to lock it in for the RHEL 9 alpha release.  Reading the FAQ at https://wiki.centos.org/FAQ/CentOSStream seems to indicate that:

"Its content is what Red Hat intends to be in the next update of a stable RHEL release."

"At a future milestone, users can expect CentOS Stream content will include content intended for inclusion in the next RHEL minor release."

"Around the time the RHEL 9 Public Beta is issued, an additional set of CentOS Stream repositories and ISOs will be available."

-spp

[Stephen Potter]

Yeah, but it's Oracle.  If you dislike IBM/RH, why in gods name would
you want to go anywhere near Oracle?

-spp

[yves eynard]

That is my understanding too— in actuality, Streams will have tighter integration with RHEL than CentOS Linux. 

I think there is a lot of FUD right now about what is actually happening. I think the best thing to do is wait and watch the next couple of months to see what Streams really means and wether or not it works for your environment. As well as what Red Hat comes up with in terms of new RHEL offerings. 

-yce

--
This list provided by the League of Professional System Administrators
http://lopsa.org/
---
You received this message because you are subscribed to the Google Groups "LOPSA Tech Discussion list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tech+uns...@lopsa.org.

To view this discussion on the web visit https://groups.google.com/a/lopsa.org/d/msgid/tech/2002d736-5ea6-16fe-af21-ea00e99ea637%40unixsa.net.

[Edward Harvey]

> On 12/9/20, 9:50 PM, "Brian J. Atkisson" <br...@atkisson.net> wrote:
>

> Red Hat
> is supposed to be announcing free or low cost RHEL subscriptions soon as
> well.

Honestly there's a solid case to be made for making RHEL free - anyone who wants to use RHEL for free now already does; they just use CentOS. So if they offer RHEL for free, they're not going to hurt their revenue stream. Their revenue stream comes from the clients who need the assurance of having a support contract, and those clients don't change just because free CentOS got renamed to free RHEL.

So, we shall see what happens.

[Patrick M Landry]

Meet Rocky Linux: New RHEL Fork by the Original CentOS Creator

https://news.itsfoss.com/rocky-linux-announcement

-- 
Patrick Landry
Director, University Computing Support Services
University of Louisiana at Lafayette
P.O. Box 43621
Lafayette, LA 70504
(337) 482-6402
patrick...@louisiana.edu
–––––––––––––––––––––––––
Université des Acadiens

[Paul Heinlein]

On Wed, 9 Dec 2020, Brian J. Atkisson wrote:

> Use something like Katello or Red Hat Satellite to batch up the
> Stream 8 updates into weekly, monthly or quarterly releases. IIRC,
> you can allow select only security updates to be promoted, while
> leaving general bug fixes and enhancements for a larger update
> batch. It will more or less mirror the dot releases.

I've considered this. My team is dubious that it won't become a drain
on time, but it's certainly up for consideration.

> The good news is CentOS 7 will be supported for many more years. Red
> Hat is supposed to be announcing free or low cost RHEL subscriptions
> soon as well. It is probably worth a phone call before freaking out.

We actually have RHEL licenses, so moving in that direction is
possible. I must admit the the license+Satellite infrastructure does
not thrill me. I take some advantage of the Satellite API, but the
best I can say is that I tolerate Satellite.

> In any case, Streams 8 is available to use now. I'd explore it more
> before discounting it. Red Hat is aiming for it to have the same level
> of stability as RHEL and CentOS classic.

Oh, definitely! I switched over a testing VM from 8.3 to Stream as
soon as we got the word.

[Brian J. Atkisson]

On 12/10/20 9:59 AM, Paul Heinlein wrote:
> On Wed, 9 Dec 2020, Brian J. Atkisson wrote:
>
>> Use something like Katello or Red Hat Satellite to batch up the Stream
>> 8 updates into weekly, monthly or quarterly releases. IIRC, you can
>> allow select only security updates to be promoted, while leaving
>> general bug fixes and enhancements for a larger update batch. It will
>> more or less mirror the dot releases.
>
> I've considered this. My team is dubious that it won't become a drain on
> time, but it's certainly up for consideration.

My team manages several Satellite 6 clusters, mostly using Ansible to
drive content views. It works well these days and some of the other
Satellite features are very helpful, like SCAP reporting. Not a sales
pitch, just saying it is a viable option.

[WK]

On 12/10/2020 12:33 AM, Stephen Potter wrote:
>
> Maybe I misunderstood the plans for Stream, but I thought it was meant
> to be an upstream of a specific RHEL major release (ie RHEL8), unlike
> Fedora which is an upstream of RHEL "next".  So, since RHEL8 is tied
> to php7.2, Stream would remain php7.2 as well, while Fedora would get
> php7.3/7.4/7.5/7.6 until they decided to lock it in for the RHEL 9
> alpha release.  Reading the FAQ at
> https://wiki.centos.org/FAQ/CentOSStream seems to indicate that:
>
> "Its content is what Red Hat intends to be in the next update of a
> stable RHEL release."
>
> "At a future milestone, users can expect CentOS Stream content will
> include content intended for inclusion in the next RHEL minor release."
>
> "Around the time the RHEL 9 Public Beta is issued, an additional set
> of CentOS Stream repositories and ISOs will be available."
>

OK, let see if I understand this.

With traditional CentOS:

When a patch or point upgrade was desired, Redhat tested it and when
ready release it to RHEL. Then the CentOS people would get the SRPM and
apply it to their distribution. Note that meant that security patches
were given to RHEL users before CentOS users who were a little more
vulnerable as a result.

With CentOS Stream:

When a patch/point upgrade (but NOT a version upgrade) is desired.
Redhat creates/tests and then deploys the the result into Stream. If
nothing blows up they put it into RHEL or it may show up in the next
RHEL distro point release (i.e 8.5)

So the result is your server may blow up which is unlikely but did
happen this issue from the summer which affected RHEL & CENTOS

https://arstechnica.com/gadgets/2020/07/red-hat-and-centos-systems-arent-booting-due-to-boothole-patches/

Stream possibly would have saved the RHEL customers in that case.

OTOH, your Stream server may be a little more secure because it got an
earlier patch release of the next horrible security issue.

-wk

[Rackow, Gene]

For all of the CentOS/RHEL comments on "being supported", please be sure to read what that means according to RH.
When the system goes into Maint Level 2, the patches you are getting are only those that are rated "critical" or "important", as deemed by the RH team.
RH may or may not agree with the CVE ratings on a hole.

To some degree this is acceptable since if the bug is not exploitable on the platform it really doesn't matter.
In other cases it can be considered death by 1000 cuts. If you pair hole 1 with hole 2, can you get root?
Others require that you made no changes from the default configs for the RH statements to be true.

These levels of support put a much bigger load on the IT and Security teams that are managing the systems as well.
You'll need to be digging into every new vuln that comes up and doing eval on it. In some cases RH provides
enough detail on why they are not touching it, but others are kind of vague.
In once case we looked at the report indicated this was not significant since the config files for the
software package had the vuln feature disabled by default. If you changed the config file, your
system was now had a crit vuln on it that RH wasn't going to fix. Back to the source tree for the app and compile on your own.

If you deal with a vuln scanner, kali, tenable, ..., many work off of banner grabs. Since the banners are
coming up as EOL or vuln versions, you'll need to dig into them to prove the patch is backported and have
docs for any auditor to prove it. Then if you accept the risk of the system, what happens when someone
rebuilds that server? Did the patch get rolled back in, or are you working from bad info?

--Gene