Content access control for hosts

You can cap host access to repositories and packages with content view environments, overrides, composite content views, and strict architecture or release rules that you evaluate in a deliberate order. Use activation keys at registration time and optional operating system or architecture limits on repositories to keep hosts on the intended content.

Content access strategies

You narrow which repositories and packages registered hosts consume from orcharhino by combining content views, lifecycle environments, overrides, and tighter rules where needed. Evaluate those options from lifecycle environments through overrides toward the strictest architecture or release limits.

ATIX AG recommends considering implementing the strategies in the order as listed here:

Content views and lifecycle environments

Use content views and lifecycle environments, incorporating content view filters as needed.

For more information about content views, see Managing content views and content view environments.

For more information about lifecycle environments, see Managing Application Lifecycles content-management.

Content overrides

By default, content hosted by orcharhino can be either enabled or disabled. In custom products, repositories are always disabled by default. Enabling a repository gives the host access to the repository packages or other content, allowing hosts to download and install the available content.

If a repository is disabled, the host is not able to access the repository content. A content override provides you with the option to override the default enablement value of either Enabled or Disabled for any repository. You can add content overrides to hosts or activation keys.

For more information about adding content overrides to hosts, see Enabling and Disabling Repositories on Hosts in Managing Hosts.

For more information about adding content overrides to activation keys, see Enabling and disabling repositories on activation key content-management.

Content view environments

Assign hosts to multiple content view environments to provide access to content from more than one content view. For more information about multiple content view environments, see Managing content view environments.

Composite content views

You can use composite content views to combine and give hosts access to the content from multiple content views. For more information about composite content views, see Creating a composite content view by using orcharhino management UI.

Architecture and operating system version restrictions

In custom products, you can set restrictions on the architecture and operating system versions for Deb repositories on which the product will be available. For example, if you restrict a custom repository to Ubuntu 26.04, it is only available on hosts running Ubuntu 26.04. Architecture and operating system version restrictions hold the highest priority among all other strategies. They cannot be overridden or invalidated by content overrides, changes to content views, or changes to lifecycle environments. For this reason, ATIX AG recommends considering the other strategies mentioned before that use architecture or operating system version restrictions.

Conditions for content availability

A host can access a repository only when that repository is in a content view environment of the host, passes filters, is enabled, and matches any architecture or operating system version restrictions. When any requirement fails, packages stay unavailable to the host even though orcharhino still publishes the repository.

A host can access a package or repository only if all of the following conditions are true:

  • The repository is included in the content view environments of the host.

  • The content view of the host has been published after the repository was added to it.

  • The repository has not been filtered out by a content view filter.

  • The repository is enabled by default or overridden to Enabled by using a content override.

  • The repository has no architecture or operating system version restrictions or it has architecture or operating system version restrictions that match the host.

Activation keys and content access

During registration, you use activation keys to assign content view environments and attach content overrides so hosts inherit the repository access you intend. After registration, adjust access per host or through bulk actions instead of changing the activation keys.

You can use activation keys to perform the following actions:

  • Assign hosts to content view environments.

  • Add content overrides to hosts.

  • Set system purpose attributes on hosts, including a release version.

Activation keys only affect hosts during registration. If a host is already registered, you can change the content access individually for each host or through host bulk actions.

Additional resources

Restricting a repository to a specific operating system or architecture in orcharhino

You restrict access to a repository so only matching hosts consume the repository from orcharhino. For example, expose the repository only to Ubuntu 26.04 hosts.

Procedure

  1. In the orcharhino management UI, navigate to Content > Products.

  2. Click the product that contains the repository sets you want to restrict.

  3. In the Repositories tab, click the repository you want to restrict.

  4. In the Publishing Settings section, set the following options:

    • Set Restrict to OS version to restrict the operating system version.

    • Set Restrict to architecture to restrict the architecture.

The text and illustrations on this page are licensed by ATIX AG under a Creative Commons Attribution Share Alike 4.0 International ("CC BY-SA 4.0") license. This page also contains text from the official Foreman documentation which uses the same license ("CC BY-SA 4.0").