On 20/01/2021 15.20, Mike McGrath wrote:

On Wed, Jan 20, 2021 at 7:48 AM Peter Georg < peter.georg@physik.uni-regensburg.de> wrote:

...

On 20/01/2021 14.14, Mike McGrath wrote:

...

Hi all, I know this was a hot topic on the list so I thought I'd share today's blog post which covers no-cost RHEL for small production

workloads

...

and no-cost RHEL for customer development teams. Keep in mind there are other programs coming, these just got done first.

https://www.redhat.com/en/blog/new-year-new-red-hat-enterprise-linux-program...

...

Bullet Points:

 - Self-Support RHEL for no-cost in production use cases of up to 16
 systems.
 - No-cost RHEL for customer development teams (larger number of

systems

...

 for non-production cases).
 - Available no later than February 1
 - Single Sign-on via a Red Hat account, or Github, Twitter, Facebook

or

...

 other accounts (You'll soon not need to provide all kinds of personal
 information like you used to).

In the blog post it is also mentioned that some users "had specific technical questions [...]. We’ve been listening. We know that CentOS Linux was fulfilling a wide variety of important roles."

So I now ask myself: Has any of these questions actually been answered by now? I'm one of these users and so far I only got an automatic reply.

Probably not the correct topic to ask this question, but I simply didn't know where else to ask.

I don't know about all of the questions but there were specific ones I've personally been following about the sign-up/sign-in process (simplified as noted in the blog post). We're also aware of some CI cases that we've looked into. I expect we'll have a blog post or video about best practices on how to automate registration and de-registration as well as automated clean-up of registered systems that are now gone. Another big one is entitlement enforcement (IE: in the old world when you hit your 16 server limit, you're prevented from attaching new systems. It is universally hated.). We've got some changes coming there to address general quality of life issues like that.

         -Mike

I thought about technical questions concerning CentOS Stream. We have been told several times by Red Hat employees on this mailing list to forward these questions to centos-questions@redhat.com as well.

Do you happen to know who is dealing with these questions or might be able to give a status update?

Probably the linked blog post actually does not refer to these kind of technical questions, but solely to technical questions concerning RHEL subscriptions (like the issues you mentioned in your last mail).

Peter

Am 21.01.21 um 12:04 schrieb Ljubomir Ljubojevic:

...

2. It is not clear if only server variants are allowed or if RHEL

Workstation variant will be able to register under Individual Developer license. I use CentOS 8 on my laptop and have Apache + MySQL + PostgreSQL installed although rarely used. What variant Workstation/Server should be installed in such case and will there be any limits what can be installed if one is chosen instead of the other (I never installed RHEL aside from initial beta releases and will have to research this first)? CentOS has all the packages from all the RHEL variants accessible in single variant.

I had the same question and found this:

https://developers.redhat.com/articles/faqs-no-cost-red-hat-enterprise-linux...

Q/A 14.

"Note that subscriptions are for a specific variant, such as desktop, workstation, or server. The no-cost subscription is for Red Hat Enterprise Linux Server, which is a superset of the other editions."

I'm also wondering about the support cycle. Do the no-cost subscriptions have the same length as the paid subscriptions? That's the whole 10 years for EL7 or EL8?

Simon

On Thursday, January 21, 2021 8:51 AM, Neal Gompa ngompa13@gmail.com wrote:

On Thu, Jan 21, 2021 at 9:50 AM Simon Matter simon.matter@invoca.ch wrote:

...

...

Am 21.01.21 um 12:04 schrieb Ljubomir Ljubojevic:

...

2. It is not clear if only server variants are allowed or if RHEL Workstation variant will be able to register under Individual Developer license. I use CentOS 8 on my laptop and have Apache + MySQL + PostgreSQL installed although rarely used. What variant Workstation/Server should be installed in such case and will there be any limits what can be installed if one is chosen instead of the other (I never installed RHEL aside from initial beta releases and will have to research this first)? CentOS has all the packages from all the RHEL variants accessible in single variant.

I had the same question and found this: https://developers.redhat.com/articles/faqs-no-cost-red-hat-enterprise-linux... Q/A 14. "Note that subscriptions are for a specific variant, such as desktop, workstation, or server. The no-cost subscription is for Red Hat Enterprise Linux Server, which is a superset of the other editions."

I'm also wondering about the support cycle. Do the no-cost subscriptions have the same length as the paid subscriptions? That's the whole 10 years for EL7 or EL8?

Yes, they do. You get access to updates and such for the entire lifecycle of the RHEL product.

Entire lifecycle for RHEL 8 is:

5 Years Full Support 5 Years Maintenance Support 2 Years Extended Life Support

I believe the 16 free licenses offer is only providing access to the Full Support and Maintenance Support. There is no indication they are planning to include the ELS for free (which also was never provided by CentOS either).

On Saturday, January 23, 2021 8:04 AM, Strahil Nikolov hunter86_bg@yahoo.com wrote:

...

I believe the 16 free licenses offer is only providing access to the Full Support and Maintenance Support. There is no indication they are planning to include the ELS for free (which also was never provided by CentOS either).

Here is what I see on my developer subscription:

dotNET on RHEL (for RHEL Server) dotNET on RHEL Beta (for RHEL Server) MRG Realtime Oracle Java (for RHEL Server) Oracle Java (for RHEL Server) - Extended Update Support Red Hat Ansible Automation Platform Red Hat Ansible Engine Red Hat Beta Red Hat CodeReady Linux Builder for ARM 64 Red Hat CodeReady Linux Builder for x86_64 Red Hat CodeReady Linux Builder for x86_64 - Extended Update Support Red Hat Container Development Kit Red Hat Container Images Red Hat Container Images Beta Red Hat Developer Tools (for RHEL Server) Red Hat Developer Tools Beta (for RHEL Server) Red Hat Developer Toolset (for RHEL Server) Red Hat Enterprise Linux Atomic Host Red Hat Enterprise Linux Atomic Host Beta Red Hat Enterprise Linux for ARM 64 Red Hat Enterprise Linux for Real Time Red Hat Enterprise Linux for SAP Applications for x86_64 Red Hat Enterprise Linux for SAP HANA for x86_64 Red Hat Enterprise Linux for x86_64 Red Hat Enterprise Linux for x86_64 - Extended Update Support Red Hat Enterprise Linux High Availability - Update Services for SAP Solutions Red Hat Enterprise Linux High Availability for x86_64 Red Hat Enterprise Linux High Availability for x86_64 - Extended Update Support Red Hat Enterprise Linux High Performance Networking (for RHEL Compute Node) Red Hat Enterprise Linux High Performance Networking (for RHEL Server) Red Hat Enterprise Linux High Performance Networking (for RHEL Server)

• Extended Update Support Red Hat Enterprise Linux Load Balancer (for RHEL Server) Red Hat Enterprise Linux Load Balancer (for RHEL Server) - Extended Update Support Red Hat Enterprise Linux Resilient Storage for x86_64 Red Hat Enterprise Linux Resilient Storage for x86_64 - Extended Update Support Red Hat Enterprise Linux Scalable File System (for RHEL Server) Red Hat Enterprise Linux Scalable File System (for RHEL Server) - Extended Update Support Red Hat Enterprise Linux Server Red Hat Enterprise Linux Server - Update Services for SAP Solutions Red Hat EUCJP Support (for RHEL Server) - Extended Update Support Red Hat S-JIS Support (for RHEL Server) - Extended Update Support Red Hat Software Collections (for RHEL Server) Red Hat Software Collections Beta (for RHEL Server) RHEL for SAP (for IBM Power LE) - Update Services for SAP Solutions RHEL for SAP - Extended Update Support RHEL for SAP - Update Services for SAP Solutions RHEL for SAP HANA - Extended Update Support RHEL for SAP HANA - Update Services for SAP

  I think that 'Extended Update Support' is providing the latest phase of EL life.

  Best Regards, Strahil Nikolov

Are you seeing any updates to RHEL 6 published in Decmeber 2020 or January 2021 from your developer subscription?

Are you seeing any updates to RHEL 6 published in Decmeber 2020 or January 2021 from your developer subscription?

I have no RHEL 6 systems at all, but I can access "Red Hat Enterprise Linux for x86_64 - Extended Update Suppport" for 6.7 so I guess I the dev subscription has access to it.

Yet, this is still the old dev subscription and it's limited to 1 phisical host/16 VMs for pure non-prod purposes.

Best Regards, Strahil Nikolov

I still believe (anyone can correct me if I'm wrong), that the Extended Life Cycle Support (ELS) for the 11th year of 6.10 is *NOT* included. To get that additional extention to the lifecycle still needs to be purchased.

I think you are right. As far as I remmeber even a regular customer won't have access to the 11th year unless paid for that.

Still, the dev subscription provides enough to keep a RHEL system up and running for 10 years (if nothing changes ... ).

Best Regards, Strahil Nikolov

On Thu, Jan 21, 2021 at 6:49 AM Markus Falb markus.falb@mafalb.at wrote:

On Thu, 2021-01-21 at 12:04 +0100, Ljubomir Ljubojevic wrote:

...

3. Users that register Individual Developer licenses should be warned

that they need to renew subscription every 365 days and that they should not miss the date(?). Someone commented that if subscription is not renewed before it expires they might be problems? Is that true, and what are the problems if it is true?

My experiences with the developer subscription in the past: you *had* to miss the date. There was no way to renew before the end date was reached. You had to wait for the subscription to expire until you could get a new one. This is another workflow as with paid subscriptions.

kind regards, markus

This sounds annoying, I'll ask around a bit and see what the intention is and if there are any changes planned.

-Mike

Am 28.01.21 um 22:37 schrieb Mike McGrath:

On Thu, Jan 21, 2021 at 8:06 AM Mike McGrath <mmcgrath@redhat.com mailto:mmcgrath@redhat.com> wrote:

On Thu, Jan 21, 2021 at 6:49 AM Markus Falb <markus.falb@mafalb.at
<mailto:markus.falb@mafalb.at>> wrote:

    On Thu, 2021-01-21 at 12:04 +0100, Ljubomir Ljubojevic wrote:

     >
     > 3. Users that register Individual Developer licenses should
    be warned
     > that they need to renew subscription every 365 days and that they
     > should
     > not miss the date(?). Someone commented that if subscription
    is not
     > renewed before it expires they might be problems? Is that
    true, and
     > what
     > are the problems if it is true?

    My experiences with the developer subscription in the past: you
    *had*
    to miss the date. There was no way to renew before the end date was
    reached. You had to wait for the subscription to expire until
    you could
    get a new one. This is another workflow as with paid subscriptions.

    kind regards, markus


This sounds annoying, I'll ask around a bit and see what the
intention is and if there are any changes planned.

             -Mike 

Getting back to this - it looks like this problem remains.  I haven't tried this but your registrations should remain.  Once you renew your content access is restored.  I don't have an account that is about to expire though so I can't verify this directly.

more details: https://developers.redhat.com/articles/renew-your-red-hat-developer-program-... https://developers.redhat.com/articles/renew-your-red-hat-developer-program-subscription

Thanks for looking into this.

From the above site:

"You may need to remove and then re-attach your license after accepting the new T&Cs for your system to recognize the renewed subscription."

This a bit cumbersome!?

-- Leon

On 1/22/21 12:44 AM, Nico Kadel-Garcia wrote:

On Thu, Jan 21, 2021 at 6:04 AM Ljubomir Ljubojevic centos@plnet.rs wrote:

...

3. Users that register Individual Developer licenses should be warned

that they need to renew subscription every 365 days and that they should not miss the date(?). Someone commented that if subscription is not renewed before it expires they might be problems? Is that true, and what

If you're setting up more than one such host, set up an internal reposync mirror "just in case".. It also profoundly improves the performance of "mock" for building RPM's internally.

My main job is "IT guy" for several small companies that needed convincing to pay for server-like PC's (average CPU, more expensive MB and more RAM, with 2-3 mirrored HDD's), so my customers are spread around in few towns/cities. I would have to host reposync on internet facing server with good internet and maintaining repo even with mrepo was a chore, I hosted CentOS 5 and 6 repos at https://rpms .plnet.rs (took it down few weeks ago) and even built ~70 packages for Desktop CentOS usage, so internal repo is not for my use case. I will probably just install TrueNAS and be done with it for Samba+VM use case I have the most. No registration, no renewing, no limit, excellent web config, free, ZFS...

On Fri, Jan 22, 2021 at 5:39 AM Peter Eckel via CentOS-devel < centos-devel@centos.org> wrote:

Hi Mike,

thanks for the information, this is at least partly good news.

Whet I currently can't figure out - maybe you have some information about it - is the situation with, e.g. Vagrant.

I rely a lot on Vagrant boxes for development and testing work, and up to now the situation with RHEL is that there are none, probably due to legal issues and because RHN registration doesn't mix well with instances created and deleted on-the-fly. The obvious solution is - or rather, was - CentOS, which so far fit my needs. CentOS Stream in all likelyhood will not fill that gap.

Are there plans for making it possible to create Vagrant boxes and similar items based on "FreeRHEL"?

I don't think we're going to ship vagrant images directly. I know several customers are using vagrant with RHEL and we've got some people using it internally. We've got some kbase and docs on the customer portal (which you do have access to with these developer program accounts).

https://access.redhat.com/documentation/en-us/red_hat_container_development_...

de-registering a box could be made part of the teardown process I would think. I've also heard stale boxes (IE: registered systems that are no longer check-ing in) have some way to do an automated cleanup after 2 days or so? I'm a little confused on how that process works though, its actually on my todo list to check out in February when the new simpler content access is in place.

-Mike

Cheers,

Peter.

On Fri, Jan 22, 2021 at 8:32 AM Leon Fauster via CentOS-devel centos-devel@centos.org wrote:

Am 22.01.21 um 14:18 schrieb Mike McGrath:

...

On Fri, Jan 22, 2021 at 5:39 AM Peter Eckel via CentOS-devel <centos-devel@centos.org mailto:centos-devel@centos.org> wrote:

Hi Mike,

thanks for the information, this is at least partly good news.

Whet I currently can't figure out - maybe you have some information
about it - is the situation with, e.g. Vagrant.

I rely a lot on Vagrant boxes for development and testing work, and
up to now the situation with RHEL is that there are none, probably
due to legal issues and because RHN registration doesn't mix well
with instances created and deleted on-the-fly. The obvious solution
is - or rather, was - CentOS, which so far fit my needs. CentOS
Stream in all likelyhood will not fill that gap.

Are there plans for making it possible to create Vagrant boxes and
similar items based on "FreeRHEL"?

I don't think we're going to ship vagrant images directly. I know several customers are using vagrant with RHEL and we've got some people using it internally. We've got some kbase and docs on the customer portal (which you do have access to with these developer program accounts).

https://access.redhat.com/documentation/en-us/red_hat_container_development_... https://access.redhat.com/documentation/en-us/red_hat_container_development_kit/2.2/html/getting_started_guide/introducing_red_hat_container_development_kit

de-registering a box could be made part of the teardown process I would think. I've also heard stale boxes (IE: registered systems that are no longer check-ing in) have some way to do an automated cleanup after 2 days or so? I'm a little confused on how that process works though, its actually on my todo list to check out in February when the new simpler content access is in place.

Honestly not so much experience with mock but what about mock build environments. While mock bootstraps the context to build rpms quite often, there is the need to access the repos. Does mock support "login" into such "RH accounts" and logout (deregister)?

CentOS with there mirrors was quite easy in this case.

It does not, unfortunately. You need to have subscription-manager configured on your host to be able to use RHEL content with Mock (which is a bit of a hassle in its own right...).

Am 22.01.21 um 14:53 schrieb Neal Gompa:

On Fri, Jan 22, 2021 at 8:32 AM Leon Fauster via CentOS-devel centos-devel@centos.org wrote:

...

Am 22.01.21 um 14:18 schrieb Mike McGrath:

