Content flow in orcharhino involves management and distribution of content from external sources to hosts.

Content in orcharhino flows from external content sources to orcharhino Server. orcharhino Proxies mirror the content from orcharhino Server to hosts.

The graphics in this section are Red Hat illustrations. Non-Red Hat illustrations are welcome. If you want to contribute alternative images, raise a pull request in the Foreman Documentation GitHub page. Note that in Red Hat terminology, "Satellite" refers to Foreman and "Capsule" refers to Smart Proxy.

A content view is a deliberately curated subset of content that your hosts can access. By creating a content view, you can define the software versions used by a particular environment or orcharhino Proxy.

Each content view creates a set of repositories across each environment. Your orcharhino Server stores and manages these repositories. For example, you can create content views in the following ways:

A Default Organization View is an application-controlled content view for all content that is synchronized to orcharhino. You can register a host to the Library environment on orcharhino to consume the Default Organization View without configuring content views and lifecycle environments.

You can access unprotected repositories in the Default Organization View content view. The URL consists of your orcharhino Proxy FQDN, /pulp/content/, your organization label, /Library/custom/, your product label, /, your repository label, and a trailing /, for example, https://orcharhino.example.com/pulp/content/Example/Library/custom/AlmaLinux_9/BaseOS/.

When you promote a content view from one environment to the next environment in the application lifecycle, orcharhino updates the repository and publishes the packages.

With Distribute archived content view versions enabled, you can access unprotected repositories in published content view versions. The URL consists of your orcharhino Proxy FQDN, /pulp/content/, your organization label, /content_views/, your content view, your content view version, /custom/, your product label, /, your repository label, and a trailing /, for example, https://orcharhino.example.com/pulp/content/Example/content_views/AlmaLinux_9/2.1/custom/AlmaLinux_9/BaseOS/.

If you want to access the latest published content view, the URL consists of your orcharhino Proxy FQDN, /pulp/content/, your organization label, your lifecycle, your content view, /custom/, your product label, /, your repository label, and a trailing /, for example, https://orcharhino.example.com/pulp/content/Example/Production/AlmaLinux_9/custom/AlmaLinux_9/AlmaLinux_9/.

You can use these URLs to provide versioned orcharhino Clients during host registration.

Application lifecycles are divided into lifecycle environments which represent each stage of the application lifecycle. By linking lifecycle environments, you create an environment path.

You can promote content along the environment path to the next lifecycle environment when required. When you promote a content view from one environment to the next environment in the application lifecycle, orcharhino updates the repository and publishes the packages. For example, if development ends on a particular version of an application, you can promote this version to the testing environment and start development on the next version.

The graphics in this section are Red Hat illustrations. Non-Red Hat illustrations are welcome. If you want to contribute alternative images, raise a pull request in the Foreman Documentation GitHub page. Note that in Red Hat terminology, "Satellite" refers to Foreman and "Capsule" refers to Smart Proxy.

With orcharhino, you can import and manage many content types. You can use content from Red Hat as well as from Canonical, Oracle, SUSE, and other custom content.

For example, orcharhino supports the following content types:

With orcharhino, you can provision hosts by using the following methods.

For more information, see compute resources.

orcharhino Server is the central component of a orcharhino deployment where you plan and manage the content lifecycle.

A typical orcharhino deployment includes one orcharhino Server on which you perform the following operations:

orcharhino Server delegates content distribution, host provisioning, and communication to orcharhino Proxies. orcharhino Server itself also includes a orcharhino Proxy.

orcharhino Server also contains a fine-grained authentication system. You can grant orcharhino users permissions to access precisely the parts of the infrastructure for which they are responsible.

With orcharhino Proxies, you can extend the reach and scalability of your orcharhino deployment. orcharhino Proxies provide the following functionalities in a orcharhino deployment:

By using content views, you can specify the exact subset of content that orcharhino Proxy makes available to hosts. For more information, see Content and patch management with orcharhino.

A host is any Linux client that orcharhino manages. Hosts can be physical or virtual.

You can deploy virtual hosts on any platform supported by orcharhino, such as Amazon EC2, Google Compute Engine, libvirt, Microsoft Azure, Oracle Linux Virtualization Manager, oVirt, Proxmox, RHV, and VMware vSphere.

With orcharhino, you can manage hosts at scale, including monitoring, provisioning, remote execution, configuration management, software management, and subscription management.

