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).
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.
- Peter
On Wed, Jan 20, 2021 at 8:14 AM Mike McGrath mmcgrath@redhat.com 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).
This is exciting! I'm glad you folks are working to increase access and usability of RHEL for more people. :)
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
- Peter
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
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
On Wed, Jan 20, 2021 at 2:47 PM 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.
I am sending those responses. Folks who sent inquiries that were related to the announcements we made today should have gotten a response from me this morning, generally before the blog went live. I am, around calls today, working through the remaining questions with a response. Because we don't have all the programs complete, many of the emails are acknowledgements.
However, this is not the first time these emails have been read. We have been putting the data in them into the various program teams.
Probably not the correct topic to ask this question, but I simply didn't know where else to ask.
Here is great. And now you have a name/person to talk to as well.
Thank you.
regards,
bex
- Peter
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Wed, Jan 20, 2021 at 8:14 AM Mike McGrath mmcgrath@redhat.com 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.
THANK YOU!
This sounds like 90% of what CentOS users were really wanting in the extended email threads over the last weeks.
/me downloads RHEL8 to rebuild an aging home-use CentOS6 VM.
On 1/20/21 2:14 PM, 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... https://www.redhat.com/en/blog/new-year-new-red-hat-enterprise-linux-programs-easier-ways-access-rhel
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).
Hi. I am glad our relentless pestering was not for nothing, no-cost for small production use is what will appease many who did not already decided to switch to other distros (maybe even though who did not start to actually convert to other distro's). Based on comments about 'what to do next" some ~30% stated they will move to Debian/Ubuntu. I personally have only one personal web/mail server and the rest are Samba + Windows VM internal servers so I have to chose between TrueNAS that has ZFS + VM + excellent web config vs classical Linux server (at this point no-cost RHEL is real option).
And I guess with no-cost RHEL's after a while RHEL market share will rise and Red Hat will be able to see direct impact of no-cost production servers on market share.
I read announcement and few articles and comments on Facebook, and I have few comments and questions.
1. Wording of the blog article has left me confused what exactly "small-use production" means (exact definition) since no-cost license is tied to "Developer" license which is for next 10 days still "no production use". I had read it later somewhere on Red Hat site but the blog it self is not explicit enough. So make sure texts clearly state "Developer" status is only a legacy and production systems are allowed.
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.
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? Notice that with no-cost production licenses many who register will have no clue about registration process (on any distro) and you should make everything about registration and subscription as plain/simple as possible and explained as detailed as possible (during the registration should be best).
Am 21.01.21 um 12:04 schrieb Ljubomir Ljubojevic:
- 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."
-- Leon
On Thu, 2021-01-21 at 12:04 +0100, Ljubomir Ljubojevic wrote:
- 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
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:
- 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 21.01.21 um 12:04 schrieb Ljubomir Ljubojevic:
- 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 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:
- 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.
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:
- 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 Thu, Jan 21, 2021 at 6:04 AM Ljubomir Ljubojevic centos@plnet.rs wrote:
On 1/20/21 2:14 PM, 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... https://www.redhat.com/en/blog/new-year-new-red-hat-enterprise-linux-programs-easier-ways-access-rhel
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).
Hi. I am glad our relentless pestering was not for nothing, no-cost for small production use is what will appease many who did not already decided to switch to other distros (maybe even though who did not start to actually convert to other distro's). Based on comments about 'what to do next" some ~30% stated they will move to Debian/Ubuntu. I personally have only one personal web/mail server and the rest are Samba + Windows VM internal servers so I have to chose between TrueNAS that has ZFS + VM
- excellent web config vs classical Linux server (at this point no-cost
RHEL is real option).
And I guess with no-cost RHEL's after a while RHEL market share will rise and Red Hat will be able to see direct impact of no-cost production servers on market share.
The "no-cost RHEL's will still require registration. Registering every member of a cluster was always a burden for RHEL users. It was why, commercially, I urged my employers to buy generous bulk licenses, rip the registration tools the hell out, and use an internal RHEL mirror built with my published reposync tools to reduce the registration burden and to reduce bandwidth costs and *vastly* improve the performance of running "yum" to our corporate mirrors. It's what I expect to do with CentOS 8 stream, to generate locked internally mirrors for pointing to a stable point release. The tools are at https://github.com/nkadel/nkadel-rsync-scripts .
I read announcement and few articles and comments on Facebook, and I have few comments and questions.
- Wording of the blog article has left me confused what exactly
"small-use production" means (exact definition) since no-cost license is tied to "Developer" license which is for next 10 days still "no production use". I had read it later somewhere on Red Hat site but the blog it self is not explicit enough. So make sure texts clearly state "Developer" status is only a legacy and production systems are allowed.
The confusion may be deliberate. There have been various details of this whole mess with different interpretations, including from Red Hat and CentOS leadership.
- 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.
- 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.
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:
- 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...
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"?
Cheers,
Peter.
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.
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.
-- Leon
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...).
On Fri, Jan 22, 2021 at 08:53:54AM -0500, Neal Gompa wrote:
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...).
Yeah this is a use-case I've raised with the RHEL programs team.
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 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.
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.
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:
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.
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.
podman pull registry.access.redhat.com/ubi8
I am told by our container team that uploads to dockerhub are complicated for reasons I do not understand.
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.
josh
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_...
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 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_...
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
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 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_...
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?
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.
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
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?
On 1/23/21 4:46 PM, redbaronbrowser via CentOS-devel wrote:
On Saturday, January 23, 2021 8:04 AM, Strahil Nikolov hunter86_bg@yahoo.com wrote:
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?
I registered developer account few days ago and read notice that Developer version supports only latest versions...
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)
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
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 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.
josh
On Sunday, January 24, 2021 10:44 AM, Strahil Nikolov hunter86_bg@yahoo.com wrote:
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.
Thanks for looking into that for me.
RHEL 6 had 5.5 years of Mainstream Support during which it went from 6.0 to 6.7.
RHEL 6 had 3.5 years of Maintenance Support during which it went from 6.8 to 6.10.
The fact you are using the "Extended Update Support" being applied to 6.7 seems to indicate that subscription gave you access to the 3.5 year period to get you to 6.10.
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.
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 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.
You seem to have only gotten to GPL v2 Section 1.
If you continue to read on to GPL v2 Section 3, you will find:
"3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2"
So, it clearly indicates the section 1 right to redistribute verbatim copies is extended by section 3 to object/executable form.
If you talk to a member of the Free Software Foundation, you will find that compiling a program still creates a derivative work.
There is also legal precedent since Apple v. Franklin that the source code license also applies to the object code. The opcodes and values passed to those opcodes is another form of source code, just not the prefered format for modification.
So far the discussion has been if Red Hat should continue to offer update services after someone performs redistribution of the GPL covered derivative work. It has already been acknowledge Red Hat has the legal right to revoke update service but should reconsider that chilling effect on Copyleft fundamental values.
But Josh Boyer has taken the threat from Red Hat to the next level. It is nowm implied gcc and rpmbuild can take a GPL work and turn it 100% into Red Hat intellectual property independant of the GPL simply on the basis the derivative work is no longer considered by RH to be source code. That if someone redistributes Red Hat's "ownership" of bash they should expect a civil or criminal legal consequences. Or if they redistribute Red Hat's "ownership" of glibc they should expec the same legal consequences. Or redistribute of Red Hat's "ownership" of gcc...
The copyright of the contributors and the license they selected if being completely disregarded by Red Hat for all object code redistribution.
This level of threat against what the GPL covers is something I expected from Oracle but not Red Hat. This has now surpassed the scope of centos-devel and the Red Hat attack needs to be addressed on a multitude of forums of GPL contributors.
I withdraw my offer to seek guidance from the Free Software Foundation. There clearly is no common ground to work from.
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 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 Sunday, January 24, 2021 2: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.
josh
The statement "as a general reminder, the GPL and LGPL are source code licenses" is a clearly written threatening stance being taken by Red Hat.
It indicates Red Hat is disregarding all the sections of the GPL and LGPL dealing with object code, executables and derivative works.
The availablity of the source code is not being disputed or material.
With CentOS 8, I can take bash-4.4.19-12.el8.x86_64.rpm and redistribute it verbatim such that the digital signature can confirm it remains as-is. As long as I don't misrepresent use of the trademark of being anything more than a verbatim copy, the core values of Copyleft remain.
Mike McGrath has indicated as part of the transistion from CentOS 8 to RHEL 8 there exist a group of people that are "unentitled" to this GPL covered derivative work.
It may not be a change for RHEL, but it is a change for CentOS users.
It has been stated that if there are problems that can impact the ability of CentOS users to use the new RHEL offering then let Red Hat know as there would be additional changes announced on the 1st.
Well, I have let Red Hat know that putting a chilling effect and banning users for exercising the Copyleft redistribution terms is a problem for being able to use RHEL. The answer has made clear we should not expect this to be fixed on the 1st.
Instead, the clarification goes a step further with a harsh miltant stance against Copyleft.
Pointing out Red Hat continues to provide source code doesn't change the statement.
Here is what is important:
GPL covers derivative works.
Object code is a derivative work.
GPL covers object code.
Executables are a derivative work.
GPL covers excutables.
LGPL covers direct modifications creating derivative works.
Again, object code is a derivative work.
And again, executables are a derivative work.
Honoring the spirit of Copyleft does not ever restrict redistribution of a derivative work.
Red Hat can publish the source code to bash where ever it wants, the statement "as a general reminder, the GPL and LGPL are source code licenses" will still be invalid.
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 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
I recognized that you didn't directly make claims about the GPL and LGPL. That is why I asked for clarification.
But a discussion of mirroring RHEL packages for mock is very likely to include GPL and LGPL packages. The claims made still seem to indirectly apply to GPL/LGPL packages.
If I create a repo of mirrored packages that are all covered by the GPL/LGPL such as glibc-devel, does there exist a concept of "unentitled" people to that repo? I am not trying to take anything out of context, instead I am just following what logically the statement seems to apply to.
The issue of creating a mirror of specific GPL/LGPL covered packages for recreating a bug for building a project is not a hypothetical. I have actually done this with CentOS and my understanding has it is not in violation with any CentOS user agreement to have done so.
Since my request for clarification has simply been labeled as being in bad faith, I will try to get more counsel on the issue from sources external to Red Hat and report back.
On Sunday, January 24, 2021 7:13 PM, Mark Mielke mark.mielke@gmail.com wrote:
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:
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.
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.
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.
-- Mark Mielke mark.mielke@gmail.com
A lot of the issues we are seeing follows very closely with the transistion to Fedora during 2003/2004. Ensuring availability of the SRPMs wasn't ever an issue that exceeded the first year of Fedora.
I'm guessing this is an oversight and it will be resolved before 2022. I think the "announcements haven't change that" is a likely forword looking statement.
However, that isn't the only issue that seem to be forword looking statement phrased as if it has already been resolved. I doubt all those issues will be addressed by 2022.
Rich Bowen seem to be sincerely working on being open and transparent so we may eventually be able to track what issues Red Hat considers seriously and the status on how they are working to resolve them. (Including continued SRPM availablity without CentOS 8).
It is odd they never simply enabled SRPM access on the CentOS koji.
In the mean time, it seems like Red Hat is just gauging the community response on an announcement by announcement basis instead of having a clear roadmap. Again, much like RH did during the first year of Fedora. So what was the point of RH claiming they learned from mistakes they made with the community during the creation of Fedora then?
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.
On Sun, Jan 24, 2021, at 8:13 PM, Mark Mielke wrote:
On Sun, Jan 24, 2021 at 3:04 PM Josh Boyer jwboyer@redhat.com wrote:
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:
- RHEL packages are available in SRPM form from a public FTP site.
No longer the case. Now only accessible in git.
- RHEL EUS packages are available in SRPM form only to subscribers
with EUS subscriptions.
Correct. Also included with the Free Developer Program. (Very helpful for ensuring compatibility, IMO.)
- RHEL ELS packages are available in SRPM form only to subscribers
with ELS subscriptions.
These are not included with the Free Developer Subscription.
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.)
V/r, James Cassell
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 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, 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.
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
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.
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).
So in my opinion, they have already prepared for this with regards to git.centos.org, it will just continue as I described above.
But of course, this is just my personal opinion.
- Jake
On 1/24/21 12:28 PM, redbaronbrowser via CentOS-devel wrote:
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."
They have been straddling this fence since RHEL was first made, and, to the best of my knowledge, the RHEL subscription contract has not been tested in court (I've not combed PACER for it, though). Someone would have to violate their contract AND then have their subscription revoked due to breach of contract AND then sue Red Hat for the subscription termination. This would be a long, involved, and costly process. And this is the only way to really settle the issue of whether GPL prohibits restrictions on the redistribution of object code derivative works.
Back to the word you took exception to; in RHEL-speak, 'unentitled' means a server that doesn't have an 'entitlement' through subscription-manager. It doesn't refer to third-parties, but to the second party's server. That was the context for the use of the word, that of a server using the binary RPMs for mock buildroots but run by someone with a subscription. At least that was my understanding of the word given the context.
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 Mon, Jan 25, 2021 at 10:57 AM Mark Mielke mark.mielke@gmail.com wrote:
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.
-- Mark Mielke mark.mielke@gmail.com
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.
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.
-Mike
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 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
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 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,
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 5: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)
I think he's saying is that he's not sure yet how this will work out, but he's at least committing to everything existing in CentOS Stream Git trees at some point before release to RHEL, unless someone goofs up for some reason.
Given that Fedora 34 hasn't even been branched yet for Red Hat to start branching for CentOS Stream 9, I think that's about as concrete of a response as we're going to get for now.
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:00 PM Mike McGrath mmcgrath@redhat.com wrote:
On Mon, Jan 25, 2021 at 4:36 PM Leon Fauster via CentOS-devel < centos-devel@centos.org> wrote:
snip
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.
The above is *almost* English. Trying again.
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 is 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 - the best-case scenario is source being exactly as it is today. The worst-case scenario is I would have to look through the CentOS-Stream gitlab repo for specific versions I want as you've described above.
-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 1/25/21 8:56 PM, Mike McGrath wrote:
... 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.
Thanks for the quick reply. If I understand correctly, the idea is to move from RHEL point releases to a rolling distro inside a major point release, powered by CI/CD automated tests to ensure that any point in time, any commit, will be ready to ship (or at least tagged commits, which I guess official RHEL packages would be built from)? Then rebuilds would only have to checkout a specific tag and rebuild?
As long as point releases exist, I think it would make sense to run RHEL in production and CentOS Stream on testing machines, to get advanced notice if something is going to break in the next point release and be able to file bugs. With a rolling model, this time difference would become much smaller. Would there still be an equivalent of EUS is such a rolling model, allowing an organization to get security updates until bugs in backported features are sorted out?
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 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.
--Rich
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?
On 1/26/21 6:34 PM, redbaronbrowser via CentOS-devel wrote:
For the CentOS Dojo, was Hopin Ltd. selected by FOSDEM or is it only being used specifically for the Dojo?
I'm actually not aware of what platform FOSDEM is using. Red Hat OSPO (Open Source Program Office) has a Hopin account and is letting us use that. Also, I used Hopin to run the recent ApacheCon event for the Apache Software Foundation, so I have some experience with how it works.
--Rich
On 20.01.2021 15: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).
I have same questions.
This is copy of my email to centos-questions@redhat.com
==============================================================================
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?
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???
And I can't have more than 16 instances (bare metal + VMs + containers) with a RHEL subscription?
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?
==============================================================================
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?
More details here:
- https://www.oracle.com/linux/
- https://linux.oracle.com/switch/centos/
==============================================================================
[...]
On Thu, Jan 28, 2021 at 6:22 AM Gena Makhomed gmm@csdoc.com wrote:
On 20.01.2021 15: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).
I have same questions.
This is copy of my email to centos-questions@redhat.com
==============================================================================
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?
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???
And I can't have more than 16 instances (bare metal + VMs + containers) with a RHEL subscription?
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?
==============================================================================
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.).
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.
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.
[1]: https://podcast.asknoahshow.com/216?t=1877
-- 真実はいつも一つ!/ Always, there's only one truth!
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: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.
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!
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
On Thu, Jan 21, 2021 at 8:06 AM Mike McGrath mmcgrath@redhat.com wrote:
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:
- 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-...
-Mike
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
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:
==============================================================================
[...]
-- 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 Thursday, January 28, 2021 2:55 PM, Gena Makhomed gmm@csdoc.com wrote:
On 28.01.2021 14:54, Neal Gompa wrote:
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 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.
However, I don't believe Stream will always be like that. The key question should be when will we be able to see the existing CI/CD test code and when can we issue pull requests?
I would have liked to have seen a CentOS transistion critera established at the Nov 11th board meeting instead of a hard CentOS 8 termination date. If easier access to RHEL, gitlab and CI/CD access had all been completed *BEFORE* announcing the CentOS 8 end date, I think it would have been recieved better. Then when the criteria was reached start the 12 month clock to kill CentOS 8.
Of course, that is not what happened. So, while I am sure community access to improve CI/CD testing could bring Stream out of a beta like state eventually, I don't know if that can be accomplished by the end of the year. There is a lot of work to do.
If we can't get Stream in better shape in time for the C8 beheading, I would completely understand if you look at alternatives to Stream.
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.
John
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
Am 28.01.21 um 23:12 schrieb Trevor Hemsley via CentOS-devel:
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/
Its fewer AFTER "full support phase" but then Stream (for the current major release) is not anymore ...
-- Leon
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 Thu, Jan 28, 2021 at 4:15 PM Neal Gompa ngompa13@gmail.com wrote:
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.
Using the "RHEL beta" increases the risks of a bleeding edge kernel change disable your systems. Been there, done that.
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.
I anticipate that many will not leave CentOS 7, or Amazon Linux 2.
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".
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?
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.
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.
As I understand, there are only two available options for me:
1) Migrate to Oracle Linux, Alma Linux, Rocky Linux.
2) Migrate to Ubuntu / Debian / some other distro.
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 11:17:13AM +0200, Gena Makhomed wrote:
So, as I understand, all decisions about killing CentOS were made not by Red Hat, but by the top managers of IBM.
You understand wrong. There is zero indication whatsoever this was an IBM move.
Could we please move beyond the FUD and BS already?
John
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.
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?)
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.
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 Fri, Jan 29, 2021 at 08:20:48PM +0200, Gena Makhomed 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?)
This is not an official response. Just some thoughts.
I don't think there is anything specifically forbidding this, but I think it's pretty easy to tell that it _feels_ kind of off. I mean, the whole fact that you're speculating about such a scheme as a possible way to skirt the intent says you feel that too. Like I said to someone asking about one person person registering many different accounts with different emails, there's some degree of just plain expecting people to play nice.
As far as problems with the plan, aside from the overhead of managing it all, I think there's a pretty good argument that if the actual subscriptions aren't _actively managed_ by those 128 employees but instead handled centrally in their name only, that's probably actually cheating not just "smells cheaty".
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.
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:
- 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.
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.
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 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.
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 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 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?
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.
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.
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 Fri, Jan 29, 2021 at 8:51 PM redbaronbrowser via CentOS-devel centos-devel@centos.org wrote:
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.
I want to reiterate what Matthew said. He's right. Don't read into my interviews that you've seen published as us pushing RHEL over CentOS Stream. Interviews result in pieces that are what the journalist wanted to write about. If they want to write about RHEL, they ask questions about RHEL and I answer about RHEL. if someone wants to write about CentOS Stream then they'd get CentOS Stream answers.
regards,
bex
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.
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
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 Sat, Jan 30, 2021 at 2:49 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.
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".
The $800 "Standard Server" license - I believe this is the one that supports either 1 physical, or 2 VM... which helps a bit if you are calculating cost. It brings down the per-VM cost to $400, and at scale a small discount might apply... perhaps $350 USD/year after discount. But, if you need EUS - then it increases again as an optional add-on cost, so back up to $475+ USD/year per VM.
You may be able to negotiate for the $2500 "Red Hat Enterprise Linux for Virtual Datacenters" license to cover your whole physical host, whether or not you are running a certified hypervisor or container technology. Lots of fine print around what support would look like in such a scenario, but you may be able to pitch it.
Once you add it all up, it still ends up being a problem at scale. For smaller deployments - it's fine. It is the break-even point where you have to have your own support + development stuff anyways, that the proposition really starts to break down.
On 29.01.2021 20:35, Matthew Miller 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?)
This is not an official response. Just some thoughts.
I don't think there is anything specifically forbidding this, but I think it's pretty easy to tell that it _feels_ kind of off. I mean, the whole fact that you're speculating about such a scheme as a possible way to skirt the intent says you feel that too. Like I said to someone asking about one person person registering many different accounts with different emails, there's some degree of just plain expecting people to play nice.
As far as problems with the plan, aside from the overhead of managing it all, I think there's a pretty good argument that if the actual subscriptions aren't _actively managed_ by those 128 employees but instead handled centrally in their name only, that's probably actually cheating not just "smells cheaty".
Matthew, thank you for the detailed answer.
Since I manage more than 16 bare metal servers / virtual machines - now I understand that I shouldn't even try to use no-cost RHEL for production. And the only available option for me is migration to the Oracle Linux / Alma Linux / Rocky Linux / Debian / Ubuntu.
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 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.
We are a small company and website hosting is low-margin business, so we can't buy RHEL for each bare metal server / virtual machine.
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.
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 31.01.2021 0:57, Gordon Messmer wrote:
systemd-nspawn is defaulting to a private user namespace, but no private network namespace, and that combination is not supported.
This is not true. By default systemd-nspawn creates private user namespace and private network namespace.
See /usr/lib/systemd/system/systemd-nspawn@.service on the CentOS 8 / CentOS Stream 8 and the man page for more details: https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html
If you configure a private network namespace, does that nspawn container start properly?
This is not systemd-nspawn issue, because all works fine with CentOS 8.3 kernel. And broken with CentOS Stream 8 kernel. This is CentOS Stream 8 kernel regression.
System journal fragment:
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
On Sat, Jan 30, 2021 at 4:57 PM Gordon Messmer gordon.messmer@gmail.com wrote:
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.
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.
-Mike
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/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?
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.
What you are facing is a typical issue of moving things forward and just because something worked in the past doesn't mean it will always work in the future. This is why you are testing and this is why Red Hat is testing their supported use cases.
If you have a RHEL subscription and Red Hat says they are supporting systemd-nspwan containers, they would very likely test it and thus the regression would already have been detected. Red Hat always says they per se don't support something that is not tested.
But what are your options now, if it is not supported and thus not tested and hence won't work in RHEL 8.4 and thus not in CentOS 8.4, nor OL 8.4, nor Alma or Rocky 8.4 (since they all inherit the bugs from RHEL). Where would you open a bug report and hope to get it fixed (for free)?
If you have a RHEL subscription you could open a support case and likely have more weight to get it fixed.
If you are Streams User, you can early detect that something *you* depend on is not covered by Red Hat's test suite (maybe because it is not - yet ? - supported by Red Hat), open a bug report in Red Hat's bugzilla (as you did) and thus it is way more likely to get some attention than in a OEL, Rocky or Alma bug tracker where none of the RHEL engineers is looking at (why should they?).
If you are on OL, Alma or Rocky and you are facing the bug when updating to 8.4 (still assuming since Red Hat is not supporting it and thus they don't test it and thus won't detect it before you do), what would be your options? How would you get it fixed? What would you do until it is fixed in 8.5 or 8.6? And the same thing you would there, you can also do for Stream. So I don't see much value in moving to these rebuilds, except that you get exposed to bugs much later, bugs that will likely not be fixed, as it's a regression in a unsupported feature.
And if Red Hat would not have done the strategic decision to move to Stream, you would be exactly in the same situation with CentOS Linux as you will in the future with Alma, Rocky and Oracle.
So since nobody yet showed that Red Hat is supporting systemd-nspwan containers and thus it is indeed a regression they should really not put into Stream, I would refuse to follow your logic of calling Stream Beta due to a regression for a use case that was never supported.
However, having you using Stream and reporting regression in unsupported features might in the end make Stream, RHEL and all their rebuilds much better supported.
Thus I think it's a good thing and it's also good you are reporting these things.
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.
But calling Stream Beta just because of a regression in a unsupported future?
~pete
El mié, 20 ene 2021 a las 10:14, Mike McGrath (mmcgrath@redhat.com) escribió:
- Available no later than February 1
Today is January 31, isn't it?..... :-)
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.
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
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 Mon, Feb 1, 2021 at 11:26 AM Sergio Belkin sebelk@gmail.com wrote:
El mié, 20 ene 2021 a las 10:14, Mike McGrath (mmcgrath@redhat.com) escribió:
- Available no later than February 1
Today is January 31, isn't it?..... :-)
The new terms are live as of an hour or two ago. I just used a personal account to verify I could download and register. It's installing via Red Hat's CDN as I type. New "16 production server" terms can be found here:
https://www.redhat.com/wapps/tnc/viewterms/72ce03fd-1564-41f3-9707-a09747625...
-Mike
On Mon, Feb 01, 2021 at 01:30:20PM -0600, Mike McGrath wrote:
The new terms are live as of an hour or two ago. I just used a personal account to verify I could download and register. It's installing via Red Hat's CDN as I type. New "16 production server" terms can be found here:
https://www.redhat.com/wapps/tnc/viewterms/72ce03fd-1564-41f3-9707-a09747625...
Yep, same here. I used my existing personal account (created back before I joined Red Hat), and logged in at https://developers.redhat.com/register. This made me agree to some terms and then dropped me at https://developers.redhat.com/confirmation. Having done that, at https://access.redhat.com/management/subscriptions I see that I now have a Red Hat developer subscription. Cool.
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?
But calling Stream Beta just because of a regression in a unsupported future?
I find your logic hard to follow for this specific "unsupported feature."
The prefer way of using modern mock is use of nspawn. The prefer method of using mock with koji uses nspawn.
To be more specific, as far as I can tell I can take CentOS 8.0 as the basis for a koji environment and use it with mock using nspawn to build CentOS 8.0 updates and CentOS 8.1 packages.
I can then update the environment to CentOS 8.1 and still use it to build CentOS 8.1 updates and CentOS 8.2 packages.
I can then update the environment to CentOS 8.2 and still use it to build CentOS 8.2 updates and CentOS 8.3 packages.
I can then update the environment to CentOS 8.3 and still use it to build CentOS 8.3 updates.
If I then update to build servers to Stream, there is a problem with that foundational component that was previously working on the build servers.
The idea that RHEL team would treat this as unsupported and release it regardless as part of RHEL 8.4 does not sound correct to me.
The idea that clones would also break their own koji environment and never provide support to get them working again also does not sound correct to me. At some point the clones would release some sort of "plus" kernel with a fix to address their own build environments and that of their users.
For a regression in a component this valuable to modern koji setups to exist does indicate to me that Stream is still, as of today, in a beta/rawhide like state.
As you pointed out, we should expect CI/CD to address this issue. But that will be over some length of **time** and December 31, 2021 is a *HARD* target.
It would just be really nice to also have a hard deadline for being able to contribute to the CI/CD test as well. I foresee next January being the month when several users will give Stream a single chance to pass or fail on their own criteria. Several might be even more strict than we are being today. I want to have Stream in a condition that allows it to put it's best foot forward by that date.
Karsten Wade implied CI/CD will make Stream usable for 95% of current CentOS users. I would like to believe that but what I am seeing still has *ALOT* of work to do. And there does not seem to be a hard deadline for when the community can contribute to CI/CD, only a hard deadline for CentOS 8.
We are now 20% of the way between November 11, 2020 and December 31, 2021. Even if you feel calling Stream today "beta" is unfair, are you really willing to say that we are 20% or more of the way done to getting Stream to the best possible state to encourage adoption by 95% of existing CentOS users?
To be clear, I am not trying to trash-talk Stream. Rather I see a miscommunication in where we are today and how/when we are going to move forward. Step one of fixing a problem is admitting you have one.
On Monday, February 1, 2021 1:30 PM, Mike McGrath mmcgrath@redhat.com wrote:
On Mon, Feb 1, 2021 at 11:26 AM Sergio Belkin sebelk@gmail.com wrote:
El mié, 20 ene 2021 a las 10:14, Mike McGrath (mmcgrath@redhat.com) escribió:
- Available no later than February 1
Today is January 31, isn't it?..... :-)
The new terms are live as of an hour or two ago. I just used a personal account to verify I could download and register. It's installing via Red Hat's CDN as I type. New "16 production server" terms can be found here:
https://www.redhat.com/wapps/tnc/viewterms/72ce03fd-1564-41f3-9707-a09747625...
Is there any plans to change "Try it free" on this page: https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux
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?
On Mon, Feb 1, 2021 at 2:18 PM redbaronbrowser via CentOS-devel < centos-devel@centos.org> wrote:
On Monday, February 1, 2021 1:30 PM, Mike McGrath mmcgrath@redhat.com wrote:
On Mon, Feb 1, 2021 at 11:26 AM Sergio Belkin sebelk@gmail.com wrote:
El mié, 20 ene 2021 a las 10:14, Mike McGrath (mmcgrath@redhat.com) escribió:
- Available no later than February 1
Today is January 31, isn't it?..... :-)
The new terms are live as of an hour or two ago. I just used a personal account to verify I could download and register. It's installing via Red Hat's CDN as I type. New "16 production server" terms can be found here:
https://www.redhat.com/wapps/tnc/viewterms/72ce03fd-1564-41f3-9707-a09747625...
Is there any plans to change "Try it free" on this page: https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux
I'm not aware of any, and even if you click on that it offers a free trial which seems a bit moot to me. I'll leave that to the people who run the websites though. I know they've got plans but don't know what it would mean for any sort of trial or "try it out" type verbiage.
-Mike
On 01/02/2021 20:44, Matthew Miller wrote:
On Mon, Feb 01, 2021 at 01:30:20PM -0600, Mike McGrath wrote:
The new terms are live as of an hour or two ago. I just used a personal account to verify I could download and register. It's installing via Red Hat's CDN as I type. New "16 production server" terms can be found here:
https://www.redhat.com/wapps/tnc/viewterms/72ce03fd-1564-41f3-9707-a09747625...
Yep, same here. I used my existing personal account (created back before I joined Red Hat), and logged in at https://developers.redhat.com/register. This made me agree to some terms and then dropped me at https://developers.redhat.com/confirmation. Having done that, at https://access.redhat.com/management/subscriptions I see that I now have a Red Hat developer subscription. Cool.
I thought (maybe wrong) that it was said that it doesn't need to create an account , but just logging in with one from github or other recognized social media would work ?
Or is that the process ? create a new profile (through "developers.redhat.com/register") and then agree to the terms ?
Just curious
On Mon, Feb 01, 2021 at 09:52:56PM +0100, Fabian Arrotin wrote:
I thought (maybe wrong) that it was said that it doesn't need to create an account , but just logging in with one from github or other recognized social media would work ?
Or is that the process ? create a new profile (through "developers.redhat.com/register") and then agree to the terms ?
There is single-sign-on with:
* Github * Stack Exchange * Linked In * Twitter * Facebook * Google * Windows
although I have not tried it. (Well, I did try it, but it already knew that my twitter account was associated with my RH one, so that didn't prove anything useful except that log-in through that will work.)
This _will_ create an account, in any case — you just can use the external auth provider. You'll need the account to manage your subscription, after all.
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 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.
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 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?
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.
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.
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.
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.
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.
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
El lun, 1 feb 2021 a las 17:31, Mike McGrath (mmcgrath@redhat.com) escribió:
On Mon, Feb 1, 2021 at 2:18 PM redbaronbrowser via CentOS-devel < centos-devel@centos.org> wrote:
On Monday, February 1, 2021 1:30 PM, Mike McGrath mmcgrath@redhat.com wrote:
On Mon, Feb 1, 2021 at 11:26 AM Sergio Belkin sebelk@gmail.com wrote:
El mié, 20 ene 2021 a las 10:14, Mike McGrath (mmcgrath@redhat.com) escribió:
- Available no later than February 1
Today is January 31, isn't it?..... :-)
The new terms are live as of an hour or two ago. I just used a personal account to verify I could download and register. It's installing via Red Hat's CDN as I type. New "16 production server" terms can be found here:
https://www.redhat.com/wapps/tnc/viewterms/72ce03fd-1564-41f3-9707-a09747625...
Is there any plans to change "Try it free" on this page: https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux
I'm not aware of any, and even if you click on that it offers a free trial which seems a bit moot to me. I'll leave that to the people who run the websites though. I know they've got plans but don't know what it would mean for any sort of trial or "try it out" type verbiage.
-Mike
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Ok, I've just registered, what does mean "Try it" at https://developers.redhat.com/products/rhel/download ? Is that "Try it and then pay" or "try during a trial-period"?
Thanks in advance
On Tue, Feb 2, 2021 at 8:50 AM Sergio Belkin sebelk@gmail.com wrote:
El lun, 1 feb 2021 a las 17:31, Mike McGrath (mmcgrath@redhat.com) escribió:
On Mon, Feb 1, 2021 at 2:18 PM redbaronbrowser via CentOS-devel < centos-devel@centos.org> wrote:
On Monday, February 1, 2021 1:30 PM, Mike McGrath mmcgrath@redhat.com wrote:
On Mon, Feb 1, 2021 at 11:26 AM Sergio Belkin sebelk@gmail.com wrote:
El mié, 20 ene 2021 a las 10:14, Mike McGrath (mmcgrath@redhat.com) escribió:
- Available no later than February 1
Today is January 31, isn't it?..... :-)
The new terms are live as of an hour or two ago. I just used a personal account to verify I could download and register. It's installing via Red Hat's CDN as I type. New "16 production server" terms can be found here:
https://www.redhat.com/wapps/tnc/viewterms/72ce03fd-1564-41f3-9707-a09747625...
Is there any plans to change "Try it free" on this page: https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux
I'm not aware of any, and even if you click on that it offers a free trial which seems a bit moot to me. I'll leave that to the people who run the websites though. I know they've got plans but don't know what it would mean for any sort of trial or "try it out" type verbiage.
-Mike
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Ok, I've just registered, what does mean "Try it" at https://developers.redhat.com/products/rhel/download ? Is that "Try it and then pay" or "try during a trial-period"?
Thanks in advance
Just means try it. Go ahead and download it, register it, and you're in the program! There's no second step to that and you can keep using it. The developer program requires you to renew annually (it is free).
-Mike
--
Sergio Belkin LPIC-2 Certified - http://www.lpi.org _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Mon, 2021-02-01 at 16:00 -0500, Matthew Miller wrote:
On Mon, Feb 01, 2021 at 09:52:56PM +0100, Fabian Arrotin wrote:
I thought (maybe wrong) that it was said that it doesn't need to create an account , but just logging in with one from github or other recognized social media would work ?
Or is that the process ? create a new profile (through "developers.redhat.com/register") and then agree to the terms ?
There is single-sign-on with:
- Github
- Stack Exchange
- Linked In
- Windows
Can we use FAS for single-sign-on? :)
Jonathan
On Tue, Feb 02, 2021 at 10:21:52PM +0000, Jonathan Dieter wrote:
Can we use FAS for single-sign-on? :)
Good question! I'll ask!
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.
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. 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.
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.
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!
W dniu 01.02.2021 o 16:55, Marcin Juszkiewicz pisze:
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.
I do wonder which way to go now. Both are similar.
UBI:8 way:
11:21 (0s) hrw@puchatek:~$ docker run --rm -it -u root registry.access.redhat.com/ubi8
[root@1dcf18241722 /]# dnf remove -y subscription-manager
[root@1dcf18241722 /]# dnf install -y http://mirror.centos.org/centos/8-stream/BaseOS/x86_64/os/Packages/centos-gp...
[root@1dcf18241722 /]# dnf install -y http://mirror.centos.org/centos/8-stream/BaseOS/x86_64/os/Packages/centos-st...
[root@1dcf18241722 /]# dnf distrosync -y Transaction Summary ================================================================ Install 17 Packages Upgrade 79 Packages
Total size: 58 M Total download size: 48 M
CentOS:8 way:
11:25 (0s) hrw@puchatek:~$ docker run --rm -it -u root centos:8
[root@868f8bd7dd05 /]# dnf install centos-release-stream -y [root@868f8bd7dd05 /]# dnf swap centos-{linux,stream}-repos -y [root@868f8bd7dd05 /]# dnf distrosync
Transaction Summary ================================================================ Install 29 Packages Upgrade 85 Packages
Total download size: 73 M
On 2/1/21 3:26 PM, redbaronbrowser via CentOS-devel wrote:
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?
All of the content will be published to YouTube. YouTube has a pretty decent auto-subtitle functionality that you can turn on when you're watching. I've been very pleased with it.
I assume Hopin is similar to Jitsi with a real-time chat window that someone could transcribe into?
There is a chat window, but I don't have anybody who will be doing real-time transcription.
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?
We did. The advantage of Hopin is that we don't have to stand up a server and maintain it and provide it with bandwidth. We continue to evaluate alternatives, but at this time we're not really considering self-hosting, even though we are aware that Jitsi is open source.
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/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.'
RHEL went with 'update rollup' numbering for a long while (up through 4U9), but the CentOS trees just replaced the U with a . instead; it's not been that long ago since that was finally retired at the end of ELS for RHEL 4U9 in 2017, although CentOS never had the ELS SRPMs to rebuild. So there was never a 'RHEL 3.1;' there was RHEL 3 Update 1 (3U1), up through RHEL 4U9. Yes, that is a bit of a semantic hair-splitting, but hear me out here....
It also wasn't a hard cutover where one day we had Red Hat Linux 9 and the next day we had Red Hat Enterprise Linux 3; RHEL (in the form of RHL 6.2E (which could be considered RHEL 1, even though it wasn't called that) and RHAS 2.1 "Pensacola") had been around for a bit prior to Shrike. Taroon (RHEL 3) came after Ca^H^HSevern, but Pensacola was released shortly after Ham^H^H^HSkipjack, in March 2002, a full year 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 have a CentOS 2.1 VM running some internal code that had been running on RHL 5.2 up until three or four years ago (that RHL 5.2 box ran for almost twenty years). (Most of this information is available at https://access.redhat.com/articles/3078 although RHL 6.2E doesn't make that page; also see https://docs.fedoraproject.org/en-US/quick-docs/fedora-and-red-hat-enterpris... )
So Red Hat taking a year to get its toes wet and figure out what to do isn't a new thing; RHEL releases overlapped 'regular' RHL releases for three years if you count Red Hat Linux Enterprise Edition 6.2E as 'RHEL 1,' which was GA on 2000-03-27; Shrike (RHL 9) went GA on 2003-03-31, although Cam^H^H^HSevern (the supposed RHL 10 beta) went public beta 2003-07-21; Taroon (RHEL 3) didn't go GA until 2003-10-22. It took Red Hat that long to make the tough decision to get out of the 6-month-cycle retail boxed set space.
Back to the versioning, originally the 'RHEL Y Update X' releases were considered (at least by me) as 'update rollups' (Windows-speak: Service Packs or just see MS' definitions at https://docs.microsoft.com/en-us/troubleshoot/windows-client/deployment/stan... ) and not 'point releases;' it wasn't until RHEL 5 that they really can be considered 'point releases' if I remember correctly. And I always reserve the right to be wrong, or to mis-remember things, but I'm using my private archives of several mailing lists, public and private, for source material here, as well as the two histories I've linked to above. Updating was pretty primitive back then, and it had not been long since the first version of 'up2date' had been released. Having 'update rollups' released on CD is convenient, especially for new installs, rather than install the GA and slog through all the updates to get up to the current update set.
But with 5.x through 8.x Red Hat seems to have yielded to the 'point release' model, and the pattern changed somewhat relative to what had been the case with RHEL 4Ux, with much more major changes happening in early 'minor versions' (which is what I take 'point release' to mean, instead of just being my perception of the original 'update rollup' model where there aren't really 'minor versions' in this sense). So your 'few years' is technically correct for RHEL.
HOWEVER, the CentOS releases always had the confusing 'point' in them (see vault.centos.org's directory tree). BUT, the Red Hat FTP site with the source RPMs have neither point releases nor Update numbers visible anywhere; you have the GA SRPMS and the updates SRPMS (all of them, not just the latest version, stuffed into a single directory). There is NO tag to show, in the updates tree, which update (or point release) had what SRPM. You can look for yourself; that FTP site is still up and still has the historical SRPMs in it; the base directories are http://ftp.redhat.com/pub/redhat/linux/updates/enterprise/ and http://ftp.redhat.com/pub/redhat/linux/enterprise/%C2%A0 (for regular RHL everything is at http://archive.download.redhat.com/pub/redhat/linux/ ). CentOS 2.1 is a special case in this regard; CentOS 3.1 should really be considered the starting point; there is no CentOS 3.0.
So CentOS Stream, other than only containing the latest RPMS, follows right in the footsteps of RHEL's SRPMS distribution pattern that's been from the very beginning; if all you have are the RHEL SRPMS there are NO point releases to be seen anywhere. This 'pointless-ness' is NOT really a change in direction for RHEL; it is a change in CentOS users' (and later RHEL users, VARs, and software/hardware vendors) assumptions about 'point releases' that were addressed (at least an attempt was made to address the assumptions) by the CentOS 7 'pointless' versioning that everybody got riled up about.
It is understandable that people want a reference point for support; a rolling release model makes that difficult, and thus 'point releases' to provide such a reference point becomes SOP, even if that 'point release' is horribly out of date and insecure, but has the shared-library link-print that the software or hardware needs.
I welcome informed corrections and additions to what I've written here; I was an observer during this time for the most part, not a 'doer' of any rebuild itself, and my perspective is biased a bit by that point of view, I'm sure.
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.
... snipped the rest because I am in agreement with what was written.
It is understandable that people want a reference point for support; a rolling release model makes that difficult, and thus 'point releases' to provide such a reference point becomes SOP, even if that 'point release' is horribly out of date and insecure, but has the shared-library link-print that the software or hardware needs.
I welcome informed corrections and additions to what I've written here; I was an observer during this time for the most part, not a 'doer' of any rebuild itself, and my perspective is biased a bit by that point of view, I'm sure.
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Fri, 2021-01-29 at 23:09 +0000, 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?
Rich already linked to the latest talk below. I had a more recent one at SCALE 18x that went in a bit more detail but the recording was botched. I will be talking about CentOS Stream at FB specifically at DevConf.cz later this month: https://devconfcz2021.sched.com/event/gmOa/centos-stream-at-facebook
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.
We do "rolling OS updates". We keep dated snapshots of the repo and whenever we do an update we shard a change to dnf.conf to include the repo with the new snapshot and run 'dnf upgrade' from Chef. We test this on a few machines and then (slowly) roll it across the fleet over a couple of weeks. Sometimes we might have to add a quirk or two to the Chef recipe that manages the upgrade, but it generally works pretty well. None of this is specific to Stream: we'd been doing this with CentOS 6 and 7 as well (and you can find older talks I gave where we cover it). With Stream it's just easier as there's only one repo in play, instead of having to track "updates" and then resync the main repo whenever a point release is cut.
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.
We do keep the dated snapshots around, but we never rollback updates. If something goes wrong we stop the rollout, fix it (often with some logic in Chef) and resume the rollout.
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.
Cheers Davide
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:
On Wed, Feb 3, 2021 at 7:27 PM Davide Cavalca via CentOS-devel centos-devel@centos.org wrote:
We do "rolling OS updates". We keep dated snapshots of the repo and whenever we do an update we shard a change to dnf.conf to include the repo with the new snapshot and run 'dnf upgrade' from Chef. We test
And... this is why I publish tools for reposync and rsync based mirroring of RHEL or CentOS repositories. CentOs is a bit easier due to being able to use "rsync" and get associated ISO or PXE images. reposync has a mild advantage in mapping a particular state of the dns repository.
On 2/3/21 1:44 PM, Stephen John Smoogen wrote:
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.
It's hard to believe it was ever small enough that 8 engineers could keep up at all; we're long past the days when a whole release fit on a single 650MB CD. You guys did a great job in those early days!
...A fun fact about Pensacola is, if I remember correctly, that it carried the MAJOR version of 2.1 through seven update cycles; ...
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
Oh, that is rich! As I recall people were even happier when it hit x.2, the 'real stable' release. It threw everybody off-guard when RHL 7.3 released.... People are funny, no? Explains RHL 6.2E, too. I had often wondered why RHEL 2.1, now I know. Thanks for that!
On 2/4/21 4:54 PM, Lamar Owen wrote:
On 2/3/21 1:44 PM, Stephen John Smoogen wrote:
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.
It's hard to believe it was ever small enough that 8 engineers could keep up at all; we're long past the days when a whole release fit on a single 650MB CD. You guys did a great job in those early days!
...A fun fact about Pensacola is, if I remember correctly, that it carried the MAJOR version of 2.1 through seven update cycles; ...
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
Oh, that is rich! As I recall people were even happier when it hit x.2, the 'real stable' release. It threw everybody off-guard when RHL 7.3 released.... People are funny, no? Explains RHL 6.2E, too. I had often wondered why RHEL 2.1, now I know. Thanks for that!
Down the memory lane: https://imgur.com/a/e427iy0
Used since spring of 2000 when a Redhater gifted it to me.
On 2/4/21 10:51 AM, Manuel Wolfshant wrote:
Down the memory lane: https://imgur.com/a/e427iy0
Used since spring of 2000 when a Redhater gifted it to me.
Memory lane is not a bad place to revisit every once in a while. It makes me remember why I got into this craziness in the first place. I bought the RH 4.2 edition of Powertools (6 CD set) as my first purchased RHL, and still have it.... I still have the RHL 5.2 CD's, mainly because up until 2018 I had an old RHL 5.2 machine running, and kept the CDs and the boot floppy just in case rescue was needed. Later copies I either got as part of the beta team or via Cheapbytes.