...

On Fri, Jan 22, 2021 at 5:39 AM Peter Eckel via CentOS-devel <centos-devel@centos.org mailto:centos-devel@centos.org> wrote:

 Hi Mike,

 thanks for the information, this is at least partly good news.

 Whet I currently can't figure out - maybe you have some information
 about it - is the situation with, e.g. Vagrant.

 I rely a lot on Vagrant boxes for development and testing work, and
 up to now the situation with RHEL is that there are none, probably
 due to legal issues and because RHN registration doesn't mix well
 with instances created and deleted on-the-fly. The obvious solution
 is - or rather, was - CentOS, which so far fit my needs. CentOS
 Stream in all likelyhood will not fill that gap.

 Are there plans for making it possible to create Vagrant boxes and
 similar items based on "FreeRHEL"?

I don't think we're going to ship vagrant images directly. I know several customers are using vagrant with RHEL and we've got some people using it internally. We've got some kbase and docs on the customer portal (which you do have access to with these developer program accounts).

https://access.redhat.com/documentation/en-us/red_hat_container_development_... https://access.redhat.com/documentation/en-us/red_hat_container_development_kit/2.2/html/getting_started_guide/introducing_red_hat_container_development_kit

de-registering a box could be made part of the teardown process I would think. I've also heard stale boxes (IE: registered systems that are no longer check-ing in) have some way to do an automated cleanup after 2 days or so? I'm a little confused on how that process works though, its actually on my todo list to check out in February when the new simpler content access is in place.

Honestly not so much experience with mock but what about mock build environments. While mock bootstraps the context to build rpms quite often, there is the need to access the repos. Does mock support "login" into such "RH accounts" and logout (deregister)?

CentOS with there mirrors was quite easy in this case.

It does not, unfortunately. You need to have subscription-manager configured on your host to be able to use RHEL content with Mock (which is a bit of a hassle in its own right...).

Thanks, I was afraid reading this. So free RHEL make it more worse.

-- Leon

On Fri, Jan 22, 2021 at 1:54 PM redbaronbrowser via CentOS-devel centos-devel@centos.org wrote:

On Friday, January 22, 2021 12:13 PM, Leon Fauster via CentOS-devel centos-devel@centos.org wrote:

...

Am 22.01.21 um 14:53 schrieb Neal Gompa:

...

On Fri, Jan 22, 2021 at 8:32 AM Leon Fauster via CentOS-devel centos-devel@centos.org wrote:

...

Am 22.01.21 um 14:18 schrieb Mike McGrath:

...

On Fri, Jan 22, 2021 at 5:39 AM Peter Eckel via CentOS-devel <centos-devel@centos.org mailto:centos-devel@centos.org> wrote:

 Hi Mike,

 thanks for the information, this is at least partly good news.

 Whet I currently can't figure out - maybe you have some information
 about it - is the situation with, e.g. Vagrant.

 I rely a lot on Vagrant boxes for development and testing work, and
 up to now the situation with RHEL is that there are none, probably
 due to legal issues and because RHN registration doesn't mix well
 with instances created and deleted on-the-fly. The obvious solution
 is - or rather, was - CentOS, which so far fit my needs. CentOS
 Stream in all likelyhood will not fill that gap.

 Are there plans for making it possible to create Vagrant boxes and
 similar items based on "FreeRHEL"?

I don't think we're going to ship vagrant images directly. I know several customers are using vagrant with RHEL and we've got some people using it internally. We've got some kbase and docs on the customer portal (which you do have access to with these developer program accounts). https://access.redhat.com/documentation/en-us/red_hat_container_development_... https://access.redhat.com/documentation/en-us/red_hat_container_development_... de-registering a box could be made part of the teardown process I would think. I've also heard stale boxes (IE: registered systems that are no longer check-ing in) have some way to do an automated cleanup after 2 days or so? I'm a little confused on how that process works though, its actually on my todo list to check out in February when the new simpler content access is in place.

Honestly not so much experience with mock but what about mock build environments. While mock bootstraps the context to build rpms quite often, there is the need to access the repos. Does mock support "login" into such "RH accounts" and logout (deregister)? CentOS with there mirrors was quite easy in this case.

It does not, unfortunately. You need to have subscription-manager configured on your host to be able to use RHEL content with Mock (which is a bit of a hassle in its own right...).

Thanks, I was afraid reading this. So free RHEL make it more worse.

They are also setting a termination date for the official centos8 docker hub image with no replacement being provided by RHEL.

There is no official centosstream on docker hub and I question how much a streamlatest image would ever be used.

I'd rather have centos:8 replaced with CentOS Stream 8 content rather than just abandoned.

W dniu 22.01.2021 o 19:59, Josh Boyer pisze:

On Fri, Jan 22, 2021 at 1:54 PM redbaronbrowser via CentOS-devel

...

They are also setting a termination date for the official centos8 docker hub image with no replacement being provided by RHEL.

The official RHEL UBI images can be found in the Red Hat Container Catalog and do not require registration or entitlement to pull or use, and are expressly created to allow full redistribution.

I am one of developer in OpenStack Kolla where we use(d) centos:8 as a base for our OpenStack containers. With no centos:8-stream images it looks like we will need to move to RHEL UBI8 one instead.

And then remove subscription-manager from it, add all CentOS Stream, CentOS SIGs repos.

Which probably will not be far from using centos:8 and moving it to use Stream. And this is even easier as image already has needed repositories.

...

There is no official centosstream on docker hub and I question how much a streamlatest image would ever be used.

Brian has a solution for this coming.

Waiting for it too.

On 22/01/2021 18:13, Leon Fauster via CentOS-devel wrote:

Am 22.01.21 um 14:53 schrieb Neal Gompa:

...

On Fri, Jan 22, 2021 at 8:32 AM Leon Fauster via CentOS-devel centos-devel@centos.org wrote:

...

Am 22.01.21 um 14:18 schrieb Mike McGrath:

...

On Fri, Jan 22, 2021 at 5:39 AM Peter Eckel via CentOS-devel <centos-devel@centos.org mailto:centos-devel@centos.org> wrote:

Hi Mike,

thanks for the information, this is at least partly good news.

Whet I currently can't figure out - maybe you have some information      about it - is the situation with, e.g. Vagrant.

I rely a lot on Vagrant boxes for development and testing work, and      up to now the situation with RHEL is that there are none, probably      due to legal issues and because RHN registration doesn't mix well      with instances created and deleted on-the-fly. The obvious solution      is - or rather, was - CentOS, which so far fit my needs. CentOS      Stream in all likelyhood will not fill that gap.

Are there plans for making it possible to create Vagrant boxes and      similar items based on "FreeRHEL"?

I don't think we're going to ship vagrant images directly.  I know several customers are using vagrant with RHEL and we've got some people using it internally.  We've got some kbase and docs on the customer portal (which you do have access to with these developer program accounts).

https://access.redhat.com/documentation/en-us/red_hat_container_development_...

https://access.redhat.com/documentation/en-us/red_hat_container_development_kit/2.2/html/getting_started_guide/introducing_red_hat_container_development_kit

de-registering a box could be made part of the teardown process I would think.  I've also heard stale boxes (IE: registered systems that are no longer check-ing in) have some way to do an automated cleanup after 2 days or so?  I'm a little confused on how that process works though, its actually on my todo list to check out in February when the new simpler content access is in place.

Honestly not so much experience with mock but what about mock build environments. While mock bootstraps the context to build rpms quite often, there is the need to access the repos. Does mock support "login" into such "RH accounts" and logout (deregister)?

CentOS with there mirrors was quite easy in this case.

It does not, unfortunately. You need to have subscription-manager configured on your host to be able to use RHEL content with Mock (which is a bit of a hassle in its own right...).

Thanks, I was afraid reading this. So free RHEL make it more worse.

If you are building a lot of stuff in mock, you will almost certainly want to set up your own internal mirror of RHEL content for mock to build against.

On 22/01/2021 20:45, Mike McGrath wrote:

On Fri, Jan 22, 2021 at 2:16 PM Phil Perry <pperry@elrepo.org mailto:pperry@elrepo.org> wrote:

On 22/01/2021 18:13, Leon Fauster via CentOS-devel wrote:
 > Am 22.01.21 um 14:53 schrieb Neal Gompa:
 >> On Fri, Jan 22, 2021 at 8:32 AM Leon Fauster via CentOS-devel
 >> <centos-devel@centos.org <mailto:centos-devel@centos.org>> wrote:
 >>>
 >>> Am 22.01.21 um 14:18 schrieb Mike McGrath:
 >>>>
 >>>>
 >>>> On Fri, Jan 22, 2021 at 5:39 AM Peter Eckel via CentOS-devel
 >>>> <centos-devel@centos.org <mailto:centos-devel@centos.org>
<mailto:centos-devel@centos.org <mailto:centos-devel@centos.org>>>
wrote:
 >>>>
 >>>>      Hi Mike,
 >>>>
 >>>>      thanks for the information, this is at least partly good
news.
 >>>>
 >>>>      Whet I currently can't figure out - maybe you have some
 >>>> information
 >>>>      about it - is the situation with, e.g. Vagrant.
 >>>>
 >>>>      I rely a lot on Vagrant boxes for development and testing
work,
 >>>> and
 >>>>      up to now the situation with RHEL is that there are none,
probably
 >>>>      due to legal issues and because RHN registration doesn't
mix well
 >>>>      with instances created and deleted on-the-fly. The obvious
 >>>> solution
 >>>>      is - or rather, was - CentOS, which so far fit my needs.
CentOS
 >>>>      Stream in all likelyhood will not fill that gap.
 >>>>
 >>>>      Are there plans for making it possible to create Vagrant
boxes and
 >>>>      similar items based on "FreeRHEL"?
 >>>>
 >>>>
 >>>> I don't think we're going to ship vagrant images directly.  I know
 >>>> several customers are using vagrant with RHEL and we've got
some people
 >>>> using it internally.  We've got some kbase and docs on the
customer
 >>>> portal (which you do have access to with these developer program
 >>>> accounts).
 >>>>
 >>>>
https://access.redhat.com/documentation/en-us/red_hat_container_development_kit/2.2/html/getting_started_guide/introducing_red_hat_container_development_kit
<https://access.redhat.com/documentation/en-us/red_hat_container_development_kit/2.2/html/getting_started_guide/introducing_red_hat_container_development_kit>

 >>>>
 >>>>
<https://access.redhat.com/documentation/en-us/red_hat_container_development_kit/2.2/html/getting_started_guide/introducing_red_hat_container_development_kit
<https://access.redhat.com/documentation/en-us/red_hat_container_development_kit/2.2/html/getting_started_guide/introducing_red_hat_container_development_kit>>

 >>>>
 >>>>
 >>>> de-registering a box could be made part of the teardown
process I would
 >>>> think.  I've also heard stale boxes (IE: registered systems
that are no
 >>>> longer check-ing in) have some way to do an automated cleanup
after 2
 >>>> days or so?  I'm a little confused on how that process works
though,
 >>>> its
 >>>> actually on my todo list to check out in February when the new
simpler
 >>>> content access is in place.
 >>>>
 >>>
 >>> Honestly not so much experience with mock but what about mock build
 >>> environments. While mock bootstraps the context to build rpms quite
 >>> often, there is the need to access the repos. Does mock support
"login"
 >>> into such "RH accounts" and logout (deregister)?
 >>>
 >>> CentOS with there mirrors was quite easy in this case.
 >>>
 >>
 >> It does not, unfortunately. You need to have subscription-manager
 >> configured on your host to be able to use RHEL content with Mock
 >> (which is a bit of a hassle in its own right...).
 >>
 >
 > Thanks, I was afraid reading this. So free RHEL make it more worse.
 >

If you are building a lot of stuff in mock, you will almost certainly
want to set up your own internal mirror of RHEL content for mock to
build against.

I asked around about this a bit.  I think you're allowed to download whatever content you are entitled to and keep an internal mirror as long as it is protected somehow (IE: don't let unentitled people get access to it as I think you'd run afoul of redistribution problems).   In other words, if you're downloading a repo and using it for your purposes, I don't think that violates our agreement.  It turns out this is the thing that makes satellite possible.

-Mike

Yes, absolutely, and to clarify, that's exactly what I meant by "internal mirror" just for mock to build against (populate the mock buildroot).

On Friday, January 22, 2021 4:38 PM, redbaronbrowser via CentOS-devel centos-devel@centos.org wrote:

On Friday, January 22, 2021 2:45 PM, Mike McGrath mmcgrath@redhat.com wrote:

...

On Fri, Jan 22, 2021 at 2:16 PM Phil Perry pperry@elrepo.org wrote:

...

On 22/01/2021 18:13, Leon Fauster via CentOS-devel wrote:

...

Am 22.01.21 um 14:53 schrieb Neal Gompa:

...

On Fri, Jan 22, 2021 at 8:32 AM Leon Fauster via CentOS-devel centos-devel@centos.org wrote:

...

Am 22.01.21 um 14:18 schrieb Mike McGrath: > > > On Fri, Jan 22, 2021 at 5:39 AM Peter Eckel via CentOS-devel > <centos-devel@centos.org mailto:centos-devel@centos.org> wrote: > > Hi Mike, > > thanks for the information, this is at least partly good news. > > Whet I currently can't figure out - maybe you have some > information > about it - is the situation with, e.g. Vagrant. > > I rely a lot on Vagrant boxes for development and testing work, > and > up to now the situation with RHEL is that there are none, probably > due to legal issues and because RHN registration doesn't mix well > with instances created and deleted on-the-fly. The obvious > solution > is - or rather, was - CentOS, which so far fit my needs. CentOS > Stream in all likelyhood will not fill that gap. > > Are there plans for making it possible to create Vagrant boxes and > similar items based on "FreeRHEL"? > > > I don't think we're going to ship vagrant images directly. I know > several customers are using vagrant with RHEL and we've got some people > using it internally. We've got some kbase and docs on the customer > portal (which you do have access to with these developer program > accounts). > > https://access.redhat.com/documentation/en-us/red_hat_container_development_... > > https://access.redhat.com/documentation/en-us/red_hat_container_development_kit/2.2/html/getting_started_guide/introducing_red_hat_container_development_kit > > > de-registering a box could be made part of the teardown process I would > think. I've also heard stale boxes (IE: registered systems that are no > longer check-ing in) have some way to do an automated cleanup after 2 > days or so? I'm a little confused on how that process works though, > its > actually on my todo list to check out in February when the new simpler > content access is in place. >

Honestly not so much experience with mock but what about mock build environments. While mock bootstraps the context to build rpms quite often, there is the need to access the repos. Does mock support "login" into such "RH accounts" and logout (deregister)?

CentOS with there mirrors was quite easy in this case.

It does not, unfortunately. You need to have subscription-manager configured on your host to be able to use RHEL content with Mock (which is a bit of a hassle in its own right...).

Thanks, I was afraid reading this. So free RHEL make it more worse.

If you are building a lot of stuff in mock, you will almost certainly want to set up your own internal mirror of RHEL content for mock to build against.

I asked around about this a bit. I think you're allowed to download whatever content you are entitled to and keep an internal mirror as long as it is protected somehow (IE: don't let unentitled people get access to it as I think you'd run afoul of redistribution problems). In other words, if you're downloading a repo and using it for your purposes, I don't think that violates our agreement. It turns out this is the thing that makes satellite possible.

-Mike

Thank you for looking into this.

Just to clarify, you mean we should avoid redistributing RPMs not covered by the GPL/LGPL, right?

For RPMs that are covered by the GPL and LGPL, it should not violate any agreement to redistribute those to anyone? As long as the form of redistribution doesn't claim the receiver is entitled to Red Hat support, anyone is entitled to the GPL/LGPL covered RPMs?

Mike McGrath, I find it troubling a VP level member of Red Hat, Inc. might be implying there exist people that are unentitled to GPL/LGPL covered works. If you don't mind, I would like to see if I can get a member of the Free Software Foundation involved.

