Entitlement without enforcement: how ELM handles content access

Contributors

Brady Dibble, Director of Product Marketing

On CIQ Enterprise Linux Manager (ELM), you resolve entitlement once, at your mirror. Your subscription authenticates against CIQ Depot at sync time, and every host afterward installs from that mirror. That is true at 200 hosts and at 20,000, because entitlement resolves upstream of your fleet.

Every content view you build inherits entitlement from one Depot sync, and so does every host that installs from the view.

Give entitlement one place to resolve

Depot, the CIQ service your RLC Pro subscription authenticates against, governs which repositories you can mirror. You point ELM at Depot with your credentials, sync those repositories onto your own mirror, and curate content views out of them. Your host groups install from a published view.

Enterprise Linux entitlement covers the Depot share of that mirror. Your own internal repositories and open repositories such as Extra Packages for Enterprise Linux (EPEL) sync on the same schedule, and a content view draws from all three sources as one catalog. Mirroring accepts any RPM-based distribution, while curation, dependency resolution, and errata target Enterprise Linux content only.

What does a host check before it installs a package from a content view? Its repository configuration. That configuration reaches the host through the optional lightweight ELM agent or through a repository file you hand out with Ansible. Either way, the host resolves the content view version its host group points at, then installs through standard package management. See what ELM covers, from mirror through rollback.

Take the subscription-enforcement service out of the runbook

An entitlement model that reaches the host creates operational work, and that work scales with the fleet. Your operations team stands the service up, keeps it reachable from every segment that installs packages, registers each host against it, and reconciles that record as machines join, move between groups, and retire. Teams run this model successfully at every fleet size. That work lands in the runbook, and it stays there for the life of the fleet.

ELM asks for a mirror, the storage under it, a sync schedule, and the curation work that moves each view into production. None of that scales with host count. Point another 5,000 machines at a content view, and you change the host count while the entitlement path stays where it was.

What happens to a rollout if Depot is unreachable? It finishes. The content the rollout needs already sits on your mirror, and the ELM control plane makes no license callback and sends no telemetry. An interruption at Depot delays your next mirror refresh, and the promotion you scheduled for Friday still runs.

ELM governs its users on a separate track, with its own accounts and role-based access control, wired to a directory over LDAP or SAML. You decide who can curate a view, who can promote one into production, and who can only read what shipped.

Entitlement decides which content your subscription covers. Role-based access control decides who on your team moves it.

See entitlement resolve at the mirror Request a demo: ELM syncs entitled content, curates a view, and promotes it into production

Keep entitlement out of the install path

Four decisions determine what a host runs, and each resolves in a different place.

DecisionWhere it resolves
Which repositories the subscription can mirrorDepot, at sync time
Which packages a host installsThe content view its host group points at, at promotion
Who can curate, publish, and promoteELM role-based access control, wired to LDAP or SAML
Whether a host may install at allIts own repository configuration, at install time

The first two decisions are separate, but an enforcement model binds them together by design, which is why it needs a service in the middle. Keep them apart, and your rollout path runs on repository configuration alone.

Disconnected segments resolve entitlement before the content ever leaves a connected system. Lifecycle control that runs on-premises covers that boundary in full.

Evaluating ELM for your own fleet? Request a demo of a content view curated, promoted, and rolled back

Subscribe to our newsletter

Related posts

The CVE didn't bring the fleet down. The patch meant to fix it did.

The CVE didn't bring the fleet down. The patch meant to fix it did.

Migrate to RLC Pro from any Linux environment

Migrate to RLC Pro from any Linux environment

Lifecycle control that runs on-premises: own the cost, the cadence, and the entitlement

Lifecycle control that runs on-premises: own the cost, the cadence, and the entitlement

Content views without the translation tax: moving your lifecycle workflow to ELM

Content views without the translation tax: moving your lifecycle workflow to ELM

Built for scale. Chosen by the world’s best.

2.75M+

Rocky Linux instances

Being used world wide

90%

Of fortune 100 companies

Use CIQ supported technologies

250k

Avg. monthly downloads

Rocky Linux

9

Enterprise products

Spanning the kernel to the orchestrator

Have questions about your infrastructure?

Talk to a CIQ engineer about Rocky Linux, HPC, and AI infrastructure.

Talk to an Expert