The following diagram represents the high-level architecture of orcharhino.

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.

There are four stages through which content flows in this architecture:

The following diagram provides a closer look at the distribution of content from orcharhino Server to orcharhino Proxies.

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.

By default, each organization has a Library of content from external sources. Content Views are subsets of content from the Library created by intelligent filtering. You can publish and promote Content Views into life cycle environments (typically Dev, QA, and Production). When creating a orcharhino Proxy, you can choose which life cycle environments will be copied to that orcharhino Proxy and made available to managed hosts.

Content Views can be combined to create Composite Content Views. It can be beneficial to have a separate Content View for a repository of packages required by an operating system and a separate one for a repository of packages required by an application. One advantage is that any updates to packages in one repository only requires republishing the relevant Content View. You can then use Composite Content Views to combine published Content Views for ease of management.

Which Content Views should be promoted to which orcharhino Proxy depends on the orcharhino Proxy’s intended functionality. Any orcharhino Proxy can run DNS, DHCP, and TFTP as infrastructure services that can be supplemented, for example, with content or configuration services.

You can update orcharhino Proxy by creating a new version of a Content View using synchronized content from the Library. The new Content View version is then promoted through life cycle environments. You can also create in-place updates of Content Views. This means creating a minor version of the Content View in its current life cycle environment without promoting it from the Library. For example, if you need to apply a security erratum to a Content View used in Production, you can update the Content View directly without promoting to other life cycles. For more information on content management, see Managing Content.

orcharhino consists of the following open source projects:

The terminology used in orcharhino and its components is extensive. For explanations of frequently used terms, see Glossary of Terms.

There are two sets of features provided by orcharhino Proxies. You can use orcharhino Proxy to run services required for host management. If you have the Katello plug-in installed, you can also configure orcharhino Proxy to mirror content from orcharhino Server.

Infrastructure and host management services:

Content related features, provided by the Katello plug-in:

Not all orcharhino Proxy features have to be enabled at once. You can configure a orcharhino Proxy for a specific limited purpose. Some common configurations include:

The goal of orcharhino Proxy isolation is to provide a single endpoint for all of the host’s network communications so that in remote network segments, you need only open firewall ports to the orcharhino Proxy itself. The following diagram shows how the orcharhino components interact in the scenario with hosts connecting to an isolated orcharhino Proxy.

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 diagram shows how the orcharhino components interact when hosts connect directly to orcharhino Server. Note that as the base system of an external orcharhino Proxy is a Client of the orcharhino, this diagram is relevant even if you do not intend to have directly connected hosts.

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

Organizations divide orcharhino resources into logical groups based on ownership, purpose, content, security level, or other divisions. You can create and manage multiple organizations through orcharhino, then divide and assign your subscriptions to each individual organization. This provides a method of managing the content of several individual organizations under one management system.

Locations divide organizations into logical groups based on geographical location. Each location is created and used by a single account, although each account can manage multiple locations and organizations.

Application life cycles are divided into life cycle environments which represent each stage of the application life cycle. Life cycle environments are linked to form an environment path. You can promote content along the environment path to the next life cycle environment when required. 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.

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.

Flat Structure

The advantage of a flat structure is limited complexity, as inheritance is avoided. In a deployment with few host types, this scenario is the best option. However, without inheritance there is a risk of high duplication of settings between host groups.

Life Cycle Environment Based Structure

In this hierarchy, the first host group level is reserved for parameters specific to a life cycle environment. The second level contains operating system related definitions, and the third level contains application specific settings. Such structure is useful in scenarios where responsibilities are divided among life cycle environments (for example, a dedicated owner for the Development, QA, and Production life cycle stages).

Application Based Structure

This hierarchy is based on roles of hosts in a specific application. For example, it enables defining network settings for groups of back-end and front-end servers. The selected characteristics of hosts are segregated, which supports Puppet-focused management of complex configurations. However, the content views can only be assigned to host groups at the bottom level of this hierarchy.

Location Based Structure

In this hierarchy, the distribution of locations is aligned with the host group structure. In a scenario where the location (orcharhino Proxy) topology determines many other attributes, this approach is the best option. On the other hand, this structure complicates sharing parameters across locations, therefore in complex environments with a large number of applications, the number of host group changes required for each configuration change increases significantly.

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 bootloaders 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 bootloader is created using the grub2-mkimage unsigned. To perform the Secure Boot, the bootloader 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 OS installer), you must enroll keys manually into the EFI firmware for each host:

+

You can use Kickstart to automate the installation process of a orcharhino or orcharhino Proxy by creating a Kickstart file that contains all the information that is required for the installation. For more information about Kickstart, see Performing an automated installation using Kickstart in Performing an advanced RHEL 8 installation.

When you install orcharhino, the foreman-installer command creates databases on the same server that you install orcharhino. Depending on your requirements, moving to external databases can provide increased working memory for orcharhino, which can improve response times for database operating requests. Moving to external databases distributes the workload and can increase the capacity for performance tuning.

Consider using external databases if you plan to use your orcharhino deployment for the following scenarios:

For more information about using an external database, see Using External Databases with orcharhino in Installing orcharhino Server.

This section outlines general considerations that should help you to specify your orcharhino deployment scenario. The most common deployment scenarios are listed in Common Deployment Scenarios. The defining questions are:

The Red Hat Subscription Manifest determines what Red Hat repositories are accessible from your orcharhino Server. Once you enable a Red Hat repository, an associated orcharhino Product is created automatically. For distributing content from custom sources you need to create products and repositories manually. Red Hat repositories are signed with GPG keys by default, and it is recommended to create GPG keys also for your custom repositories. The configuration of custom repositories depends on the type of content they hold (RPM packages, or Docker images).

Repositories configured as yum repositories, that contain only RPM packages, can make use of the new download policy setting to save on synchronization time and storage space. This setting enables selecting from Immediate and On demand. The On demand setting saves space and time by only downloading packages when requested by clients. For detailed instructions on setting up content sources see Importing Content in Managing Content.

A custom repository within orcharhino Server is in most cases populated with content from an external staging server. Such servers lie outside of the orcharhino infrastructure, however, it is recommended to use a revision control system (such as Git) on these servers to have better control over the custom content.

orcharhino provides features for precise management of the content life cycle. A life cycle environment represents a stage in the content life cycle, a Content View is a filtered set of content, and can be considered as a defined subset of content. By associating Content Views with life cycle environments, you make content available to hosts in a defined way. See Content Life Cycle in orcharhino for visualization of the process. For a detailed overview of the content management process see Importing Custom Content in Managing Content. The following section provides general scenarios for deploying content views as well as life cycle environments.

The default life cycle 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 life cycle 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.

Content deployment is the management of errata and packages on content hosts. There are two methods for content deployment on orcharhino. The default method is remote execution, and the second method is the deprecated Katello agent.

orcharhino provides several features to help you automate the host provisioning, including provisioning templates, configuration management with Puppet, and host groups for standardized provisioning of host roles. For a description of the provisioning workflow see Provisioning Workflow in Provisioning Hosts. The same guide contains instructions for provisioning on various compute resources.

Assigning a role to a user enables controlling access to orcharhino components based on a set of permissions. You can think of role based authentication as a way of hiding unnecessary objects from users who are not supposed to interact with them.

There are various criteria for distinguishing among different roles within an organization. Apart from the administrator role, the following types are common:

When defining a custom role, consider the following recommendations:

For instructions on defining roles and assigning them to users, see Managing Users and Roles in Administering orcharhino. The same guide contains information on configuring external authentication sources.

This section provides a short overview of selected orcharhino capabilities that can be used for automating certain tasks or extending the core usage of orcharhino:

An integrated orcharhino Proxy is a virtual orcharhino Proxy that is created by default in orcharhino Server during the installation process. This means orcharhino Server can be used to provision directly connected hosts for orcharhino deployment in a single geographical location, therefore only one physical server is needed. The base systems of isolated orcharhino Proxies can be directly managed by orcharhino Server, however it is not recommended to use this layout to manage other hosts in remote locations.

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.

It is recommended 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. See orcharhino System Architecture for an illustration of this approach.

You can configure a orcharhino Proxy (integrated or standalone) to use external DNS, DHCP, or TFTP service. If you already have a server that provides these services in your environment, you can integrate it with your orcharhino deployment. For information about how to configure a orcharhino Proxy with external services, see Configuring orcharhino Proxy with External Services in Installing orcharhino Proxy.