On Saturday, January 23, 2021 8:25 PM, Lamar Owen lowen@pari.edu wrote:

On 1/23/21 6:55 AM, redbaronbrowser via CentOS-devel wrote:

...

On Friday, January 22, 2021 4:38 PM, redbaronbrowser via CentOS-devel centos-devel@centos.org wrote:

...

Just to clarify, you mean we should avoid redistributing RPMs not covered by the GPL/LGPL, right? For RPMs that are covered by the GPL and LGPL, it should not violate any agreement to redistribute those to anyone?  As long as the form of redistribution doesn't claim the receiver is entitled to Red Hat support, anyone is entitled to the GPL/LGPL covered RPMs?

Mike McGrath, I find it troubling a VP level member of Red Hat, Inc. might be implying there exist people that are unentitled to GPL/LGPL covered works.  If you don't mind, I would like to see if I can get a member of the Free Software Foundation involved.

So, the way I read the subscription agreement and interpret it for myself and myself alone (that is, this is not legal advice and I am not a lawyer), redistributing material (any material, not just RPMs or SRPMs but things like subscriptin-only bugzilla content, kernel patchset reasons, etc) from my active Red Hat Enterprise Linux subscription is grounds for termination by Red Hat of my access to subscription content.  They can't take away what I already have, but they can take away my ability to access future subscription content.

In a nutshell: my interpretation for myself and myself alone is that I am free to redistribute the GPL-covered packages.  Red Hat is also free to refuse to continue to do business with me. I thus make the choice to not redistribute.

GPL does NOT require distribution to the public software that is distributed for a fee ( https://www.gnu.org/licenses/gpl-faq.en.html#DoesTheGPLRequireAvailabilityTo... ).  If you do actually get a FSF staff member involved, they will probably tell you the same thing.

Quoting Bradley Kuhn in a 2011 posting ( http://ebb.org/bkuhn/blog/2011/03/05/open-core-slur.html ): " I do have strong, negative opinions about the RHEL business model; I have long called it the "if you like copyleft, your money is no good here" business model. It's a GPL-compliant business model merely because the GPL is silent on whether or not you must keep someone as your customer. Red Hat tells RHEL customers that if they chose to engage in their rights under GPL, then their support contract will be canceled. I've often pointed out (although this may be the first time publicly on the Internet) that Red Hat found a bright line of GPL compliance, walked right up to it, and were the first to stake out a business model right on the line." (and the followup post at http://ebb.org/bkuhn/blog/2011/03/11/linux-red-hat-gpl.html is a good read)

I agree with you and didn't expect a FSF member to say Red Hat is doing anything *legally* wrong.

Put please re-read that FAQ answer again carefully:

"If I distribute GPLed software for a fee, am I required to also make it available to the public without a charge? (#DoesTheGPLRequireAvailabilityToPublic)"

"No. However, if someone pays your fee and gets a copy, the GPL gives them the freedom to release it to the public, with or without a fee. For example, someone could pay your fee, and then put her copy on a web site for the general public."

While it says Red Hat has no obligation to *directly* make GPL software publicly available, it indicates there should be the possibility of it being indirectly publicly available.

What Mike McGrath is indicating Red Hat puts a chilling effect on that indirect redistribution of GPL/LGPL works to the "unentitled."

So, my expectation is that the FSF member would try to explain why using the word "unentitled" goes against the *spirit* of the GPL/LGPL family of licenses. (And hopefully can phrase it better than I can).

Just to be clear, I am not asking for a loophole to be able to redistribute *ALL* of RHEL while retaining access to updates. If they want to say people need to be entitled to RHEL RPMs that are not covered by the GPL/LGPL, each person/organization needs to subscribe themselves, I will accept that.

But 2011 statement is extremely damning of Red Hat when he says "if you like copyleft, your money is no good here business model." The relief to this statement was CentOS was available the established alternative to avoiding the chilling effect of that business model.

If the move now is RHEL is giving more with it's offer than CentOS is taking away, then the core values of Copyleft should be retained as well.

I see it as damaging to Red Hat in the long run sending the message that GPL/LGPL rights respected by CentOS should be disregarded by users when agreeing to the "better" 16 RHEL licenses.

The attitude of Red Hat should not be that people will continue to contribute to free software projects regardless of how RH uses the term "unentitled."

During this transistion of CentOS users into RHEL users they should re-examine the commentary made back in 2011. Not further re-establish a disregard for the spirit of Copyleft through a chilling effect written into user agreements.

On Sun, Jan 24, 2021 at 11:50 AM Josh Boyer jwboyer@redhat.com wrote:

On Sun, Jan 24, 2021 at 12:28 PM redbaronbrowser via CentOS-devel centos-devel@centos.org wrote:

...

On Saturday, January 23, 2021 8:25 PM, Lamar Owen lowen@pari.edu

wrote:

...

...

On 1/23/21 6:55 AM, redbaronbrowser via CentOS-devel wrote:

...

On Friday, January 22, 2021 4:38 PM, redbaronbrowser via CentOS-devel centos-devel@centos.org wrote:

...

Just to clarify, you mean we should avoid redistributing RPMs not covered by the GPL/LGPL, right? For RPMs that are covered by the GPL and LGPL, it should not

violate

...

...

...

...

any agreement to redistribute those to anyone? As long as the form of redistribution doesn't claim the receiver is entitled to Red Hat support, anyone is entitled to the GPL/LGPL covered RPMs?

Mike McGrath, I find it troubling a VP level member of Red Hat, Inc. might be implying there exist people that are unentitled to GPL/LGPL covered works. If you don't mind, I would like to see if I can get a member of the Free Software Foundation involved.

So, the way I read the subscription agreement and interpret it for myself and myself alone (that is, this is not legal advice and I am not a lawyer), redistributing material (any material, not just RPMs or

SRPMs

...

...

but things like subscriptin-only bugzilla content, kernel patchset reasons, etc) from my active Red Hat Enterprise Linux subscription is grounds for termination by Red Hat of my access to subscription content. They can't take away what I already have, but they can take away my ability to access future subscription content.

In a nutshell: my interpretation for myself and myself alone is that I am free to redistribute the GPL-covered packages. Red Hat is also free to refuse to continue to do business with me. I thus make the choice to not redistribute.

GPL does NOT require distribution to the public software that is distributed for a fee (

https://www.gnu.org/licenses/gpl-faq.en.html#DoesTheGPLRequireAvailabilityTo...

...

...

). If you do actually get a FSF staff member involved, they will probably tell you the same thing.

Quoting Bradley Kuhn in a 2011 posting ( http://ebb.org/bkuhn/blog/2011/03/05/open-core-slur.html ): " I do

have

...

...

strong, negative opinions about the RHEL business model; I have long called it the "if you like copyleft, your money is no good here" business model. It's a GPL-compliant business model merely because the GPL is silent on whether or not you must keep someone as your customer. Red Hat tells RHEL customers that if they chose to engage in their rights under GPL, then their support contract will be canceled. I've often pointed out (although this may be the first time publicly on the Internet) that Red Hat found a bright line of GPL compliance, walked right up to it, and were the first to stake out a business model right on the line." (and the followup post at http://ebb.org/bkuhn/blog/2011/03/11/linux-red-hat-gpl.html is a good

read)

...

I agree with you and didn't expect a FSF member to say Red Hat is doing

anything *legally* wrong.

...

Put please re-read that FAQ answer again carefully:

"If I distribute GPLed software for a fee, am I required to also make it

available to the public without a charge? (#DoesTheGPLRequireAvailabilityToPublic)"

...

"No. However, if someone pays your fee and gets a copy, the GPL gives

them the freedom to release it to the public, with or without a fee. For example, someone could pay your fee, and then put her copy on a web site for the general public."

...

While it says Red Hat has no obligation to *directly* make GPL software

publicly available, it indicates there should be the possibility of it being indirectly publicly available.

...

What Mike McGrath is indicating Red Hat puts a chilling effect on that

indirect redistribution of GPL/LGPL works to the "unentitled."

...

So, my expectation is that the FSF member would try to explain why using

the word "unentitled" goes against the *spirit* of the GPL/LGPL family of licenses. (And hopefully can phrase it better than I can).

As a general reminder, the GPL and LGPL are source code licenses. The source code to the packages in Red Hat Enterprise Linux releases, GPL or otherwise, are released on git.centos.org, which requires no registration and no terms to accept. The recent announcements around CentOS Linux and CentOS Stream did not alter this approach.

Thanks, Josh. I do have to point out that I made no claims about the GPL, LGPL, or even source code in my original response. It was simply one human talking to another human on a mailing list to try and come to a common understanding of what Red Hat considers ok and not ok. Unfortunately, my words continue to be parsed or taken out of context by some of the more anonymous members of this mailing list who continue to act in bad faith. I'll refrain from commenting on our license and terms in the future.

For those that want to participate in the RHEL programs, you are all on your own to find whatever counsel you'd like to understand them.

-Mike

On Sunday, January 24, 2021 12:31 PM, Mike McGrath mmcgrath@redhat.com wrote:

On Sun, Jan 24, 2021 at 11:50 AM Josh Boyer jwboyer@redhat.com wrote:

...

On Sun, Jan 24, 2021 at 12:28 PM redbaronbrowser via CentOS-devel centos-devel@centos.org wrote:

...

On Saturday, January 23, 2021 8:25 PM, Lamar Owen lowen@pari.edu wrote:

...

On 1/23/21 6:55 AM, redbaronbrowser via CentOS-devel wrote:

...

On Friday, January 22, 2021 4:38 PM, redbaronbrowser via CentOS-devel centos-devel@centos.org wrote:

...

Just to clarify, you mean we should avoid redistributing RPMs not covered by the GPL/LGPL, right? For RPMs that are covered by the GPL and LGPL, it should not violate any agreement to redistribute those to anyone? As long as the form of redistribution doesn't claim the receiver is entitled to Red Hat support, anyone is entitled to the GPL/LGPL covered RPMs?

Mike McGrath, I find it troubling a VP level member of Red Hat, Inc. might be implying there exist people that are unentitled to GPL/LGPL covered works. If you don't mind, I would like to see if I can get a member of the Free Software Foundation involved.

So, the way I read the subscription agreement and interpret it for myself and myself alone (that is, this is not legal advice and I am not a lawyer), redistributing material (any material, not just RPMs or SRPMs but things like subscriptin-only bugzilla content, kernel patchset reasons, etc) from my active Red Hat Enterprise Linux subscription is grounds for termination by Red Hat of my access to subscription content. They can't take away what I already have, but they can take away my ability to access future subscription content.

In a nutshell: my interpretation for myself and myself alone is that I am free to redistribute the GPL-covered packages. Red Hat is also free to refuse to continue to do business with me. I thus make the choice to not redistribute.

GPL does NOT require distribution to the public software that is distributed for a fee ( https://www.gnu.org/licenses/gpl-faq.en.html#DoesTheGPLRequireAvailabilityTo... ). If you do actually get a FSF staff member involved, they will probably tell you the same thing.

Quoting Bradley Kuhn in a 2011 posting ( http://ebb.org/bkuhn/blog/2011/03/05/open-core-slur.html ): " I do have strong, negative opinions about the RHEL business model; I have long called it the "if you like copyleft, your money is no good here" business model. It's a GPL-compliant business model merely because the GPL is silent on whether or not you must keep someone as your customer. Red Hat tells RHEL customers that if they chose to engage in their rights under GPL, then their support contract will be canceled. I've often pointed out (although this may be the first time publicly on the Internet) that Red Hat found a bright line of GPL compliance, walked right up to it, and were the first to stake out a business model right on the line." (and the followup post at http://ebb.org/bkuhn/blog/2011/03/11/linux-red-hat-gpl.html is a good read)

I agree with you and didn't expect a FSF member to say Red Hat is doing anything *legally* wrong.

Put please re-read that FAQ answer again carefully:

"If I distribute GPLed software for a fee, am I required to also make it available to the public without a charge? (#DoesTheGPLRequireAvailabilityToPublic)"

"No. However, if someone pays your fee and gets a copy, the GPL gives them the freedom to release it to the public, with or without a fee. For example, someone could pay your fee, and then put her copy on a web site for the general public."

While it says Red Hat has no obligation to *directly* make GPL software publicly available, it indicates there should be the possibility of it being indirectly publicly available.

What Mike McGrath is indicating Red Hat puts a chilling effect on that indirect redistribution of GPL/LGPL works to the "unentitled."

So, my expectation is that the FSF member would try to explain why using the word "unentitled" goes against the *spirit* of the GPL/LGPL family of licenses. (And hopefully can phrase it better than I can).

As a general reminder, the GPL and LGPL are source code licenses. The source code to the packages in Red Hat Enterprise Linux releases, GPL or otherwise, are released on git.centos.org, which requires no registration and no terms to accept. The recent announcements around CentOS Linux and CentOS Stream did not alter this approach.

Thanks, Josh. I do have to point out that I made no claims about the GPL, LGPL, or even source code in my original response. It was simply one human talking to another human on a mailing list to try and come to a common understanding of what Red Hat considers ok and not ok. Unfortunately, my words continue to be parsed or taken out of context by some of the more anonymous members of this mailing list who continue to act in bad faith. I'll refrain from commenting on our license and terms in the future.

For those that want to participate in the RHEL programs, you are all on your own to find whatever counsel you'd like to understand them.

-Mike

Ok, I seeked out counsel on these issues. Here is the findings I got from it. Anyone can make corrections if the counsel I got was invalid. I broke it up into Q&A format to make it easier to read.

Q1) Can I have a mirror of RHEL for things like mock or network based installs?

A1) Yes, but the EULA requires protecting without fail the Red Hat trademark that is included in all of the RPMs that make up RHEL

Q2) Can other third-parties (such as a consultant or customer) access the mirror if they also have valid RHEL licenses?

A2) No, the EULA restricts all redistribution of the trademark. Only exception requires a separate written agreement with Red Hat.

Q3) What if the the redistribution is accidental such as a misconfiguration or data breach?

A3) EULA provides no such exception, it still is the customer's responsiblity

Q4) What if a data breach is because of a security issue with the RHEL software itself?

A4) EULA provides no such exception

Q5) Isn't only the redhat-logos package contain trademarks?

A5) No, all RHEL packages specify Red Hat as the vendor in the RPM meta-data

Q6) Can I replace that meta-data and then redistribute the modified package?

A6) That would break the GPG digital signature. But there are also other instances of the trademark contained inside the RPM data which is a compress cpio archive.

Q7) If I am willing to use my own GPG signing key, change the RPM meta-data, decompress and unpack the cpio and search/replace the trademark and then repack it back into a RPM, then can I redistribute it?

A7) No, there are cases in which the trademark must remain such as copyright notices. It may no longer be a violation of the EULA to redistribute but it would be in violation of other licenses indicating the statement of copyright can not be modified.

Q8) So, if I do everything in Q7 but carefully only replace specific instances of the trademark, then can it redistributed

A8) Possibly. I couldn't find any case in which anyone has tried. If a de-branding contains any mistake then it would still be in violating of the RHEL EULA. The established practice is the rebuild with the CentOS provided debranding patches.

Q9) If there is a EULA violation by mistake, what is the worst that could happen?

A9) Red Hat can ban the user/customer forever from being a RHEL subscriber. They can also seek legal damages for the trademark violation.

Q10) Why is Red Hat doing this?

A10) I have no proof they are. This is a pessimistic worst case senario read of the EULA. It would also be hard to prove they never have banned someone from RHEL subscriptions for any of the above issues. Unlike a trademark lawsuit, a banning from business services does not involve any court record.

Q11) What is a safe way to have a local package mirror for mock or network installs?

A11) Stream does not involve the RHEL End User License Agreement at all. Using it instead of RHEL is the legally safest way to accomplish these goals.

