Restricting hosts' access to content

orcharhino offers multiple options for restricting host access to content. To give hosts access to a specific subset of the content managed by orcharhino, you can use the following strategies. ATIX AG recommends to consider implementing the strategies in the order 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.

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

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.

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.

Architecture and OS version restrictions

In custom products, you can set restrictions on the architecture and OS versions for Yum repositories on which the product will be available. For example, if you restrict a custom repository to Amazon Linux 2023, it is only available on hosts running Amazon Linux 2023. Architecture and OS 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, it is recommended to consider the other strategies mentioned before using architecture or OS version restrictions.

Incorporating all strategies

A particular package or repository is available to a host only if all of the following are true:

  • The repository is included in the host’s content view and lifecycle environment.

  • The host’s content view 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 using a content override.

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

Using activation keys

Using activation keys can simplify the workflow for some of these strategies. You can use activation keys to perform the following actions:

  • Assign hosts to content views and lifecycle environments.

  • Add content overrides to hosts.

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

Activation keys only affect hosts during registration. If a host is already registered, the above attributes can be changed individually for each host or through content host bulk actions. For more information, see Managing Activation Keys in Managing Content.

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").