orcharhino consists of several open source projects integrated with each other, such as the following:

orcharhino Proxies provide local host management services and can mirror content from orcharhino Server.

To mirror content from orcharhino Server, orcharhino Proxy provides the following functionalities:

You can use orcharhino Proxy to run the following services for infrastructure and host management:

You can configure a orcharhino Proxy for a specific limited purpose by enabling only selected features on that orcharhino Proxy. Common configurations include the following:

The communication between orcharhino Server and hosts registered to a orcharhino Proxy is routed through that orcharhino Proxy. orcharhino Proxy also provides orcharhino services to hosts.

Many of the services that orcharhino Proxy manages use dedicated network ports. However, orcharhino Proxy ensures that all communications from the host to orcharhino Server use a single source IP address, which simplifies firewall administration.

In this topology, orcharhino Proxy provides a single endpoint for all host network communications so that in remote network segments, only firewall ports to the orcharhino Proxy itself must be open.

The graphics in this section are Red Hat illustrations. Non-Red Hat illustrations are welcome. If you want to contribute alternative images, raise a pull request in the Foreman Documentation GitHub page. Note that in Red Hat terminology, "Satellite" refers to Foreman and "Capsule" refers to Smart Proxy.

In this topology, hosts connect to orcharhino Server rather than a orcharhino Proxy. This applies also to orcharhino Proxies themselves because the orcharhino Proxy is a host of orcharhino Server.

You can find complete instructions for configuring the host-based firewall to open the required ports in the following documents:

On your orcharhino Server, you can define organizations and locations to help organize content, hosts, and configurations. Organizations and locations enable you to arrange orcharhino resources into logically structured groups. For example, you can create groups based on ownership, purpose, content, or security level. You can create and manage multiple organizations through orcharhino, then divide and assign subscriptions to each individual organization.

orcharhino Server defines all locations and organizations. Each orcharhino Proxy synchronizes content and handles configuration of hosts in a different location.

Your orcharhino Server retains the management function, while the content and configuration is synchronized between your orcharhino Server and orcharhino Proxies assigned to certain locations.

A host group acts as a template for common host settings.

With host groups, you can define many settings for hosts, such as lifecycle environment, content view, or Ansible roles that are available to the hosts. Instead of defining the settings individually for each host, you can use host groups to define common settings once and apply them to multiple hosts.

You can create nested host groups.

A host collection is a group of content hosts.

With host collections, you can perform the same action on multiple hosts at once. These actions include the installation, removal, and update of packages and errata, change of assigned lifecycle environment, and change of content view.

For example, you can use host collections to group hosts by function, department, or business unit.

You can manage and monitor your orcharhino infrastructure from a browser with the orcharhino management UI. For example, you can use the following navigation features in the orcharhino management UI:

You can configure and manage your orcharhino Server with CLI commands by using Hammer.

Using Hammer has the following benefits:

To issue Hammer commands, a user must have access to your orcharhino Server.

In the background, each Hammer command first establishes a binding to the API, then sends a request. This can have performance implications when executing a large number of Hammer commands in sequence. In contrast, scripts that use API commands communicate directly with the Satellite API and they establish the binding only once.

You can write custom scripts and external applications that access the orcharhino API over HTTP with the Representational State Transfer (REST) API provided by orcharhino Server. Use the REST API to integrate with enterprise IT systems and third-party applications, perform automated maintenance or error checking tasks, and automate repetitive tasks with scripts.

Using the REST API has the following benefits:

Scripts based on API commands communicate directly with the orcharhino API, which makes them faster than scripts based on Hammer commands or Ansible Playbooks relying on modules within theforeman.foreman.

With remote execution, you can run jobs on hosts from orcharhino Proxies by using shell scripts or Ansible roles and playbooks.

Use remote execution for the following benefits in orcharhino:

Communication for remote execution occurs through orcharhino Proxy, which means that orcharhino Server does not require direct access to the target host, and can scale to manage many hosts.

To use remote execution, you must define a job template. A job template is a command that you want to apply to remote hosts. You can execute a job template multiple times.

orcharhino uses ERB syntax job templates. For more information, see Template Writing Reference in Managing hosts.

By default, orcharhino includes several job templates for shell scripts and Ansible. For more information, see Setting up Job Templates in Managing hosts.

orcharhino Ansible Collections is a set of Ansible modules that interact with the orcharhino API. You can manage and automate many aspects of orcharhino with orcharhino Ansible collections.