Hopefully this is helpful for detemining when/how to use RHEL and when to use Stream. I welcome any corrections.

On Sun, Jan 24, 2021 at 1:41 PM redbaronbrowser via CentOS-devel centos-devel@centos.org wrote:

On Sunday, January 24, 2021 11:50 AM, Josh Boyer jwboyer@redhat.com wrote:

...

As a general reminder, the GPL and LGPL are source code licenses. The source code to the packages in Red Hat Enterprise Linux releases, GPL or otherwise, are released on git.centos.org, which requires no registration and no terms to accept. The recent announcements around CentOS Linux and CentOS Stream did not alter this approach.

But Josh Boyer has taken the threat from Red Hat to the next level.

I made no threat. I pointed out that we provide sources to packages, regardless of whether they were GPL or not and any recent announcements haven't changed that.

josh

On Sun, Jan 24, 2021 at 3:04 PM Josh Boyer jwboyer@redhat.com wrote:

On Sun, Jan 24, 2021 at 1:41 PM redbaronbrowser via CentOS-devel centos-devel@centos.org wrote:

...

On Sunday, January 24, 2021 11:50 AM, Josh Boyer jwboyer@redhat.com wrote:

...

As a general reminder, the GPL and LGPL are source code licenses. The source code to the packages in Red Hat Enterprise Linux releases, GPL or otherwise, are released on git.centos.org, which requires no registration and no terms to accept. The recent announcements around CentOS Linux and CentOS Stream did not alter this approach.

But Josh Boyer has taken the threat from Red Hat to the next level.

I made no threat. I pointed out that we provide sources to packages, regardless of whether they were GPL or not and any recent announcements haven't changed that.

For "we provide source to packages", this was my understanding:

1) RHEL packages are available in SRPM form from a public FTP site. For GPL software, this nicely aligns with the spirit of the GPL. For non-GPL software, this may be an additional nice gesture to apply GPL thinking to all the source code whether or not it is GPL. It may also keep things simple, since so much of it is GPL. For the software published to the public on the public FTP site, there should be no restrictions that apply, as there is no agreement between the user and Red Hat.

2) RHEL EUS packages are available in SRPM form only to subscribers with EUS subscriptions. For GPL software, such a person should be able to legally download the SRPM, rebuild it, and redistribute the newly built binary as a right provided by the GPL. However, the Red Hat contract states some restrictions around access to non-public content which may contradict the GPL, in which case this is a place where Red Hat could void the contract despite the GPL granting full rights to the user. For non-GPL software, this is much more grey zone. Personally, I've avoiding looking at or using the SRPM content from RHEL EUS, as it seems like a landmine. Instead, I prefer to use an upstream release from Fedora or EPEL, or backport a later RHEL package version, than rely on RHEL EUS. For those not aware - RHEL EUS is generally the minor release date plus two years, and represents the "branch" that people were talking about when they say that RHEL differs from CentOS Linux. Essentially, RHEL has EUS streams, while CentOS Linux does not have EUS streams.

3) RHEL ELS packages are available in SRPM form only to subscribers with ELS subscriptions. This is the same as above, but could extend beyond the 10 years support life of an RHEL release. I don't think I've ever had an ELS subscription so I can't speak much more about this.

When it comes to CentOS Linux, CentOS Linux aligned with 1). It never aligned with 2) or 3).

With CentOS Stream, I believe 1) will also disappear. The reference to git.centos.org seems to be glossing over that git.centos.org does not contain the RHEL / RHEL EUS / RHEL ELS package sources, but only includes the *CentOS* sources. And if CentOS Stream continues, then CentOS Stream sources will receive updates, but if CentOS Linux does not continue, then it seems doubtful that CentOS Linux sources will receive updates. Meaning, that by 2022, I expect the RHEL sources to no longer be available via git.centos.org, and the idea that "announcements haven't change that" is likely to be false. I think announcements have definitely changed this.

But, let's come back to this in a year and see who is right.

On 1/25/21 4:01 AM, redbaronbrowser via CentOS-devel wrote:

Not that anything I said matters, it seems all of my feedback is tagged "bad faith" now so I guess I am the only one frustrated about things.

For me, it does matter what you write, but since I do not have vested interest in Red Hat or CentOS any more, I am not passionate about it any more and could care less what they do. I have already managed some Debian servers and I could find my way around, and once they are set up I have very little to do beside update. And I can say that majority of people commenting on Facebook is waiting Rocky/Lenix but are prepared to go elswere (Oracle, Debian, Ubuntu, Mint...).

On Mon, Jan 25, 2021 at 1:46 AM James Cassell fedoraproject@cyberpear.com wrote:

...

When it comes to CentOS Linux, CentOS Linux aligned with 1). It never aligned with 2) or 3).

With CentOS Stream, I believe 1) will also disappear. The reference to git.centos.org seems to be glossing over that git.centos.org does not contain the RHEL / RHEL EUS / RHEL ELS package sources, but only includes the *CentOS* sources. And if CentOS Stream continues, then CentOS Stream sources will receive updates, but if CentOS Linux does not continue, then it seems doubtful that CentOS Linux sources will receive updates. Meaning, that by 2022, I expect the RHEL sources to no longer be available via git.centos.org, and the idea that "announcements haven't change that" is likely to be false. I think announcements have definitely changed this.

But, let's come back to this in a year and see who is right.

I agree with your assessment and fear Rocky Linux et al. will have to resort to using "bootleg" SRPMs if/when RH stops publishing the RHEL branched code to CentOS git. (Their statements to date indicate they'll continue publishing these, but I don't count on it.)

I do not believe that they'll stop. Just because they'll stop building it doesn't mean that they can't continue to use it as a mechanism for delivering the sources in a way that's straightforward to understand and build.

-- 真実はいつも一つ！/ Always, there's only one truth!

On Mon, Jan 25, 2021 at 4:54 AM Jake Shipton listmail@crazylinuxnerd.net wrote:

On Mon, 2021-01-25 at 02:38 -0500, Neal Gompa wrote:

...

I do not believe that they'll stop. Just because they'll stop building it doesn't mean that they can't continue to use it as a mechanism for delivering the sources in a way that's straightforward to understand and build.

Indeed. Let's not forget we're talking about a git repository here, and how git works.

Yes, let's not forget how it works...

The way the git.centos.org is currently laid out is basically 1 package is 1 repository.

Within that repository are separate branches, these branches are currently set out as follows (for CentOS 8):

c8 c8-beta c8s

There is no "RHEL" branches above. The "c8" is for "CentOS Linux". It is not a view of the RHEL internal Git repositories. It is a process which seems mostly manually, whereby content is copied and de-branded from points in time in the RHEL internal Git repositories, to the "c8" branch. The result is then made available for "CentOS 8 Linux" users and build processes to consume.

No CentOS 8 Linux means no need to maintain this "c8" branch. We already see cases where one or the other branch isn't maintained and somebody asks "is it going to happen?" and then somebody does it.

You'll notice immediately c8s is clearly CentOS Stream, c8 is CentOS as we use it daily, and c8-beta was setup during the beta.

So - Redhat could easily just continue exactly as they are now.

Except, Red Hat has clearly stated that they will *not* do exactly as they are now doing. CentOS 8 is dead. Long live CentOS 8 Stream.

CentOS Stream updates will be pushed to the c8s branch, RHEL updates will continue to go to c8 branch as it does now, and perhaps c8-beta branch will just get dropped (no longer necessary).

This is a presumption, that I think will unfortunately prove false.

So in my opinion, they have already prepared for this with regards to git.centos.org, it will just continue as I described above.

They prepared it for CentOS Linux. CentOS Linux is dead. It will most likely not continue.

Of course, if Red Hat would like to clarify here and tell me that I am absolutely wrong, and the "c8" branch will definitely be maintained into 2022, I will apologize for my doubt. Feel free to force me to apologize. I will be happy to apologize if I am wrong. Just let me know.

On 1/25/21 7:29 PM, Mike McGrath wrote:

A fair question.  I've been in a few discussions related to this internally and there are no plans to make changes for RHEL8 (IE: us sending our debranded(ish) code to the centos git instance).  I could imagine scenarios where that gets moved to gitlab.  But generally how we push will remain the duration of RHEL8 - we just won't be building it into CentOS.  Don't take this to mean it's a guarantee or that Red Hat promised or whatever.  I'm just saying that at the moment we've discussed it, no one is currently advocating for us to stop releasing RHEL8 code in the way we do, and so we have no plans on changes there at this time.

Excuse me, perhaps I'm reading too much into your words, just for my own understanding: does this mean it's not clear if Red Hat will continue forever to release the sources for RHEL publicly, and perhaps only provide them to their customers, at some point in the future? I'm thinking more from perspective of rebuilds like Alma Linux or Oracle EL - they wouldn't have anything to rebuild by themselves anymore. With the zero-cost RHEL covering the use case of many small companies and hobbyists, I imagine this would be possible.

On Monday, January 25, 2021 1:56 PM, Mike McGrath mmcgrath@redhat.com wrote:

On Mon, Jan 25, 2021 at 1:03 PM Laurențiu Păncescu lpancescu@centosproject.org wrote:

...

On 1/25/21 7:29 PM, Mike McGrath wrote:

...

A fair question. I've been in a few discussions related to this internally and there are no plans to make changes for RHEL8 (IE: us sending our debranded(ish) code to the centos git instance). I could imagine scenarios where that gets moved to gitlab. But generally how we push will remain the duration of RHEL8 - we just won't be building it into CentOS. Don't take this to mean it's a guarantee or that Red Hat promised or whatever. I'm just saying that at the moment we've discussed it, no one is currently advocating for us to stop releasing RHEL8 code in the way we do, and so we have no plans on changes there at this time.

Excuse me, perhaps I'm reading too much into your words, just for my own understanding: does this mean it's not clear if Red Hat will continue forever to release the sources for RHEL publicly, and perhaps only provide them to their customers, at some point in the future? I'm thinking more from perspective of rebuilds like Alma Linux or Oracle EL

• they wouldn't have anything to rebuild by themselves anymore. With the

zero-cost RHEL covering the use case of many small companies and hobbyists, I imagine this would be possible.

This is an area where written text falls flat and a conversation would be better but here goes....

For RHEL9 and forward, I suspect we won't be doing a RHEL release, and then releasing that code as we do today because.....

... the code should already be available via CentOS Stream. To put it another way, the current plan of record is - If you ever find a RHEL binary, and cannot find the corresponding source code in the CentOS Stream gitlab instance, that means we've messed something up along the way because it was one of the explicit goals for CentOS Stream. It might be released in RHEL first with a bit of delay (we're talking hours or a day or two not weeks), like with a 0-day CVE. But generally, it should already be in CentOS Stream well before it's in RHEL.

I hope that's clearer. Worst case, the rebuilders you're talking about will have to get to know our gitlab layouts, but all the code will be there.

For emphasis: There are no plans to stop making RHEL code available to the public at this time. It will just take a different route to get there than it has under RHEL8/CentOS8 and before.

-Mike

That answer sounds fairly complete on that point.

If you feel a conversation would work better for filling in the remaining gaps, would you and/or Bex or Rich ever record a Jitsi Q/A session with select members of the centos-devel mailing list that you feel are acting in good faith? Or is that what the CentOS Dojo is for?

The things I haven't found answers to (if that even matters) is:

When and how can the community expected to be able to start contributing?

Is gitlab just being used as a respository?

Will the project management tools of gitlab be used to highlight the tasks RHEL is focusing on and estimated progress?

Can we file issues through gitlab instead of bugzilla?

Will code for performing the specific CI/CD tests be in gitlab?

Will the communty be able to submit pull requests for additional CI/CD tests or improvements to existing ones?

On Tuesday, January 26, 2021 7:29 AM, Rich Bowen rbowen@redhat.com wrote:

On 1/25/21 4:58 PM, redbaronbrowser via CentOS-devel wrote:

...

If you feel a conversation would work better for filling in the remaining gaps, would you and/or Bex or Rich ever record a Jitsi Q/A session with select members of the centos-devel mailing list that you feel are acting in good faith?  Or is that what the CentOS Dojo is for?

I think that having as many venues for this as possible is ultimately a very good thing.

So, yes, the CentOS Dojo is for that, but the time slot for doing this is limited, so likely won't get to everyone's questions.

I've also put the "Office Hours" back on the meeting schedule - https://www.centos.org/community/calendar/#CentOS_Office_Hours - but those times are chosen fairly randomly, and if they don't work for people we can move them around

And we have indeed talked about doing some Q&A videos over the coming weeks. I need to get this on my calendar and actually start recording them, of course. I'll work with Bex and Mike and others to try to make this happen sooner rather than later. Thanks for the prod.

You are welcome.

For the CentOS Dojo, was Hopin Ltd. selected by FOSDEM or is it only being used specifically for the Dojo?

Am 25.01.21 um 20:56 schrieb Mike McGrath:

On Mon, Jan 25, 2021 at 1:03 PM Laurențiu Păncescu <lpancescu@centosproject.org mailto:lpancescu@centosproject.org> wrote:

On 1/25/21 7:29 PM, Mike McGrath wrote:
 > A fair question.  I've been in a few discussions related to this
 > internally and there are no plans to make changes for RHEL8 (IE: us
 > sending our debranded(ish) code to the centos git instance).  I
could
 > imagine scenarios where that gets moved to gitlab.  But generally
how we
 > push will remain the duration of RHEL8 - we just won't be
building it
 > into CentOS.  Don't take this to mean it's a guarantee or that
Red Hat
 > promised or whatever.  I'm just saying that at the moment we've
 > discussed it, no one is currently advocating for us to stop
releasing
 > RHEL8 code in the way we do, and so we have no plans on changes
there at
 > this time.

Excuse me, perhaps I'm reading too much into your words, just for my
own
understanding: does this mean it's not clear if Red Hat will continue
forever to release the sources for RHEL publicly, and perhaps only
provide them to their customers, at some point in the future? I'm
thinking more from perspective of rebuilds like Alma Linux or Oracle EL
- they wouldn't have anything to rebuild by themselves anymore. With
the
zero-cost RHEL covering the use case of many small companies and
hobbyists, I imagine this would be possible.

This is an area where written text falls flat and a conversation would be better but here goes....

For RHEL9 and forward, I suspect we won't be doing a RHEL release, and then releasing that code as we do today because.....

... the code should already be available via CentOS Stream.  To put it another way, the current plan of record is - If you ever find a RHEL binary, and cannot find the corresponding source code in the CentOS Stream gitlab instance, that means we've messed something up along the way because it was one of the explicit goals for CentOS Stream.  It might be released in RHEL first with a bit of delay (we're talking hours or a day or two not weeks), like with a 0-day CVE.  But generally, it should already be in CentOS Stream well before it's in RHEL.

I hope that's clearer.  Worst case, the rebuilders you're talking about will have to get to know our gitlab layouts, but all the code will be there.

For emphasis: There are no plans to stop making RHEL code available to the public at this time.  It will just take a different route to get there than it has under RHEL8/CentOS8 and before.

Without wanting to imply anything, but when I read between the lines: This sounds that the next major RHEL releases will not provide sources in a way, that allows someone to identify the current snapshot or point in time of a RHEL release. That is exactly what people are complaining about CentOS Stream and next minor release. So, everything (rpm artifacts) are then on "upstream" (gitlab/rolling dev) and no more "downstream" side (ftp:10yearsago, git:today). Do I misread this? (as you stated, a multi-modal conversation would be more appropriate)

-- Leon

On Mon, Jan 25, 2021 at 4:36 PM Leon Fauster via CentOS-devel < centos-devel@centos.org> wrote:

Am 25.01.21 um 20:56 schrieb Mike McGrath:

...

On Mon, Jan 25, 2021 at 1:03 PM Laurențiu Păncescu <lpancescu@centosproject.org mailto:lpancescu@centosproject.org>

wrote:

...

On 1/25/21 7:29 PM, Mike McGrath wrote:
 > A fair question.  I've been in a few discussions related to this
 > internally and there are no plans to make changes for RHEL8 (IE:

us

...

 > sending our debranded(ish) code to the centos git instance).  I
could
 > imagine scenarios where that gets moved to gitlab.  But generally
how we
 > push will remain the duration of RHEL8 - we just won't be
building it
 > into CentOS.  Don't take this to mean it's a guarantee or that
Red Hat
 > promised or whatever.  I'm just saying that at the moment we've
 > discussed it, no one is currently advocating for us to stop
releasing
 > RHEL8 code in the way we do, and so we have no plans on changes
there at
 > this time.

Excuse me, perhaps I'm reading too much into your words, just for my
own
understanding: does this mean it's not clear if Red Hat will continue
forever to release the sources for RHEL publicly, and perhaps only
provide them to their customers, at some point in the future? I'm
thinking more from perspective of rebuilds like Alma Linux or Oracle

EL

...

- they wouldn't have anything to rebuild by themselves anymore. With
the
zero-cost RHEL covering the use case of many small companies and
hobbyists, I imagine this would be possible.

This is an area where written text falls flat and a conversation would be better but here goes....

For RHEL9 and forward, I suspect we won't be doing a RHEL release, and then releasing that code as we do today because.....

... the code should already be available via CentOS Stream. To put it another way, the current plan of record is - If you ever find a RHEL binary, and cannot find the corresponding source code in the CentOS Stream gitlab instance, that means we've messed something up along the way because it was one of the explicit goals for CentOS Stream. It might be released in RHEL first with a bit of delay (we're talking hours or a day or two not weeks), like with a 0-day CVE. But generally, it should already be in CentOS Stream well before it's in RHEL.

I hope that's clearer. Worst case, the rebuilders you're talking about will have to get to know our gitlab layouts, but all the code will be

there.

...

For emphasis: There are no plans to stop making RHEL code available to the public at this time. It will just take a different route to get there than it has under RHEL8/CentOS8 and before.

Without wanting to imply anything, but when I read between the lines: This sounds that the next major RHEL releases will not provide sources in a way, that allows someone to identify the current snapshot or point in time of a RHEL release. That is exactly what people are complaining about CentOS Stream and next minor release. So, everything (rpm artifacts) are then on "upstream" (gitlab/rolling dev) and no more "downstream" side (ftp:10yearsago, git:today). Do I misread this? (as you stated, a multi-modal conversation would be more appropriate)

In an unusual turn of events, I actually should have been a tiny bit more ambiguous in my original response :). We haven't decided what to do with RHEL9's source code yet. It may end up at git.centos.org exactly as 8 does today. We're just not that far along in 9 development and those conversations haven't been finalized. I can say though - were I to put myself in a RHEL-9 rebuilders shoes though, best case source is exactly as its are today. Worst case I would have to look through the gitlab repo for specific versions I want as you've described above.

-Mike

On Mon, Jan 25, 2021 at 5:36 PM Leon Fauster via CentOS-devel centos-devel@centos.org wrote:

Without wanting to imply anything, but when I read between the lines: This sounds that the next major RHEL releases will not provide sources in a way, that allows someone to identify the current snapshot or point in time of a RHEL release. That is exactly what people are complaining about CentOS Stream and next minor release. So, everything (rpm artifacts) are then on "upstream" (gitlab/rolling dev) and no more "downstream" side (ftp:10yearsago, git:today). Do I misread this? (as you stated, a multi-modal conversation would be more appropriate)

-- Leon

Welcome to reposync and date-stamped copies of the daily or weekly updates. This is what we have to do to get a locked-down EPEL release: it's not a new problem.

On Mon, Jan 25, 2021 at 1:30 PM Mike McGrath mmcgrath@redhat.com wrote:

On Mon, Jan 25, 2021 at 10:57 AM Mark Mielke mark.mielke@gmail.com wrote:

...

Of course, if Red Hat would like to clarify here and tell me that I am absolutely wrong, and the "c8" branch will definitely be maintained into 2022, I will apologize for my doubt. Feel free to force me to apologize. I will be happy to apologize if I am wrong. Just let me know.

A fair question. I've been in a few discussions related to this internally and there are no plans to make changes for RHEL8 (IE: us sending our debranded(ish) code to the centos git instance). I could imagine scenarios where that gets moved to gitlab. But generally how we push will remain the duration of RHEL8 - we just won't be building it into CentOS. Don't take this to mean it's a guarantee or that Red Hat promised or whatever. I'm just saying that at the moment we've discussed it, no one is currently advocating for us to stop releasing RHEL8 code in the way we do, and so we have no plans on changes there at this time.

Hmmm... with no guarantee or promise, I can't decide whether I should apologize. :-) But, I do appreciate the consideration, so thanks for that.

Unless it is mostly or fully automated, I think the effort to maintain it will likely put it out of scope without a commitment to keep it up-to-date. But, personally I prefer the original SRPM on the FTP site approach anyways rather than Red Hat taking on the effort of de-branding and keeping these up-to-date, so personally - if either of these are maintained, it will come across as good faith for me.

For 9, it seems less likely we'll have the same branching structure unless we've got some particular use for it as part of the CentOS Stream process. All the code will be in GitLab as part of stream but exactly how that gets linked to point in time releases, branches, etc - may be part of our internal release process.

Interesting to plan ahead, but I think it is expected that 9 would change things around. Most of the concern around 8 for me, has to do with the mid-release change. Personally, I would have been less surprised, and less concerned, if the original announcement you made was about 9, and 8 was allowed to run its course.

Thanks,

On 28.01.2021 14:54, Neal Gompa wrote:

On Thu, Jan 28, 2021 at 6:22 AM Gena Makhomed gmm@csdoc.com wrote:

...

What is about running in the one bare metal RHEL server virtual machines with different subscription owners? For example, run in production on one bare metal server 16 VMs with subscription owner Alice, and 16 VMs with subscription owner Bob, and 16 VMs with subscription owner Carl, and so on. Are such configurations legal and allowed or not? I didn't find any limitations on the blog article, but for sure and for future I need a clean and unambiguous answer from Red Hat.

If such configurations are allowed - this is a legal workaround for a limit of 16 no-cont RHEL instances. For example, a small company, with 50 employees can absolutely legally have free and no-cost 800 RHEL servers in self-support mode. Company with 100 employees can have 1600 free no-cost RHEL servers in self-support mode and so on.

If such configurations are forbidden (on what basis?) - I have no choice but to migrate from free CentOS and no-cost RHEL to Oracle Linux or Alma Linux or Rocky Linux.

And in the future if my company grows and I will need to buy commercial support - I will be forced by Red Hat's decision to buy subscriptions for Oracle Linux from the Oracle Corporation?

Is this the real goal of the no-cost RHEL 16 instance limit - force CentOS users migrate to Oracle Linux?

Brian Exelbierd explained this whole thing quite well on the Ask Noah Show[1]. The answer to this is that what you're saying is perfectly allowed. The bet here is that this is sufficiently costly, risky, and a hassle (who wants to manage 100+ Red Hat accounts? I know I wouldn't!) that the company in question would decide to purchase RHEL subscriptions from Red Hat, especially after experiencing the value that Red Hat provides (Red Hat Insights, live kernel patching, etc.).

But did you know the minimal price of one RHEL Server subscription?

~ 350 USD/year.

So, subscription for 100 servers/VMs will be cost 35_000 USD/year.

Every year. For 10 years price of 100 subscriptions is 350_000 USD.

You don't need 100 Red Hat accounts, for 100 server subscriptions.

For 112 RHEL Server subscriptions you need only 7 Red Hat accounts.

16 * 7 == 112.

Managing 7 Red Hat accounts really is sufficiently costly, risky, and a hassle? I don't see any problems with such work for 7 accounts.

For 1600 servers minimal commercial price is 560_000 USD/year. and price is 5_600_000 USD for 10 year subscription. For 1600 servers.

Managing 100 Red Hat accounts really is sufficiently costly, risky, and a hassle? This work cost more then 5_600_000 USD for 10 years?

I don’t understand one thing, if it is so easy to get workaround these restrictions of 16 no-cost RHEL instances and at the same time bypassing these restrictions is completely legal - why were these restrictions introduced at all?

So that CentOS users should think about whether they should switch to no-cost RHEL, or maybe they should think about switching to completely free variant of Enterprise Linux from Oracle, which does not have such restrictions on the number of no-cost instances and don't need any subscriptions for seamless work at all?

As previously CentOS Linux users live (mostly) without commercial subscription and support from RHEL, the same in the future, they can live with no-cost Oracle Linux (mostly) without commercial subscription.

If user of mass installation of Oracle Linux in future need commercial support - he/she will buy commercial support from Oracle Corporation, not from Red Hat/IBM. It's obvious, isn't it? Money will go to Oracle.

This is some kind of strange situation when the Enterprise Linux was created by Red Hat staff and Fedora community, but the Oracle Corporation will make additional money on it, because this is where a large number of CentOS users can/will go in current situation.

What I would have liked to see is the addition of some generic low-cost subscription options that would be sufficiently below the floor to fit with even low-margin businesses so that as a business grows from 16, to 50, to 100, to 1000, and so on, the company would continue to use RHEL and continue to support the awesome work Red Hat does. Right now, the current pricing is so unbelievably expensive that I would instead just convert the boxes from RHEL to CentOS Stream after a certain threshold.

CentOS Stream is just a beta-version for next minor RHEL release.

CentOS Stream is not ready for production, see for example, bugreport https://bugzilla.redhat.com/show_bug.cgi?id=1913806 - this bug is present in CentOS Stream 8, but absent in CentOS 8.3.

I firmly believe that low-cost self-support options would be a good value for Red Hat to offer to the market, especially for a lot of those startups that eventually grow past the 16 server limit. I hope that's on the docket based on the comment at the top of the RHEL blog post that this is the first of many new programs.

I hope so too, because if they do nothing, then many CentOS users will simply leave for Oracle Linux. I just don't see any other way out now.

On Thu, Jan 28, 2021 at 3:16 PM Neal Gompa ngompa13@gmail.com wrote:

On Thu, Jan 28, 2021 at 3:55 PM Gena Makhomed gmm@csdoc.com wrote:

...

On 28.01.2021 14:54, Neal Gompa wrote:

...

On Thu, Jan 28, 2021 at 6:22 AM Gena Makhomed gmm@csdoc.com wrote:

...

...

What is about running in the one bare metal RHEL server virtual

machines

...

...

...

with different subscription owners? For example, run in production on one bare metal server 16 VMs with subscription owner Alice, and 16 VMs with subscription owner Bob, and 16 VMs with subscription owner Carl, and so on. Are such configurations legal and allowed or not? I didn't find any limitations on the blog article, but for sure and for future

I

...

...

...

need a clean and unambiguous answer from Red Hat.

If such configurations are allowed - this is a legal workaround for a limit of 16 no-cont RHEL instances. For example, a small company, with 50 employees can absolutely legally have free and no-cost 800 RHEL servers in self-support mode. Company with 100 employees can have 1600 free no-cost RHEL servers in self-support mode and so on.

If such configurations are forbidden (on what basis?) - I have no

choice

...

...

...

but to migrate from free CentOS and no-cost RHEL to Oracle Linux or

Alma

...

...

...

Linux or Rocky Linux.

And in the future if my company grows and I will need to buy

commercial

...

...

...

support - I will be forced by Red Hat's decision to buy subscriptions for Oracle Linux from the Oracle Corporation?

Is this the real goal of the no-cost RHEL 16 instance limit - force CentOS users migrate to Oracle Linux?

...

Brian Exelbierd explained this whole thing quite well on the Ask Noah Show[1]. The answer to this is that what you're saying is perfectly allowed. The bet here is that this is sufficiently costly, risky, and a hassle (who wants to manage 100+ Red Hat accounts? I know I

wouldn't!)

...

...

that the company in question would decide to purchase RHEL subscriptions from Red Hat, especially after experiencing the value that Red Hat provides (Red Hat Insights, live kernel patching, etc.).

But did you know the minimal price of one RHEL Server subscription?

~ 350 USD/year.

So, subscription for 100 servers/VMs will be cost 35_000 USD/year.

Every year. For 10 years price of 100 subscriptions is 350_000 USD.

You don't need 100 Red Hat accounts, for 100 server subscriptions.

For 112 RHEL Server subscriptions you need only 7 Red Hat accounts.

16 * 7 == 112.

Managing 7 Red Hat accounts really is sufficiently costly, risky, and a hassle? I don't see any problems with such work for 7 accounts.

For 1600 servers minimal commercial price is 560_000 USD/year. and price is 5_600_000 USD for 10 year subscription. For 1600 servers.

Managing 100 Red Hat accounts really is sufficiently costly, risky, and a hassle? This work cost more then 5_600_000 USD for 10 years?

It can be quite a hassle, especially if they have to be keyed to individual accounts and automation and such can only provision from one set of credentials at a time. At larger scale setups, it becomes quite messy and involved to actually maintain that.

I also believe those individual accounts are tied to the individual. If they leave a company - their subscriptions go with them.

-Mike

From experience, I can already say it's a pain to manage *one* Red Hat account, much less 7 or 100. It's not just the money, it's the labor and the opportunity costs.

...

I don’t understand one thing, if it is so easy to get workaround these restrictions of 16 no-cost RHEL instances and at the same time bypassing these restrictions is completely legal - why were these restrictions introduced at all?

So that CentOS users should think about whether they should switch to no-cost RHEL, or maybe they should think about switching to completely free variant of Enterprise Linux from Oracle, which does not have such restrictions on the number of no-cost instances and don't need any subscriptions for seamless work at all?

As previously CentOS Linux users live (mostly) without commercial subscription and support from RHEL, the same in the future, they can live with no-cost Oracle Linux (mostly) without commercial subscription.

If user of mass installation of Oracle Linux in future need commercial support - he/she will buy commercial support from Oracle Corporation, not from Red Hat/IBM. It's obvious, isn't it? Money will go to Oracle.

This is some kind of strange situation when the Enterprise Linux was created by Red Hat staff and Fedora community, but the Oracle Corporation will make additional money on it, because this is where a large number of CentOS users can/will go in current situation.

...

What I would have liked to see is the addition of some generic low-cost subscription options that would be sufficiently below the floor to fit with even low-margin businesses so that as a business grows from 16, to 50, to 100, to 1000, and so on, the company would continue to use RHEL and continue to support the awesome work Red Hat does. Right now, the current pricing is so unbelievably expensive that I would instead just convert the boxes from RHEL to CentOS Stream after a certain threshold.

CentOS Stream is just a beta-version for next minor RHEL release.

CentOS Stream is not ready for production, see for example, bugreport https://bugzilla.redhat.com/show_bug.cgi?id=1913806

• this bug is present in CentOS Stream 8, but absent in CentOS 8.3.

Meh. Legacy CentOS Linux gets serious bugs all the time too. I had dozens of AMD servers that wouldn't boot because of a critical bug introduced in CentOS 7.3. There was a whole cycle where I had to hold back kernels because they couldn't release a fix until CentOS 7.4 arrived.

At least with CentOS Stream, when the fix is made, I'll get it right away. That's better than before.

...

...

I firmly believe that low-cost self-support options would be a good value for Red Hat to offer to the market, especially for a lot of those startups that eventually grow past the 16 server limit. I hope that's on the docket based on the comment at the top of the RHEL blog post that this is the first of many new programs.

I hope so too, because if they do nothing, then many CentOS users will simply leave for Oracle Linux. I just don't see any other way out now.

I'm optimistic. I know the folks at Red Hat are doing their best, and I have faith in them.

-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel

On 28.01.2021 23:14, Neal Gompa wrote:

...

...

I firmly believe that low-cost self-support options would be a good value for Red Hat to offer to the market, especially for a lot of those startups that eventually grow past the 16 server limit. I hope that's on the docket based on the comment at the top of the RHEL blog post that this is the first of many new programs.

