1. Foreman overview and concepts
Foreman is a centralized tool for provisioning, remote management, and monitoring of multiple Enterprise Linux deployments. With Foreman, you can deploy, configure, and maintain your systems across physical, virtual, and cloud environments.
1.1. Provisioning management with Foreman
With Foreman, you can provision hosts on various compute resources with many provisioning methods from a unified interface.
1.1.1. Provisioning methods in Foreman
With Foreman, you can provision hosts by using the following methods.
- Bare-metal hosts
-
Foreman provisions bare-metal hosts primarily by using PXE boot and MAC address identification. When provisioning bare-metal hosts with Foreman, you can do the following:
-
Create host entries and specify the MAC address of the physical host to provision.
-
Boot blank hosts to use the Foreman Discovery service, which creates a pool of hosts that are ready for provisioning.
-
Provision hosts with UEFI Secure Boot.
-
Boot and provision hosts by using PXE-less methods.
-
- Cloud providers
-
Foreman connects to private and public cloud providers to provision instances of hosts from images stored in the cloud environment. When provisioning from cloud with Foreman, you can do the following:
-
Select which hardware profile to use.
-
Provision cloud instances from specific providers by using their APIs.
-
- Virtualization infrastructure
-
Foreman connects to virtualization infrastructure services, such as oVirt and VMware. When provisioning virtual machines with Foreman, you can do the following:
-
Provision virtual machines from virtual image templates.
-
Use the same PXE-based boot methods that you use to provision bare-metal hosts.
-
1.1.2. Additional resources
-
For information about how to provision hosts with Foreman, see Provisioning hosts.
1.2. Major Foreman components
A typical Foreman deployment consists of the following components: a Foreman server, Smart Proxy servers that mirror content from Foreman server, and hosts that receive content and configuration from Foreman server and Smart Proxy servers.
1.2.1. Foreman server overview
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:
-
Content lifecycle management
-
Configuration of Smart Proxy servers
-
Configuration of hosts
-
Host provisioning
-
Patch management
-
Subscription management
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.
-
For more information about managing permissions, see Managing users and roles in Administering Foreman.
1.2.2. Smart Proxy overview
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:
-
Running localized services to discover, provision, control, and configure hosts.
1.2.3. Overview of hosts in 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.
1.2.4. List of key open source components of Foreman
Foreman consists of several open source projects integrated with each other, such as the following:
- Foreman
-
Foreman is a lifecycle management application for physical and virtual systems. It helps manage hosts throughout their lifecycle, from provisioning and configuration to orchestration and monitoring.
- Katello
-
Katello is an optional plugin of Foreman that extends Foreman capabilities with additional features for content, subscription, and repository management. Katello enables Foreman to subscribe to repositories and to download content.
- Candlepin
-
Candlepin is a service for subscription management.
- Pulp
-
Pulp is a service for repository and content management.
1.2.5. Smart Proxy features
Smart Proxy servers provide local host management services.
Smart Proxies provide the following functionalities:
- DHCP
-
Smart Proxy can manage a DHCP server, including integration with an existing solution, such as ISC DHCP servers, Active Directory, and Libvirt instances.
- DNS
-
Smart Proxy can manage a DNS server, including integration with an existing solution, such as ISC BIND and Active Directory.
- TFTP
-
Smart Proxy can integrate with any UNIX-based TFTP server.
- Realm
-
Smart Proxy can manage Kerberos realms or domains so that hosts can join them automatically during provisioning. Smart Proxy can integrate with an existing infrastructure, including FreeIPA and Active Directory.
- Puppet server
-
Smart Proxy can act as a configuration management server by running a Puppet server.
- Puppet Certificate Authority
-
Smart Proxy can integrate with the Puppet certificate authority (CA) to provide certificates to hosts.
- Baseboard Management Controller (BMC)
-
Smart Proxy can provide power management for hosts by using the Intelligent Platform Management Interface (IPMI) or Redfish standards.
- Provisioning template proxy
-
Smart Proxy can serve provisioning templates to hosts.
- OpenSCAP
-
Smart Proxy can perform security compliance scans on hosts.
- Remote Execution (REX)
-
Smart Proxy can run remote job execution on hosts.
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:
- Infrastructure Smart Proxies: DNS + DHCP + TFTP
-
Smart Proxies with these services provide infrastructure services for hosts and have all necessary services for provisioning new hosts.
1.2.6. Smart Proxy networking
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.
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.
-
Ports and firewall requirements in Installing Foreman Server nightly on Debian/Ubuntu
-
Ports and firewall requirements in Installing a Smart Proxy Server nightly on Debian/Ubuntu
1.2.7. Additional resources
-
See Installing a Smart Proxy Server nightly on Debian/Ubuntu for details on Smart Proxy server requirements, installation, and scalability considerations.
-
See Configuring Smart Proxies with a load balancer for details on distributing load among Smart Proxy servers.
1.3. Foreman infrastructure organization concepts
You can use several elements to structure and organize the resources within your Foreman environment.
1.3.1. Organizations and locations in Foreman
On your Foreman server, you can define organizations and locations to help organize content, hosts, and configurations. Organizations and locations enable you to arrange Foreman 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 Foreman, then divide and assign subscriptions to each individual organization.
- Organizations
-
Organizations typically represent different business units, departments, or teams, such as Finance, Marketing, or Web Development. To manage Red Hat content, each organization requires a separate Red Hat subscription manifest.
By creating organizations, you can create logical containers to isolate and manage their configurations separately according to their specific requirements.
- Locations
-
Locations typically represent physical locations, such as countries or cities.
By creating locations, you can define geographical sites where hosts are located. For example, this is useful in environments with multiple data centers.
You can use locations to map the network infrastructure to prevent incorrect host placement or configuration. While you cannot assign a subnet, domain, or compute resources directly to a Smart Proxy server, you can assign them to a location.
Unlike organizations, locations can have a hierarchical structure.
Foreman server defines all locations and organizations. Each Smart Proxy server synchronizes content and handles configuration of hosts in a different location.
Your Foreman server retains the management function, while the content and configuration is synchronized between your Foreman server and Smart Proxy servers assigned to certain locations.
The structure of a multi-national company includes the Finance, Marketing, and Sales departments. The company operates across United States, United Kingdom, and Japan.
The system administrator creates the following organizations on their Foreman server:
-
Finance
-
Marketing
-
Sales
Additionally, the administrator creates the following locations on their Foreman server:
-
United States
-
United Kingdom
-
Japan
The administrator can define a nested location hierarchy to divide the United States location into additional locations based on specific cities:
-
Boston
-
Phoenix
-
San Francisco
1.3.2. Host groups overview
A host group acts as a template for common host settings.
With host groups, you can define many settings for hosts, such as host parameters or operating system settings 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.
Important
|
When you change the settings of an existing host group, the new settings do not propagate to the hosts assigned to the host group. Only Puppet class settings get updated on hosts after you change them in the host group. |
1.3.3. Additional resources
-
For examples of Foreman deployment, see Foreman deployment planning.
1.4. Tools for administration of Foreman
You can use multiple tools to manage Foreman.
1.4.1. Foreman web UI overview
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:
Navigation feature | Description |
---|---|
Organization dropdown |
Choose the organization you want to manage. |
Location dropdown |
Choose the location you want to manage. |
Monitor |
Provides summary dashboards and reports. |
Hosts |
Provides host inventory and provisioning configuration tools. |
Configure |
Provides general configuration tools and data, including host groups and Ansible content. |
Infrastructure |
Provides tools on configuring how Foreman interacts with the environment. |
Provides event notifications to keep administrators informed of important environment changes. |
|
Administer |
Provides advanced configuration for settings such as users, role-based access control (RBAC), and general settings. |
1.4.2. Hammer CLI overview
You can configure and manage your Foreman server with CLI commands by using Hammer.
Using Hammer has the following benefits:
-
Create shell scripts based on Hammer commands for basic task automation.
-
Redirect output from Hammer to other tools.
-
Use the
--debug
option with Hammer to test responses to API calls before applying the API calls in a script. For example:hammer --debug organization list
.
To issue Hammer commands, a user must have access to your Foreman server.
Note
|
To ensure a user-friendly and intuitive experience, the Foreman web UI takes priority when developing new functionality. Therefore, some features that are available in the Foreman web UI might not yet be available for Hammer. |
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 Foreman API and they establish the binding only once.
-
For more information about Hammer CLI, see Using the Hammer CLI tool.
1.4.3. Foreman API overview
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:
-
Configure any programming language, framework, or system with support for HTTP protocol to use the API.
-
Create client applications that require minimal knowledge of the Foreman infrastructure because users discover many details at runtime.
-
Adopt the resource-based REST model for intuitively managing a virtualization platform.
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.
Important
|
API commands differ between versions of Foreman. When you prepare to upgrade Foreman server, update all the scripts that contain Foreman API commands. |
-
For more information on Foreman API, see Using the Foreman REST API.
1.4.4. Remote execution in 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:
-
Run jobs on multiple hosts at once.
-
Use variables in your commands for more granular control over the jobs you run.
-
Use host facts and parameters to populate the variable values.
-
Specify custom values for templates when you run the command.
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.
-
See Configuring and setting up remote jobs in Configuring hosts by using Ansible.
1.4.5. Managing Foreman with Ansible
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.
-
For more information about using Ansible to configure hosts, see Configuring hosts by using Ansible.
-
For more information about automating Foreman using Ansible, see Managing Foreman with Ansible in Administering Foreman.
1.5. Supported usage and versions of Foreman components
Foreman supports the following use cases, architectures, and versions.
1.5.1. Foreman server operating system
Foreman has packages for Enterprise Linux 9, Debian 12, and Ubuntu 22.04. Katello plugin packages, which provide content management capabilities, are only available for Enterprise Linux.
Foreman community only packages Foreman for x86_64.
1.5.2. Client operating systems
Using Foreman, you can manage multiple operating systems that have Foreman clients:
-
Amazon Linux
-
Debian
-
Enterprise Linux 10, 9, and 8
-
Fedora
-
OpenSUSE
-
SUSE Linux Enterprise Server
-
Ubuntu
Foreman can integrate with the following client features:
-
Ansible
-
OpenSCAP
-
OpenSSH
-
Puppet
-
Salt
-
Windows Remote Management (WinRM)
-
Operating system installers that can perform unattended installations, such as Anaconda or Debian-installer
2. Foreman deployment planning
2.1. Deployment path for Foreman
During installation and initial configuration of Foreman, you can customize your deployment to fit your specific needs and operational environment. By customizing each stage of the deployment process, you can choose deployment options that meet the requirements of your organization.
2.1.1. Installing a Foreman server
Installing an instance of Foreman server on a dedicated server is the first step to a working Foreman infrastructure.
-
For complete information on installing a Foreman server, including prerequisites and predefined tuning profiles, see Installing Foreman Server nightly on Debian/Ubuntu.
Configuring Foreman server with external database
Running the foreman-installer
command, used to install a Foreman server, also installs PostgreSQL databases on the server.
However, you can configure your Foreman server to use external databases instead.
Moving to external databases distributes the workload and can reduce overall Foreman memory usage.
Consider using external databases if you plan to use your Foreman deployment for the following scenarios:
-
Frequent remote execution tasks. This requires a high volume of records in PostgreSQL and generates heavy database workloads.
-
High disk I/O workloads from frequent repository synchronization or content view publishing. This requires Foreman to create a record in PostgreSQL for each job.
-
High volume of hosts.
-
High volume of synchronized content.
-
For more information about using an external database, see Using external databases with Foreman in Installing Foreman Server nightly on Debian/Ubuntu.
Configuring DNS, DHCP, and TFTP
You can manage DNS, DHCP, and TFTP centrally within the Foreman environment, or you can manage them independently after disabling their maintenance on Foreman.
-
For more information about configuring DNS, DHCP, and TFTP on Foreman server, see Configuring DNS, DHCP, and TFTP in Installing Foreman Server nightly on Debian/Ubuntu.
2.1.2. Configuring external authentication in Foreman
Foreman includes native support for authentication with a username and password. If you require additional methods of authentication, configure your Foreman server to use an external authentication source.
Username and password | Single sign-on (SSO) | One-time password (OTP) | Time-based one-time password (TOTP) | PIV cards | |
---|---|---|---|---|---|
Active Directory (direct integration) |
Yes |
Yes |
No |
No |
No |
FreeIPA |
Yes (Linux and Active Directory users) |
Yes (Linux users only) |
No |
No |
No |
Quarkus-based Keycloak |
Yes |
Yes |
Yes |
Yes |
Yes |
Wildfly-based Keycloak |
Yes |
Yes |
Yes |
Yes |
Yes |
LDAP |
Yes |
No |
No |
No |
No |
-
For more information, see Configuring authentication for Foreman users.
2.1.3. Planning organization and location context
Context in Foreman 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 Foreman.
Important
|
If you use host groups to bundle provisioning and configuration information, avoid mismatching resources from mutually exclusive contexts. For example, setting a subnet from one organization or location and a compute resource from a different organization or location creates an invalid host group. |
Some resources in Foreman, such as Ansible roles and operating systems, are not part of any organization or location context.
-
For examples of deployment scenarios, see Common deployment scenarios.
2.1.4. Installing Smart Proxy servers
By installing Smart Proxy servers, you extend the reach and scalability of your Foreman deployment. Setting up a Smart Proxy server registers the base operating system on which you are installing to Foreman server and configures the new Smart Proxy server to provide the required services within your Foreman deployment.
You can install a Smart Proxy server in each of your geographic locations. By assigning a Smart Proxy to each location, you decrease the load on Foreman server, increase redundancy, and reduce bandwidth usage.
Note
|
The maximum number of Smart Proxy servers that Foreman server can support has no fixed limit. It was tested that a Foreman server can support 17 Smart Proxy servers with 2 vCPUs. |
Decide what services you want to enable on each Smart Proxy server. You can configure the DNS, DHCP, and TFTP services on one of your Smart Proxy servers or you can use an external server to provide these services to your Smart Proxy servers.
-
For information on installing Smart Proxy servers, including prerequisites and configuring external services, see Installing a Smart Proxy Server nightly on Debian/Ubuntu.
2.1.5. Defining role-based access control policies
Users in Foreman can have one or more roles assigned. These roles are associated with permissions that enable users to perform specified administrative actions in Foreman. Permission filters define the actions allowed for a certain resource type.
Foreman provides a set of predefined roles with permissions sufficient for standard tasks. You can also configure custom roles.
Note
|
One of the predefined roles is the Default role. Foreman assigns the Default role to every user in the system. By default, the Default role grants only a limited set of permissions. Be aware that if you add a permission to the Default role, every Foreman users will gain that permission. Assigning a different role to a user does not remove the Default role from the user. |
The following types of roles are commonly defined within various Foreman deployments:
- Roles related to applications or parts of infrastructure
-
For example, roles for owners of Enterprise Linux as the operating system as opposed to roles for owners of application servers and database servers.
- Roles related to a particular stage of the software lifecycle
-
For example, roles divided among the development, testing, and production phases, where each phase has one or more owners.
- Roles related to specific tasks
-
For example, you can create a role for security managers and a role for license managers, depending on the specific tasks users need to be able to perform within your organization.
-
For more information, including details about creating custom roles and granting permissions to roles, see Managing users and roles in Administering Foreman.
Best practices for role-based access control in Foreman
-
Define the expected tasks and responsibilities: Define the subset of the Foreman infrastructure that you want the role to access as well as actions permitted on this subset. Think of the responsibilities of the role and how it differs from other roles.
-
Use predefined roles whenever possible: Foreman provides several sample roles that you can use. Copying and editing an existing role can be a good start for creating a custom role.
-
Adopt a granular approach to user role management: Define roles with specific and well-scoped permissions. Note that each user can have multiple roles assigned and that permissions from these roles are cumulative.
-
Add permissions gradually and test the results: When creating a custom role, start with a limited set of permissions and add permissions one by one, while testing continuously. Ensure to test your custom role to verify that it works as intended.
-
Consider areas of interest and granting read-only access: Even though a role has a limited area of responsibility, it might need a wider set of permissions. Therefore, you can grant the role a read-only access to parts of Foreman infrastructure that influence its area of responsibility.
2.1.6. Configuring provisioning
After your basic Foreman infrastructure is in place, you can start configuring provisioning to ensure that Foreman 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 Foreman by connecting the provider as a compute resource to Foreman.
The following Foreman features support automating the provisioning of your hosts:
-
Provisioning templates enable you to define the way Foreman installs an operating system on your hosts.
-
The Discovery service enables you to detect unknown hosts and virtual machines on the provisioning network.
This requires the Discovery plugin. For more information, see Installing the Discovery service in Provisioning hosts.
-
Host groups enable you to standardize provisioning of host configurations.
-
For a complete guide to provisioning, see Provisioning hosts.
2.1.7. Overview of recommended disaster recovery plans
Choose a disaster recovery plan that best helps ensure the continuity of Foreman services in your deployment.
- Snapshots of virtualized Foreman server
-
- How do I back up?
-
Virtualize your Foreman server and use the hypervisor tools to take virtual machine snapshots of the server. This method is suitable if you can run Foreman in a virtual machine.
- How will I recover in case of a disruptive event?
-
To recover Foreman services, restore a virtual machine snapshot.
- Disadvantages and expected impact
-
Expect some amount of data inconsistency after recovery, based on how old your last snapshot is. You will lose data changes that have occurred since the snapshot you are using to recover was taken.
- Active and passive Foreman server, with external storage
-
- How do I back up?
-
Store the following critical data on network attached storage: database in
/var/lib/pgsql
. Replicate this storage into a different data center. Attach the storage to a Foreman server that is a clone of the primary Foreman server but runs passively. - How will I recover in case of a disruptive event?
-
To recover Foreman services, switch DNS records of the active Foreman server with the passive Foreman server. This ensures that the passive server becomes the active server. All hosts remain connected without configuration updates.
- Disadvantages and expected impact
-
If the network attached storage is replicated to another location, expect some amount of data inconsistency after recovery based on the synchronization interval.
- Active and passive Foreman server, with backup and restore
-
- How do I back up?
-
Ensure periodic backups of your Foreman server. Copy this backup to a passive Foreman server and restore it on the passive server.
- How will I recover in case of a disruptive event?
-
To recover Foreman services, switch DNS records of the active Foreman server with the passive Foreman server. This ensures that the passive server becomes the active server. All hosts remain connected without configuration updates.
- Disadvantages and expected impact
-
Expect some amount of data inconsistency after recovery, based on how often you took and restored backups and on how long it takes to complete the restore process.
- Dual active Foreman server
-
- How do I back up?
-
Operate an active, independent Foreman server per data center. Hosts from each data center are registered to the Foreman server in that data center. Then configure automation to ensure recovery in case of a disruptive event. For example, you can periodically run a health check and if the health check discovers that the current Foreman server a host is registered to does not resolve, the host is re-registered to the other Foreman server.
To minimize downtime, you can automate the recovery in various ways. For example, you can use the Foreman Ansible collection. For more information, see Managing Foreman with Ansible in Administering Foreman.
- How will I recover in case of a disruptive event?
-
To recover Foreman services, re-register all hosts to the Foreman server in the other data center.
-
For a complete guide to disaster recovery, see Preparing for disaster recovery and recovering from data loss in Administering Foreman.
-
To create backups of your Foreman server and Smart Proxy servers, use the
foreman-maintain backup
command. For more information, see Backing up Foreman server and Smart Proxy server in Administering Foreman. -
To back up your hosts, you can use remote execution to configure recurring backup tasks that Foreman 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.
2.1.8. Additional deployment tasks
Foreman offers a range of additional capabilities that you can use to further enhance your Foreman deployment. For example:
- Remote execution commands on hosts
-
With remote execution, you can perform various tasks on multiple hosts simultaneously. Foreman supports the following modes of transport for remote execution: pull-based mode (over MQTT/HTTPS) and push-based mode (over SSH).
For more information, see Configuring and setting up remote jobs in Managing hosts.
- Automating tasks with a configuration management tool
-
By integrating Foreman with a configuration management tool, you can automate repetitive tasks and ensure consistent configuration of your hosts.
You can use Ansible to configure hosts. For more information on using Ansible with Foreman, see Configuring hosts by using Ansible.
You can use Puppet to configure hosts. For more information on using Puppet with Foreman, see Configuring hosts by using Puppet.
- Security management with OpenSCAP
-
You can enable the OpenSCAP plugin on your Foreman server and any Smart Proxy servers. With OpenSCAP, you can manage compliance policies and run security compliance scans on your hosts. After the scan completes, a compliance report is uploaded to your Foreman server.
For more information, see Managing security compliance.
- Load balancing
-
With load balancing configured on your Smart Proxy servers, you can improve performance on Smart Proxy servers while also improving performance and stability for host connections to Foreman.
For more information, see Configuring Smart Proxies with a load balancer.
2.2. Common deployment scenarios
This section provides a brief overview of common deployment scenarios for Foreman. Note that many variations and combinations of the following layouts are possible.
2.2.1. Single location with segregated subnets
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.
2.2.2. Multiple locations
Foreman community recommends 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.
2.2.3. Host group structures
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.
- 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 or Smart Proxy server topology determines many other attributes, this approach is the best option. However, 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.
2.3. Provisioning requirements
An important feature of Foreman is unattended provisioning of hosts. To achieve this, Foreman uses DNS and DHCP infrastructures, PXE booting, TFTP, and Kickstart. Use this chapter to understand the working principle of these concepts.
2.3.1. PXE booting
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.
PXE sequence
-
The host boots the PXE image if no other bootable image is found.
-
A NIC of the host sends a broadcast request to the DHCP server.
-
The DHCP server receives the request and sends standard information about the network: IP address, subnet mask, gateway, DNS, the location of a TFTP server, and a boot image.
-
The host obtains the boot loader
image/pxelinux.0
and the configuration filepxelinux.cfg/00:MA:CA:AD:D
from the TFTP server. -
The host configuration specifies the location of a kernel image,
initrd
and Kickstart. -
The host downloads the files and installs the image.
-
For more information about PXE Booting, see Network boot provisioning workflow in Provisioning hosts.
PXE booting requirements
To provision machines using PXE booting, ensure that you meet the following requirements:
-
Optional: If the host and the DHCP server are separated by a router, configure the DHCP relay agent and point to the DHCP server.
-
Ensure that all the network-based firewalls are configured to allow clients on the subnet to access the Smart Proxy. For more information, see Smart Proxy networking.
-
Ensure that your client has access to the DHCP and TFTP servers.
-
Ensure that both Foreman server and Smart Proxy have DNS configured and are able to resolve provisioned host names.
-
Ensure that the UDP ports 67 and 68 are accessible by the client to enable the client to receive a DHCP offer with the boot options.
-
Ensure that the UDP port 69 is accessible by the client so that the client can access the TFTP server on the Smart Proxy.
-
Ensure that the TCP port 80 is accessible by the client to allow the client to download files and Kickstart templates from the Smart Proxy.
-
Ensure that the host provisioning interface subnet has a DHCP Smart Proxy set.
-
Ensure that the host provisioning interface subnet has a TFTP Smart Proxy set.
-
Ensure that the host provisioning interface subnet has a Templates Smart Proxy set.
-
Ensure that DHCP with the correct subnet is enabled using the Foreman installer.
-
Enable TFTP using the Foreman installer.
2.3.2. HTTP booting
You can use HTTP booting to boot systems over a network using HTTP.
HTTP booting requirements with managed DHCP
To provision machines through HTTP booting ensure that you meet the following requirements:
For HTTP booting to work, ensure that your environment has the following client-side configurations:
-
All the network-based firewalls are configured to allow clients on the subnet to access the Smart Proxy. For more information, see Smart Proxy networking.
-
Your client has access to the DHCP and DNS servers.
-
Your client has access to the HTTP UEFI Boot Smart Proxy.
-
Optional: If the host and the DHCP server are separated by a router, configure the DHCP relay agent and point to the DHCP server.
Although TFTP protocol is not used for HTTP UEFI Booting, Foreman uses TFTP Smart Proxy API to deploy boot loader configuration.
For HTTP booting to work, ensure that Foreman has the following configurations:
-
Both Foreman server and Smart Proxy have DNS configured and are able to resolve provisioned host names.
-
The UDP ports 67 and 68 are accessible by the client so that the client can send and receive a DHCP request and offer.
-
Ensure that the TCP port 8000 is open for the client to download the boot loader and Kickstart templates from the Smart Proxy.
-
The TCP port 8443 is open for the client to download the boot loader from the Smart Proxy using the HTTPS protocol.
-
The subnet that functions as the host’s provisioning interface has a DHCP Smart Proxy, an HTTP Boot Smart Proxy, a TFTP Smart Proxy, and a Templates Smart Proxy
HTTP booting requirements with unmanaged DHCP
To provision machines through HTTP booting without managed DHCP ensure that you meet the following requirements:
-
HTTP UEFI Boot URL must be set to one of:
-
http://smartproxy.example.com:8000
-
https://smartproxy.example.com:8443
-
-
Ensure that your client has access to the DHCP and DNS servers.
-
Ensure that your client has access to the HTTP UEFI Boot Smart Proxy.
-
Ensure that all the network-based firewalls are configured to allow clients on the subnet to access the Smart Proxy. For more information, see Smart Proxy networking.
-
An unmanaged DHCP server available for clients.
-
An unmanaged DNS server available for clients. In case DNS is not available, use IP address to configure clients.
Although TFTP protocol is not used for HTTP UEFI Booting, Foreman use TFTP Smart Proxy API to deploy boot loader configuration.
-
Ensure that both Foreman server and Smart Proxy have DNS configured and are able to resolve provisioned host names.
-
Ensure that the UDP ports 67 and 68 are accessible by the client so that the client can send and receive a DHCP request and offer.
-
Ensure that the TCP port 8000 is open for the client to download boot loader and Kickstart templates from the Smart Proxy.
-
Ensure that the TCP port 8443 is open for the client to download the boot loader from the Smart Proxy through HTTPS.
-
Ensure that the host provisioning interface subnet has an HTTP Boot Smart Proxy set.
-
Ensure that the host provisioning interface subnet has a TFTP Smart Proxy set.
-
Ensure that the host provisioning interface subnet has a Templates Smart Proxy set.
Appendix A: Technical users provided and required by Foreman
The Foreman installation process automatically creates system accounts. They manage files and process ownership of the components integrated into Foreman. Some of these accounts have fixed UIDs and GIDs, while others take the next available UID and GID on the system instead. To control the UIDs and GIDs assigned to accounts, you can define accounts before installing Foreman. Because some of the accounts have hard-coded UIDs and GIDs, it is not possible to do this with all accounts created during Foreman installation.
The following table lists all the accounts created by Foreman during installation. You can predefine accounts that have Yes in the Flexible UID and GID column with custom UID and GID before installing Foreman.
Do not change the home and shell directories of system accounts because they are requirements for Foreman.
Because of potential conflicts with local users that Foreman creates, you cannot use external identity providers for the system users of the Foreman base operating system.
User name | UID | Group name | GID | Flexible UID and GID | Home | Shell |
---|---|---|---|---|---|---|
foreman |
N/A |
foreman |
N/A |
yes |
/usr/share/foreman |
/sbin/nologin |
foreman-proxy |
N/A |
foreman-proxy |
N/A |
yes |
/usr/share/foreman-proxy |
/sbin/nologin |
www-data |
33 |
www-data |
33 |
no |
/var/www |
/usr/sbin/nologin |
postgres |
26 |
postgres |
26 |
no |
/var/lib/postgresql |
/bin/bash |
puppet |
52 |
puppet |
52 |
no |
/opt/puppetlabs/server/data/puppetserver |
/sbin/nologin |
Appendix B: Glossary of terms used in Foreman
Foreman is a complete lifecycle management tool for physical hosts, virtual machines, and cloud instances. Key features include automated host provisioning, configuration management, and content management including patch and errata management. You can automate tasks and quickly provision hosts, all through a single unified interface.
This alphabetically ordered glossary provides an overview of Foreman related technical terms.
- Ansible
-
Ansible is an agentless open-source automation engine. For hosts running Linux, Ansible uses SSH to connect to hosts. For hosts running Microsoft Windows, Ansible relies on WinRM. It uses playbooks and roles to describe and bundle tasks. Within Foreman, you can use Ansible to configure hosts and perform remote execution.
For more information about using Ansible to configure hosts, see Configuring hosts by using Ansible. For more information about automating Foreman using Ansible, see Managing Foreman with Ansible in Administering Foreman.
- Answer file
-
A configuration file that defines settings for an installation scenario. Answer files are defined in the YAML format and stored in the
/etc/foreman-installer/scenarios.d/
directory. To see the default values for installation scenario parameters, use theforeman-installer --full-help
command on your Foreman server.
- ARF report
-
Asset Reporting Format (ARF) reports are the result of OpenSCAP compliance scans on hosts which have a policy assigned. Summarizes the security compliance of hosts managed by Foreman. They list compliance criteria and whether the scanned host has passed or failed.
- Audits
-
Provide a report on changes made by a specific user. Audits can be viewed in the Foreman web UI under Monitor > Audits.
- Baseboard management controller (BMC)
-
Enables remote power management of bare-metal hosts. In Foreman, you can create a BMC interface to manage selected hosts.
- Boot disk
-
An ISO image used for PXE-less provisioning. This ISO enables the host to connect to Foreman server, boot the installation media, and install the operating system. There are several kinds of boot disks: host image, full host image, generic image, and subnet image.
- Catalog
-
A document that describes the desired system state for one specific host managed by Puppet. It lists all of the resources that need to be managed, as well as any dependencies between those resources. Catalogs are compiled by a Puppet server from Puppet Manifests and data from Puppet agents.
- Compliance policy
-
Compliance policies refer to the application of SCAP content to hosts by using Foreman with its OpenSCAP plugin. You can create compliance policies by using the Foreman web UI, Hammer CLI, or API. A compliance policy requires the setting of a specific XCCDF profile from a SCAP content, optionally using a tailoring file. You can set up scheduled tasks on Foreman that check your hosts for compliance against SCAP content. When a compliance policy scan completes, the host sends an ARF report to Foreman.
- Compute profile
-
Specifies default attributes for new virtual machines on a compute resource.
- Compute resource
-
A compute resource is an external virtualization or cloud infrastructure that you can attach to Foreman. Foreman can provision, configure, and manage hosts within attached compute resources. Examples of compute resources include VMware or libvirt and cloud providers such as Microsoft Azure or Amazon EC2.
- Configuration Management
-
Configuration management describes the task of configuring and maintaining hosts. In Foreman, you can use Ansible, Puppet, and Salt to configure and maintain hosts with Foreman as a single source of infrastructure truth.
- Discovered host
-
A bare-metal host detected on the provisioning network by the Discovery plugin.
- Discovery image
-
Refers to the minimal operating system based on Enterprise Linux that is PXE-booted on hosts to acquire initial hardware information and to communicate with Foreman server before starting the provisioning process.
- Discovery plugin
-
Enables automatic bare-metal discovery of unknown hosts on the provisioning network. The plugin consists of three components: services running on Foreman server and Smart Proxy server, and the Discovery image running on host.
- Discovery rule
-
A set of predefined provisioning rules which assigns a host group to discovered hosts and triggers provisioning automatically.
- Enterprise Linux
-
An umbrella term for the following Red Hat Enterprise Linux-like operating systems:
-
AlmaLinux
-
CentOS Linux
-
CentOS Stream
-
Oracle Linux
-
Red Hat Enterprise Linux
-
Rocky Linux
Foreman is tested on AlmaLinux and CentOS Stream.
-
- ERB
-
Embedded Ruby (ERB) is a template syntax used in provisioning and job templates.
- External node classifier (ENC)
-
A construct that provides additional data for a server to use when configuring hosts. When Puppet obtains information about nodes from an external source instead of its own database, the external source is called External node classifier. If the Puppet plugin is installed, Foreman can act as an External node classifier to Puppet servers in a Foreman deployment.
- Facter
-
A program that provides information (facts) about the system on which it is run; for example, Facter can report total memory, operating system version, architecture, and more. Puppet modules enable specific configurations based on host data gathered by Facter.
- Facts
-
Host parameters such as total memory, operating system version, or architecture. Facts are reported by Facter and used by Puppet.
- Foreman
-
Foreman is an open-source component to provision and manage hosts.
- Full host image
-
A boot disk used for PXE-less provisioning of a specific host. The full host image contains an embedded Linux kernel and init RAM disk of the associated operating system installer.
- Generic image
-
A boot disk for PXE-less provisioning that is not tied to a specific host. The generic image sends the MAC address of your host to Foreman server, which matches it against the host entry.
- Hammer
-
Hammer is a command-line interface tool for Foreman. You can execute Hammer commands from the command line or utilize it in scripts. You can use Hammer to automate certain recurring tasks as an alternative to Foreman Ansible collection or Foreman API.
- Host
-
A host is a physical, virtual, or cloud instance registered to Foreman.
- Host collection
-
A user defined group of one or more Hosts used for bulk actions such as errata installation.
- Host group
-
A host group is a template to build hosts that holds shared parameters, such as subnet or lifecycle environment. It helps to unify configuration management in Ansible, Puppet, and Salt by grouping hosts. You can nest host groups to create a hierarchical structure. For more information, see Working with host groups in Managing hosts.
- Host image
-
A boot disk used for PXE-less provisioning of a specific host. The host image only contains the boot files necessary to access the installation media on Foreman server.
- Incremental upgrade (of a content view)
-
The act of creating a new (minor) content view version in a lifecycle environment. Incremental upgrades provide a way to make in-place modification of an already published content view. Useful for rapid updates, for example when applying security errata.
- Job
-
A command executed remotely on a host from Foreman server. Every job is defined in a job template.
- Location
-
A collection of default settings that represent a physical place. Location is a tag mostly used for geographical separation of hosts within Foreman. Examples include different cities or different data centers.
- Migrating Foreman
-
The process of moving an existing Foreman installation to a new instance.
- OpenSCAP
-
A project implementing security compliance auditing according to the Security Content Automation Protocol (SCAP). OpenSCAP is integrated in Foreman to provide compliance auditing for hosts.
- Organization
-
An isolated collection of systems, content, and other functionality within Foreman. Organization is a tag used for organizational separation of hosts within Foreman. Examples include different teams or business units.
- Parameter
-
Defines the behavior of Foreman components during provisioning. Depending on the parameter scope, we distinguish between global, domain, host group, and host parameters. Depending on the parameter complexity, we distinguish between simple parameters (key-value pair) and smart parameters (conditional arguments, validation, overrides).
- Parametrized class (smart class parameter)
-
A parameter created by importing a class from Puppet server.
- Permission
-
Defines an action related to a selected part of Foreman infrastructure (resource type). Each resource type is associated with a set of permissions, for example the Architecture resource type has the following permissions: view_architectures, create_architectures, edit_architectures, and destroy_architectures. You can group permissions into roles and associate them with users or user groups.
- Provisioning
-
The provisioning of a host is the deployment of the base operating system on the host and registration of the host to Foreman. Optionally, the process continues with the supply of content and configuration. This process is ideally automated. Provisioned hosts run on compute resources or bare metal, never Foreman server or Smart Proxy servers.
- Provisioning template
-
Provisioning templates are templates that automate deployment of an operating system on hosts. Foreman contains provisioning templates for all supported host operating system families:
-
AutoYaST for SUSE Linux Enterprise Server
-
Kickstart for AlmaLinux, Amazon Linux, CentOS, Oracle Linux, Red Hat Enterprise Linux, and Rocky Linux
-
Preseed files for Debian and Ubuntu
-
- Puppet
-
Puppet is a configuration management tool utilizing a declarative language in a server-client architecture. For more information about using Puppet to configure hosts, see Configuring hosts by using Puppet.
- Puppet agent
-
A service running on a host that applies configuration changes to that host.
- Puppet environment
-
An isolated set of Puppet agent nodes that can be associated with a specific set of Puppet Modules.
- Puppet manifest
-
Refers to Puppet scripts, which are files with the .pp extension. The files contain code to define a set of necessary resources, such as packages, services, files, users and groups, and so on, using a set of key-value pairs for their attributes.
Do not confuse with Manifest (Red Hat subscription manifest).
- Puppet server
-
A Smart Proxy server component that provides a Puppet catalog to hosts for execution by the Puppet agent.
- Puppet module
-
A self-contained bundle of code (Puppet Manifests) and data (facts) that you can use to manage resources such as users, files, and services.
- PXE
-
PXE stands for preboot execution environment and is used to boot operating systems received from the network rather than a local disk. It requires a compatible network interface card (NIC) and relies on DHCP and TFTP.
- Recurring logic
-
A job executed automatically according to a schedule. In the Foreman web UI, you can view those jobs under Monitor > Recurring logics.
- Remote execution (REX)
-
Remote execution is the process of using Foreman to run commands on registered hosts.
- Resource type
-
Refers to a part of Foreman infrastructure, for example host, Smart Proxy, or architecture. Used in permission filtering.
- Role
-
Specifies a collection of permissions that are applied to a set of resources, such as hosts. Roles can be assigned to users and user groups. Foreman provides a number of predefined roles.
- Salt
-
Salt is a configuration management tool used to maintain hosts in certain defined states, for example have packages installed or services running. It is designed to be idempotent. For more information about using Salt to configure hosts, see Configuring hosts by using Salt.
- SCAP content
-
SCAP stands for Security Content Automation Protocol and refers to
.xml
files containing the configuration and security baseline against which hosts are checked. Foreman uses SCAP content in compliance policies.
- Smart Proxy server
-
Smart Proxy servers can provide DHCP, DNS, and TFTP services and act as an Ansible control node, Puppet server, or Salt Master in separate networks. They interact with Foreman server in a client-server model.
Smart Proxy servers are required in Foreman deployments that manage IT infrastructure spanning across multiple networks and useful for Foreman deployments across various geographical locations.
- Subnet image
-
A type of generic image for PXE-less provisioning that communicates through Smart Proxy server.
- Subscription Manager
-
Subscription Manager is a client application to register hosts to Foreman.
- Tailoring files
-
Tailoring files specify a set of modifications to existing SCAP content. They adapt SCAP content to your particular needs without changing the original SCAP content itself.
- Task
-
A background process executed on the Foreman or Smart Proxy server, such as repository synchronization or content view publishing. You can monitor the task status in the Foreman web UI under Monitor > Foreman Tasks > Tasks.
- Trend
-
A means of tracking changes in specific parts of Foreman infrastructure. Configure trends in Foreman web UI under Monitor > Trends. Requires foreman_statistics plugin on your Foreman server.
- Updating Foreman
-
The process of advancing your Foreman server and Smart Proxy server installations from one patch release to the next, for example Foreman nightly.0 to Foreman nightly.1.
- Upgrading Foreman
-
The process of advancing your Foreman server and Smart Proxy server installations from one minor release to the next, for example Foreman 3.14 to Foreman nightly.
- User group
-
A collection of roles which can be assigned to a collection of users.
- User
-
Anyone registered to use Foreman. Authentication and authorization is possible through built-in logic, through external resources (LDAP, Identity Management, or Active Directory), or with Kerberos.
- Virtualization
-
Virtualization describes the process of running multiple operating systems with various applications on a single hardware host using hypervisors like VMware, Proxmox, or libvirt. It facilitates scalability and cost savings. You can attach virtualization infrastructure as compute resources to Foreman. Enable appropriate plugins to access this feature.
- virt-who
-
An agent for retrieving IDs of virtual machines from the hypervisor. When used with Foreman, virt-who reports those IDs to Foreman server so that it can provide subscriptions for hosts provisioned on virtual machines.
- XCCDF profiles
-
Extensible configuration checklist description format (XCCDF) profiles are a component of SCAP content. XCCDF is a language to write security checklists and benchmarks. An XCCDF file contains security configuration rules for lists of hosts.
Appendix C: CLI help
Foreman offers multiple user interfaces: Foreman web UI, Hammer CLI, API, and through Ansible collection theforeman.foreman. If you want to administer Foreman on the command line, have a look at the following help output.
- Foreman services
-
A set of services that Foreman server and Smart Proxy servers use for operation. You can use the
foreman-maintain
tool to manage these services. To see the full list of services, enter theforeman-maintain service list
command on the machine where Foreman or Smart Proxy server is installed. For more information, runforeman-maintain --help
on your Foreman server or Smart Proxy server.
- Foreman plugins
-
You can extend Foreman by installing plugins. For more information, run
foreman-installer --full-help
on your Foreman server or Smart Proxy server.
- Hammer CLI
-
You can manage Foreman on the command line using
hammer
. For more information on using Hammer CLI, see Using the Hammer CLI tool or runhammer --help
on your Foreman server or Smart Proxy server.