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

Content in Foreman flows from external content sources to Foreman server. Smart Proxy servers mirror the content from Foreman 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 Smart Proxy server.

Each content view creates a set of repositories across each environment. Your Foreman 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 Foreman. You can register a host to the Library environment on Foreman 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 Smart Proxy FQDN, /pulp/content/, your organization label, /Library/custom/, your product label, /, your repository label, and a trailing /, for example, https://foreman.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, Foreman 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 Smart 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://foreman.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 Smart 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://foreman.example.com/pulp/content/Example/Production/AlmaLinux_9/custom/AlmaLinux_9/AlmaLinux_9/.

With Foreman, you can import and manage many content types.

For example, Foreman supports the following content types:

Simple Content Access (SCA) in Foreman simplifies management of software entitlements. With SCA, you can add valid subscriptions to a subscription allocation or manifest and refresh within Foreman. Therefore, with SCA enabled, you do not need to attach subscriptions individually to hosts.

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

Foreman server is the central component of a Foreman deployment where you plan and manage the content lifecycle.

A typical Foreman deployment includes one Foreman server on which you perform the following operations:

Foreman server delegates content distribution, host provisioning, and communication to Smart Proxy servers. Foreman server itself also includes a Smart Proxy.

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

On your Foreman server, you can define multiple organizations and locations to help organize content, hosts, and configurations.

With Smart Proxy servers, you can extend the reach and scalability of your Foreman deployment. Smart Proxy servers provide the following functionalities in a Foreman deployment:

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

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

You can deploy virtual hosts on any platform supported by Foreman, such as Amazon EC2, Google Compute Engine, KVM, libvirt, Microsoft Azure, OpenStack, oVirt, Proxmox, Rackspace Cloud Services, or VMware vSphere.

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

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

Smart Proxy servers provide local host management services. With the Katello plugin, they can also mirror content from Foreman server.

If you have the Katello plugin installed, you can use Smart Proxy to mirror content from Foreman server:

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

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

The communication between Foreman server and hosts registered to a Smart Proxy server is routed through that Smart Proxy server. Smart Proxy server also provides Foreman services to hosts.

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

In this topology, Smart Proxy provides a single endpoint for all host network communications so that in remote network segments, only firewall ports to the Smart 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 Foreman server rather than a Smart Proxy. This applies also to Smart Proxies themselves because the Smart Proxy server is a host of Foreman server.

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.

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

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

You can configure and manage your Foreman server with CLI commands by using Hammer.

Using Hammer has the following benefits:

To issue Hammer commands, a user must have access to your Foreman 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 Foreman API over HTTP with the Representational State Transfer (REST) API provided by Foreman 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 Foreman 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 Smart Proxies by using shell scripts or Ansible roles and playbooks.

Use remote execution for the following benefits in Foreman:

Communication for remote execution occurs through Smart Proxy server, which means that Foreman 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.

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

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

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

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

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

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

Foreman has packages for Enterprise Linux 8 and 9, Debian 11 and Ubuntu 20.04 and 22.04. Katello plugin packages, which provide content management capabilities, are only available for Enterprise Linux.

Foreman community only packages Foreman for x86_64.

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

Foreman 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:

An integrated Smart Proxy is a virtual Smart Proxy server that is created by default in Foreman server during the installation process. This means Foreman server can be used to provision directly connected hosts for Foreman deployment in a single geographical location, therefore only one physical server is needed. The base systems of isolated Smart Proxies can be directly managed by Foreman 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 Foreman is deployed in a single geographic location. This can be achieved for example by deploying multiple Smart Proxy servers with DHCP and DNS services, but the recommended way is to create segregated subnets using a single Smart Proxy. This Smart Proxy is then used to manage hosts and compute resources in those segregated networks to ensure they only have to access the Smart 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 Smart Proxy server per geographic location. This practice can save bandwidth since hosts obtain content from a local Smart Proxy server. Synchronization of content from remote repositories is done only by the Smart 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.

You can configure a Smart Proxy server (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 Foreman deployment. For information about how to configure a Smart Proxy with external services, see Configuring Smart Proxy server with External Services in Installing a Smart Proxy Server 3.12 on Enterprise Linux.

When you install Foreman, the foreman-installer command creates databases on the same server that you install Foreman. Depending on your requirements, moving to external databases can provide increased working memory for Foreman, 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 Foreman deployment for the following scenarios:

For more information about using an external database, see Using External Databases with Foreman in Installing Foreman Server with Katello 4.14 plugin on Enterprise Linux.

This section outlines general considerations that should help you to specify your Foreman 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 Foreman server. Once you enable a Red Hat repository, an associated Foreman 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.

Yum repositories that contain only RPM packages support the On demand download policy, which reduces synchronization time and storage space. The On demand download policy saves space and time by only downloading packages when requested by hosts. For detailed instructions on setting up content sources, see Importing Content in Managing content.

A custom repository within Foreman server is in most cases populated with content from an external staging server. Such servers lie outside of the Foreman 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.

Foreman provides features for precise management of the content lifecycle. A lifecycle environment represents a stage in the content lifecycle, a Content View is a filtered set of content, and can be considered as a defined subset of content. By associating Content Views with lifecycle environments, you make content available to hosts in a defined way.

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.

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

Content deployment manages errata and packages on content hosts. Foreman can be configured to perform remote execution over MQTT/HTTPS (pull-based) or SSH (push-based). While remote execution is enabled on Foreman server by default, it is disabled on Smart Proxy servers and content hosts. You must enable it manually.

Foreman 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 Foreman 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 Foreman. The same guide contains information on configuring external authentication sources.

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

Organizations divide Foreman resources into logical groups based on ownership, purpose, content, security level, or other divisions. You can create and manage multiple organizations through Foreman, 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 lifecycles are divided into lifecycle environments which represent each stage of the application lifecycle. Lifecycle environments are linked to form an environment path. You can promote content along the environment path to the next lifecycle 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.

Lifecycle environment based structure

In this hierarchy, the first host group level is reserved for parameters specific to a lifecycle 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 lifecycle environments (for example, a dedicated owner for the Development, QA, and Production lifecycle 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 (Smart Proxy server) 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 Foreman 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 operating system installer), you must enroll keys manually into the EFI firmware for each host:

+