...

I hope so too, because if they do nothing, then many CentOS users will simply leave for Oracle Linux. I just don't see any other way out now.

I'm optimistic. I know the folks at Red Hat are doing their best, and I have faith in them.

Yes, you are right, the folks at Red Hat are doing their best, but Red Hat is not independent, now it is an IBM subsidiary.

So, as I understand, all decisions about killing CentOS were made not by Red Hat, but by the top managers of IBM.

IBM acquired Red Hat for 34 billion USD, and now they just wants to return money.

Killing the CentOS achieves several goals:

1. Most of CentOS users are transferred to beta testers for the next minor version of RHEL (CentOS Stream), which makes it possible to improve the quality of minor releases of RHEL, which can bring additional profit for IBM in the long term.

2. A smaller part of the CentOS users are transferred to the paid version of RHEL, which brings additional profit for IBM in the short term.

3. For those users for whom neither option (1) nor option (2) is suitable, the RHEL no-cost option was offered with a limit of 16 instances. Over time, some of them will go to the users of paid version of RHEL, also increasing the profit of IBM.

Killing the CentOS - "Nothing personal, it's just business".

On Friday, January 29, 2021 3:17 AM, Gena Makhomed gmm@csdoc.com wrote:

On 28.01.2021 23:14, Neal Gompa wrote:

...

I'm optimistic. I know the folks at Red Hat are doing their best, and I have faith in them.

Yes, you are right, the folks at Red Hat are doing their best, but Red Hat is not independent, now it is an IBM subsidiary.

So, as I understand, all decisions about killing CentOS were made not by Red Hat, but by the top managers of IBM.

IBM acquired Red Hat for 34 billion USD, and now they just wants to return money.

There are issues with the governance but IBM was not one of them.

Long time respected members of the CentOS were at the Nov 11th meeting including Johnny Hughes and Thomas Oulevey. If IBM had come in and strong armed the decision, one of them would have said something.

Bex has explained on the Ask Noah show that IBM is acting as nothing more than a trusted partner in this decision. He further explains in the Register it was Red Hat that decided to change the funding for CentOS.

If you have any contacts inside IBM involved with AIX, I suggest you talk with them about their thoughts on how Red Hat is going about things. If you can find one that will talk off the cuff, I think you might find they are surprised by Red Hat's actions as several of us.

Killing the CentOS achieves several goals:

1. Most of CentOS users are transferred to beta testers for the next minor version of RHEL (CentOS Stream), which makes it possible to improve the quality of minor releases of RHEL, which can bring additional profit for IBM in the long term.

I wish there are a push towards most CentOS users to Stream.

Instead, it is clear making free RHEL licenses was a priority. They are delivering on new RHEL terms before they make available Stream on gitlab and the other changes need for Stream to be a meaningful upstream.

There is probably hope that free RHEL users will eventually outgrow it and become paying users. But it doesn't fit that there is any expectation this will increase profits in the next couple years.

2. A smaller part of the CentOS users are transferred to the paid version of RHEL, which brings additional profit for IBM in the short term.

3. For those users for whom neither option (1) nor option (2) is suitable, the RHEL no-cost option was offered with a limit of 16 instances. Over time, some of them will go to the users of paid version of RHEL, also increasing the profit of IBM.

With how Red Hat went about things, I think it is more likely in the short term a small number of users will move to paid versions of competitors Red Hat.

It has been stated that this was not about increasing profits and I believe them. This is about redirecting funding.

Killing the CentOS - "Nothing personal, it's just business".

That is true.

Is it legal to use RHEL inside systemd-nspawn containers without registration and without activation subscription inside the container?

My understanding is they are allowing this.

Do I need to start the registration process inside each container, or will the "yum update" command inside the container work without it?

It is not possible to use yum update without the registration ID. It seems implied that copying the registration into UBI containers on the system will be permitted. Maybe Bex can give a more clear statement regarding registration re-use on containers. Otherwise, re-using RPMs from the yum cache or getting RPMs using yumdownloader seems to be permitted.

Developer Subscriptions allowed to use for production workloads only by individuals, and totally forbidden to use by companies?

Listen to the Ask Noah show interview with Bex because that explains things better. A president of a company can use some of their free licenses to for their small business if they choose to. However, the activation is still tied to the individual so if they leave the company the rights to the activation leave with them. So, it is not totally forbidden but impractical.

no-cost RHEL as I understand is forbidden to use by companies.

My understanding is a company can use up to 16 licenses for production use without support for free.

It just doesn't scale up across employees.

350 USD/year RHEL is forbidden to use for virtual machines. If you are using something else as the hypervisor then you can use the RHEL license

My understanding is if you purchased only a single $350 license you can use it for being a HV or a VM but not both.

800 USD/year RHEL is too expensive for each bare metal / VM / container.

Website hosting is low-margin businesses, it is unreal to pay 800 USD/year for each virtual machine/container.

I agree. A lot of hosting control panels do not officially support or recommend CentOS 8 or RHEL 8 yet.

Time will tell what impact moving the CentOS 8 end of life date from 10 years to 2 years has. It may be that the established hosting control panels will be promoting migrating to other distributions.

One hosting server can have several dozen or even several hundred of virtual machines or systemd-nspawn containers.

With that density of VMs per hypervisor, talk to your Red Hat account manager about RHEL OpenStack Platform.

As I understand, there are only two available options for me:

There are much more than two options available. Listing them out goes beyond the scope of this forum.

My focus at this point is on the transistion to Stream and how poorly that transistion is occuring so far.

The offer to get for free access to GPL/LGPL that prohibit redistribution on the bases of being branded as owned by Red Hat like cattle more offends me than being of any use. If Red Hat could have been more respectful of the spirit of Copyleft then maybe trying RHEL again would be a consideration.

On Friday, January 29, 2021 1:12 PM, Matthew Miller mattdm@mattdm.org wrote:

On Fri, Jan 29, 2021 at 07:06:02PM +0000, redbaronbrowser via CentOS-devel wrote:

...

Instead, it is clear making free RHEL licenses was a priority. They are delivering on new RHEL terms before they make available Stream on gitlab and the other changes need for Stream to be a meaningful upstream.

I don't think you should read too much into that. These things are done by very different teams, all going as fast as they can.

I am sorry, I worded that badly. Also based on Bex's interview that Red Hat is expecting more people to move to free RHEL than to move to Stream.

It does not upset me that Red Hat is promoting RHEL with the claim it is a better option over Stream. That is to be expected.

I also agree they are working as fast as they can on both fronts.

The things that bother me are:

(1) Setting a termination date for CentOS 8 independant of how long it takes to make Stream available in a meaningful way

(2) Lack of achieving a success criteria for Stream before setting the termination date

(3) Indicating the promises of governance was just a document that silently went "out of date"

(4) Now talking about the future of Stream 9 like that is something that will not just go silently out of date as well

Once we are asked to accept fundamental aspects of the CentOS / Red Hat merging simply go "out of date." Then it seems reasonable to be skeptical of if the 16 RHEL offering or Stream will even continue to exist at all after 4 years. Anything said now today should be considered "out of date" long before Stream 9 is even possibly a thing.

On 29.01.2021 21:06, redbaronbrowser via CentOS-devel wrote:

...

Developer Subscriptions allowed to use for production workloads only by individuals, and totally forbidden to use by companies?

Listen to the Ask Noah show interview with Bex because that explains things better.

Sorry, but I can't. Because English is not my native language. Written English I can read, but spoken English is just a bunch of sounds for me - I can't understand it.

...

350 USD/year RHEL is forbidden to use for virtual machines.

If you are using something else as the hypervisor then you can use the RHEL license

My understanding is if you purchased only a single $350 license you can use it for being a HV or a VM but not both.

Look at the page

https://www.redhat.com/en/store/red-hat-enterprise-linux-server

350 USD/year Red Hat subscription described as:

"Can only be deployed on physical systems".

I understand these words as "forbidden to use inside virtual machines".

On Saturday, January 30, 2021 1:48 PM, Gena Makhomed gmm@csdoc.com wrote:

On 29.01.2021 21:06, redbaronbrowser via CentOS-devel wrote:

...

...

Developer Subscriptions allowed to use for production workloads only by individuals, and totally forbidden to use by companies?

...

Listen to the Ask Noah show interview with Bex because that explains things better.

Sorry, but I can't. Because English is not my native language. Written English I can read, but spoken English is just a bunch of sounds for me - I can't understand it.

@Rich Bowen

Is the any plans for transcription to be provided for the CentOS Dojo for people with accessability? Either real time or afterwards?

I assume Hopin is similar to Jitsi with a real-time chat window that someone could transcribe into?

I have also been meaning to ask if the RH Open Source Program Office has ever done a review of Jitsi or ever plans to?

Am 28.01.21 um 21:55 schrieb Gena Makhomed:

On 28.01.2021 14:54, Neal Gompa wrote:

...

On Thu, Jan 28, 2021 at 6:22 AM Gena Makhomed gmm@csdoc.com wrote:

...

...

What is about running in the one bare metal RHEL server virtual machines with different subscription owners? For example, run in production on one bare metal server 16 VMs with subscription owner Alice, and 16 VMs with subscription owner Bob, and 16 VMs with subscription owner Carl, and so on. Are such configurations legal and allowed or not? I didn't find any limitations on the blog article, but for sure and for future I need a clean and unambiguous answer from Red Hat.

If such configurations are allowed - this is a legal workaround for a limit of 16 no-cont RHEL instances. For example, a small company, with 50 employees can absolutely legally have free and no-cost 800 RHEL servers in self-support mode. Company with 100 employees can have 1600 free no-cost RHEL servers in self-support mode and so on.

If such configurations are forbidden (on what basis?) - I have no choice but to migrate from free CentOS and no-cost RHEL to Oracle Linux or Alma Linux or Rocky Linux.

And in the future if my company grows and I will need to buy commercial support - I will be forced by Red Hat's decision to buy subscriptions for Oracle Linux from the Oracle Corporation?

Is this the real goal of the no-cost RHEL 16 instance limit - force CentOS users migrate to Oracle Linux?

...

Brian Exelbierd explained this whole thing quite well on the Ask Noah Show[1]. The answer to this is that what you're saying is perfectly allowed. The bet here is that this is sufficiently costly, risky, and a hassle (who wants to manage 100+ Red Hat accounts? I know I wouldn't!) that the company in question would decide to purchase RHEL subscriptions from Red Hat, especially after experiencing the value that Red Hat provides (Red Hat Insights, live kernel patching, etc.).

But did you know the minimal price of one RHEL Server subscription?

~ 350 USD/year.

So, subscription for 100 servers/VMs will be cost 35_000 USD/year.

Every year. For 10 years price of 100 subscriptions is 350_000 USD.

You don't need 100 Red Hat accounts, for 100 server subscriptions.

For 112 RHEL Server subscriptions you need only 7 Red Hat accounts.

16 * 7 == 112.

Managing 7 Red Hat accounts really is sufficiently costly, risky, and a hassle? I don't see any problems with such work for 7 accounts.

For 1600 servers minimal commercial price is 560_000 USD/year. and price is 5_600_000 USD for 10 year subscription. For 1600 servers.

Managing 100 Red Hat accounts really is sufficiently costly, risky, and a hassle? This work cost more then 5_600_000 USD for 10 years?

I don’t understand one thing, if it is so easy to get workaround these restrictions of 16 no-cost RHEL instances and at the same time bypassing these restrictions is completely legal - why were these restrictions introduced at all?

So that CentOS users should think about whether they should switch to no-cost RHEL, or maybe they should think about switching to completely free variant of Enterprise Linux from Oracle, which does not have such restrictions on the number of no-cost instances and don't need any subscriptions for seamless work at all?

As previously CentOS Linux users live (mostly) without commercial subscription and support from RHEL, the same in the future, they can live with no-cost Oracle Linux (mostly) without commercial subscription.

If user of mass installation of Oracle Linux in future need commercial support - he/she will buy commercial support from Oracle Corporation, not from Red Hat/IBM. It's obvious, isn't it? Money will go to Oracle.

And what the calculation for OL subscriptions?

This is some kind of strange situation when the Enterprise Linux was created by Red Hat staff and Fedora community, but the Oracle Corporation will make additional money on it, because this is where a large number of CentOS users can/will go in current situation.

...

What I would have liked to see is the addition of some generic low-cost subscription options that would be sufficiently below the floor to fit with even low-margin businesses so that as a business grows from 16, to 50, to 100, to 1000, and so on, the company would continue to use RHEL and continue to support the awesome work Red Hat does. Right now, the current pricing is so unbelievably expensive that I would instead just convert the boxes from RHEL to CentOS Stream after a certain threshold.

CentOS Stream is just a beta-version for next minor RHEL release.

CentOS Stream is not ready for production, see for example, bugreport https://bugzilla.redhat.com/show_bug.cgi?id=1913806

• this bug is present in CentOS Stream 8, but absent in CentOS 8.3.

Not sure but maybe because systemd-nspawn is not supported?

-- Leon

Am 28.01.21 um 23:48 schrieb John R. Dennison:

On Thu, Jan 28, 2021 at 10:22:42PM +0100, Leon Fauster via CentOS-devel wrote:

...

And what the calculation for OL subscriptions?

OEL is free. And please start trimming replies, having to wade through cascaded replies is getting a bit annoying.

Sure, I was just joking and forget the smiley :-)

-- Leon

On 28/01/2021 22:09, redbaronbrowser via CentOS-devel wrote:

I agree that Stream in it's current form is beta version quality. That bug is clearly a regression that shouldn't exist in something expected "to have fewer bugs." It is frustrating.

Typo.

s/fewer/newer/

Trevor

Hi Gena,

On Thu, Jan 28, 2021 at 12:23 PM Gena Makhomed gmm@csdoc.com wrote:

This is copy of my email to centos-questions@redhat.com

This is in my queue - sorry for not having gotten back to you yet. I'll reply here for some of this.

==============================================================================

Hello Red Hat,

As I understand from the Red Hat blog article "New Year, new Red Hat Enterprise Linux programs: Easier ways to access RHEL" I am limited to only 16 no-cost RHEL instances. Limit 16 instances means bare metal servers and KVM virtual machines, right?

In general yes, containers, as mentioned below are a bit ambiguous without some definition.

But what about systemd-nspawn OS-level virtualization containers? To be able run "yum update" inside systemd-nspawn containers I need to activate Red Hat subscription inside each container too???

RHEL UBI containers when run on an entitled RHEL host do not need to be separately entitled and do not count toward the 16 entitlements. This is part of the set of "super powers" RHEL UBI gets when run on RHEL.

If you run the registration inside of the container, that will count toward your 16 entitlements. For example, running a RHEL UBI container on a non-RHEL host where you wish to access the additional content available with your subscription.

And I can't have more than 16 instances (bare metal + VMs + containers) with a RHEL subscription?

The Individual developer subscription is limited to 16 entitlements. There are other subscription models that have more.

This is too strict restriction for me. Because I use now CentOS 8 in production and use systemd-nspawn containers for hosting websites, and create for each website a separate systemd-nspawn container.

Or I can legally create and legally "yum update" and legally use in production OS-level virtualization systemd-nspawn containers without activating RHEL subscription for each such container?

But I still need to activate the RHEL subscription for each VM which runs an RHEL instance?

Virtual machines need to be separately entitled. They count toward the 16 entitlements.

More generally speaking, anytime you register you consume an entitlement. This is one huge advantage of using RHEL UBI on registered RHEL hosts.

==============================================================================

What is about running in the one bare metal RHEL server virtual machines with different subscription owners? For example, run in production on one bare metal server 16 VMs with subscription owner Alice, and 16 VMs with subscription owner Bob, and 16 VMs with subscription owner Carl, and so on. Are such configurations legal and allowed or not? I didn't find any limitations on the blog article, but for sure and for future I need a clean and unambiguous answer from Red Hat.

