이 콘텐츠는 선택한 언어로 제공되지 않습니다.
Chapter 5. Restricting hosts' access to content
Satellite offers multiple options for restricting host access to content. To give hosts access to a specific subset of the content managed by Satellite, you can use the following strategies. Red Hat 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 Chapter 7, Managing content views.
For more information about lifecycle environments, see Chapter 6, Managing application lifecycles.
- Content overrides
By default, content hosted by Satellite can be either enabled or disabled. In custom products, repositories are always disabled by default, while Red Hat products can be either enabled or disabled by default depending on the specific repository. 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 Section 9.7, “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 Section 7.9, “Creating a composite content view”.
- Architecture and OS version restrictions
-
In custom products, you can set restrictions on the architecture and OS versions for
yumrepositories on which the product will be available. For example, if you restrict a custom repository to Red Hat Enterprise Linux 8, it is only available on hosts running Red Hat Enterprise Linux 8. 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. Red Hat repositories set architecture and OS version restrictions automatically. - Release version
- Certain Red Hat repositories, such as the Red Hat Enterprise Linux dot release repositories, include a Release version in their repository metadata. The release version is then compared with the release version specified in the System purpose properties of the host. Access to content may be limited or restricted based on this comparison. For more information about setting system purpose attributes, see Creating a Host in Red Hat Satellite in Managing hosts.
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.
- For certain Red Hat repositories either no release version is set or the release version matches that of 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.