You can automate the installation process of a orcharhino Server or orcharhino Proxy by creating a Kickstart file that contains all the information that is required for the installation.

When you run a orcharhino Kickstart script, the script performs the following actions:

For more information about Kickstart, see Automated installation workflow in Automatically installing RHEL 8.

Using orcharhino, you can manage multiple operating systems that have orcharhino clients:

orcharhino can integrate with the following client features:

The Katello plugin provides functionality for content and subscription management. The following utilities are provided for supported client operating systems:

Installing an instance of orcharhino Server on a dedicated server is the first step to a working orcharhino infrastructure.

orcharhino includes native support for authentication with a username and password. If you require additional methods of authentication, configure your orcharhino Server to use an external authentication source.

Context in orcharhino consists of organizations and locations. You can associate most resources, for example hosts, subnets, and domains, with at least one organization and location context.

Resources and users can generally only access resources within their own context, which makes configuring organizations and locations an integral part of access management in orcharhino.

By installing orcharhino Proxies, you extend the reach and scalability of your orcharhino deployment. Setting up a orcharhino Proxy registers the base operating system on which you are installing to orcharhino Server and configures the new orcharhino Proxy to provide the required services within your orcharhino deployment.

You can install a orcharhino Proxy in each of your geographic locations. By assigning a orcharhino Proxy to each location, you decrease the load on orcharhino Server, increase redundancy, and reduce bandwidth usage.

Decide what services you want to enable on each orcharhino Proxy. You can configure the DNS, DHCP, and TFTP services on one of your orcharhino Proxies or you can use an external server to provide these services to your orcharhino Proxies.

A Red Hat subscription manifest is a set of encrypted files that contains your subscription information. orcharhino Server uses this information to access the Red Hat CDN and find what repositories are available for the associated subscription.

To ensure that your orcharhino Server can manage software and provide it to your hosts, you must create repositories and synchronize them.

Creating repositories allows you to choose the specific software required for your environment. By creating only the necessary repositories, you avoid downloading unnecessary content.

Synchronizing repositories downloads the content from Red Hat CDN or another source to your orcharhino Server. The synchronized content is stored on your orcharhino Server, eliminating the need for hosts to access the repositories. You can synchronize repositories manually, or you can create a sync plan to ensure synchronization runs on a regular basis.

When defining your content lifecycle in orcharhino, you can use content views and lifecycle environments to define which hosts can access which content and content versions. By default, orcharhino includes the Default Organization View content view and the Library lifecycle environment.

In smaller deployments or when you do not require content versioning and environment promotion, you can associate a host to the Library environment under the Default Organization View without configuring additional lifecycle environments.

Users in orcharhino can have one or more roles assigned. These roles are associated with permissions that enable users to perform specified administrative actions in orcharhino. Permission filters define the actions allowed for a certain resource type.

orcharhino provides a set of predefined roles with permissions sufficient for standard tasks. You can also configure custom roles.

The following types of roles are commonly defined within various orcharhino deployments:

After your basic orcharhino infrastructure is in place, you can start configuring provisioning to ensure that orcharhino can seamlessly create, configure, and manage hosts.

The process depends on whether you want to provision bare-metal hosts, virtual machines, or cloud instances, but it includes defining installation media, configuring provisioning templates, and other tasks. If you are provisioning virtual machines or cloud instances, you must also integrate your compute provider with orcharhino by connecting the provider as a compute resource to orcharhino.

The following orcharhino features support automating the provisioning of your hosts:

Ensure to back up your orcharhino data so that you can recover your orcharhino deployment in case of a disaster.

To create backups of your orcharhino Server and orcharhino Proxies, use the foreman-maintain backup command. For more information, see Backing up orcharhino Server and orcharhino Proxy in Administering orcharhino.

To backup your hosts, you can use remote execution to configure recurring backup tasks that orcharhino will run on the hosts. For more information, see Configuring and setting up remote jobs in Managing hosts.

To create snapshots of hosts, you can use the Snapshot Management plugin. For more information, see Creating snapshots of a host in Managing hosts.

orcharhino offers a range of additional capabilities that you can use to further enhance your orcharhino deployment. For example:

Your infrastructure might require multiple isolated subnets even if orcharhino is deployed in a single geographic location. This can be achieved for example by deploying multiple orcharhino Proxies with DHCP and DNS services, but the recommended way is to create segregated subnets using a single orcharhino Proxy. This orcharhino Proxy is then used to manage hosts and compute resources in those segregated networks to ensure they only have to access the orcharhino Proxy for provisioning, configuration, errata, and general management. For more information on configuring subnets, see Managing hosts.

ATIX AG recommends to create at least one orcharhino Proxy per geographic location. This practice can save bandwidth since hosts obtain content from a local orcharhino Proxy. Synchronization of content from remote repositories is done only by the orcharhino Proxy, not by each host in a location. In addition, this layout makes the provisioning infrastructure more reliable and easier to configure.

The graphics in this section are Red Hat illustrations. Non-Red Hat illustrations are welcome. If you want to contribute alternative images, raise a pull request in the Foreman Documentation GitHub page. Note that in Red Hat terminology, "Satellite" refers to Foreman and "Capsule" refers to Smart Proxy.

The following section provides general scenarios for deploying content views as well as lifecycle environments.

The default lifecycle environment called Library gathers content from all connected sources. It is not recommended to associate hosts directly with the Library as it prevents any testing of content before making it available to hosts. Instead, create a lifecycle environment path that suits your content workflow. The following scenarios are common:

The following content view scenarios are common:

The optimal solution depends on the nature of your host environment. Avoid creating a large number of content views, but keep in mind that the size of a content view affects the speed of related operations (publishing, promoting). Also make sure that when creating a subset of packages for the content view, all dependencies are included as well. Note that Kickstart repositories should not be added to content views, as they are used for host provisioning only.

If you plan to have more than one Red Hat Network account, or if you want to manage systems belonging to another entity that is also a Red Hat Network account holder, then you and the other account holder can assign subscriptions, as required, to manifests. A customer that does not have a orcharhino subscription can create a Subscription Asset Manager manifest, which can be used with orcharhino, if they have other valid subscriptions. You can then use the multiple manifests in one orcharhino Server to manage multiple organizations.

If you must manage systems but do not have access to the subscriptions for the RPMs, you must use Red Hat Enterprise Linux orcharhino Add-On. For more information, see orcharhino Add-On.

The following diagram shows two Red Hat Network account holders, who want their systems to be managed by the same orcharhino installation. In this scenario, Example Corporation 1 can allocate any subset of their 60 subscriptions, in this example they have allocated 30, to a manifest. This can be imported into the orcharhino as a distinct Organization. This allows system administrators the ability to manage Example Corporation 1’s systems using orcharhino completely independently of Example Corporation 2’s organizations (R&D, Operations, and Engineering).

When creating a Red Hat subscription manifest:

orcharhino allows the use of future-dated subscriptions in the manifest. This enables uninterrupted access to repositories when future-dated subscriptions are added to a manifest before the expiry date of existing subscriptions.

Note that the Red Hat subscription manifest can be modified and reloaded to orcharhino Server in case of any changes in your infrastructure, or when adding more subscriptions. Manifests should not be deleted. If you delete the manifest from the Red Hat Customer Portal or in the orcharhino management UI it will unregister all of your content hosts.

The fact that host groups can be nested to inherit parameters from each other allows for designing host group hierarchies that fit particular workflows. A well planned host group structure can help to simplify the maintenance of host settings. This section outlines four approaches to organizing host groups.

Preboot execution environment (PXE) provides the ability to boot a system over a network. Instead of using local hard drives or a CD-ROM, PXE uses DHCP to provide host with standard information about the network, to discover a TFTP server, and to download a boot image.

You can use HTTP booting to boot systems over a network using HTTP.

When orcharhino is installed on Enterprise Linux using foreman-installer, grub2 and shim boot loaders that are signed by Red Hat are deployed into the TFTP and HTTP UEFI Boot directory. PXE loader options named "SecureBoot" configure hosts to load shim.efi.

On Debian and Ubuntu operating systems, the grub2 boot loader is created using the grub2-mkimage unsigned. To perform the Secure Boot, the boot loader must be manually signed and key enrolled into the EFI firmware. Alternatively, grub2 from Ubuntu or Enterprise Linux can be copied to perform booting.

Grub2 in Enterprise Linux 8.0-8.3 were updated to mitigate Boot Hole Vulnerability and keys of existing Enterprise Linux kernels were invalidated. To boot any of the affected Enterprise Linux kernel (or operating system installer), you must enroll keys manually into the EFI firmware for each host: