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!