If such configurations are allowed - this is a legal workaround for a limit of 16 no-cont RHEL instances. For example, a small company, with 50 employees can absolutely legally have free and no-cost 800 RHEL servers in self-support mode. Company with 100 employees can have 1600 free no-cost RHEL servers in self-support mode and so on.

No. The Individual Developer Subscriptions do not accrue to a company. Companies do not get to use this program. As others have pointed out, doing this will create management nightmares and liability concerns. When the terms and conditions are released you would need each individual to study them in detail to determine if they could be part of this amalgamation that you are proposing and still be within the terms of the legal agreement they entered into.

Red Hat believes that in the situation you describe a company would be best served by having a conversation with a commercial provider to find a good fit for this workload. Obviously we'd like that to be with us about RHEL, but we understand that other options exist in the market.

regards,

bex

If such configurations are forbidden (on what basis?) - I have no choice but to migrate from free CentOS and no-cost RHEL to Oracle Linux or Alma Linux or Rocky Linux.

And in the future if my company grows and I will need to buy commercial support - I will be forced by Red Hat's decision to buy subscriptions for Oracle Linux from the Oracle Corporation?

Is this the real goal of the no-cost RHEL 16 instance limit - force CentOS users migrate to Oracle Linux?

More details here:

• https://www.oracle.com/linux/

• https://linux.oracle.com/switch/centos/

==============================================================================

[...]

-- Best regards, Gena _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel

-- Did this email arrive after work for you? Stop reading it and enjoy some work/life balance.

Brian "bex" Exelbierd (he/him/his) Community Business Owner, RHEL Product Management @bexelbie | http://www.winglemeyer.org bexelbie@redhat.com

On Fri, Jan 29, 2021 at 6:30 AM Gena Makhomed gmm@csdoc.com wrote:

Hi Brian,

On 28.01.2021 23:38, Brian (bex) Exelbierd wrote:

...

...

As I understand from the Red Hat blog article "New Year, new Red Hat Enterprise Linux programs: Easier ways to access RHEL" I am limited to only 16 no-cost RHEL instances. Limit 16 instances means bare metal servers and KVM virtual machines, right?

In general yes, containers, as mentioned below are a bit ambiguous without some definition.

...

But what about systemd-nspawn OS-level virtualization containers? To be able run "yum update" inside systemd-nspawn containers I need to activate Red Hat subscription inside each container too???

...

RHEL UBI containers when run on an entitled RHEL host do not need to be separately entitled and do not count toward the 16 entitlements. This is part of the set of "super powers" RHEL UBI gets when run on RHEL.

Situation with RHEL UBI is clear, and I don't ask about them.

My question is exclusively about systemd-nspawn containers.

https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html

systemd-nspawn containers provided in RHEL by systemd-container package.

...

If you run the registration inside of the container, that will count toward your 16 entitlements.

Yes, I understand what if I run the registration inside of the container, that will count toward my 16 entitlements.

My question is this:

Is it legal to use RHEL inside systemd-nspawn containers without registration and without activation subscription inside the container?

Do I need to start the registration process inside each container, or will the "yum update" command inside the container work without it?

Well, strictly speaking, you only need to do this if you cut off subscription-manager from the host's registration. There's a hook in Podman that pulls in the host RHEL subscription entitlement into the container so that everything works without registering a new entitlement (as permitted by the terms). You'd need to do something similar for systemd-nspawn to qualify it properly as container usage.

...

...

What is about running in the one bare metal RHEL server virtual machines with different subscription owners? For example, run in production on one bare metal server 16 VMs with subscription owner Alice, and 16 VMs with subscription owner Bob, and 16 VMs with subscription owner Carl, and so on. Are such configurations legal and allowed or not? I didn't find any limitations on the blog article, but for sure and for future I need a clean and unambiguous answer from Red Hat.

If such configurations are allowed - this is a legal workaround for a limit of 16 no-cont RHEL instances. For example, a small company, with 50 employees can absolutely legally have free and no-cost 800 RHEL servers in self-support mode. Company with 100 employees can have 1600 free no-cost RHEL servers in self-support mode and so on.

...

No. The Individual Developer Subscriptions do not accrue to a company. Companies do not get to use this program.

Are you talking about the announcement on 1 February "No-cost RHEL for small production workloads" ?

Surprise!

Developer Subscriptions allowed to use for production workloads only by individuals, and totally forbidden to use by companies?

: We’re addressing this by expanding the terms of the Red Hat Developer : program so that the Individual Developer subscription for RHEL can be : used in production for up to 16 systems. That’s exactly what it sounds : like: for small production use cases, this is no-cost, self-supported : RHEL.

"can be used in production for up to 16 systems"

• I didn't find here forbid to use by companies.

...

Red Hat believes that in the situation you describe a company would be best served by having a conversation with a commercial provider to find a good fit for this workload. Obviously we'd like that to be with us about RHEL, but we understand that other options exist in the market.

Conversation about what?

no-cost RHEL as I understand is forbidden to use by companies.

Strictly speaking, it is not forbidden for use by companies. It's forbidden to *register* to companies. That means it *must* be tied to an individual, and if that person leaves the company, those entitlements go with it. It's deliberately designed this way so someone could do a startup with RHEL and scale up eventually to proper commercial licenses if successful. This was a specific example the Brian said was permitted in the Ask Noah Show interview[1].

[1]: https://podcast.asknoahshow.com/216?t=1877

350 USD/year RHEL is forbidden to use for virtual machines.

800 USD/year RHEL is too expensive for each bare metal / VM / container.

Website hosting is low-margin businesses, it is unreal to pay 800 USD/year for each virtual machine/container.

One hosting server can have several dozen or even several hundred of virtual machines or systemd-nspawn containers.

VMs require separate entitlements, containers do not. Describing nspawn as a VM probably confused Brian, it is explicitly not a VM technology, as it can't boot a kernel or simulate hardware.

But this circles back to my hope that RHEL subscription pricing can be improved to support a broader base.

On Fri, Jan 29, 2021 at 1:21 PM Gena Makhomed gmm@csdoc.com wrote:

On 29.01.2021 14:28, Neal Gompa wrote:

...

...

Is it legal to use RHEL inside systemd-nspawn containers without registration and without activation subscription inside the container?

Do I need to start the registration process inside each container, or will the "yum update" command inside the container work without it?

...

Well, strictly speaking, you only need to do this if you cut off subscription-manager from the host's registration. There's a hook in Podman that pulls in the host RHEL subscription entitlement into the container so that everything works without registering a new entitlement (as permitted by the terms). You'd need to do something similar for systemd-nspawn to qualify it properly as container usage.

Neal, thank you! You really helped me.

Now I understand how it should work from a technical point of view.

But will be such hack of systemd-nspawn containers made by myself legal, or such modification of systemd-nspawn containers is completely illegal and not allowed?

Because systemd-nspawn containers provide OS-level virtualization, and from users point of view they are almost identical to virtual machines. Virtual machines limited to only allowed 16 subscriptions, but systemd-nspawn containers not limited at all, and one no-cost RHEL server can have running 100, 200 or even more systemd-nspawn containers.

It's *not* virtualization in the sense that Red Hat cares about. It's not booting another kernel. It's not another computer system. This is already allowed because otherwise it becomes a huge problem for Podman and OpenShift systems to run RHEL containers. If you're entitled to the host, you're entitled automatically for containers.

Note that RHEL UBI is probably a better fit here, since it doesn't have the RHEL subscription restrictions on it: https://access.redhat.com/articles/4238681

...

...

...

...

What is about running in the one bare metal RHEL server virtual machines with different subscription owners? For example, run in production on one bare metal server 16 VMs with subscription owner Alice, and 16 VMs with subscription owner Bob, and 16 VMs with subscription owner Carl, and so on. Are such configurations legal and allowed or not? I didn't find any limitations on the blog article, but for sure and for future I need a clean and unambiguous answer from Red Hat.

If such configurations are allowed - this is a legal workaround for a limit of 16 no-cont RHEL instances. For example, a small company, with 50 employees can absolutely legally have free and no-cost 800 RHEL servers in self-support mode. Company with 100 employees can have 1600 free no-cost RHEL servers in self-support mode and so on.

...

...

...

No. The Individual Developer Subscriptions do not accrue to a company. Companies do not get to use this program.

[...]

...

...

...

Red Hat believes that in the situation you describe a company would be best served by having a conversation with a commercial provider to find a good fit for this workload. Obviously we'd like that to be with us about RHEL, but we understand that other options exist in the market.

...

...

Conversation about what?

no-cost RHEL as I understand is forbidden to use by companies.

...

Strictly speaking, it is not forbidden for use by companies. It's forbidden to *register* to companies. That means it *must* be tied to an individual, and if that person leaves the company, those entitlements go with it. It's deliberately designed this way so someone could do a startup with RHEL and scale up eventually to proper commercial licenses if successful. This was a specific example the Brian said was permitted in the Ask Noah Show interview[1].

In the example above - Alice and Bob are employers of company, which are registered Individual Developer Subscriptions using corporate mail, for example, alice@example.com and bob@example.com example.com - domain and mail server owned by Example Corporation.

Is such registration allowed?

Is Alice and Bob allowed together use these 32 subscriptions for servers and VMs used in production for company purposes?

And what changed if we have not 2 but 32 employers? 32 employers of company together can have 512 subscriptions for servers and VMs.

And what changed if we have not 2 but 128 employers? 128 employers of company together can have 2048 subscriptions for servers and VMs.

If Alise of Bob leaves the company - they email will be blocked, servers and VMs will be deregistered from Alise of Bob accounts before Alice and Bob fired from the company, and these servers and VMs anew will be registered to another employers of company.

Such a scheme of work with subscriptions will work without problems or such scheme of work is forbidden and illegal? (on which reason?)

You should probably stop asking about this on this list. I suspect if people really abused this in the way you're describing, it'll just go away entirely. So, please don't abuse the nice things folks give to the community. It'd be more productive to just ask Red Hat for low-cost options for your business vertical.

...

...

Website hosting is low-margin businesses, it is unreal to pay 800 USD/year for each virtual machine/container.

One hosting server can have several dozen or even several hundred of virtual machines or systemd-nspawn containers.

...

VMs require separate entitlements, containers do not. Describing nspawn as a VM probably confused Brian, it is explicitly not a VM technology, as it can't boot a kernel or simulate hardware.

https://en.wikipedia.org/wiki/OS-level_virtualization

• this is a common term for naming containers that use

https://en.wikipedia.org/wiki/Linux_namespaces for resource isolation, using shared kernel.

Red Hat does not acknowledge "OS containers" as any different from "app containers". Indeed, the RHEL 8 systemd container is effectively the same environment you'd be creating with nspawn yourself. They are both "virtualized" in the technical sense, but in the sense that Red Hat subscription management cares about it, they are not.

You are not duplicating cores, you are not duplicating RAM, and you're not duplicating the kernel instance. It's one host system of shared resources across everything, and that's considered fine.

Remember that Mock uses systemd-nspawn too, and it would be a huge problem if that wasn't allowed.

-- 真実はいつも一つ！/ Always, there's only one truth!

On Sun, Jan 31, 2021 at 2:54 AM Gena Makhomed gmm@csdoc.com wrote:

On 29.01.2021 20:35, Neal Gompa wrote:

...

...

In the example above - Alice and Bob are employers of company, which are registered Individual Developer Subscriptions using corporate mail, for example, alice@example.com and bob@example.com example.com - domain and mail server owned by Example Corporation.

Is such registration allowed?

Is Alice and Bob allowed together use these 32 subscriptions for servers and VMs used in production for company purposes?

And what changed if we have not 2 but 32 employers? 32 employers of company together can have 512 subscriptions for servers and VMs.

And what changed if we have not 2 but 128 employers? 128 employers of company together can have 2048 subscriptions for servers and VMs.

If Alise of Bob leaves the company - they email will be blocked, servers and VMs will be deregistered from Alise of Bob accounts before Alice and Bob fired from the company, and these servers and VMs anew will be registered to another employers of company.

Such a scheme of work with subscriptions will work without problems or such scheme of work is forbidden and illegal? (on which reason?)

...

You should probably stop asking about this on this list. I suspect if people really abused this in the way you're describing, it'll just go away entirely. So, please don't abuse the nice things folks give to the community. It'd be more productive to just ask Red Hat for low-cost options for your business vertical.

Why should Red Hat make any exceptions to the rules for me personally? In their place, I would establish the same rules of the game for all users, so I am not even going to ask them to make an exception to the rules for me personally.

Do you remember the article https://www.redhat.com/en/blog/new-year-new-red-hat-enterprise-linux-program...

Quote from there: "We're working on a variety of additional programs for other use cases, and plan to provide another update in mid-February."

Perhaps Brian Exelbierd will be able to answer our questions on this list, if any, after additional programs from the Red Hat are announced.

-- Best regards, Gena

Big Blue needs money. Red Hat needs its community (Open source developers and users). What we need is a win-win for all parties included.

--- Lee

On Fri, Jan 29, 2021 at 1:36 PM Matthew Miller mattdm@mattdm.org wrote:

And if instead your company comes up with some process for _actually_ managing everyone's active participation, well, okay, fine, but maybe that time would be better spent on figuring out how to actually just cope with CentOS Stream — or to skip all that and decide that you're at a scale where actually paying for RHEL isn't all that terrible after all and all the employees can concentrate on doing their actual jobs.

I'm trying to stay out of the weeds on many of the recent re-hashes of known concerns and known responses to these concerns, but I want to be clear about this point...

The larger the scale, the less attractive RHEL is. This is a fundamental problem with the RHEL licensing model. Once the RHEL licensing cost exceeds around $0.5M/year, you can now afford people to work on this problem. If you were to exceed $5M/year, you can have a team of people working on this problem. This is the problem I raised to our Red Hat sales rep in 2016, and this is the problem that they never provided a solution for. The discounts provided at scale were insignificant as factors. This is why "Facebook" (as one example of scale in context for this discussion) is using CentOS Stream, and not using RHEL.

If the Red Hat licensing model scaled properly, I don't think there would be a real problem being discussed here. In my case, we would have stayed an RHEL-only shop.

So yes - let's all keep the FUD to a minimum. Maybe IBM had nothing to do with this turn of events. But also, it's not true that if your requirements scale up, RHEL becomes more attractive. So both of these ideas should be left out of the discussion. Thanks.

On 1/29/21 6:09 PM, redbaronbrowser via CentOS-devel wrote:

On Friday, January 29, 2021 4:58 PM, Mark Mielke mark.mielke@gmail.com wrote:

...

This is why "Facebook" (as one example of scale in context for this discussion) is using CentOS Stream, and not using RHEL.

Is there any public interview that Facebook is using the latest Stream packages in production?

Here's the interview that we have published - https://www.youtube.com/watch?v=cA_Nd3crBuA&list=PLuRtbOXpVDjCShu-x87qtr...

It seems to me that Facebook is doing it's own CI/CD tests and avoid regressions that would impact it.

I'm willing to accept that Facebook is using select versions of packages from Stream. I have a harder time believing they are using Stream the same way one of us would of running yum and expecting things to continue to work.

The folks on the above video are, I believe, here on this mailing list, so I won't presume to speak for them.

They'll also be presenting at tomorrow's Dojo - https://wiki.centos.org/Events/Dojo/FOSDEM2021 - and will likely have time for questions at the end of their session.

Facebook is also probably retaining an internal vault of previous versions to allow them to revert. Again, that is not the same as what is exposed to most of us.

It would be nice to see whatever tests Facebook considers important contributed back into Stream's own CD/CI but so far I haven't gotten an answer as to when/if public access to updating the tests will be available. _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel

On 2/3/21 4:26 PM, Davide Cavalca via CentOS-devel wrote:

...

It would be nice to see whatever tests Facebook considers important contributed back into Stream's own CD/CI but so far I haven't gotten an answer as to when/if public access to updating the tests will be available.

Sure, happy to participate in this when something becomes available.

I think it is.  Neal Gompa mentioned this link the other day:

https://git.centos.org/centos/t_functional

On Fri, 29 Jan 2021 at 17:58, Mark Mielke mark.mielke@gmail.com wrote:

On Fri, Jan 29, 2021 at 1:36 PM Matthew Miller mattdm@mattdm.org wrote:

...

And if instead your company comes up with some process for _actually_ managing everyone's active participation, well, okay, fine, but maybe

that

...

time would be better spent on figuring out how to actually just cope with CentOS Stream — or to skip all that and decide that you're at a scale

where

...

actually paying for RHEL isn't all that terrible after all and all the employees can concentrate on doing their actual jobs.

I'm trying to stay out of the weeds on many of the recent re-hashes of known concerns and known responses to these concerns, but I want to be clear about this point...

The larger the scale, the less attractive RHEL is. This is a fundamental problem with the RHEL licensing model. Once the RHEL licensing cost exceeds around $0.5M/year, you can now afford people to work on this problem. If you were to exceed $5M/year, you can have a team of people working on this problem. This is the problem I raised to our Red Hat sales rep in 2016, and this is the problem that they never provided a solution for. The discounts provided at scale were insignificant as factors. This is why "Facebook" (as one example of scale in context for this discussion) is using CentOS Stream, and not using RHEL.

Depending on what industry you are in, you are looking at about 0.25-0.5 M/year per person in expenses spread through a company. Those sorts of companies have investors (owners) who want the company to only focus on their core competency which is usually making some other widget than an OS. If your company does not have those concerns, good on them and on you for being lucky to be in that spot. A lot of companies are not and that is where the scaling up proposition does work.

On 1/30/21 1:00 PM, Gena Makhomed wrote:

I can't use CentOS Stream - it is beta quality and has critical bugs. For example: https://bugzilla.redhat.com/show_bug.cgi?id=1913806

As far as I can tell:

systemd-nspawn is defaulting to a private user namespace, but no private network namespace, and that combination is not supported. If you configure a private network namespace, does that nspawn container start properly?

https://www.freedesktop.org/software/systemd/man/systemd.nspawn.html#%5BNetw...

I'm inferring some of this, so if you've already got private network namespace configured, that's probably not the cause.

On 1/30/2021 3:25 PM, Gena Makhomed wrote:

Jan 21 15:55:12 centos-stream systemd-nspawn[1235]: Failed to mount sysfs on /sys/full (MS_RDONLY|MS_NOSUID|MS_NODEV|MS_NOEXEC ""): Operation not permitted

appears systemd-nspawn is trying to access write an area not suppose to. probably / it can be a bug most likely upstream with systemd?

On 31.01.2021 1:51, Mike McGrath wrote:

I'm not sure we've ever really looked at systemd-nspawn from a subscription service point of view. For Docker and Podman, we've always viewed those containers as just processes running on the system (this is a notable difference from how VMs are viewed). Containers inherit access to subscription services via the host they're on. That's why UBI should see additional content available when it's running on a RHEL system as opposed to something like CentOS or Ubuntu.

The problem wouldn't be running systemd-nspawn content. The problem would be getting the content into the container you're building though honestly I've never used nspawn and I'm not even sure what storage format it uses.

systemd-nspawn by default uses the directory /var/lib/machines/test for storing the operating system tree of the container named "test".

Copying entitlements from host to systemd-nspawn container possible, as I understand, it is just a files located on predefined locations.

Solution for the related problem (I am not sure what this is legal): https://patrick.uiterwijk.org/blog/2016/10/6/rhel-containers-on-non-rhel-hos...

On 1/31/21 5:14 AM, Peter Meier wrote:

So since nobody yet showed that Red Hat is supporting systemd-nspwan container

To that point, Red Hat's Container Support Policy does not list systemd-nspawn as one of the supported engines.  There is a "solutions" article that suggests that nspawn should at least start a minimal container, but that may not apply to RHEL 8.  I can't tell.

https://access.redhat.com/articles/2726611

https://access.redhat.com/solutions/1533893

On Mon, Feb 1, 2021 at 3:14 PM redbaronbrowser via CentOS-devel centos-devel@centos.org wrote:

On Sunday, January 31, 2021 7:14 AM, Peter Meier peter.meier@immerda.ch wrote:

...

...

I can't use CentOS Stream - it is beta quality and has critical bugs. For example: https://bugzilla.redhat.com/show_bug.cgi?id=1913806 This bug is critical for me, because I use systemd-nspawn containers for production. I will continue to use CentOS Stream in the future, but only as the beta-tester, to see what new will be in the future minor release of Oracle Linux / Alma Linux / Rocky Linux.

[...]

And as a Stream user and contributor you can also add your use case to t_functional which in the end becomes gating for Stream. So you avoid future regression for your use case, although it is even not officially supported.

How? When?

I still see no method to submit a pull request against the official CI/CD t_function sets. I also have not seen an ETA to being able to do so.

Where is the example code of existing t_function sets?

Where is the style/coding guide that must be followed to get new t_functions accept?

The functional tests are stored here: https://git.centos.org/centos/t_functional

You can make pull requests against it there.

On Mon, Feb 1, 2021 at 5:32 PM redbaronbrowser redbaronbrowser@protonmail.com wrote:

On Monday, February 1, 2021 3:55 PM, Neal Gompa ngompa13@gmail.com wrote:

...

On Mon, Feb 1, 2021 at 3:14 PM redbaronbrowser via CentOS-devel centos-devel@centos.org wrote:

...

On Sunday, January 31, 2021 7:14 AM, Peter Meier peter.meier@immerda.ch wrote:

...

...

I can't use CentOS Stream - it is beta quality and has critical bugs. For example: https://bugzilla.redhat.com/show_bug.cgi?id=1913806 This bug is critical for me, because I use systemd-nspawn containers for production. I will continue to use CentOS Stream in the future, but only as the beta-tester, to see what new will be in the future minor release of Oracle Linux / Alma Linux / Rocky Linux.

[...] And as a Stream user and contributor you can also add your use case to t_functional which in the end becomes gating for Stream. So you avoid future regression for your use case, although it is even not officially supported.

How? When? I still see no method to submit a pull request against the official CI/CD t_function sets. I also have not seen an ETA to being able to do so. Where is the example code of existing t_function sets? Where is the style/coding guide that must be followed to get new t_functions accept?

The functional tests are stored here:https://git.centos.org/centos/t_functional

You can make pull requests against it there.

I was under the impression that the RHEL team was sitting on much more than this. It seem like there was a good chance I would duplicating efforts on tests already done internally if I tried to contribute right now.

What exists looks like the level of testing I would expect of a *downstream* distribution. The amount of commits over the last three months also seem like downstream distribution level.

If this is the complete offering from the RHEL team to make Stream an upstream usable by 95% or more of CentOS users then that is very discouraging.

My personal perspective is we are having to recreate something to the level of Wikipedia from scratch in 11 months but at least most of the articles beginning with Z have been written.

The other stuff is in Fedora under the Fedora CI banner. That will have much more of an impact when CentOS Stream 9 opens in three months. Most of those tests are in the Fedora Git server now: https://src.fedoraproject.org/projects/tests/%2A

Some extra tests are part of the package git repositories, like in the case of sudo: https://src.fedoraproject.org/rpms/sudo/blob/master/f/tests

But these things aren't available for CentOS Stream 8 and I'm not sure they ever will be, since they're being rewritten more or less from scratch and upstreamed into Fedora now for CentOS Stream 9.

On 02/02/2021 05:03, redbaronbrowser via CentOS-devel wrote:

On Monday, February 1, 2021 4:57 PM, Neal Gompa ngompa13@gmail.com wrote:

...

The other stuff is in Fedora under the Fedora CI banner.

That is fine but the messaging of what, where, when and how of Stream has been extremely poor. I can't find a reference to that on the CentOS blog or FAQ.

In fact, the Karsten Wade blog post was worded in a way that implied these tests were already being applied to Stream.

...

That will have much more of an impact when CentOS Stream 9 opens in three months.

Hopefully someone can walk me through this part.

So, we have been told the life cycle of Stream is 5 years.

Stream 8 was released September 24, 2019 so a period of 5 years should go at least to September 2024.

We will have both a Stream 8 and a Stream 9 from May 2021 to September 2024? And then Stream 9 will continue to May 2026?

I believe the 5 year starting point is from the release of RHEL 8 (e.g, May 2019), not the release of Stream 8. i.e, Stream runs for the 5 year Full Support period and ends when the underlying (downstream) product enters it's Maintenance Support phase.

https://access.redhat.com/support/policy/updates/errata

Should we expect a third Stream 10 to be added 18 months after May?

...

Most of those tests are in the Fedora Git server now: https://src.fedoraproject.org/projects/tests/*

Some extra tests are part of the package git repositories, like in the case of sudo: https://src.fedoraproject.org/rpms/sudo/blob/master/f/tests

But these things aren't available for CentOS Stream 8 and I'm not sure they ever will be, since they're being rewritten more or less from scratch and upstreamed into Fedora now for CentOS Stream 9.

Well, there have been Red Hat employees that stated in December that "enough information" had been provided for everyone to make their choice.

I made my choice at that point that I wanted to help prepare Stream 8 for the CentOS 8 termination date. I have no interest in Stream 9, there was nothing stated about it at the time we had "enough information." If Red Hat is unwilling to help greatly improve CI/CD for the remaining 3+ years of Stream 8, that is going to be extremely frustrating.

Am 02.02.21 um 13:25 schrieb Neal Gompa:

On Tue, Feb 2, 2021 at 7:22 AM Phil Perry pperry@elrepo.org wrote:

...

On 02/02/2021 05:03, redbaronbrowser via CentOS-devel wrote:

...

On Monday, February 1, 2021 4:57 PM, Neal Gompa ngompa13@gmail.com wrote:

...

The other stuff is in Fedora under the Fedora CI banner.

That is fine but the messaging of what, where, when and how of Stream has been extremely poor. I can't find a reference to that on the CentOS blog or FAQ.

In fact, the Karsten Wade blog post was worded in a way that implied these tests were already being applied to Stream.

...

That will have much more of an impact when CentOS Stream 9 opens in three months.

Hopefully someone can walk me through this part.

So, we have been told the life cycle of Stream is 5 years.

Stream 8 was released September 24, 2019 so a period of 5 years should go at least to September 2024.

We will have both a Stream 8 and a Stream 9 from May 2021 to September 2024? And then Stream 9 will continue to May 2026?

I believe the 5 year starting point is from the release of RHEL 8 (e.g, May 2019), not the release of Stream 8. i.e, Stream runs for the 5 year Full Support period and ends when the underlying (downstream) product enters it's Maintenance Support phase.

https://access.redhat.com/support/policy/updates/errata

Yes. That means the clock on CentOS Stream 9 starts when Red Hat Enterprise Linux 9 is GA (which would be in 2022). Thus, CentOS Stream 9 will be around for *six* years, not five.

Just a though - the full support phase between RHEL7 and RHEL8 is already not equal. The latter also make a difference between baseos and appstream. There is a chance that the next major RHEL will bring an update.

-- Leon

On Tue, Feb 2, 2021 at 10:26 PM Nico Kadel-Garcia nkadel@gmail.com wrote:

On Tue, Feb 2, 2021 at 7:25 AM Neal Gompa ngompa13@gmail.com wrote:

...

On Tue, Feb 2, 2021 at 7:22 AM Phil Perry pperry@elrepo.org wrote:

...

On 02/02/2021 05:03, redbaronbrowser via CentOS-devel wrote:

...

On Monday, February 1, 2021 4:57 PM, Neal Gompa ngompa13@gmail.com wrote:

...

The other stuff is in Fedora under the Fedora CI banner.

That is fine but the messaging of what, where, when and how of Stream has been extremely poor. I can't find a reference to that on the CentOS blog or FAQ.

In fact, the Karsten Wade blog post was worded in a way that implied these tests were already being applied to Stream.

...

That will have much more of an impact when CentOS Stream 9 opens in three months.

Hopefully someone can walk me through this part.

So, we have been told the life cycle of Stream is 5 years.

Stream 8 was released September 24, 2019 so a period of 5 years should go at least to September 2024.

We will have both a Stream 8 and a Stream 9 from May 2021 to September 2024? And then Stream 9 will continue to May 2026?

I believe the 5 year starting point is from the release of RHEL 8 (e.g, May 2019), not the release of Stream 8. i.e, Stream runs for the 5 year Full Support period and ends when the underlying (downstream) product enters it's Maintenance Support phase.

https://access.redhat.com/support/policy/updates/errata

Yes. That means the clock on CentOS Stream 9 starts when Red Hat Enterprise Linux 9 is GA (which would be in 2022). Thus, CentOS Stream 9 will be around for *six* years, not five.

Or.... a small miracle could occur, the mis-step of discarding point releases in favor of making all CentOS 8 users the beta users for RHEL, and CentOS go back to publishing point releases that match RHEL point releases.

This is not going to happen. Doing that would be contrary to Red Hat's goals for investing in CentOS in the first place, as they've already said over and over.

That was precisely what happened the last time Red Hat tried to discard point releases with "Red Hat 9" back in 2003. RHEL came out a few years later with point releases, and CentOS was developed to match.

Uhh, that's not what happened...?

Red Hat Linux was killed that year and split into two: Fedora Core and Red Hat Enterprise Linux.

Red Hat Linux != RHEL

Red Hat Enterprise Linux made service packs (which CentOS called point releases) regularly with infrequent releases, but Fedora Core just made new releases regularly instead.

-- 真実はいつも一つ！/ Always, there's only one truth!

On Wed, 3 Feb 2021 at 12:13, Lamar Owen lowen@pari.edu wrote:

On 2/2/21 10:26 PM, Nico Kadel-Garcia wrote:

...

Or.... a small miracle could occur, the mis-step of discarding point releases in favor of making all CentOS 8 users the beta users for RHEL, and CentOS go back to publishing point releases that match RHEL point releases. That was precisely what happened the last time Red Hat tried to discard point releases with "Red Hat 9" back in 2003. RHEL came out a few years later with point releases, and CentOS was developed to match.

The first 'pointless' release was Guinness (RHL 7), if I remember correctly. Nice bit of revisionism in your post, by the way, as the reality is that the CentOS 'point releases' came before RHEL's 'point releases.'

Yes that was the first one. RHL6 was going to be the first pointless release but there were too many howls of protest from Engineering against it. RHL 7 was the first boxed pointless and the plan was to try and engage in doing just updates for 1,2,3 but that turned into too much sticking in the mud compared to other boxed sets which were pushing they were faster to market than Red Hat Linux. So 8 became its own thing and then 9, and there were howls of protest from various people who had built their deployments around X being a major and Y being smaller changes.. however the kernel and other software were now moving at a rate where 8 engineers could not keep up with all the packages needed at different levels.

before Shrike (RHL 9) was released. A fun fact about Pensacola is, if I

remember correctly, that it carried the MAJOR version of 2.1 through seven update cycles; so you had the last update roll-up package RHEL 2.1U7 in 2005, although it was supported through the end of May 2009; there was never a RHEL 2.2, and RHEL 2.1U7 is not RHEL 2.7. I still

Yep.. the marketing reason was simple. The general IT manager rule for large deployments is NEVER deploy software which is 1.x or 2.0 . They will wait until 2.1 comes out. So like RHL 2.1, there was a RHEL-2.1 and yep.. people installed it a LOT more than RHEL-3 because it wasn't 3.1 . The general rule started to change after this where Update numbers were more important so large deployments wait until U3 [so if you had a new product and want to get it deployed as soon as it is out.. call it Foobar-2 Update3. You may find that you get various auditing checkmarks clicked right away.