1. Overview of Hosts in Foreman
A host is any Linux client that Foreman manages. Hosts can be physical or virtual. Virtual hosts can be deployed 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.
Foreman enables host management at scale, including monitoring, provisioning, remote execution, configuration management, software management, and subscription management. You can manage your hosts from the Foreman web UI or from the command line.
In the Foreman web UI, you can browse all hosts recognized by Foreman server, grouped by type:
-
All Hosts – a list of all hosts recognized by Foreman server.
-
Discovered Hosts – a list of bare-metal hosts detected on the provisioning network by the Discovery plug-in.
-
Content Hosts – a list of hosts that manage tasks related to content and subscriptions.
-
Host Collections – a list of user-defined collections of hosts used for bulk actions such as errata installation.
To search for a host, type in the Search field, and use an asterisk (*) to perform a partial string search.
For example, if searching for a content host named dev-node.example.com
, click the Content Hosts page and type dev-node*
in the Search field.
Alternatively, *node*
will also find the content host dev-node.example.com.
Warning
|
Foreman server is listed as a host itself even if it is not self-registered. Do not delete Foreman server from the list of hosts. |
2. Administering Hosts
This chapter describes creating, registering, administering, and removing hosts.
2.1. Creating a Host in Foreman
Use this procedure to create a host in Foreman. To use the CLI instead of the Foreman web UI, see the CLI procedure.
-
In the Foreman web UI, click Hosts > Create Host.
-
On the Host tab, enter the required details.
-
Click the Ansible Roles tab, and from the Ansible Roles list, select one or more roles that you want to add to the host. Use the arrow icon to manage the roles that you add or remove.
-
On the Puppet Classes tab, select the Puppet classes you want to include.
-
On the Interfaces tab:
-
For each interface, click Edit in the Actions column and configure the following settings as required:
-
Type — For a Bond or BMC interface, use the Type list and select the interface type.
-
MAC address — Enter the MAC address.
-
DNS name — Enter the DNS name that is known to the DNS server. This is used for the host part of the FQDN.
-
Domain — Select the domain name of the provisioning network. This automatically updates the Subnet list with a selection of suitable subnets.
-
IPv4 Subnet — Select an IPv4 subnet for the host from the list.
-
IPv6 Subnet — Select an IPv6 subnet for the host from the list.
-
IPv4 address — If IP address management (IPAM) is enabled for the subnet, the IP address is automatically suggested. Alternatively, you can enter an address. The address can be omitted if provisioning tokens are enabled, if the domain does not mange DNS, if the subnet does not manage reverse DNS, or if the subnet does not manage DHCP reservations.
-
IPv6 address — If IP address management (IPAM) is enabled for the subnet, the IP address is automatically suggested. Alternatively, you can enter an address.
-
Managed — Select this checkbox to configure the interface during provisioning to use the Smart Proxy provided DHCP and DNS services.
-
Primary — Select this checkbox to use the DNS name from this interface as the host portion of the FQDN.
-
Provision — Select this checkbox to use this interface for provisioning. This means TFTP boot will take place using this interface, or in case of image based provisioning, the script to complete the provisioning will be executed through this interface. Note that many provisioning tasks, such as downloading RPMs by anaconda, Puppet setup in a
%post
script, will use the primary interface. -
Virtual NIC — Select this checkbox if this interface is not a physical device. This setting has two options:
-
Tag — Optionally set a VLAN tag. If unset, the tag will be the VLAN ID of the subnet.
-
Attached to — Enter the device name of the interface this virtual interface is attached to.
-
-
-
Click OK to save the interface configuration.
-
Optionally, click Add Interface to include an additional network interface. For more information, see Adding Network Interfaces.
-
Click Submit to apply the changes and exit.
-
-
On the Operating System tab, enter the required details. For Red Hat operating systems, select Synced Content for Media Selection. If you want to use non Red Hat operating systems, select All Media, then select the installation media from the Media Selection list. You can select a partition table from the list or enter a custom partition table in the Custom partition table field. You cannot specify both.
-
On the Parameters tab, click Add Parameter to add any parameter variables that you want to pass to job templates at run time. This includes all Puppet Class, Ansible playbook parameters and host parameters that you want to associate with the host. To use a parameter variable with an Ansible job template, you must add a Host Parameter.
If you want to create a host with pull mode for remote job execution, add the
enable-remote-execution-pull
parameter with typeboolean
set totrue
. For more information, see Transport Modes for Remote Execution. -
On the Additional Information tab, enter additional information about the host.
-
Click Submit to complete your provisioning request.
-
To create a host associated to a host group, enter the following command:
# hammer host create \ --name "My_Host_Name" \ --hostgroup "My_Host_Group" \ --interface="primary=true, \ provision=true, \ mac=mac_address, \ ip=ip_address" \ --organization "My_Organization" \ --location "My_Location" \ --ask-root-password yes
This command prompts you to specify the root password. It is required to specify the host’s IP and MAC address. Other properties of the primary network interface can be inherited from the host group or set using the
--subnet
, and--domain
parameters. You can set additional interfaces using the--interface
option, which accepts a list of key-value pairs. For the list of available interface settings, enter thehammer host create --help
command.
2.2. Cloning Hosts
You can clone existing hosts.
-
In the Foreman web UI, navigate to Hosts > All Hosts.
-
In the Actions menu, click Clone.
-
On the Host tab, ensure to provide a Name different from the original host.
-
On the Interfaces tab, ensure to provide a different IP address.
-
Click Submit to clone the host.
For more information, see Creating a Host in Foreman.
2.3. Associating A Virtual Machine with Foreman from a Hypervisor
-
In the Foreman web UI, navigate to Infrastructure > Compute Resources.
-
Select a compute resource.
-
On the Virtual Machines tab, click Associate VM from the Actions menu.
2.4. Changing a Module Stream for a Host
If you have a host running Enterprise Linux 8, you can modify the module stream for the repositories you install.
You can enable, disable, install, update, and remove module streams from your host in the Foreman web UI.
-
In the Foreman web UI, navigate to Hosts > All Hosts.
-
Click the name of the host you want to modify.
-
Click the Content tab, then click the Module streams tab.
-
Click the vertical ellipsis next to the module and select the action you want to perform. You get a REX job notification once the remote execution job is complete.
2.5. Creating a Host Group
If you create a high volume of hosts, many of the hosts can have common settings and attributes. Adding these settings and attributes for every new host is time consuming. If you use host groups, you can apply common attributes to hosts that you create.
A host group functions as a template for common host settings, containing many of the same details that you provide to hosts. When you create a host with a host group, the host inherits the defined settings from the host group. You can then provide additional details to individualize the host.
To use the CLI instead of the Foreman web UI, see the CLI procedure.
You can create a hierarchy of host groups. Aim to have one base level host group that represents all hosts in your organization and provide general settings, and then nested groups to provide specific settings. For example, you can have a base level host group that defines the operating system, and two nested host groups that inherit the base level host group:
-
Hostgroup:
Base
(Red Hat Enterprise Linux 7.6)-
Hostgroup:
Webserver
(applies thenginx
Puppet class)-
Host:
webserver1.example.com
(web server) -
Host:
webserver2.example.com
(web server)
-
-
Hostgroup:
Storage
(applies thenfs
Puppet class)-
Host:
storage1.example.com
(storage server) -
Host:
storage2.example.com
(storage server)
-
-
Host:
custom.example.com
(custom host)
-
In this example, all hosts use Red Hat Enterprise Linux 7.6 as their operating system because of their inheritance of the Base
host group.
The two web server hosts inherit the settings from the Webserver
host group, which includes the nginx
Puppet class and the settings from the Base
host group.
The two storage servers inherit the settings from the Storage
host group, which includes the nfs
Puppet class and the settings from the Base
host group.
The custom host only inherits the settings from the Base
host group.
-
In the Foreman web UI, navigate to Configure > Host Groups and click Create Host Group.
-
If you have an existing host group that you want to inherit attributes from, you can select a host group from the Parent list. If you do not, leave this field blank.
-
Enter a Name for the new host group.
-
Enter any further information that you want future hosts to inherit.
-
Click the Ansible Roles tab, and from the Ansible Roles list, select one or more roles that you want to add to the host. Use the arrow icon to manage the roles that you add or remove.
-
Click the additional tabs and add any details that you want to attribute to the host group.
NotePuppet fails to retrieve the Puppet CA certificate while registering a host with a host group associated with a Puppet environment created inside a
Production
environment.To create a suitable Puppet environment to be associated with a host group, manually create a directory:
# mkdir /etc/puppetlabs/code/environments/example_environment
-
Click Submit to save the host group.
-
Create the host group with the
hammer hostgroup create
command. For example:# hammer hostgroup create --name "Base" \ --architecture "My_Architecture" \ --content-source-id _My_Content_Source_ID_ \ --content-view "_My_Content_View_" \ --domain "_My_Domain_" \ --lifecycle-environment "_My_Lifecycle_Environment_" \ --locations "_My_Location_" \ --medium-id _My_Installation_Medium_ID_ \ --operatingsystem "_My_Operating_System_" \ --organizations "_My_Organization_" \ --partition-table "_My_Partition_Table_" \ --puppet-ca-proxy-id _My_Puppet_CA_Proxy_ID_ \ --puppet-environment "_My_Puppet_Environment_" \ --puppet-proxy-id _My_Puppet_Proxy_ID_ \ --root-pass "My_Password" \ --subnet "_My_Subnet_"
2.6. Creating a Host Group for Each Lifecycle Environment
Use this procedure to create a host group for the Library lifecycle environment and add nested host groups for other lifecycle environments.
To create a host group for each life cycle environment, run the following Bash script:
MAJOR="My_Major_OS_Version"
ARCH="My_Architecture"
ORG="My_Organization"
LOCATIONS="My_Location"
PTABLE_NAME="My_Partition_Table"
DOMAIN="My_Domain"
hammer --output csv --no-headers lifecycle-environment list --organization "${ORG}" | cut -d ',' -f 2 | while read LC_ENV; do
[[ ${LC_ENV} == "Library" ]] && continue
hammer hostgroup create --name "rhel-${MAJOR}server-${ARCH}-${LC_ENV}" \
--architecture "${ARCH}" \
--partition-table "${PTABLE_NAME}" \
--domain "${DOMAIN}" \
--organizations "${ORG}" \
--query-organization "${ORG}" \
--locations "${LOCATIONS}" \
--lifecycle-environment "${LC_ENV}"
done
2.7. Adding a Host to a Host Group
You can add a host to a host group in the Foreman web UI.
-
In the Foreman web UI, navigate to Hosts > All Hosts.
-
Click the name of the host you want to modify.
-
Click the Edit button.
-
Select the host group from the Host Group list.
-
Click Submit.
-
The Details card under the Overview tab now shows the host group your host belongs to.
2.8. Changing the Host Group of a Host
Use this procedure to change the Host Group of a host.
If you reprovision a host after changing the host group, the fresh values that the host inherits from the host group will be applied.
-
In the Foreman web UI, navigate to Hosts > All Hosts.
-
Click the name of the host you want to modify.
-
Click the Edit button.
-
Select the new host group from the Host Group list.
-
Click Submit.
-
The Details card under the Overview tab now shows the host group your host belongs to.
2.9. Adding a Host to a Host Collection
You can add a host to a host collection in the Foreman web UI.
A host must be registered to Foreman to add it to a Host Collection.
Note that if you add a host to a host collection, the Foreman auditing system does not log the change.
-
In the Foreman web UI, navigate to Hosts > All Hosts.
-
Click the name of the host you want to modify.
-
In the Host collections card, click the vertical ellipsis and select Add host to collections.
-
Select the host collection.
-
Click Add.
-
To add a host to a host collection, enter the following command:
# hammer host-collection add-host \ --host-ids My_Host_ID_1 \ --id My_Host_Collection_ID
2.10. Changing the Content Source of a Host
A content source is a Smart Proxy that a host consumes content from. Use this procedure to change the content source for a host.
-
In the Foreman web UI, navigate to Hosts > All Hosts.
-
Click the name of the host you want to modify.
-
Click the vertical ellipsis icon next to the Edit button and select Change content source.
-
Select Environment, Content View, and Content Source from the lists.
-
Click Change content source.
You can either complete the content source change using remote execution or manually. To update configuration on host using remote execution, click Run job invocation. For more information about running remote execution jobs, see Configuring and Setting up Remote Jobs. To update the content source manually, execute the autogenerated commands from Change content source on the host.
2.11. Changing the Environment of a Host
Use this procedure to change the environment of a host.
-
In the Foreman web UI, navigate to Hosts > All hosts.
-
Click the name of the host you want to modify.
-
Click the vertical ellipsis in the Content view details card and select Edit content view assignment.
-
Select the environment.
-
Select the content view.
-
Click Save.
2.12. Changing the Managed Status of a Host
Hosts provisioned by Foreman are Managed by default. When a host is set to Managed, you can configure additional host parameters from Foreman server. These additional parameters are listed on the Operating System tab. If you change any settings on the Operating System tab, they will not take effect until you set the host to build and reboot it.
If you need to obtain reports about configuration management on systems using an operating system not supported by Foreman, set the host to Unmanaged.
-
In the Foreman web UI, navigate to Hosts > All hosts.
-
Click the name of the host you want to modify.
-
Click the Edit button.
-
Click Manage host or Unmanage host to change the host’s status.
-
Click Submit.
2.13. Enabling Tracer on a Host
Use this procedure to enable Tracer on Foreman and access Traces. Tracer displays a list of services and applications that need to be restarted. Traces is the output generated by Tracer in the Foreman web UI.
-
https://yum.theforeman.org/client/3.3/ repository is synced
-
https://yum.theforeman.org/client/3.3/ repository is available in the content view and the lifecycle environment of the host
-
https://yum.theforeman.org/client/3.3/ repository is enabled for the host
-
Remote execution is enabled
-
In the Foreman web UI, navigate to Hosts > All Hosts.
-
Click the name of the host you want to modify.
-
Click the Traces tab, then click the Enable Traces button.
-
Select the provider to install
katello-host-tools-tracer
from the list. -
Click the Enable Tracer button. You get a REX job notification once the remote execution job is complete.
2.14. Restarting Applications on a Host
Use this procedure to restart applications from the Foreman web UI.
-
In the Foreman web UI, navigate to Hosts > All Hosts.
-
Click the name of the hosts you want to modify.
-
Select the Traces tab.
-
Select applications that you want to restart.
-
Select Restart via remote execution from the Restart app list. You will get a REX job notification once the remote execution job is complete.
2.15. Assigning a Host to a Specific Organization
Use this procedure to assign a host to a specific organization. For general information about organizations and how to configure them, see Managing Organizations in Managing Organizations and Locations in Foreman.
Note
|
If your host is already registered with a different organization, you must first unregister the host before assigning it to a new organization.
To unregister the host, run |
-
In the Foreman web UI, navigate to Hosts > All hosts.
-
Select the checkbox of the host you want to change.
-
From the Select Action list, select Assign Organization. A new option window opens.
-
From the Select Organization list, select the organization that you want to assign your host to. Select the checkbox Fix Organization on Mismatch.
NoteA mismatch happens if there is a resource associated with a host, such as a domain or subnet, and at the same time not associated with the organization you want to assign the host to. The option Fix Organization on Mismatch will add such a resource to the organization, and is therefore the recommended choice. The option Fail on Mismatch will always result in an error message. For example, reassigning a host from one organization to another will fail, even if there is no actual mismatch in settings.
-
Click Submit.
2.16. Assigning a Host to a Specific Location
Use this procedure to assign a host to a specific location. For general information about locations and how to configure them, see Creating a Location in Managing Content.
-
In the Foreman web UI, navigate to Hosts > All hosts.
-
Select the checkbox of the host you want to change.
-
From the Select Action list, select Assign Location. A new option window opens.
-
Navigate to the Select Location list and choose the location that you want for your host. Select the checkbox Fix Location on Mismatch.
NoteA mismatch happens if there is a resource associated with a host, such as a domain or subnet, and at the same time not associated with the location you want to assign the host to. The option Fix Location on Mismatch will add such a resource to the location, and is therefore the recommended choice. The option Fail on Mismatch will always result in an error message. For example, reassigning a host from one location to another will fail, even if there is no actual mismatch in settings.
-
Click Submit.
2.17. Switching between Hosts
When you are on a particular host in the Foreman web UI, you can navigate between hosts without leaving the page by using the host switcher. Click ⇄ next to the hostname. This displays a list of hosts in alphabetical order with a pagination arrow and a search bar to find the host you are looking for.
2.18. Removing a Host from Foreman
Use this procedure to remove a host from Foreman.
-
In the Foreman web UI, navigate to Hosts > All hosts or Hosts > Content Hosts. Note that there is no difference from what page you remove a host, from All hosts or Content Hosts. In both cases, Foreman removes a host completely.
-
Select the hosts that you want to remove.
-
From the Select Action list, select Delete Hosts.
-
Click Submit to remove the host from Foreman permanently.
Warning
|
By default, the To delete a virtual machine on the compute resource, navigate to Administer > Settings and select the Provisioning tab.
Setting |
2.18.1. Disassociating A Virtual Machine from Foreman without Removing It from a Hypervisor
-
In the Foreman web UI, navigate to Hosts > All Hosts and select the checkbox to the left of the hosts to be disassociated.
-
From the Select Action list, select the Disassociate Hosts button.
-
Optional: Select the checkbox to keep the hosts for future action.
-
Click Submit.
2.19. Creating Snapshots of a Managed Host
You can use the Snapshot Management plug-in to create snapshots of managed hosts.
-
You have installed the Snapshot Management plug-in successfully. For more information, see github.com/ATIX-AG/foreman_snapshot_management.
-
Your managed host is running on VMware vSphere or Proxmox.
-
In the Foreman web UI, navigate to Hosts > All Hosts and select a host.
-
On the Snapshots tab, click Create Snapshot.
-
Enter a Name.
-
Optional: Enter a Description.
-
Optional: In the Snapshot Mode field, select Memory if you want to include the RAM in your snapshot or Quiecse if you want to ensure the full state of the VM is written to disk before creating the snapshot.
-
Click Submit to create a snapshot.
Caution
|
Keeping more than three snapshots per host slows down the creation and rollback process. Consider deleting older snapshots when creating new ones. |
3. Registering Hosts and Setting Up Host Integration
You must register hosts that have not been provisioned through Foreman to be able to manage them with Foreman. You can register hosts through Foreman server or Smart Proxy server.
Note that the entitlement-based subscription model is deprecated and will be removed in a future release. Foreman community recommends that you use the access-based subscription model of Simple Content Access instead.
You must also install and configure tools on your hosts, depending on which integration features you want to use. Use the following procedures to install and configure host tools:
3.1. Supported Clients in Registration
Foreman supports the following operating systems and architectures for registration.
Note
|
The following combinations have been tested. Global registration is a provisioning template for a shell script, which can be extended for additional systems. If you decide to extend the template, please submit your changes to our repository. Thanks for your contribution! |
- Supported Host Operating Systems
-
The hosts can use the following operating systems:
-
Amazon Linux
-
Debian
-
Enterprise Linux 9, 8, 7
-
Fedora
-
OpenSUSE
-
SUSE Linux Enterprise Server
-
Ubuntu
-
- Supported Host Architectures
-
The hosts can use the following architectures:
-
x86_64/amd64
-
3.2. Registering Hosts by Using Global Registration
You can register a host to Foreman by generating a curl
command on Foreman and running this command on hosts.
This method uses two provisioning templates: Global Registration template and Linux host_init_config default template.
That gives you complete control over the host registration process.
You can also customize the default templates if you need greater flexibility. For more information, see Customizing the Registration Templates.
-
You can extend registration options by plug-ins. For more information, see How to Create a Plugin and Slot and Fill.
3.2.1. Global Parameters for Registration
You can configure the following global parameters by navigating to Configure > Global Parameters:
-
The
host_registration_insights
parameter is used in theinsights
snippet. If the parameter is set totrue
, the registration installs and enables the Red Hat Insights client on the host. If the parameter is set tofalse
, it prevents Foreman and the Red Hat Insights client from uploading Inventory reports to your Red Hat Hybrid Cloud Console. The default value isfalse
. When overriding the parameter value, set the parameter type toboolean
. -
The
host_packages
parameter is for installing packages on the host. -
The
host_registration_remote_execution
parameter is used in theremote_execution_ssh_keys
snippet. If it is set totrue
, the registration enables remote execution on the host. The default value istrue
. -
The
remote_execution_ssh_keys
,remote_execution_ssh_user
,remote_execution_create_user
, andremote_execution_effective_user_method
parameters are used in theremote_execution_ssh_keys
snippet. For more details, see the snippet.
You can navigate to snippets in the Foreman web UI through Hosts > Templates > Provisioning Templates.
3.2.2. Registering a Host
You can register a host by using registration templates and set up various integration features and host tools during the registration process.
-
Your user account has a role assigned that has the
create_hosts
permission. -
You must have root privileges on the host that you want to register.
-
If you want to use Smart Proxy servers instead of your Foreman server, ensure that you have configured your Smart Proxy servers accordingly. For more information, see Configuring Smart Proxy for Host Registration and Provisioning in Installing an External Smart Proxy Server 3.3.
-
If your Foreman server or Smart Proxy server is behind an HTTP proxy, configure the Subscription Manager on your host to use the HTTP proxy for connection.
-
In the Foreman web UI, navigate to Hosts > Register Host.
-
Optional: Select a different Organization.
-
Optional: Select a different Location.
-
Optional: From the Host Group list, select the host group to associate the hosts with. Fields that inherit value from Host group: Operating system, Activation Keys and Lifecycle environment.
-
Optional: From the Operating system list, select the operating system of hosts that you want to register. Specifying an operating system is required when you register machines without
subscription-manager
, such as Debian or Ubuntu. -
Optional: From the Smart Proxy list, select the Smart Proxy to register hosts through.
-
Optional: Select the Insecure option, if you want to make the first call insecure. During this first call, hosts download the CA file from Foreman. Hosts will use this CA file to connect to Foreman with all future calls making them secure.
Foreman community recommends that you avoid insecure calls.
If an attacker, located in the network between Foreman and a host, fetches the CA file from the first insecure call, the attacker will be able to access the content of the API calls to and from the registered host and the JSON Web Tokens (JWT). Therefore, if you have chosen to deploy SSH keys during registration, the attacker will be able to access the host using the SSH key.
Instead, you can manually copy and install the CA file on each host before registering the host.
To do this, find where Foreman stores the CA file by navigating to Administer > Settings > Authentication and locating the value of the SSL CA file setting.
Copy the CA file to the
/etc/pki/ca-trust/source/anchors/
directory on hosts and enter the following commands:# update-ca-trust enable # update-ca-trust
Then register the hosts with a secure
curl
command, such as:# curl -sS https://foreman.example.com/register ...
The following is an example of the
curl
command with the--insecure
option:# curl -sS --insecure https://foreman.example.com/register ...
-
Select the Advanced tab.
-
From the Setup REX list, select whether you want to deploy Foreman SSH keys to hosts or not.
If set to
Yes
, public SSH keys will be installed on the registered host. The inherited value is based on thehost_registration_remote_execution
parameter. It can be inherited, for example from a host group, an operating system, or an organization. When overridden, the selected value will be stored on host parameter level. -
From the Setup Insights list, select whether you want to install
insights-client
and register the hosts to Insights.The Insights tool is available for Red Hat Enterprise Linux only. It has no effect on other operating systems.
You must enable the following repositories on a registered machine:
-
Red Hat Enterprise Linux 6:
rhel-6-server-rpms
-
Red Hat Enterprise Linux 7:
rhel-7-server-rpms
-
Red Hat Enterprise Linux 8:
rhel-8-for-x86_64-appstream-rpms
The
insights-client
package is installed by default on Red Hat Enterprise Linux 8 except in environments whereby Red Hat Enterprise Linux 8 was deployed with "Minimal Install" option.
-
-
Optional: In the Install packages field, list the packages (separated with spaces) that you want to install on the host upon registration. This can be set by the
host_packages
parameter. -
Optional: Select the Update packages option to update all packages on the host upon registration. This can be set by the
host_update_packages
parameter. -
Optional: In the Repository field, enter a repository to be added before the registration is performed. For example, it can be useful to make the
subscription-manager
package available for the purpose of the registration. For Red Hat family distributions, enter the URL of the repository, for examplehttp://rpm.example.com/
. For Debian OS families, enter the whole line of list file content, for exampledeb http://deb.example.com/ buster 1.0
. -
Optional: In the Repository GPG key URL field, specify the public key to verify the signatures of GPG-signed packages. It needs to be specified in the ASCII form with the GPG public key header.
-
Optional: In the Token lifetime (hours) field, change the validity duration of the JSON Web Token (JWT) that Foreman uses for authentication. The duration of this token defines how long the generated
curl
command works. You can set the duration to 0 – 999 999 hours or unlimited.Note that Foreman applies the permissions of the user who generates the
curl
command to authorization of hosts. If the user loses or gains additional permissions, the permissions of the JWT change too. Therefore, do not delete, block, or change permissions of the user during the token duration.The scope of the JWTs is limited to the registration endpoints only and cannot be used anywhere else.
-
Optional: In the Remote Execution Interface field, enter the identifier of a network interface that hosts must use for the SSH connection. If you keep this field blank, Foreman uses the default network interface.
-
From the REX pull mode list, select whether you want to deploy Foreman remote execution pull client.
If set to
Yes
, the remote execution pull client is installed on the registered host. The inherited value is based on thehost_registration_remote_execution_pull
parameter. It can be inherited, for example from a host group, an operating system, or an organization. When overridden, the selected value is stored on the host parameter level.The registered host must have access to the Foreman community https://yum.theforeman.org/client/3.3/ repository.
For more information about the pull mode, see Transport Modes for Remote Execution.
-
Optional: This step is for the Katello users only. If you register Red Hat Enterprise Linux or CentOS hosts, in the Activation Keys field, enter one or more activation keys to assign to registered hosts.
-
Click the Generate button.
-
Copy the generated
curl
command. -
On the host that you want to register, run the
curl
command asroot
.
3.2.3. Customizing the Registration Templates
You can customize the registration process by editing the provisioning templates. Note that all default templates in Foreman are locked. If you want to customize the registration templates, you must clone the default templates and edit the clones.
Note
|
Foreman community only provides support for the original unedited templates. Customized templates do not receive updates released by Foreman community. |
The registration process uses the following provisioning templates:
-
The Global Registration template contains steps for registering hosts to Foreman. This template renders when hosts access the
/register
Foreman API endpoint. -
The Linux host_init_config default template contains steps for initial configuration of hosts after they are registered.
-
Navigate to Hosts > Templates > Provisioning Templates.
-
Search for the template you want to edit.
-
In the row of the required template, click Clone.
-
Edit the template as needed. For more information, see Template Writing Reference.
-
Click Submit.
-
Navigate to Administer > Settings > Provisioning.
-
Change the following settings as needed:
-
Point the Default Global registration template setting to your custom global registration template,
-
Point the Default 'Host initial configuration' template setting to your custom initial configuration template.
-
3.3. Installing the Katello Agent
You can install the Katello agent to remotely update Foreman clients.
Note
|
The Katello agent is deprecated and will be removed in a future Foreman version. Migrate your processes to use the remote execution feature to update clients remotely. For more information, see Migrating from Katello Agent to Remote Execution in Managing Hosts. |
The katello-agent
package depends on the gofer
package that provides the goferd
service.
-
You have enabled the https://yum.theforeman.org/client/3.3/ repository on the client.
-
Install the
katello-agent
package:# yum install katello-agent
-
Start the
goferd
service:# systemctl start goferd
3.4. Installing Tracer
Use this procedure to install Tracer on Foreman and access Traces. Tracer displays a list of services and applications that are outdated and need to be restarted. Traces is the output generated by Tracer in the Foreman web UI.
-
The host must be registered to Foreman.
-
The Foreman community https://yum.theforeman.org/client/3.3/ repository must be enabled and synchronized on Foreman server, and enabled on the host.
-
On the content host, install the
katello-host-tools-tracer
RPM package:# yum install katello-host-tools-tracer
-
Enter the following command:
# katello-tracer-upload
-
In the Foreman web UI, navigate to Hosts > All hosts, then click the required host name.
-
Click the Traces tab to view Traces. If it is not installed, an Enable Traces button initiates a remote execution job that installs the package.
3.5. Installing and Configuring Puppet Agent during Host Registration
You can install and configure the Puppet agent on the host during registration. A configured Puppet agent is required on the host for Puppet integration with your Foreman. For more information about Puppet, see Configuring Hosts Using Puppet.
-
You created a Product and repository for the upstream Puppet agent, such as
https://yum.puppet.com
orhttps://apt.puppet.com
, and synchronized the repository to Foreman. For more information, see Importing Content in Managing Content. -
You created an activation key that enables the Puppet agent repository for hosts. For more information, see Managing Activation Keys in Managing Content.
-
In the Foreman web UI, navigate to Configure > Global Parameters to add host parameters globally. Alternatively, you can navigate to Configure > Host Groups and edit or create a host group to add host parameters only to a host group.
-
Enable the Puppet agent using a host parameter in global parameters or a host group. Add a host parameter named
enable-puppet7
, select the boolean type, and set the value totrue
. -
Specify configuration for the Puppet agent using the following host parameters in global parameters or a host group:
-
Add a host parameter named
puppet_server
, select the string type, and set the value to the hostname of your Puppet server, such aspuppet.example.com
. -
Optional: Add a host parameter named
puppet_ca_server
, select the string type, and set the value to the hostname of your Puppet CA server, such aspuppet-ca.example.com
. Ifpuppet_ca_server
is not set, the Puppet agent will use the same server aspuppet_server
. -
Optional: Add a host parameter named
puppet_environment
, select the string type, and set the value to the Puppet environment you want the host to use.
Until the BZ2177730 is resolved, you must use host parameters to specify the Puppet agent configuration even in integrated setups where the Puppet server is a Smart Proxy server.
-
-
Navigate to Hosts > Register Host and register your host using an appropriate activation key. For more information, see Registering Hosts in Managing Hosts.
-
Navigate to Infrastructure > Smart Proxies.
-
From the list in the Actions column for the required Smart Proxy server, select Certificates.
-
Click Sign to the right of the required host to sign the SSL certificate for the Puppet agent.
3.6. Installing and Configuring Puppet Agent Manually
You can install and configure the Puppet agent on a host manually. A configured Puppet agent is required on the host for Puppet integration with your Foreman. For more information about Puppet, see Configuring Hosts Using Puppet.
-
The host must have a Puppet environment assigned to it.
-
Ensure a repository containing the Puppet agent is enabled on the host, for example apt.puppet.com or yum.puppet.com.
-
Log in to the host as the
root
user. -
Install the Puppet agent package.
-
On hosts running Enterprise Linux 8 and above:
# dnf install puppet-agent
-
On hosts running Enterprise Linux 7 and below:
# yum install puppet-agent
-
On hosts running Debian:
# apt-get install puppet-agent
-
On hosts running SUSE Linux Enterprise Server:
# zypper install puppet-agent
-
-
Add the Puppet agent to
PATH
in your current shell using the following script:. /etc/profile.d/puppet-agent.sh
-
Configure the Puppet agent. Set the
environment
parameter to the name of the Puppet environment to which the host belongs:# puppet config set server foreman.example.com --section agent # puppet config set environment My_Puppet_Environment --section agent
-
Start the Puppet agent service:
# puppet resource service puppet ensure=running enable=true
-
Create a certificate for the host:
# puppet ssl bootstrap
-
In the Foreman web UI, navigate to Infrastructure > Smart Proxies.
-
From the list in the Actions column for the required Smart Proxy server, select Certificates.
-
Click Sign to the right of the required host to sign the SSL certificate for the Puppet agent.
-
On the host, run the Puppet agent again:
# puppet ssl bootstrap
4. Migrating Hosts From Katello Agent to Remote Execution
Remote Execution is the preferred way to manage package content on hosts. The Katello Agent is deprecated and will be removed in a future Foreman version. Follow these steps to switch to Remote Execution.
-
You have previously installed the
katello-agent
package on content hosts.
-
If you have Remote Execution configured to use
ssh
mode, distribute the remote execution SSH keys to the hosts. For more information, see Distributing SSH Keys for Remote Execution. -
If you have Remote Execution configured to use
pull-mqtt
mode, deploy the remote execution pull client to the hosts. For more information, see Configuring a Host to Use the Pull Client. -
Stop the goferd service on content hosts:
# systemctl stop goferd
-
Disable the goferd service on content hosts:
# systemctl disable goferd
-
Remove the Katello agent on content hosts:
WarningIf your host is installed on oVirt version 4.4 or lower, do not remove the katello-agent
package because the removed dependencies corrupt the host.# yum remove katello-agent
-
In the Foreman web UI, navigate to Administer > Settings.
-
Select the Content tab.
-
Set the Use remote execution by default parameter to Yes.
The Foreman server now uses host management by remote execution instead of Katello Agent.
The following table shows the remote execution equivalent commands to perform specific package actions.
See hammer job-invocation create --help
to learn how to specify search queries to determine the target hosts or host collections.
Action | Katello Agent | Remote Execution |
---|---|---|
Install a package |
|
|
Install a package (host collection) |
|
|
Remove a package |
|
|
Remove a package (host collection) |
|
|
Update a package |
|
|
Update a package (host collection) |
|
|
Update all packages |
|
|
Install errata |
|
|
Install errata (host collection) |
|
|
Install a package group |
|
|
Install a package group (host collection) |
|
|
Remove a package group |
|
|
Remove a package group (host collection) |
|
|
Update a package group |
|
|
Update a package group (host collection) |
|
|
5. Adding Network Interfaces
Foreman supports specifying multiple network interfaces for a single host. You can configure these interfaces when creating a new host as described in Creating a Host in Foreman or when editing an existing host.
There are several types of network interfaces that you can attach to a host. When adding a new interface, select one of:
-
Interface: Allows you to specify an additional physical or virtual interface. There are two types of virtual interfaces you can create. Use VLAN when the host needs to communicate with several (virtual) networks using a single interface, while these networks are not accessible to each other. Use alias to add an additional IP address to an existing interface.
For more information about adding a physical interface, see Adding a Physical Interface.
For more information about adding a virtual interface, see Adding a Virtual Interface.
-
Bond: Creates a bonded interface. NIC bonding is a way to bind multiple network interfaces together into a single interface that appears as a single device and has a single MAC address. This enables two or more network interfaces to act as one, increasing the bandwidth and providing redundancy. For more information, see Adding a Bonded Interface.
-
BMC: Baseboard Management Controller (BMC) allows you to remotely monitor and manage the physical state of machines. For more information about BMC, see Enabling Power Management on Managed Hosts in Installing Foreman 3.3 Server with Katello 4.5 Plugin on RHEL/CentOS. For more information about configuring BMC interfaces, see Adding a Baseboard Management Controller (BMC) Interface.
Note
|
Additional interfaces have the Managed flag enabled by default, which means the new interface is configured automatically during provisioning by the DNS and DHCP Smart Proxy servers associated with the selected subnet.
This requires a subnet with correctly configured DNS and DHCP Smart Proxy servers.
If you use a Kickstart method for host provisioning, configuration files are automatically created for managed interfaces in the post-installation phase at |
Note
|
Virtual and bonded interfaces currently require a MAC address of a physical device. Therefore, the configuration of these interfaces works only on bare-metal hosts. |
5.1. Adding a Physical Interface
Use this procedure to add an additional physical interface to a host.
-
In the Foreman web UI, navigate to Hosts > All hosts.
-
Click Edit next to the host you want to edit.
-
On the Interfaces tab, click Add Interface.
-
Keep the Interface option selected in the Type list.
-
Specify a MAC address. This setting is required.
-
Specify the Device Identifier, for example eth0. The identifier is used to specify this physical interface when creating bonded interfaces, VLANs, and aliases.
-
Specify the DNS name associated with the host’s IP address. Foreman saves this name in Smart Proxy server associated with the selected domain (the "DNS A" field) and Smart Proxy server associated with the selected subnet (the "DNS PTR" field). A single host can therefore have several DNS entries.
-
Select a domain from the Domain list. To create and manage domains, navigate to Infrastructure > Domains.
-
Select a subnet from the Subnet list. To create and manage subnets, navigate to Infrastructure > Subnets.
-
Specify the IP address. Managed interfaces with an assigned DHCP Smart Proxy server require this setting for creating a DHCP lease. DHCP-enabled managed interfaces are automatically provided with a suggested IP address.
-
Select whether the interface is Managed. If the interface is managed, configuration is pulled from the associated Smart Proxy server during provisioning, and DNS and DHCP entries are created. If using kickstart provisioning, a configuration file is automatically created for the interface.
-
Select whether this is the Primary interface for the host. The DNS name from the primary interface is used as the host portion of the FQDN.
-
Select whether this is the Provision interface for the host. TFTP boot takes place using the provisioning interface. For image-based provisioning, the script to complete the provisioning is executed through the provisioning interface.
-
Select whether to use the interface for Remote execution.
-
Leave the Virtual NIC checkbox clear.
-
Click OK to save the interface configuration.
-
Click Submit to apply the changes to the host.
5.2. Adding a Virtual Interface
Use this procedure to configure a virtual interface for a host. This can be either a VLAN or an alias interface.
An alias interface is an additional IP address attached to an existing interface.
An alias interface automatically inherits a MAC address from the interface it is attached to; therefore, you can create an alias without specifying a MAC address.
The interface must be specified in a subnet with boot mode set to static
.
-
In the Foreman web UI, navigate to Hosts > All hosts.
-
Click Edit next to the host you want to edit.
-
On the Interfaces tab, click Add Interface.
-
Keep the Interface option selected in the Type list.
-
Specify the general interface settings. The applicable configuration options are the same as for the physical interfaces described in Adding a Physical Interface.
Specify a MAC address for managed virtual interfaces so that the configuration files for provisioning are generated correctly. However, a MAC address is not required for virtual interfaces that are not managed.
If creating a VLAN, specify ID in the form of eth1.10 in the Device Identifier field. If creating an alias, use ID in the form of eth1:10.
-
Select the Virtual NIC checkbox. Additional configuration options specific to virtual interfaces are appended to the form:
-
Tag: Optionally set a VLAN tag to trunk a network segment from the physical network through to the virtual interface. If you do not specify a tag, managed interfaces inherit the VLAN tag of the associated subnet. User-specified entries from this field are not applied to alias interfaces.
-
Attached to: Specify the identifier of the physical interface to which the virtual interface belongs, for example eth1. This setting is required.
-
-
Click OK to save the interface configuration.
-
Click Submit to apply the changes to the host.
5.3. Adding a Bonded Interface
Use this procedure to configure a bonded interface for a host. To use the CLI instead of the Foreman web UI, see the CLI procedure.
-
In the Foreman web UI, navigate to Hosts > All hosts.
-
Click Edit next to the host you want to edit.
-
On the Interfaces tab, click Add Interface.
-
Select Bond from the Type list. Additional type-specific configuration options are appended to the form.
-
Specify the general interface settings. The applicable configuration options are the same as for the physical interfaces described in Adding a Physical Interface.
Bonded interfaces use IDs in the form of bond0 in the Device Identifier field.
A single MAC address is sufficient.
If you are adding a secondary interface, select Managed. Otherwise, Foreman does not apply the configuration.
-
Specify the configuration options specific to bonded interfaces:
-
Mode: Select the bonding mode that defines a policy for fault tolerance and load balancing. See Bonding Modes Available in Foreman for a brief description of each bonding mode.
-
Attached devices: Specify a comma-separated list of identifiers of attached devices. These can be physical interfaces or VLANs.
-
Bond options: Specify a space-separated list of configuration options, for example miimon=100.
-
-
Click OK to save the interface configuration.
-
Click Submit to apply the changes to the host.
-
To create a host with a bonded interface, enter the following command:
# hammer host create --name bonded_interface \ --hostgroup-id 1 \ --ip=192.168.100.123 \ --mac=52:54:00:14:92:2a \ --subnet-id=1 \ --managed true \ --interface="identifier=eth1, \ mac=52:54:00:62:43:06, \ managed=true, \ type=Nic::Managed, \ domain_id=1, \ subnet_id=1" \ --interface="identifier=eth2, \ mac=52:54:00:d3:87:8f, \ managed=true, \ type=Nic::Managed, \ domain_id=1, \ subnet_id=1" \ --interface="identifier=bond0, \ ip=172.25.18.123, \ type=Nic::Bond, \ mode=active-backup, \ attached_devices=[eth1,eth2], \ managed=true, \ domain_id=1, \ subnet_id=1" \ --organization "My_Organization" \ --location "My_Location" \ --ask-root-password yes
5.4. Bonding Modes Available in Foreman
Bonding Mode | Description |
---|---|
balance-rr |
Transmissions are received and sent sequentially on each bonded interface. |
active-backup |
Transmissions are received and sent through the first available bonded interface. Another bonded interface is only used if the active bonded interface fails. |
balance-xor |
Transmissions are based on the selected hash policy. In this mode, traffic destined for specific peers is always sent over the same interface. |
broadcast |
All transmissions are sent on all bonded interfaces. |
802.a3 |
Creates aggregation groups that share the same settings. Transmits and receives on all interfaces in the active group. |
balance-tlb |
The outgoing traffic is distributed according to the current load on each bonded interface. |
balance-alb |
Receive load balancing is achieved through Address Resolution Protocol (ARP) negotiation. |
5.5. Adding a Baseboard Management Controller (BMC) Interface
Use this procedure to configure a baseboard management controller (BMC) interface for a host that supports this feature.
-
The
ipmitool
package is installed. -
You know the MAC address, IP address, and other details of the BMC interface on the host, and the appropriate credentials for that interface.
NoteYou only need the MAC address for the BMC interface if the BMC interface is managed, so that it can create a DHCP reservation.
-
Enable BMC on the Smart Proxy server if it is not already enabled:
-
Configure BMC power management on Smart Proxy server by running the
foreman-installer
script with the following options:# foreman-installer --foreman-proxy-bmc=true \ --foreman-proxy-bmc-default-provider=ipmitool
-
In the Foreman web UI, navigate to Infrastructure > Smart Proxies.
-
From the list in the Actions column, click Refresh. The list in the Features column should now include BMC.
-
-
In the Foreman web UI, navigate to Hosts > All hosts.
-
Click Edit next to the host you want to edit.
-
On the Interfaces tab, click Add Interface.
-
Select BMC from the Type list. Type-specific configuration options are appended to the form.
-
Specify the general interface settings. The applicable configuration options are the same as for the physical interfaces described in Adding a Physical Interface.
-
Specify the configuration options specific to BMC interfaces:
-
Username and Password: Specify any authentication credentials required by BMC.
-
Provider: Specify the BMC provider.
-
-
Click OK to save the interface configuration.
-
Click Submit to apply the changes to the host.
6. Upgrading Hosts to Next Major Red Hat Enterprise Linux Release
You can use a job template to upgrade your Red Hat Enterprise Linux hosts to the next major release. Below upgrade paths are possible:
-
Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8
-
Red Hat Enterprise Linux 8 to Red Hat Enterprise Linux 9
-
Ensure that your Red Hat Enterprise Linux hosts meet the requirements for the upgrade.
-
For Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8 upgrade, see Planning an upgrade in Upgrading from RHEL 7 to RHEL 8.
-
For Red Hat Enterprise Linux 8 to Red Hat Enterprise Linux 9 upgrade, see Planning an upgrade to RHEL 9 in Upgrading from RHEL 8 to RHEL 9.
-
-
Prepare your Red Hat Enterprise Linux hosts for the upgrade.
-
For Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8 upgrade, see Preparing a RHEL 7 system for the upgrade in Upgrading from RHEL 7 to RHEL 8.
-
For Red Hat Enterprise Linux 8 to Red Hat Enterprise Linux 9 upgrade, see Preparing a RHEL 8 system for the upgrade in Upgrading from RHEL 8 to RHEL 9.
-
-
Enable remote execution feature on Foreman. For more information, see Configuring and Setting Up Remote Jobs.
-
Distribute Foreman SSH keys to the hosts that you want to upgrade. For more information, see Distributing SSH Keys for Remote Execution.
-
On Foreman, enable the Leapp plugin:
# foreman-installer --enable-foreman-plugin-leapp
-
In the Foreman web UI, navigate to Hosts > All Hosts.
-
Select the hosts that you want to upgrade to the next major Red Hat Enterprise Linux version.
-
In the upper right of the Hosts window, from the Select Action list, select Preupgrade check with Leapp.
-
Click Submit to start the pre-upgrade check.
-
When the check is finished, click the Leapp preupgrade report tab to see if Leapp has found any issues on your hosts. Issues that have the Inhibitor flag are considered crucial and are likely to break the upgrade procedure. Issues that have the Has Remediation flag contain remediation that can help you fix the issue.
-
Click an issue that is flagged as Has Remediation to expand it.
-
If the issue contains a remediation Command, you can fix it directly from Foreman using remote execution. Select the issue.
-
If the issue contains only a remediation Hint, use the hint to fix the issue on the host manually.
Repeat this step for other issues.
-
-
After you selected any issues with remediation commands, click Fix Selected and submit the job.
-
After the issues are fixed, click the Rerun button, and then click Submit to run the pre-upgrade check again to verify that the hosts you are upgrading do not have any issues and are ready to be upgraded.
-
-
If the pre-upgrade check verifies that the hosts do not have any issues, click the Run Upgrade button and click Submit to start the upgrade.
7. Converting a Host to Red Hat Enterprise Linux
You can convert Red Hat Enterprise Linux derivative distributions into a supportable Red Hat Enterprise Linux on a host while retaining installed applications and configurations. Foreman provides the Convert2RHEL utility to simplify the conversion process.
The Convert2RHEL utility in Foreman consists of an Ansible role and Ansible playbook. You use the Ansible role to generate conversion data on Foreman server, which includes enabling required repositories and creating products, activation keys, and host groups. Then you perform the actual conversion on the host using the Ansible playbook, which installs the Convert2RHEL CLI tool on the host and runs it.
You can use the Ansible role to generate conversion data for the following conversions:
-
CentOS Linux 7 to Red Hat Enterprise Linux 7
-
Oracle Linux 7 to Red Hat Enterprise Linux 7
-
CentOS Linux 8 to Red Hat Enterprise Linux 8
-
Oracle Linux 8 to Red Hat Enterprise Linux 8
These conversions are supported by Red Hat. You can use the Ansible playbook for other conversions as well, but in those cases you must enable required repositories and configure activation keys manually instead of using the Ansible role and variables. However, this approach was not tested and is not supported.
The conversion process is similar to a minor release upgrade of Red Hat Enterprise Linux in which every RPM package on the system is replaced. Third-party packages and non-Red Hat packages that are not available in Red Hat Enterprise Linux are retained.
The Convert2RHEL utility removes unnecessary packages such as logos or packages known to cause issues during the conversion.
The utility replaces the CentOS-release
or Oracle-release
package with the rhel-release
package, and all packages signed by CentOS or Oracle with their Red Hat equivalents.
The utility also subscribes the host to Foreman community Subscription Management.
The duration of the conversion process depends on the number of packages that have to be replaced, network speed, storage speed, and similar factors.
-
Review Supported conversion paths in Converting from an RPM-based Linux distribution to RHEL.
-
You must have completed the steps 1. – 5. of the procedure Preparing for a RHEL conversion in Converting from an RPM-based Linux distribution to RHEL.
-
Ensure you have a subscription manifest uploaded to your Foreman and that there are sufficient Red Hat Enterprise Linux entitlements allocated for the conversions you intend. Alternatively, you can use Ansible variables to tell the role to import the manifest from disk. The manifest must be imported to the organization to which you will register hosts for conversion.
You can update your allocations and download the updated manifest from the Red Hat Customer Portal. For more information, see Using manifests in Red Hat Subscription Management.
-
Ensure that you have enabled Red Hat repositories in Foreman for the minor Red Hat Enterprise Linux version to which you convert your hosts.
-
Import the
theforeman.foreman.convert2rhel
Ansible role and variables. For more information, see Importing Ansible Roles and Variables in Configuring Hosts Using Ansible. -
Configure Ansible variables for generation of conversion data. For more information, see Ansible Variables for Conversion.
-
Assign the
theforeman.foreman.convert2rhel
role to the host that represents Foreman server. For more information, see Assigning Ansible Roles to an Existing Host in Configuring Hosts Using Ansible. -
Run the Ansible role on Foreman server. For more information, see Running Ansible Roles on a Host in Configuring Hosts Using Ansible.
The Ansible role generates data required for host conversion, that is, repositories, certificates, activation keys, and host groups. The role enables the
rhel-7-server-rpms
repository with the 7Server release and x86_64 architecture, orrhel-8-for-x86_64-baseos-rpms
andrhel-8-for-x86_64-appstream-rpms
, or both, depending on which variables you have set in the previous steps. -
Register a host for conversion using a generated host group.
Use the global registration template to register and subscribe your host before the conversion. Select the host group that was generated for the conversion you intend, such as
CentOS 8 converting
if you convert the host from CentOS 8. For more information, see Registering Hosts by Using Global Registration. -
Run the Convert2RHEL playbook on the host. Execute a remote job with the following settings:
-
Job category:
Convert 2 RHEL
-
Job template:
Convert to RHEL
-
Activation key:
convert2rhel_rhel7
orconvert2rhel_rhel8
For more information, see Executing a Remote Job.
-
7.1. Ansible Variables for Conversion
Before you run the Ansible role to generate conversion data, configure values of the following required Ansible variables.
Foreman imports most of the required Ansible variables from the theforeman.foreman.convert2rhel
role.
However, some variables are not imported.
These variables are marked with an asterisk *
in the tables below.
You must create those additional variables manually and assign them to the theforeman.foreman.convert2rhel
role.
Name | Type | Intent and value |
---|---|---|
|
string |
URL of your Foreman server, such as |
|
string |
Your user name |
|
string |
Your password |
|
string |
Name of your organization |
|
boolean |
Set to |
|
boolean |
Set to |
|
boolean |
Set to |
|
boolean |
Enables Red Hat Enterprise Linux 7 repositories.
Set to |
|
boolean |
Set to |
|
boolean |
Enables Red Hat Enterprise Linux 8 repositories.
Set to |
|
boolean |
Set to |
Name | Type | Intent and value |
---|---|---|
|
string |
Path to a manifest to upload from disk, such as |
|
string |
Minor release version, such as |
8. Host Management and Monitoring Using Cockpit
Cockpit is an interactive web interface that you can use to perform actions and monitor Enterprise Linux hosts. You can enable a remote-execution feature to integrate Foreman with Cockpit. When you install Cockpit on a host that you manage with Foreman, you can view the Cockpit dashboards of that host from within the Foreman web UI. You can also use the features that are integrated with Cockpit, for example, Lorax Composer.
8.1. Enabling Cockpit on Foreman
By default, Cockpit integration is disabled in Foreman. If you want to access Cockpit features for your hosts from within Foreman, you must first enable Cockpit integration on Foreman server.
-
On Foreman server, run
foreman-installer
with the--enable-foreman-plugin-remote-execution-cockpit
option:# foreman-installer --enable-foreman-plugin-remote-execution-cockpit
8.2. Managing and Monitoring Hosts Using Cockpit
You can access the Cockpit web UI through the Foreman web UI and use the functionality to manage and monitor hosts in Foreman.
-
Cockpit is enabled in Foreman.
-
Cockpit is installed on the host that you want to view:
-
For more information see Running Cockpit.
-
-
Foreman or Smart Proxy can authenticate to the host with SSH keys. For more information, see Distributing SSH Keys for Remote Execution.
-
In the Foreman web UI, navigate to Hosts > All Hosts and select the host that you want to manage and monitor with Cockpit.
-
In the upper right of the host window, click Web Console.
You can now access the full range of features available for host monitoring and management, for example, Lorax Composer, through the Cockpit.
8.3. Disabling Cockpit on Foreman
Perform the following procedure if you want to disable Cockpit on Foreman.
-
Run this
foreman-installer
command:foreman-installer --no-enable-foreman-plugin-remote-execution-cockpit
-
In the Foreman web UI, navigate to Administer > Settings and click the Remote execution tab.
-
In the Cockpit URL row, erase the setting under Value and click Submit. This removes the Web Console button from the Foreman web UI.
-
Uninstall the Cockpit package from Foreman:
yum remove rubygem-foreman_remote_execution-cockpit
9. Using the KernelCare Plug-in
You can use the KernelCare plug-in to patch the Linux kernel on managed hosts without rebooting them. The plug-in provides job templates to view and live-patch the Linux kernel on managed hosts and ensures managed hosts do not report to Foreman server that a reboot is required through tracer. For more information, see tuxcare.com/live-patching-services and docs.tuxcare.com/live-patching-services.
Important
|
The KernelCare plug-in is a technical preview. Foreman community does not recommend running this in your production environment. |
9.1. Installing the KernelCare Plug-in
Use the following procedure to install the KernelCare plug-in.
-
On your Foreman server, install the plug-in package:
# yum install rubygem-foreman_kernel_care
-
Rerun foreman-installer:
# foreman-installer
9.2. KernelCare Client
You need to provide the KernelCare client to your managed hosts. Synchronize the required repositories depending on the operating system of your managed hosts.
After synchronization, ensure to make the content consumable to your managed hosts.
9.2.1. Creating KernelCare Repositories for Enterprise Linux 9
You need to provide the KernelCare client on managed hosts to live-patch their Linux kernel.
-
In the Foreman web UI, navigate to Content > Products.
-
Click Create Product to create a product named
KernelCare Enterprise Linux
. For more information, see Creating a Product in Managing Content. -
On the Repositories tab, click New Repository to create a repository of type
yum
as follows:-
Name:
KernelCare Enterprise Linux 9
-
Upstream URL:
https://repo.cloudlinux.com/kernelcare/9/x86_64/
-
Optional: Add the KernelCare GPG pub key as content credential:
https://repo.cloudlinux.com/kernelcare/RPM-GPG-KEY-KernelCare
.
For more information, see Adding RPM Repositories in Managing Content.
-
9.2.2. Creating KernelCare Repositories for Enterprise Linux 8
You need to provide the KernelCare client on managed hosts to live-patch their Linux kernel.
-
In the Foreman web UI, navigate to Content > Products.
-
Click Create Product to create a product named
KernelCare Enterprise Linux
. For more information, see Creating a Product in Managing Content. -
On the Repositories tab, click New Repository to create a repository of type
yum
as follows:-
Name:
KernelCare Enterprise Linux 8
-
Upstream URL:
https://repo.cloudlinux.com/kernelcare/8/x86_64/
-
Optional: Add the KernelCare GPG pub key as content credential:
https://repo.cloudlinux.com/kernelcare/RPM-GPG-KEY-KernelCare
.
For more information, see Adding RPM Repositories in Managing Content.
-
9.2.3. Creating KernelCare Repositories for Enterprise Linux 7
You need to provide the KernelCare client on managed hosts to live-patch their Linux kernel.
-
In the Foreman web UI, navigate to Content > Products.
-
Click Create Product to create a product named
KernelCare Enterprise Linux
. For more information, see Creating a Product in Managing Content. -
On the Repositories tab, click New Repository to create a repository of type
yum
as follows:-
Name:
KernelCare Enterprise Linux 7
-
Upstream URL:
https://repo.cloudlinux.com/kernelcare/7/x86_64/
-
Optional: Add the KernelCare GPG pub key as content credential:
https://repo.cloudlinux.com/kernelcare/RPM-GPG-KEY-KernelCare
.
For more information, see Adding RPM Repositories in Managing Content.
-
9.3. Installing the KernelCare Package on Managed Hosts
You can use kernelcare
to patch the Linux kernel on managed hosts without rebooting them.
-
Your managed hosts have access to the KernelCare repository. For more information, see KernelCare Client.
-
In the Foreman web UI, navigate to Hosts > All Hosts and select one or multiple hosts.
-
From the Select Action menu, select Schedule Remote Job.
-
In the Job category field, select
Katello via Ansible
. -
In the Job template field, select
Install Package - Katello Ansible Default
. -
In the Package field, enter
kernelcare
. -
Click Submit to install the package on your managed hosts.
9.4. Viewing Patched Kernel Version
You can use a job template to view the patched Kernel version on managed hosts.
-
Ensure the
kernelcare
package is installed on your managed hosts. For more information, see Installing the KernelCare Package on Managed Hosts.
-
In the Foreman web UI, navigate to Hosts > All Hosts.
-
Select one or multiple hosts and under Select Action, click Schedule Remote Job.
-
In the Job category field, select
Commands
. -
In the Job template field, select
Kernel version
. -
Click Submit to view the running Linux kernel version on your hosts.
9.5. Live Patching Hosts Using KernelCare Plug-In
You can use kcarectl
provided by TuxCare to live-patch the Linux kernel on managed hosts.
By default, kcarectl
checks for updates every four hours.
If the automatic installation of patches is disabled or if you want to install patches manually at a certain time, you can start the process using a remote execution job.
-
Ensure your hosts have the
kernelcare
package installed. -
Ensure your hosts run Enterprise Linux 7, Enterprise Linux 8, or Enterprise Linux 9.
-
Ensure your hosts have access to the internet to connect to cloudlinux.com.
If your host is in a disconnected environment, you can use ePortal by Tuxcare to provide Linux kernel patches. For more information, see docs.tuxcare.com/eportal.
-
In the Foreman web UI, navigate to Hosts > All Hosts.
-
Select one or multiple hosts and under Select Action, click * Schedule Remote Job*.
-
In the Job category field, select
Commands
. -
In the Job template field, select
Run Command - SSH Default
. -
In the command field, enter
/usr/bin/kcarectl --update
. -
Click Submit to update to the latest Linux kernel on your hosts.
-
For more information on live-patching managed hosts, see docs.tuxcare.com/live-patching-services.
10. Using Report Templates to Monitor Hosts
You can use report templates to query Foreman data to obtain information about, for example, host status, registered hosts, applicable errata, applied errata, subscription details, and user activity. You can use the report templates that ship with Foreman or write your own custom report templates to suit your requirements. The reporting engine uses the embedded Ruby (ERB) syntax. For more information about writing templates and ERB syntax, see Template Writing Reference.
You can create a template, or clone a template and edit the clone. For help with the template syntax, click a template and click the Help tab.
10.1. Generating Host Monitoring Reports
To view the report templates in the Foreman web UI, navigate to Monitor > Report Templates. To schedule reports, configure a cron job or use the Foreman web UI.
-
In the Foreman web UI, navigate to Monitor > Report Templates.
-
To the right of the report template that you want to use, click Generate.
-
Optional: To schedule a report, to the right of the Generate at field, click the icon to select the date and time you want to generate the report at.
-
Optional: To send a report to an e-mail address, select the Send report via e-mail checkbox, and in the Deliver to e-mail addresses field, enter the required e-mail address.
-
Optional: Apply search query filters. To view all available results, do not populate the filter field with any values.
-
Click Submit. A CSV file that contains the report is downloaded. If you have selected the Send report via e-mail checkbox, the host monitoring report is sent to your e-mail address.
-
List all available report templates:
# hammer report-template list
-
Generate a report:
# hammer report-template generate --id My_Template_ID
This command waits until the report fully generates before completing. If you want to generate the report as a background task, you can use the
hammer report-template schedule
command.NoteIf you want to generate a subscription entitlement report, you have to use the
Days from Now
option to specify the latest expiration time of entitlement subscriptions. You can use theno limit
value to show all entitlements.Show all entitlements# hammer report-template generate \ --inputs "Days from Now=no limit" \ --name "Subscription - Entitlement Report"
Show all entitlements that are going to expire within 60 days# hammer report-template generate \ --inputs "Days from Now=60" \ --name "Subscription - Entitlement Report"
10.2. Creating a Report Template
In Foreman, you can create a report template and customize the template to suit your requirements. You can import existing report templates and further customize them with snippets and template macros.
Report templates use Embedded Ruby (ERB) syntax. To view information about working with ERB syntax and macros, in the Foreman web UI, navigate to Monitor > Report Templates, and click Create Template, and then click the Help tab.
When you create a report template in Foreman, safe mode is enabled by default.
-
In the Foreman web UI, navigate to Monitor > Report Templates, and click Create Template.
-
In the Name field, enter a unique name for your report template.
-
If you want the template to be available to all locations and organizations, select Default.
-
Create the template directly in the template editor or import a template from a text file by clicking Import. For more information about importing templates, see Importing Report Templates.
-
Optional: In the Audit Comment field, you can add any useful information about this template.
-
Click the Input tab, and in the Name field, enter a name for the input that you can reference in the template in the following format:
input('name')
. Note that you must save the template before you can reference this input value in the template body. -
Select whether the input value is mandatory. If the input value is mandatory, select the Required checkbox.
-
From the Value Type list, select the type of input value that the user must input.
-
Optional: If you want to use facts for template input, select the Advanced checkbox.
-
Optional: In the Options field, define the options that the user can select from. If this field remains undefined, the users receive a free-text field in which they can enter the value they want.
-
Optional: In the Default field, enter a value, for example, a host name, that you want to set as the default template input.
-
Optional: In the Description field, you can enter information that you want to display as inline help about the input when you generate the report.
-
Optional: Click the Type tab, and select whether this template is a snippet to be included in other templates.
-
Click the Location tab and add the locations where you want to use the template.
-
Click the Organizations tab and add the organizations where you want to use the template.
-
Click Submit to save your changes.
-
For more information about safe mode, see Report Template Safe Mode.
-
For more information about writing templates, see Template Writing Reference.
-
For more information about macros you can use in report templates, see Templates Macros.
10.3. Exporting Report Templates
You can export report templates that you create in Foreman.
-
In the Foreman web UI, navigate to Monitor > Report Templates.
-
Locate the template that you want to export, and from the list in the Actions column, select Export.
-
Repeat this action for every report template that you want to download.
An .erb
file that contains the template downloads.
-
To view the report templates available for export, enter the following command:
# hammer report-template list
Note the template ID of the template that you want to export in the output of this command.
-
To export a report template, enter the following command:
# hammer report-template dump --id My_Template_ID > example_export.erb
10.4. Exporting Report Templates Using the Foreman API
You can use the Foreman report_templates
API to export report templates from Foreman.
-
Use the following request to retrieve a list of available report templates:
Example request:$ curl --insecure --user admin:redhat \ --request GET \ --config https://foreman.example.com/api/report_templates \ | json_reformat
In this example, the
json_reformat
tool is used to format the JSON output.Example response:{ "total": 6, "subtotal": 6, "page": 1, "per_page": 20, "search": null, "sort": { "by": null, "order": null }, "results": [ { "created_at": "2019-11-20 17:49:52 UTC", "updated_at": "2019-11-20 17:49:52 UTC", "name": "Applicable errata", "id": 112 }, { "created_at": "2019-11-20 17:49:52 UTC", "updated_at": "2019-11-20 17:49:52 UTC", "name": "Applied Errata", "id": 113 }, { "created_at": "2019-11-30 16:15:24 UTC", "updated_at": "2019-11-30 16:15:24 UTC", "name": "Hosts - complete list", "id": 158 }, { "created_at": "2019-11-20 17:49:52 UTC", "updated_at": "2019-11-20 17:49:52 UTC", "name": "Host statuses", "id": 114 }, { "created_at": "2019-11-20 17:49:52 UTC", "updated_at": "2019-11-20 17:49:52 UTC", "name": "Registered hosts", "id": 115 }, { "created_at": "2019-11-20 17:49:52 UTC", "updated_at": "2019-11-20 17:49:52 UTC", "name": "Subscriptions", "id": 116 } ] }
-
Note the
id
of the template that you want to export, and use the following request to export the template:Example request:$ curl --insecure --output /tmp/_Example_Export_Template.erb_ \ --user admin:password --request GET --config \ https://foreman.example.com/api/report_templates/My_Template_ID/export
Note that
158
is an example ID of the template to export.In this example, the exported template is redirected to
host_complete_list.erb
.
10.5. Importing Report Templates
You can import a report template into the body of a new template that you want to create. Note that using the Foreman web UI, you can only import templates individually. For bulk actions, use the Foreman API. For more information, see Importing Report Templates Using the Foreman API.
-
You must have exported templates from Foreman to import them to use in new templates. For more information see Exporting Report Templates.
-
In the Foreman web UI, navigate to Monitor > Report Templates.
-
In the upper right of the Report Templates window, click Create Template.
-
On the upper right of the Editor tab, click the folder icon, and select the
.erb
file that you want to import. -
Edit the template to suit your requirements.
-
Click Submit.
For more information about customizing your new template, see Template Writing Reference.
10.6. Importing Report Templates Using the Foreman API
You can use the Foreman API to import report templates into Foreman. Importing report templates using the Foreman API automatically parses the report template metadata and assigns organizations and locations.
-
Create a template using
.erb
syntax or export a template from another Foreman.For more information about writing templates, see Template Writing Reference.
For more information about exporting templates from Foreman, see Exporting Report Templates Using the Foreman API.
-
Use the following example to format the template that you want to import to a
.json
file:# cat Example_Template.json { "name": "Example Template Name", "template": " Enter ERB Code Here " }
Example JSON File with ERB Template:{ "name": "Hosts - complete list", "template": " <%# name: Hosts - complete list snippet: false template_inputs: - name: host required: false input_type: user advanced: false value_type: plain resource_type: Katello::ActivationKey model: ReportTemplate -%> <% load_hosts(search: input('host')).each_record do |host| -%> <% report_row( 'Server FQDN': host.name ) -%> <% end -%> <%= report_render %> " }
-
Use the following request to import the template:
$ curl --insecure --user admin:redhat \ --data @Example_Template.json --header "Content-Type:application/json" \ --request POST --config https://foreman.example.com/api/report_templates/import
-
Use the following request to retrieve a list of report templates and validate that you can view the template in Foreman:
$ curl --insecure --user admin:redhat \ --request GET --config https://foreman.example.com/api/report_templates | json_reformat
10.7. Report Template Safe Mode
When you create report templates in Foreman, safe mode is enabled by default. Safe mode limits the macros and variables that you can use in the report template. Safe mode prevents rendering problems and enforces best practices in report templates. The list of supported macros and variables is available in the Foreman web UI.
To view the macros and variables that are available, in the Foreman web UI, navigate to Monitor > Report Templates and click Create Template. In the Create Template window, click the Help tab and expand Safe mode methods.
While safe mode is enabled, if you try to use a macro or variable that is not listed in Safe mode methods, the template editor displays an error message.
To view the status of safe mode in Foreman, in the Foreman web UI, navigate to Administer > Settings and click the Provisioning tab. Locate the Safemode rendering row to check the value.
11. Configuring Host Collections
This is for users of the Katello plug-in and hosts running RPM-based linux distributions. Hosts collections work via the Pulp back end.
A host collection is a group of content hosts. This feature enables you to perform the same action on multiple hosts at once. These actions can include the installation, removal, and update of packages and errata, change of assigned life cycle environment, and change of Content View. You can create host collections to suit your requirements, and those of your company. For example, group hosts in host collections by function, department, or business unit.
11.1. Creating a Host Collection
The following procedure shows how to create host collections.
-
In the Foreman web UI, navigate to Hosts > Host Collections.
-
Click New Host Collection.
-
Add the Name of the host collection.
-
Clear Unlimited Content Hosts, and enter the desired maximum number of hosts in the Limit field.
-
Add the Description of the host collection.
-
Click Save.
-
To create a host collection, enter the following command:
# hammer host-collection create \ --name "My_Host_Collection" \ --organization "My_Organization"
11.2. Cloning a Host Collection
The following procedure shows how to clone a host collection.
-
In the Foreman web UI, navigate to Hosts > Host Collections.
-
On the left hand panel, click the host collection you want to clone.
-
Click Copy Collection.
-
Specify a name for the cloned collection.
-
Click Create.
11.3. Removing a Host Collection
The following procedure shows how to remove a host collection.
-
In the Foreman web UI, navigate to Hosts > Host Collections.
-
Choose the host collection to be removed.
-
Click Remove. An alert box appears:
Are you sure you want to remove host collection Host Collection Name?
-
Click Remove.
11.4. Adding Hosts to a Host Collection in Bulk
You can add multiple hosts to a host collection.
A host must be registered to Foreman to add it to a host collection.
Note that if you add a host to a host collection, the Foreman auditing system does not log the change.
-
In the Foreman web UI, navigate to Hosts > Host Collections.
-
Select the host collection where the host should be added.
-
On the Hosts tab, select the Add subtab.
-
Select the hosts to be added from the table and click Add Selected.
-
To add multiple hosts to a host collection, enter the following command:
# hammer host-collection add-host \ --host-ids My_Host_ID_1,My_Host_ID_2 \ --id My_Host_Collection_ID
11.5. Removing a Host From a Host Collection
The following procedure shows how to remove hosts from host collections.
Note that if you remove a host from a host collection, the host collection record in the database is not modified so the Foreman auditing system does not log the change.
-
In the Foreman web UI, navigate to Hosts > Host Collections.
-
Choose the desired host collection.
-
On the Hosts tab, select the List/Remove subtab.
-
Select the hosts you want to remove from the host collection and click Remove Selected.
11.6. Adding Content to a Host Collection
These steps show how to add content to host collections in Foreman.
11.6.1. Adding Packages to a Host Collection
The following procedure shows how to add packages to host collections.
-
The content to be added should be available in one of the existing repositories or added prior to this procedure.
-
Content should be promoted to the environment where the hosts are assigned.
-
In the Foreman web UI, navigate to Hosts > Host Collections.
-
Select the host collection where the package should be added.
-
On the Collection Actions tab, click Package Installation, Removal, and Update.
-
To update all packages, click the Update All Packages button to use the default method. Alternatively, select the drop-down icon to the right of the button to select a method to use. Selecting the via remote execution - customize first menu entry will take you to the Job invocation page where you can customize the action.
-
Select the Package or Package Group radio button as required.
-
In the field provided, specify the package or package group name. Then click:
-
Install – to install a new package using the default method. Alternatively, select the drop-down icon to the right of the button and select a method to use. Selecting the via remote execution - customize first menu entry will take you to the Job invocation page where you can customize the action.
-
Update – to update an existing package in the host collection using the default method. Alternatively, select the drop-down icon to the right of the button and select a method to use. Selecting the via remote execution - customize first menu entry will take you to the Job invocation page where you can customize the action.
-
11.6.2. Viewing installed packages
Use the following procedure to view the installed packages of a host.
-
In the Foreman web UI, navigate to Hosts > All Hosts and select the name of the host.
-
On the Content tab, Packages displays a list of installed packages.
-
To see details of a package, select that package.
-
The Details tab displays details of the selected package.
-
The Files tab lists the files contained in the package.
-
The Dependencies tab lists the dependencies of the package.
-
The Repositories tab lists the repositories that contain the selected package.
-
-
You can filter these by Library or Default organization.
11.6.3. Upgrading a Package
Use the following procedure to view the installed packages of a host.
-
In the Foreman web UI, navigate to Hosts > All Hosts and select the name of the host that contains the package you want to upgrade.
-
On the Content tab, select Packages.
-
The Status column displays whether the package is upgradable or Up to date. You cannot update an up-to-date package.
-
From the list of packages, choose the package you want to upgrade and click the vertical ellipsis icon at the end of the line.
-
Choose the Apply via Remote Execution to use Remote Execution, or Apply via customized remote execution if you want to customize the remote execution, for example, to set a time when it should be applied.
-
Click Submit to upgrade the package.
11.6.4. Removing a Package From a Host
Use the following procedure to remove an installed package from a host.
-
In the Foreman web UI, navigate to Hosts > All Hosts and select the host containing the package you want to remove.
-
On the Content tab, select Packages.
-
Click the vertical ellipsis icon at the end of the line for the package you want to remove, and choose the Remove option.
-
Click Submit.
11.6.5. Adding Errata to a Host Collection
The following procedure shows how to add errata to host collections.
-
The errata to be added should be available in one of the existing repositories or added prior to this procedure.
-
Errata should be promoted to the environment where the hosts are assigned.
-
In the Foreman web UI, navigate to Hosts > Host Collections.
-
Select the host collection where the errata should be added.
-
On the Collection Actions tab, click Errata Installation.
-
Select the errata you want to add to the host collection and click the Install Selected button to use the default method. Alternatively, select the drop-down icon to the right of the button to select a method to use. Selecting the via remote execution - customize first menu entry takes you to the Job invocation page where you can customize the action.
11.6.6. Adding Errata to a Single Host
Use the following procedure to add errata to a host.
-
In the Foreman web UI, navigate to Hosts > All Hosts and select the host you want to add errata to.
-
Click the Content button and select the Errata tab.
-
Select the errata you want to add to the host, or select the checkbox at the top of the list to add all installable errata. Click the checkbox next to any errata you wish to remove from a full list.
-
Using the vertical ellipsis icon next to the errata you want to add to the host, select Apply via Remote Execution to use Remote Execution, or select Apply via customized remote execution if you want to customize the remote execution. Select Apply via Katello agent if you have no connectivity to the target host using SSH.
-
Click Submit.
11.6.7. Applying Installable Errata
Use the following procedure to view a list of installable errata and select errata to install.
-
In the Foreman web UI, navigate to Hosts > All Hosts and select the host you require.
-
If there are errata associated with the host, they are displayed in an Installable Errata card on the new Host page.
-
On the Content tab, Errata displays installable errata for the chosen host.
-
Click the checkbox for any errata you wish to install.
-
Using the vertical ellipsis icon next to the errata you want to add to the host, select Apply via Remote Execution to use Remote Execution. Select Apply via customized remote execution if you want to customize the remote execution, or select Apply via Katello agent if you have no connectivity to the target host using SSH.
-
Click Submit.
11.6.8. Filter Errata by Type and Severity
Use the following procedure to filter errata by type or severity.
-
In the Foreman web UI, navigate to Hosts > All Hosts and click the name of the host.
-
On the Contents tab, Errata lists the errata associated with the selected host.
-
Click the Type button to filter errata by type.
-
You can filter to display errata of type Security, Bugfix, or Enhancement
-
Click the Severity button to filter by severity.
-
You can filter to display errata of severity N/A, Low, Moderate, Important, or Critical.
-
To deselect your choice, return to the list of options and click the selected option again.
You can also use the Errata card on the host page to pre-filter errata for type before display.
11.6.9. Removing Content From a Host Collection
The following procedure shows how to remove packages from host collections.
-
Click Hosts > Host Collections.
-
Click the host collection where the package should be removed.
-
On the Collection Actions tab, click Package Installation, Removal, and Update.
-
Select the Package or Package Group radio button as required.
-
In the field provided, specify the package or package group name.
-
Click the Remove button to remove the package or package group using the default method. Alternatively, select the drop-down icon to the right of the button and select a method to use. Selecting the via remote execution - customize first menu entry will take you to the Job invocation page where you can customize the action.
11.6.10. Changing the Life Cycle Environment or Content View of a Host Collection
The following procedure shows how to change the assigned life cycle environment or Content View of host collections.
-
In the Foreman web UI, navigate to Hosts > Host Collection.
-
Selection the host collection where the life cycle environment or Content View should be changed.
-
On the Collection Actions tab, click Change assigned Life Cycle Environment or Content View.
-
Select the life cycle environment to be assigned to the host collection.
-
Select the required Content View from the list.
-
Click Assign.
NoteThe changes take effect in approximately 4 hours. To make the changes take effect immediately, on the host, enter the following command:
# subscription-manager refresh
You can use remote execution to run this command on multiple hosts at the same time.
12. Using Salt for Configuration Management
Use this section as a guide to configuring Foreman to use Salt for configuration management on managed hosts.
12.1. Introduction to Salt
This guide describes how to use Salt for configuration management in Foreman. This guide contains information about how to install the Salt plugin, how to integrate Foreman with an existing Salt Master, and how to configure managed hosts with Salt.
Note
|
Salt offers two distinct modes of operation: Clientless using SSH or the Salt Minion client software. |
12.2. Salt Architecture
You need a Salt Master that either runs on your Foreman server or Smart Proxy server with the Salt plugin enabled. You can also use an existing Salt Master by installing and configuring the relevant Smart Proxy features on the existing Salt Master host.
For more information on installing a Salt Master, consult the official Salt documentation. Alternatively, use the bootstrap instructions found in the official Salt package repository.
-
Managed hosts are referred to as Salt Minions.
-
Information in form of key-value pairs gathered from Salt Minions is referred to as Salt Grains.
-
Configuration templates are referred to as Salt States.
-
Bundles of Salt States are referred to as Salt Environments.
Use the same Salt version on the Salt Master as you are using on your Salt Minions. You can use Foreman’s content management to provide managed hosts with the correct version of the Salt Minion client software.
Port | Protocol | Service | Required For |
---|---|---|---|
4505 and 4506 |
TCP |
HTTPS |
Salt Master to Salt Minions |
9191 |
TCP |
HTTPS |
Salt API |
12.3. Installing Salt Plugin
To configure managed hosts with Salt, you need to install the Salt plugin.
-
Connect to your Foreman using SSH:
# ssh root@foreman.example.com
-
Install the Salt plugin:
# foreman-installer \ --enable-foreman-plugin-salt \ --enable-foreman-proxy-plugin-salt
12.4. Configuring Salt
After you have installed the Salt plugin, you need to connect it to a Salt Master. This is required when adding Salt support to an existing Foreman installation, when adding an existing Salt Master to Foreman, or when setting up Salt on Smart Proxy.
Perform all actions on your Salt Master unless noted otherwise. This is either your Foreman server or Smart Proxy server with Salt enabled.
12.4.1. Configuring Foreman
You need to configure Foreman to use the Salt plugin.
-
Connect to your Foreman using SSH:
# ssh root@foreman.example.com
-
Extend the
/etc/sudoers
file to allow theforeman-proxy
user to run Salt:Cmd_Alias SALT = /usr/bin/salt, /usr/bin/salt-key foreman-proxy ALL = NOPASSWD: SALT Defaults:foreman-proxy !requiretty
-
Add a user called
saltuser
to access the Salt API:# adduser --no-create-home --shell /bin/false --home-dir / saltuser # passwd saltuser
Enter the password for the Salt user twice.
NoteThe command
adduser saltuser -p password
does not work. Using it prevents you from importing Salt States.
12.4.2. Configuring Salt Master
Configure your Salt Master to configure managed hosts using Salt.
-
Connect to your Salt Master using SSH:
# ssh root@salt-master.example.com
-
Set Foreman as an external node classifier in
/etc/salt/master
for Salt:master_tops: ext_nodes: /usr/bin/foreman-node
-
Enable Salt Pillar data for use with Foreman:
ext_pillar: - puppet: /usr/bin/foreman-node
-
Add a Salt Environment called
base
that is associated with the/srv/salt
directory:file_roots: base: - /srv/salt
-
Use the
saltuser
user for the Salt API and specify the connection settings in/etc/salt/master
:external_auth: pam: saltuser: - '@runner' rest_cherrypy: port: 9191 host: 0.0.0.0 ssl_key: /etc/puppetlabs/puppet/ssl/private_keys/foreman.example.com.pem ssl_crt: /etc/puppetlabs/puppet/ssl/certs/foreman.example.com.pem
-
Optional: Use Salt as a remote execution provider.
You can run arbitrary commands on managed hosts by using the existing connection from your Salt Master to Salt Minions. Configure the
foreman-proxy
user to run Salt commands in/etc/salt/master
:publisher_acl: foreman-proxy: - state.template_str
12.4.3. Authenticating Salt Minions Using Salt Autosign Grains
Configure Foreman to automatically accept Salt Minions using Salt autosign Grains.
-
Configure the Grains key file on the Salt Master and add a reactor in the
/etc/salt/master
file:autosign_grains_dir: /var/lib/foreman-proxy/salt/grains reactor: - 'salt/auth': - /usr/share/foreman-proxy/salt/reactors/foreman_minion_auth.sls
The Grains file holds the acceptable keys when you deploy Salt Minions. The reactor initiates an interaction with the Salt plugin if the Salt Minion is successfully authenticated.
-
Add the reactor to the
salt/auth
event. -
Copy the Salt runners into your
file_roots
runners directory. The directory depends on your/etc/salt/master
config. If it is configured to use/srv/salt
, create the runners folder/srv/salt/_runners
and copy the Salt runners into it.# mkdir -p /srv/salt/_runners # cp /usr/share/foreman-proxy/salt/runners/* /srv/salt/_runners/
-
Restart the Salt Master service:
# systemctl restart salt-master
-
Enable the Salt reactors and runners in your Salt Environment:
# salt-run saltutil.sync_all
12.4.4. Authenticating Salt Minions Using Host Names
Configure Foreman to authenticate Salt Minions based on their host names.
This relies on the autosign.conf
file that stores the host names of Salt Minions the Salt Master accepts.
-
Connect to your Salt Master using SSH:
# ssh root@salt-master.example.com
-
Add the
foreman-proxy
user that is running Salt to theroot
user group:# usermod -a -G foreman-proxy root
-
Enable the
autosign.conf
file in/etc/salt/master
:autosign_file: /etc/salt/autosign.conf permissive_pki_access: True
-
Create the
/etc/salt/autosign.conf
file and set appropriate ownership and permissions:# touch /etc/salt/autosign.conf # chown root:foreman-proxy /etc/salt/autosign.conf # chmod 660 /etc/salt/autosign.conf
12.4.5. Enabling Salt Grains Upload
Managed hosts running the Salt Minion client software can upload Salt Grains to Foreman server or Smart Proxy server. Salt Grains are collected system properties, for example the operating system or IP address of a Salt Minion.
-
Connect to your Salt Master using SSH:
# ssh root@salt-master.example.com
-
Edit
/etc/salt/foreman.yaml
on your Salt Master::proto: https :host: foreman.example.com :port: 443 :ssl_ca: "/etc/puppetlabs/puppet/ssl/ssl_ca.pem" :ssl_cert: "/etc/puppetlabs/puppet/ssl/client_cert.pem" :ssl_key: "/etc/puppetlabs/puppet/ssl/client_key.pem" :timeout: 10 :salt: /usr/bin/salt :upload_grains: true
12.4.6. Configuring Salt API
Configure the Salt API in /etc/foreman-proxy/settings.d/salt.yml
.
-
Connect to your Salt Master using SSH:
# ssh root@salt-master.example.com
-
Edit
/etc/foreman-proxy/settings.d/salt.yml
::use_api: true :api_auth: pam :api_url: https://foreman.example.com:9191 :api_username: saltuser :api_password: password
Ensure to use the password of the previously created
saltuser
.
12.4.7. Activating Salt
-
Connect to your Salt Master using SSH:
# ssh root@salt-master.example.com
-
Restart the Salt services:
# systemctl restart salt-master salt-api
-
Connect to your Foreman using SSH:
# ssh root@foreman.example.com
-
Restart Foreman services:
# foreman-maintain service restart
-
Refresh your Smart Proxy features.
-
In the Foreman web UI, navigate to Infrastructure > Smart Proxies.
-
Click Refresh for the relevant Smart Proxy.
-
12.5. Setting up Salt Minions
Salt Minions require the Salt Minion client software to interact with your Salt Master.
12.5.1. Using Foremans Content Management
Provide managed hosts with the required Salt Minion client software using Foreman.
-
Create a product called
Salt
. For more information, see Creating a Custom Product. -
Create a repository within the Salt product for each operating system supported by Foreman that you want to install the Salt Minion client software on. For more information, see Adding RPM Repositories or Adding DEB Repositories.
Add the operating system to the name of the repository, for example
Salt for Ubuntu 20.04
.You can find the upstream URL for the Salt packages on the official Salt package repository. The URL depends on both the Salt version and the operating system, for example
https://repo.saltproject.io/py3/ubuntu/20.04/amd64/3003/
. -
Synchronize the previously created products. For more information, see Synchronizing Repositories.
-
Create a Content View for each repository. For more information, see Creating a Content View.
-
Create a Composite Content View for each major version of each operating system to make the new content available. For more information, see Create a Composite Content View.
-
Add each of your operating system specific Salt Content Views to your main Composite Content View for that operating system and version.
-
Publish a new version of the Composite Content View from the previous step.
-
Promote the Content View from the previous step to your lifecycle environments as appropriate. For more information, see Promoting a Content View.
-
Optional: Create activation keys for your Composite Content View and lifecycle environment combinations.
12.5.2. Creating a Host Group With Salt
To bundle provisioning and configuration settings, you can create a host group with Salt enabled for managed hosts.
-
In the Foreman web UI, navigate to Configure > Host Groups.
-
Click Create Host Group.
-
Click the Host Group tab and select a Salt Environment and a Salt Master.
-
Click the Salt States tab and assign Salt States to your host group.
-
Click the Activation Keys tab and select an activation key containing the Salt Minion client software.
-
Click Submit to save your host group.
Managed hosts deployed using this host group automatically install and configure the required Salt Minion client software and register with your Salt Master. For more information, see Creating a Host Group in the Managing Hosts guide.
12.5.3. Deploying Minion Hosts
Deploy managed hosts that are fully provisioned and configured for Salt usage.
-
A Salt Master
-
A Salt Environment
-
A Content View containing the required Salt Minion client software
-
An activation key
-
A lifecycle environment
-
In the Foreman web UI, navigate to Hosts > Create Host.
-
Select the previously created host group with Salt enabled.
-
Click Submit to deploy a host.
12.5.4. Verifying the Connection between Salt Master and Salt Minions
Verify the connection between your Salt Master and Salt Minions.
-
Connect to your Salt Master using SSH:
# ssh root@salt-master.example.com
-
Ping your Salt Minions:
# salt "*" test.ping
-
Display all Salt Grains of all connected Salt Minions:
# salt "*" grains.items
12.6. Salt Usage
Salt Minions managed by Foreman are associated with a Salt Master and a Salt Environment.
The associated Salt Environment within Foreman must match the actual Salt Environment from the file_roots
option in the /etc/salt/master
file.
You can configure managed hosts with Salt once they are associated with your Foreman server or Smart Proxy server and the Salt Minion client software is installed.
12.6.1. Using the Salt Hammer CLI
You can use Hammer CLI to configure managed hosts using Salt.
Run hammer --help
for more information.
-
Install
hammer_cli_foreman_salt
on your Foreman server
-
Creating a Salt State:
# hammer salt-state create \ --name My_Salt_State
-
Viewing information about a Salt Minion:
# hammer salt-minion info \ --name salt-minion.example.com
-
Adding Salt States to a Salt Minion:
# hammer salt-minion update \ --name salt-minion.example.com \ --salt-states My_Salt_State
12.6.2. Using the Salt API
Foreman Salt extends the Foreman REST API with Salt-specific features.
View the full API documentation on your Foreman server at http://foreman.example.com/apidoc/v2.html
.
-
Use
curl
to get a list of keys from smartproxy.example.com:# curl -u My_User_Name:My_Password \ -H "Accept: version=2,application/json" \ https://foreman.example.com/salt/api/v2/salt_keys/smartproxy.example.com
12.6.3. Importing Salt States
A Salt State configures parts of a host, for example, a service or the installation of a package.
You can import Salt States from your Salt Master to Foreman.
The Salt Master configuration in this guide uses a Salt Environment called base
that includes the Salt States stored in /srv/salt/
.
-
In the Foreman web UI, navigate to Configure > Salt States and click Import from FQDN.
-
Optional: Click Edit to assign Salt States to Salt Environments.
-
Optional: Click Delete to remove a Salt State from your Foreman. This only removes the Salt State from Foreman, not from the disk of your Salt Master.
-
Click Submit to import the Salt States.
After you have imported Salt States, you can assign them to hosts or Host Groups.
Salt applies these Salt States to any hosts they are assigned to every time you run state.highstate
.
Note
|
Configure the paths for Salt States and Salt Pillars in |
12.6.4. Viewing Salt Autosign Keys
The Salt Keys page lists hosts and their Salt keys. You can manually accept, reject, or delete keys.
Use the Salt autosign feature to automatically accept signing requests from managed hosts. By default, managed hosts are supplied with a Salt key during host provisioning.
Note
|
This feature only covers the autosign via |
-
In the Foreman web UI, navigate to Infrastructure > Smart Proxies.
-
Select a Smart Proxy.
-
In the Actions drop down menu, click Salt Keys.
12.6.5. Viewing Salt Reports
Salt reports are uploaded to Foreman every ten minutes using the /etc/cron.d/smart_proxy_salt
cron job.
You can trigger this action manually on your Salt Master:
# /usr/sbin/upload-salt-reports
-
To view Salt reports, in the Foreman web UI, navigate to Monitor > Config Management Reports.
-
To view Salt reports associated with an individual host, in the Foreman web UI, navigate to Hosts > All Hosts and select a single host.
12.6.6. Enabling Salt Report Uploads
The Salt Master can directly upload Salt reports to Foreman.
-
Connect to your Salt Master using SSH:
# ssh root@salt-master.example.com
-
Ensure the reactor is present:
# file /usr/share/foreman-proxy/salt/reactors/foreman_report_upload.sls
-
Copy report upload script:
# cp /usr/share/foreman-proxy/salt/runners/foreman_report_upload.py /srv/salt/_runners/
-
Add the reactor to
/etc/salt/master
:reactor: - 'salt/auth': - /usr/share/foreman-proxy/salt/reactors/foreman_minion_auth.sls - 'salt/job/*/ret/*': - /usr/share/foreman-proxy/salt/reactors/foreman_report_upload.sls
-
Restart the Salt Master:
# systemctl restart salt-master
-
Enable the new runner:
# salt-run saltutil.sync_all
-
If you use a cron job to upload facts from your Salt Master to Foreman, disable the cron job:
# rm -f /etc/cron.d/smart_proxy_salt
Alternatively, you can upload Salt reports from your Salt Master to Foreman manually:
# /usr/sbin/upload-salt-reports
12.6.7. Salt Variables
You can configure Salt Variables within Foreman. The configured values are available as Salt Pillar data.
12.6.8. Viewing ENC Parameters
You can use Foreman as an external node classifier for Salt. Click Salt ENC on the host overview page to view assigned Salt States. This shows a list of parameters that are made available for Salt usage as Salt Pillar data.
You can check what parameters are truly available on the Salt side by completing the following procedure.
-
Connect to your Salt Master using SSH:
# ssh root@salt-master.example.com
-
View available ENC parameters:
# salt '*' pillar.items
-
Optional: Refresh the Salt Pillar data if a parameter is missing:
# salt '*' saltutil.refresh_pillar
12.6.9. Running Salt
You can run arbitrary Salt functions using Foreman’s remote execution features.
Most commonly, you can run salt.highstate
on one or more Salt Minions.
This applies all relevant Salt States on your managed hosts.
-
In the Foreman web UI, navigate to Hosts > All Hosts.
-
Select one or multiple hosts.
-
Click Run Salt from the actions drop down menu.
Alternatively, you can click Run Salt from the Schedule Remote Job drop down menu on the host overview page.
Triggering a remote execution job takes you to the corresponding job overview page.
If you select a host from the list, you can see the output of the remote job in real time.
To view remote jobs, in the Foreman web UI, navigate to Monitor > Jobs.
Running state.highstate
generates a Salt report.
Note that reports are uploaded to Foreman every ten minutes.
You can use Foreman’s remote execution features to run arbitrary Salt functions. This includes an optional test mode that tells you what would happen without actually changing anything.
-
In the Foreman web UI, navigate to Hosts > All Hosts
-
Select a host.
-
Click Schedule Remote Job.
-
For the Job category field, select Salt-Call from the drop down menu.
-
For the Job template field, select Salt Run function from the drop down menu.
-
In the Function field, enter the name of the function that you want to trigger, for example,
pillar.items
ortest.ping
. -
Optional: Click Display advanced fields and enable test-run.
-
Click Submit to run the job.
You can also schedule remote jobs or run them recurrently. For more information, see Configuring and Setting up Remote Jobs in Managing Hosts.
Alternatively, you can define recurrent actions using the native Salt way.
For example, you can schedule hourly state.highstate
runs on individual Salt Minions by extending /etc/salt/minion
:
schedule: highstate: function: state.highstate minutes: 60
12.7. Salt Example
This example uses a Salt State to manage the /etc/motd
file on one or more Salt Minions.
It demonstrates the use of Foreman as an external node classifier and the use of Salt Grains.
-
Create a global parameter called
vendor_name
with the stringForeman
as its value. -
Add a new Salt State called
motd
to your Salt Master. -
Create the
/srv/salt/motd/
directory:# mkdir -p /srv/salt/motd/
-
Create
/srv/salt/motd/init.sls
as a Salt State file:/etc/motd: file.managed: - user: root - group: root - mode: 0644 - source: salt://motd/motd.template - template: jinja
-
Create
/srv/salt/motd/motd.template
as a template referenced by the Salt State file:Welcome to {{ grains['fqdn'] }} Powered by {{ salt['pillar.get']('vendor_name') }}
Access the
fqdn
Salt Grain from within this template and retrieve thevendor_name
parameter from the Salt Pillar. -
Import the
motd
Salt State into Foreman. -
Verify that Salt has been given access to the
vendor_name
parameter by running either of the following commands on your Salt Master:# salt '*' pillar.items | grep -A 1 vendor_name # salt '*' pillar.get vendor_name
If the output does not include the value of the
vendor_name
parameter, you must refresh the Salt Pillar data first:# salt '*' saltutil.refresh_pillar
For information about how to refresh Salt Pillar data, see Salt ENC parameters.
-
Add the
motd
Salt State to your Salt Minions or a host group. -
Apply the Salt State by running
state.highstate
. -
Optional: Verify the contents of
/etc/motd
on a Salt Minion.
12.8. Additional Resources for Salt
-
The official Salt documentation is a good entry point when starting with Salt.
-
You can download the Salt packages from the official Salt package repository.
13. Configuring and Setting Up Remote Jobs
Use this section as a guide to configuring Foreman to execute jobs on remote hosts.
Any command that you want to apply to a remote host must be defined as a job template. After you have defined a job template you can execute it multiple times.
13.1. About Running Jobs on Hosts
You can run jobs on hosts remotely from Smart Proxies using shell scripts or Ansible tasks and playbooks. This is referred to as remote execution.
For custom Ansible roles that you create, or roles that you download, you must install the package containing the roles on the Smart Proxy base operating system. Before you can use Ansible roles, you must import the roles into Foreman from the Smart Proxy where they are installed.
Communication 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. For more information, see Transport Modes for Remote Execution.
Foreman uses ERB syntax job templates. For more information, see Template Writing Reference.
Several job templates for shell scripts and Ansible are included by default. For more information, see Setting up Job Templates in Managing Hosts.
Note
|
Any Smart Proxy server base operating system is a client of Foreman server’s internal Smart Proxy, and therefore this section applies to any type of host connected to Foreman server, including Smart Proxies. |
You can run jobs on multiple hosts at once, and you can use variables in your commands for more granular control over the jobs you run. You can use host facts and parameters to populate the variable values.
In addition, you can specify custom values for templates when you run the command.
For more information, see Executing a Remote Job in Managing Hosts.
13.2. Remote Execution Workflow
When you run a remote job on hosts, for every host, Foreman performs the following actions to find a remote execution Smart Proxy to use.
Foreman searches only for Smart Proxies that have the remote execution feature enabled.
-
Foreman finds the host’s interfaces that have the Remote execution checkbox selected.
-
Foreman finds the subnets of these interfaces.
-
Foreman finds remote execution Smart Proxies assigned to these subnets.
-
From this set of Smart Proxies, Foreman selects the Smart Proxy that has the least number of running jobs. By doing this, Foreman ensures that the jobs load is balanced between remote execution Smart Proxies.
If you have enabled Prefer registered through Smart Proxy for remote execution, Foreman runs the REX job using the Smart Proxy the host is registered to.
By default, Prefer registered through Smart Proxy for remote execution is set to No.
To enable it, in the Foreman web UI, navigate to Administer > Settings, and on the Content tab, set Prefer registered through Smart Proxy for remote execution
to Yes.
This ensures that Foreman performs REX jobs on hosts by the Smart Proxy to which they are registered to.
If Foreman does not find a remote execution Smart Proxy at this stage, and if the Fallback to Any Smart Proxy setting is enabled, Foreman adds another set of Smart Proxies to select the remote execution Smart Proxy from. Foreman selects the most lightly loaded Smart Proxy from the following types of Smart Proxies that are assigned to the host:
-
DHCP, DNS and TFTP Smart Proxies assigned to the host’s subnets
-
DNS Smart Proxy assigned to the host’s domain
-
Realm Smart Proxy assigned to the host’s realm
-
Puppet server Smart Proxy
-
Puppet CA Smart Proxy
-
OpenSCAP Smart Proxy
If Foreman does not find a remote execution Smart Proxy at this stage, and if the Enable Global Smart Proxy setting is enabled, Foreman selects the most lightly loaded remote execution Smart Proxy from the set of all Smart Proxies in the host’s organization and location to execute a remote job.
13.3. Permissions for Remote Execution
You can control which roles can run which jobs within your infrastructure, including which hosts they can target. The remote execution feature provides two built-in roles:
-
Remote Execution Manager: Can access all remote execution features and functionality.
-
Remote Execution User: Can only run jobs.
You can clone the Remote Execution User role and customize its filter for increased granularity.
If you adjust the filter with the view_job_templates
permission on a customized role, you can only see and trigger jobs based on matching job templates.
You can use the view_hosts
and view_smart_proxies
permissions to limit which hosts or Smart Proxies are visible to the role.
The execute_template_invocation
permission is a special permission that is checked immediately before execution of a job begins.
This permission defines which job template you can run on a particular host.
This allows for even more granularity when specifying permissions.
You can run remote execution jobs against Foreman and Smart Proxy registered as hosts to Foreman with the execute_jobs_on_infrastructure_hosts
permission.
Standard Manager and Site Manager roles have this permission by default.
If you use either the Manager or Site Manager role, or if you use a custom role with the execute_jobs_on_infrastructure_hosts
permission, you can execute remote jobs against registered Foreman and Smart Proxy hosts.
For more information on working with roles and permissions, see Creating and Managing Roles in Administering Foreman.
The following example shows filters for the execute_template_invocation
permission:
name = Reboot and host.name = staging.example.com name = Reboot and host.name ~ *.staging.example.com name = "Restart service" and host_group.name = webservers
Use the first line in this example to apply the Reboot template to one selected host.
Use the second line to define a pool of hosts with names ending with .staging.example.com
.
Use the third line to bind the template with a host group.
Note
|
Permissions assigned to users with these roles can change over time. If you have already scheduled some jobs to run in the future, and the permissions change, this can result in execution failure because permissions are checked immediately before job execution. |
13.4. Transport Modes for Remote Execution
You can configure your Foreman to use two different modes of transport for remote job execution.
On Smart Proxies in ssh
mode, remote execution uses the SSH service to transport job details.
This is the default transport mode.
The SSH service must be enabled and active on the target hosts.
The remote execution Smart Proxy must have access to the SSH port on the target hosts.
Unless you have a different setting, the standard SSH port is 22.
Note
|
If your Smart Proxy already uses the # foreman-installer --foreman-proxy-plugin-remote-execution-script-mode=ssh |
On Smart Proxies in pull-mqtt
mode, remote execution uses Message Queueing Telemetry Transport (MQTT) to publish jobs it receives from Foreman server.
The host subscribes to the MQTT broker on Smart Proxy for job notifications using the yggdrasil
pull client.
After the host receives a notification, it pulls job details from Smart Proxy over HTTPS, runs the job, and reports results back to Smart Proxy.
To use the pull-mqtt
mode, you must enable it on Smart Proxy server and configure the pull client on the target hosts.
-
To enable pull mode on Smart Proxy server, see Configuring Remote Execution for Pull Client in Installing an External Smart Proxy Server 3.3.
-
To enable pull mode on an existing host, continue with Configuring a Host to Use the Pull Client.
-
To migrate a host from Katello Agent, see Migrating Hosts From Katello Agent to Remote Execution.
-
To enable pull mode on a new host, continue with either of the following procedures:
13.5. Configuring a Host to Use the Pull Client
For Smart Proxies configured to use pull-mqtt
mode, hosts can subscribe to remote jobs using the remote execution pull client.
Managed hosts do not require an SSH connection to their Smart Proxy server.
-
You have registered the host to Foreman.
-
The host’s Smart Proxy is configured to use
pull-mqtt
mode. For more information, see Configuring Remote Execution for Pull Client in Installing an External Smart Proxy Server 3.3. -
The Foreman community https://yum.theforeman.org/client/3.3/ repository is enabled and synchronized on Foreman server, and enabled on the host.
-
The host is able to communicate with its Smart Proxy over MQTT using port
1883
. -
The host is able to communicate with its Smart Proxy over HTTPS.
Note
|
The katello-pull-transport-migrate package was created to help users migrate from Katello Agent to remote execution with the pull client.
However, having Katello Agent installed on the host is not a requirement.
You can use katello-pull-transport-migrate regardless of whether Katello Agent is installed.
|
-
Install the
katello-pull-transport-migrate
package on your host:-
On Enterprise Linux 8 and Enterprise Linux 9 hosts:
# dnf install katello-pull-transport-migrate
-
On Enterprise Linux 7 hosts:
# yum install katello-pull-transport-migrate
-
On Debian/Ubuntu hosts:
# apt-get install katello-pull-transport-migrate
-
On SUSE Linux Enterprise Server hosts:
# zypper install katello-pull-transport-migrate
The package installs
foreman_ygg_worker
andyggdrasil
as dependencies and enables the pull mode on the host. The host’ssubscription-manager
configuration and consumer certificates are used to configure theyggdrasil
client on the host, and the pull mode client worker is started. -
-
Optional: To verify that the pull client is running and configured properly, check the status of the
yggdrasild
service:# systemctl status yggdrasild
-
Optional: After the package is installed, you can remove
katello-agent
from the host.WarningIf your host is installed on oVirt version 4.4 or lower, do not remove the katello-agent
package because the removed dependencies corrupt the host.
13.6. Creating a Job Template
Use this procedure to create a job template. To use the CLI instead of the Foreman web UI, see the CLI procedure.
-
In the Foreman web UI, navigate to Hosts > Job templates.
-
Click New Job Template.
-
Click the Template tab, and in the Name field, enter a unique name for your job template.
-
Select Default to make the template available for all organizations and locations.
-
Create the template directly in the template editor or upload it from a text file by clicking Import.
-
Optional: In the Audit Comment field, add information about the change.
-
Click the Job tab, and in the Job category field, enter your own category or select from the default categories listed in Default Job Template Categories in Managing Hosts.
-
Optional: In the Description Format field, enter a description template. For example,
Install package %{package_name}
. You can also use%{template_name}
and%{job_category}
in your template. -
From the Provider Type list, select SSH for shell scripts and Ansible for Ansible tasks or playbooks.
-
Optional: In the Timeout to kill field, enter a timeout value to terminate the job if it does not complete.
-
Optional: Click Add Input to define an input parameter. Parameters are requested when executing the job and do not have to be defined in the template. For examples, see the Help tab.
-
Optional: Click Foreign input set to include other templates in this job.
-
Optional: In the Effective user area, configure a user if the command cannot use the default
remote_execution_effective_user
setting. -
Optional: If this template is a snippet to be included in other templates, click the Type tab and select Snippet.
-
Click the Location tab and add the locations where you want to use the template.
-
Click the Organizations tab and add the organizations where you want to use the template.
-
Click Submit to save your changes.
You can extend and customize job templates by including other templates in the template syntax. For more information, see Template Writing Reference and Job Template Examples and Extensions in Managing Hosts.
-
To create a job template using a template-definition file, enter the following command:
# hammer job-template create \ --file "Path_to_My_Template_File" \ --job-category "My_Category_Name" \ --name "My_Template_Name" \ --provider-type SSH
13.7. Importing an Ansible Playbook by Name
You can import Ansible playbooks by name to Foreman from collections installed on Smart Proxy.
Foreman creates a job template from the imported playbook and places the template in the Ansible Playbook - Imported
job category.
If you have a custom collection, place it in /etc/ansible/collections/ansible_collections/My_Namespace/My_Collection
.
-
Ansible plugin is enabled.
-
Your Foreman account has a role that grants the
import_ansible_playbooks
permission.
-
Fetch the available Ansible playbooks by using the following API request:
# curl -X GET -H 'Content-Type: application/json' https://foreman.example.com/ansible/api/v2/ansible_playbooks/fetch?proxy_id=My_smart-proxy_ID
-
Select the Ansible playbook you want to import and note its name.
-
Import the Ansible playbook by its name:
# curl -X PUT -H 'Content-Type: application/json' -d '{ "playbook_names": ["My_Playbook_Name"] }' https://foreman.example.com/ansible/api/v2/ansible_playbooks/sync?proxy_id=My_smart-proxy_ID
You get a notification in the Foreman web UI after the import completes.
-
You can run the playbook by executing a remote job from the created job template. For more information, see Executing a Remote Job.
13.8. Importing All Available Ansible Playbooks
You can import all the available Ansible playbooks to Foreman from collections installed on Smart Proxy.
Foreman creates job templates from the imported playbooks and places the templates in the Ansible Playbook - Imported
job category.
If you have a custom collection, place it in /etc/ansible/collections/ansible_collections/My_Namespace/My_Collection
.
-
Ansible plugin is enabled.
-
Your Foreman account has a role that grants the
import_ansible_playbooks
permission.
-
Import the Ansible playbooks by using the following API request:
# curl -X PUT -H 'Content-Type: application/json' https://foreman.example.com/ansible/api/v2/ansible_playbooks/sync?proxy_id=My_smart-proxy_ID
You get a notification in the Foreman web UI after the import completes.
-
You can run the playbooks by executing a remote job from the created job templates. For more information, see Executing a Remote Job.
13.9. Configuring the Fallback to Any Smart Proxy Remote Execution Setting in Foreman
You can enable the Fallback to Any Smart Proxy setting to configure Foreman to search for remote execution Smart Proxies from the list of Smart Proxies that are assigned to hosts. This can be useful if you need to run remote jobs on hosts that have no subnets configured or if the hosts' subnets are assigned to Smart Proxies that do not have the remote execution feature enabled.
If the Fallback to Any Smart Proxy setting is enabled, Foreman adds another set of Smart Proxies to select the remote execution Smart Proxy from. Foreman also selects the most lightly loaded Smart Proxy from the set of all Smart Proxies assigned to the host, such as the following:
-
DHCP, DNS and TFTP Smart Proxies assigned to the host’s subnets
-
DNS Smart Proxy assigned to the host’s domain
-
Realm Smart Proxy assigned to the host’s realm
-
Puppet server Smart Proxy
-
Puppet CA Smart Proxy
-
OpenSCAP Smart Proxy
-
In the Foreman web UI, navigate to Administer > Settings.
-
Click Remote Execution.
-
Configure the Fallback to Any Smart Proxy setting.
-
Enter the
hammer settings set
command on Foreman to configure the Fallback to Any Smart Proxy setting. To set the value totrue
, enter the following command:# hammer settings set \ --name=remote_execution_fallback_proxy \ --value=true
13.10. Configuring the Global Smart Proxy Remote Execution Setting in Foreman
By default, Foreman searches for remote execution Smart Proxies in hosts' organizations and locations regardless of whether Smart Proxies are assigned to hosts' subnets or not. You can disable the Enable Global Smart Proxy setting if you want to limit the search to the Smart Proxies that are assigned to hosts' subnets.
If the Enable Global Smart Proxy setting is enabled, Foreman adds another set of Smart Proxies to select the remote execution Smart Proxy from. Foreman also selects the most lightly loaded remote execution Smart Proxy from the set of all Smart Proxies in the host’s organization and location to execute a remote job.
-
In the Foreman web UI, navigate to Administer > Settings.
-
Click Remote Execution.
-
Configure the Enable Global Smart Proxy setting.
-
Enter the
hammer settings set
command on Foreman to configure theEnable Global Smart Proxy
setting. To set the value totrue
, enter the following command:# hammer settings set \ --name=remote_execution_global_proxy \ --value=true
13.11. Setting an Alternative Directory for Remote Execution Jobs in Push Mode
By default, Foreman uses the /var/tmp
directory on hosts for remote execution jobs in push mode.
If the /var/tmp
directory on your host is mounted with the noexec
flag, Foreman cannot execute remote execution job scripts in this directory.
You can use foreman-installer
to set an alternative directory for executing remote execution jobs in push mode.
-
On your host, create a new directory:
# mkdir /My_Remote_Working_Directory
-
Copy the SELinux context from the default
/var/tmp
directory:# chcon --reference=/var/tmp /My_Remote_Working_Directory
-
Configure your Foreman server or Smart Proxy server to use the new directory:
# foreman-installer \ --foreman-proxy-plugin-remote-execution-script-remote-working-dir /My_Remote_Working_Directory
13.12. Setting an Alternative Directory for Remote Execution Jobs in Pull Mode
By default, Foreman uses the /run
directory on hosts for remote execution jobs in pull mode.
If the /run
directory on your host is mounted with the noexec
flag, Foreman cannot execute remote execution job scripts in this directory.
You can use the yggdrasild
service to set an alternative directory for executing remote execution jobs in pull mode.
On your host, perform these steps:
-
Create a new directory:
# mkdir /My_Remote_Working_Directory
-
Access the
yggdrasild
service configuration:# systemctl edit yggdrasild
-
Specify the alternative directory by adding the following line to the configuration:
Environment=FOREMAN_YGG_WORKER_WORKDIR=/My_Remote_Working_Directory
-
Restart the
yggdrasild
service:# systemctl restart yggdrasild
13.13. Altering the Privilege Elevation Method
By default, push-based remote execution uses sudo
to switch from the SSH user to the effective user that executes the script on your host.
In some situations, you might require to use another method, such as su
or dzdo
.
You can globally configure an alternative method in your Foreman settings.
-
Your user account has a role assigned that grants the
view_settings
andedit_settings
permissions. -
If you want to use
dzdo
for Ansible jobs, ensure thecommunity.general
Ansible collection, which contains the required dzdo become plug-in, is installed. For more information, see Installing collections in Ansible documentation.
-
Navigate to Administer > Settings.
-
Select the Remote Execution tab.
-
Click the value of the Effective User Method setting.
-
Select the new value.
-
Click Submit.
13.14. Distributing SSH Keys for Remote Execution
For Smart Proxies in ssh
mode, remote execution connections are authenticated using SSH.
The public SSH key from Smart Proxy must be distributed to its attached hosts that you want to manage.
Ensure that the SSH service is enabled and running on the hosts. Configure any network or host-based firewalls to enable access to port 22.
Use one of the following methods to distribute the public SSH key from Smart Proxy to target hosts:
-
Using the Foreman API to Obtain SSH Keys for Remote Execution.
-
Configuring a Kickstart Template to Distribute SSH Keys During Provisioning.
-
For new Foreman hosts, you can deploy SSH keys to Foreman hosts during registration using the global registration template. For more information, see Registering a Host to Foreman Using the Global Registration Template in Managing Hosts.
Foreman distributes SSH keys for the remote execution feature to the hosts provisioned from Foreman by default.
If the hosts are running on Amazon Web Services, enable password authentication. For more information, see New User Accounts.
13.15. Distributing SSH Keys for Remote Execution Manually
To distribute SSH keys manually, complete the following steps:
-
Copy the SSH pub key from your Smart Proxy to your target host:
# ssh-copy-id -i ~foreman-proxy/.ssh/id_rsa_foreman_proxy.pub root@client.example.com
Repeat this step for each target host you want to manage.
-
To confirm that the key was successfully copied to the target host, enter the following command on Smart Proxy:
# ssh -i ~foreman-proxy/.ssh/id_rsa_foreman_proxy root@client.example.com
13.16. Adding a Passphrase to SSH Key Used for Remote Execution
By default, Smart Proxy uses a non-passphrase protected SSH key to execute remote jobs on hosts. You can protect the SSH key with a passphrase by following this procedure.
-
On your Foreman server or Smart Proxy server, use
ssh-keygen
to add a passphrase to your SSH key:# ssh-keygen -p -f ~foreman-proxy/.ssh/id_rsa_foreman_proxy
-
Users now must use a passphrase when running remote execution jobs on hosts.
13.17. Using the Foreman API to Obtain SSH Keys for Remote Execution
To use the Foreman API to download the public key from Smart Proxy, complete this procedure on each target host.
-
On the target host, create the
~/.ssh
directory to store the SSH key:# mkdir ~/.ssh
-
Download the SSH key from Smart Proxy:
# curl https://smartproxy.example.com:9090/ssh/pubkey >> ~/.ssh/authorized_keys
-
Configure permissions for the
~/.ssh
directory:# chmod 700 ~/.ssh
-
Configure permissions for the
authorized_keys
file:# chmod 600 ~/.ssh/authorized_keys
13.18. Configuring a AutoYaST Template to Distribute SSH Keys During Provisioning
You can add a remote_execution_ssh_keys
snippet to your custom AutoYaST template to deploy SSH Keys to hosts during provisioning.
AutoYaST templates that Foreman ships include this snippet by default.
Foreman copies the SSH key for remote execution to the systems during provisioning.
-
To include the public key in newly-provisioned hosts, add the following snippet to the AutoYaST template that you use:
<%= snippet 'remote_execution_ssh_keys' %>
13.19. Configuring a Kickstart Template to Distribute SSH Keys During Provisioning
You can add a remote_execution_ssh_keys
snippet to your custom Kickstart template to deploy SSH Keys to hosts during provisioning.
Kickstart templates that Foreman ships include this snippet by default.
Foreman copies the SSH key for remote execution to the systems during provisioning.
-
To include the public key in newly-provisioned hosts, add the following snippet to the Kickstart template that you use:
<%= snippet 'remote_execution_ssh_keys' %>
13.20. Configuring a Preseed Template to Distribute SSH Keys During Provisioning
You can add a remote_execution_ssh_keys
snippet to your custom Preseed template to deploy SSH Keys to hosts during provisioning.
Preseed templates that Foreman ships include this snippet by default.
Foreman copies the SSH key for remote execution to the systems during provisioning.
-
To include the public key in newly-provisioned hosts, add the following snippet to the Preseed template that you use:
<%= snippet 'remote_execution_ssh_keys' %>
13.21. Configuring a keytab for Kerberos Ticket Granting Tickets
Use this procedure to configure Foreman to use a keytab to obtain Kerberos ticket granting tickets. If you do not set up a keytab, you must manually retrieve tickets.
-
Find the ID of the
foreman-proxy
user:# id -u foreman-proxy
-
Modify the
umask
value so that new files have the permissions600
:# umask 077
-
Create the directory for the keytab:
# mkdir -p "/var/kerberos/krb5/user/My_User_ID"
-
Create a keytab or copy an existing keytab to the directory:
# cp My_Client.keytab /var/kerberos/krb5/user/My_User_ID/client.keytab
-
Change the directory owner to the
foreman-proxy
user:# chown -R foreman-proxy:foreman-proxy "/var/kerberos/krb5/user/My_User_ID"
-
Ensure that the keytab file is read-only:
# chmod -wx "/var/kerberos/krb5/user/My_User_ID/client.keytab"
-
Restore the SELinux context:
# restorecon -RvF /var/kerberos/krb5
13.22. Configuring Kerberos Authentication for Remote Execution
You can use Kerberos authentication to establish an SSH connection for remote execution on Foreman hosts.
-
Enroll Foreman server on the Kerberos server
-
Enroll the Foreman target host on the Kerberos server
-
Configure and initialize a Kerberos user account for remote execution
-
Ensure that the foreman-proxy user on Foreman has a valid Kerberos ticket granting ticket
-
To install and enable Kerberos authentication for remote execution, enter the following command:
# foreman-installer --scenario katello \ --foreman-proxy-plugin-remote-execution-script-ssh-kerberos-auth true
-
To edit the default user for remote execution, in the Foreman web UI, navigate to Administer > Settings and click the Remote Execution tab. In the SSH User row, edit the second column and add the user name for the Kerberos account.
-
Navigate to remote_execution_effective_user and edit the second column to add the user name for the Kerberos account.
-
To confirm that Kerberos authentication is ready to use, run a remote job on the host. For more information, see Executing a Remote Job in Managing Hosts.
13.23. Setting up Job Templates
Foreman provides default job templates that you can use for executing jobs. To view the list of job templates, navigate to Hosts > Job templates. If you want to use a template without making changes, proceed to Executing a Remote Job in Managing Hosts.
You can use default templates as a base for developing your own. Default job templates are locked for editing. Clone the template and edit the clone.
-
To clone a template, in the Actions column, select Clone.
-
Enter a unique name for the clone and click Submit to save the changes.
Job templates use the Embedded Ruby (ERB) syntax. For more information about writing templates, see the Template Writing Reference in Managing Hosts.
To create an Ansible job template, use the following procedure and instead of ERB syntax, use YAML syntax.
Begin the template with ---
.
You can embed an Ansible playbook YAML file into the job template body.
You can also add ERB syntax to customize your YAML Ansible template.
You can also import Ansible playbooks in Foreman.
For more information, see Synchronizing Repository Templates in Managing Hosts.
At run time, job templates can accept parameter variables that you define for a host. Note that only the parameters visible on the Parameters tab at the host’s edit page can be used as input parameters for job templates.
13.24. Executing a Remote Job
You can execute a job that is based on a job template against one or more hosts.
To use the CLI instead of the Foreman web UI, see the CLI procedure.
-
In the Foreman web UI, navigate to Hosts > All Hosts and select the target hosts on which you want to execute a remote job. You can use the search field to filter the host list.
-
From the Select Action list, select Schedule a Job.
-
On the Job invocation page, define the main job settings:
-
Select the Job category and the Job template you want to use.
-
Optional: Select a stored search string in the Bookmark list to specify the target hosts.
-
Optional: Further limit the targeted hosts by entering a Search query. The Resolves to line displays the number of hosts affected by your query. Use the refresh button to recalculate the number after changing the query. The preview icon lists the targeted hosts.
-
The remaining settings depend on the selected job template. See Creating a Job Template for information on adding custom parameters to a template.
-
Optional: To configure advanced settings for the job, click Display advanced fields. Some of the advanced settings depend on the job template, the following settings are general:
-
Effective user defines the user for executing the job, by default it is the SSH user.
-
Concurrency level defines the maximum number of jobs executed at once, which can prevent overload of systems' resources in a case of executing the job on a large number of hosts.
-
Timeout to kill defines time interval in seconds after which the job should be killed, if it is not finished already. A task which could not be started during the defined interval, for example, if the previous task took too long to finish, is canceled.
-
Type of query defines when the search query is evaluated. This helps to keep the query up to date for scheduled tasks.
-
Execution ordering determines the order in which the job is executed on hosts: alphabetical or randomized.
Concurrency level and Timeout to kill settings enable you to tailor job execution to fit your infrastructure hardware and needs.
-
-
To run the job immediately, ensure that Schedule is set to Execute now. You can also define a one-time future job, or set up a recurring job. For recurring tasks, you can define start and end dates, number and frequency of runs. You can also use cron syntax to define repetition. For more information about cron, see Automate your Linux system tasks with cron.
-
Click Submit. You can view status of the jobs in the Recent Jobs section on the same page.
-
Enter the following command on Foreman:
# hammer settings set \ --name=remote_execution_global_proxy \ --value=false
-
Find the ID of the job template you want to use:
# hammer job-template list
-
Show the template details to see parameters required by your template:
# hammer job-template info --id My_Template_ID
-
Execute a remote job with custom parameters:
# hammer job-invocation create \ --inputs My_Key_1="My_Value_1",My_Key_2="My_Value_2",... \ --job-template "My_Template_Name" \ --search-query "My_Search_Query"
Replace
My_Search_Query
with the filter expression that defines hosts, for example"name ~ My_Pattern"
. For more information about executing remote commands with hammer, enterhammer job-template --help
andhammer job-invocation --help
.
13.25. Scheduling a Recurring Ansible Job for a Host
You can schedule a recurring job to run Ansible roles on hosts.
-
Ensure you have the
view_foreman_tasks
,view_job_invocations
, andview_recurring_logics
permissions.
-
In the Foreman web UI, navigate to Hosts > All Hosts and select the target host on which you want to execute a remote job.
-
On the Ansible tab, select Jobs.
-
Click Schedule recurring job.
-
Define the repetition frequency, start time, and date of the first run in the Create New Recurring Ansible Run window.
-
Click Submit.
-
Optional: View the scheduled Ansible job in host overview or by navigating to Ansible > Jobs.
13.26. Scheduling a Recurring Ansible Job for a Host Group
You can schedule a recurring job to run Ansible roles on host groups.
-
In the Foreman web UI, navigate to Configure > Host groups.
-
In the Actions column, select Configure Ansible Job for the host group you want to schedule an Ansible roles run for.
-
Click Schedule recurring job.
-
Define the repetition frequency, start time, and date of the first run in the Create New Recurring Ansible Run window.
-
Click Submit.
13.27. Monitoring Jobs
You can monitor the progress of a job while it is running. This can help in any troubleshooting that may be required.
Ansible jobs run on batches of 100 hosts, so you cannot cancel a job running on a specific host. A job completes only after the Ansible playbook runs on all hosts in the batch.
-
In the Foreman web UI, navigate to Monitor > Jobs. This page is automatically displayed if you triggered the job with the
Execute now
setting. To monitor scheduled jobs, navigate to Monitor > Jobs and select the job run you wish to inspect. -
On the Job page, click the Hosts tab. This displays the list of hosts on which the job is running.
-
In the Host column, click the name of the host that you want to inspect. This displays the Detail of Commands page where you can monitor the job execution in real time.
-
Click Back to Job at any time to return to the Job Details page.
-
Find the ID of a job:
# hammer job-invocation list
-
Monitor the job output:
# hammer job-invocation output \ --host "My_Host_Name" \ --id My_Job_ID
-
Optional: To cancel a job, enter the following command:
# hammer job-invocation cancel \ --id My_Job_ID
14. Host Status in Foreman
In Foreman, each host has a global status that indicates which hosts need attention. Each host also has sub-statuses that represent status of a particular feature. With any change of a sub-status, the global status is recalculated and the result is determined by statuses of all sub-statuses.
14.1. Host Global Status Overview
The global status represents the overall status of a particular host. The status can have one of three possible values: OK, Warning, or Error. You can find global status on the Hosts Overview page. The status displays a small icon next to host name and has a color that corresponds with the status. Hovering over the icon renders a tooltip with sub-status information to quickly find out more details. To view the global status for a host, in the Foreman web UI, navigate to Hosts > All Hosts.
- OK
-
No errors were reported by any sub-status. This status is highlighted with the color green.
- Warning
-
While no error was detected, some sub-status raised a warning. For example, there are no configuration management reports for the host even though the host is configured to send reports. It is a good practice to investigate any warnings to ensure that your deployment remains healthy. This status is highlighted with the color yellow.
- Error
-
Some sub-status reports a failure. For example, a run contains some failed resources. This status is highlighted with the color red.
If you want to search for hosts according to their status, use the syntax for searching in Foreman that is outlined in the Searching and Bookmarking chapter of the Administering Foreman guide, and then build your searches out using the following status-related examples:
To search for hosts that have an OK status:
global_status = ok
To search for all hosts that deserve attention:
global_status = error or global_status = warning
14.2. Host Sub-status Overview
A sub-status monitors only a part of a host’s capabilities.
To view the sub-statuses of a host, in the Foreman web UI, navigate to Hosts > All Hosts and click on the host whose full status you want to inspect. You can view the global host status next to the name of the host and the host sub-statuses on the Host status card.
Each sub-status has its own set of possible values that are mapped to the three global status values.
Below are listed sub-statuses that Foreman contains. There can be more sub-statuses depending on which plug-ins you add to your Foreman.
- Configuration
-
This sub-status is only relevant if Foreman uses a configuration management system like Ansible, Puppet, or Salt.
Possible values:
Label Global host status Alerts disabled
OK
Active
OK
Pending
OK
No changes
OK
No reports
OK / Warning
Out of sync
Warning
Error
Error
Additional information about the values of this sub-status:
-
Active: During the last configuration, some resources were applied.
-
Pending: During the last configuration, some resources would be applied but your configuration management integration was configured to run in
noop
mode. -
No changes: During the last configuration, nothing changed.
-
No reports: This can be both a Warning or OK status. When there are no reports but the host uses an associated Smart Proxy for configuration management or the
always_show_configuration_status
setting is set totrue
, it maps to Warning. Otherwise it maps to OK. -
Error: This indicates an error during configuration. For example, a configuration run failed to install a package.
-
Out of sync: A configuration report was not received within the expected interval, based on the
outofsync_interval
setting. Reports are identified by an origin and can have different intervals based upon it.
-
- Build
-
This sub-status is only relevant for hosts provisioned from Foreman or hosts registered through global registration.
Possible values:
Label Global host status Number value Installed
OK
0
Pending installation
OK
1
Token expired
Error
2
Installation error
Error
3
- Compliance
-
Indicates if the host is compliant with OpenSCAP policies.
Possible values:
Label Global host status Number value Compliant
OK
0
Inconclusive
Warning
1
At least one incompliant
Error
2
- Execution
-
Status of the last completed remote execution job.
Possible values:
Label Global host status Number value Last execution succeeded / No execution finished yet
OK
0
Last execution failed
Error
1
Unknown execution status
OK
2 or 3
Last execution cancelled
OK
4
- Errata
-
Indicates if Errata is available on the host.
Possible values:
Label Global host status Number value Up to date
OK
0
Unknown
Warning
1
Needed errata
Error
2
Needed security errata
Error
3
- Subscription
-
Indicates if the host has a valid RHEL subscription.
Possible values:
Label Global host status Number value Fully entitled
OK
0
Partially entitled
Warning
1
Unentitled
Error
2
Unknown
Warning
3
Unsubscribed hypervisor
Warning
4
SCA enabled
OK
5
- Service level
-
Indicates if a subscription matching your specified Service level syspurpose value can be attached.
Possible values:
Label Global host status Number value Unknown
OK
0
Mismatched
Warning
1
Matched
OK
2
Not specified
OK
3
- Role
-
Indicates if a subscription matching your specified Role syspurpose value can be attached.
Possible values:
Label Global host status Number value Unknown
OK
0
Mismatched
Warning
1
Matched
OK
2
Not specified
OK
3
- Usage
-
Indicates if a subscription matching your specified Usage syspurpose value can be attached.
Possible values:
Label Global host status Number value Unknown
OK
0
Mismatched
Warning
1
Matched
OK
2
Not specified
OK
3
- Addons
-
Indicates if a subscription matching your specified Addons syspurpose value can be attached.
Possible values:
Label Global host status Number value Unknown
OK
0
Mismatched
Warning
1
Matched
OK
2
Not specified
OK
3
- System purpose
-
Indicates if a subscription matching your specified syspurpose values can be attached.
Possible values:
Label Global host status Number value Unknown
OK
0
Mismatched
Warning
1
Matched
OK
2
Not specified
OK
3
- Traces
-
Indicates if the host needs a reboot or a process restart.
Possible values:
Label Global host status Number value Unknown
Warning
-1
Up to date
OK
0
Required process restart
Error
1
Required reboot
Error
2
If you want to search for hosts according to their sub-status, use the syntax for searching in Foreman that is outlined in the Searching and Bookmarking chapter of the Administering Foreman guide, and then build your searches out using the following status-related examples:
You search for hosts' configuration sub-statuses based on their last reported state.
For example, to find hosts that have at least one pending resource:
status.pending > 0
To find hosts that restarted some service during last run:
status.restarted > 0
To find hosts that have an interesting last run that might indicate something has happened:
status.interesting = true
15. Synchronizing Template Repositories
In Foreman, you can synchronize repositories of job templates, provisioning templates, report templates, and partition table templates between Foreman server and a version control system or local directory. In this chapter, a Git repository is used for demonstration purposes.
This section details the workflow for installing and configuring the TemplateSync plug-in and performing exporting and importing tasks.
15.1. Enabling the TemplateSync Plug-in
-
To enable the plug-in on your Foreman server, enter the following command:
# foreman-installer --enable-foreman-plugin-templates
-
To verify that the plug-in is installed correctly, ensure Administer > Settings includes the TemplateSync menu.
15.2. Configuring the TemplateSync Plug-in
In the Foreman web UI, navigate to Administer > Settings > TemplateSync to configure the plug-in. The following table explains the attributes behavior. Note that some attributes are used only for importing or exporting tasks.
Parameter | API parameter name | Meaning on importing | Meaning on exporting |
---|---|---|---|
Associate |
Accepted values: |
Associates templates with OS, Organization, and Location based on metadata. |
N/A |
Branch |
|
Specifies the default branch in Git repository to read from. |
Specifies the default branch in Git repository to write to. |
Dirname |
|
Specifies the subdirectory under the repository to read from. |
Specifies the subdirectory under the repository to write to. |
Filter |
|
Imports only templates with names that match this regular expression. |
Exports only templates with names that match this regular expression. |
Force import |
|
Imported templates overwrite locked templates with the same name. |
N/A |
Lock templates |
|
Do not overwrite existing templates when you import a new template with the same name, unless Force import is enabled. |
N/A |
Metadata export mode |
Accepted values: |
N/A |
Defines how metadata is handled when exporting:
|
Negate |
Accepted values: |
Imports templates ignoring the filter attribute. |
Exports templates ignoring the filter attribute. |
Prefix |
|
Adds specified string to the beginning of the template if the template name does not start with the prefix already. |
N/A |
Repo |
|
Defines the path to the repository to synchronize from. |
Defines the path to a repository to export to. |
Verbosity |
Accepted values: |
Enables writing verbose messages to the logs for this action. |
N/A |
15.3. Using Repository Sources
You can use existing repositories or local directories to synchronize templates with your Foreman server.
15.3.1. Synchronizing Templates with an Existing Repository
Use this procedure to synchronize templates between your Foreman server and an existing repository.
-
If you want to use HTTPS to connect to the repository and you use a self-signed certificate authentication on your Git server, validate the certificate:
# sudo -u foreman git config --global http.sslCAPath Path_To_My_Certificate
-
If you want to use SSH to connect to the repository, perform the following steps:
-
Create an SSH key pair if you do not already have it. Do not specify a passphrase.
# sudo -u foreman ssh-keygen
-
Configure your version control server with the public key from your Foreman, which resides in
/usr/share/foreman/.ssh/id_rsa.pub
. -
Accept the Git SSH host key as the
foreman
user:# sudo -u foreman ssh git.example.com
-
-
Configure the TemplateSync plug-in settings on a TemplateSync tab.
-
Change the Branch setting to match the target branch on a Git server.
-
Change the Repo setting to match the Git repository. For example, for the repository located in
git@git.example.com/templates.git
set the setting intogit@git.example.com/templates.git
.
-
15.3.2. Synchronizing Templates with a Local Directory
Synchronizing templates with a local directory is useful if you have configured a version control repository in the local directory. That way, you can edit templates and track the history of edits in the directory. You can also synchronize changes to Foreman server after editing the templates.
-
Each template must contain the location and organization that the template belongs to. This applies to all template types. Before you import a template, ensure that you add the following section to the template:
<%# kind: provision name: My_Provisioning_Template oses: - My_first_OS - My_second_OS locations: - My_first_Location - My_second_Location organizations: - My_first_Organization - My_second_Organization %>
-
In
/var/lib/foreman
, create a directory for storing templates:# mkdir /var/lib/foreman/My_Templates_Dir
NoteYou can place your templates to a custom directory outside
/var/lib/foreman
, but you have to ensure that theForeman
service can read its contents. The directory must have the correct file permissions and theforeman_lib_t
SELinux label. -
Change the owner of the new templates directory to the
foreman
user:# chown foreman /var/lib/foreman/My_Templates_Dir
-
Change the Repo setting on the TemplateSync tab to match the
/var/lib/foreman/My_Templates_Dir/
directory.
15.4. Importing and Exporting Templates
You can import and export templates using the Foreman web UI, Hammer CLI, or Foreman API. Foreman API calls use the role-based access control system, which enables the tasks to be executed as any user. You can synchronize templates with a version control system, such as Git, or a local directory.
15.4.1. Importing Templates
You can import templates from a repository of your choice.
You can use different protocols to point to your repository, for example /tmp/dir
, git://example.com
, https://example.com
, and ssh://example.com
.
Note
|
The templates provided by Foreman are locked and you cannot import them by default.
To overwrite this behavior, change the |
-
Each template must contain the location and organization that the template belongs to. This applies to all template types. Before you import a template, ensure that you add the following section to the template:
<%# kind: provision name: My_Provisioning_Template oses: - My_first_OS - My_second_OS locations: - My_first_Location - My_second_Location organizations: - My_first_Organization - My_second_Organization %>
To use the CLI instead of the Foreman web UI, see the CLI procedure. To use the API, see the API Procedure.
-
In the Foreman web UI, navigate to Hosts > Sync Templates.
-
Click Import.
-
Each field is populated with values configured in Administer > Settings > TemplateSync. Change the values as required for the templates you want to import. For more information about each field, see Configuring the TemplateSync Plug-in.
-
Click Submit.
The Foreman web UI displays the status of the import. The status is not persistent; if you leave the status page, you cannot return to it.
-
To import a template from a repository, enter the following command:
$ hammer import-templates \ --branch "My_Branch" \ --filter '.*Template Name$' \ --organization "My_Organization" \ --prefix "[Custom Index] " \ --repo "https://git.example.com/path/to/repository"
For better indexing and management of your templates, use
--prefix
to set a category for your templates. To select certain templates from a large repository, use--filter
to define the title of the templates that you want to import. For example--filter '.*Ansible Default$'
imports various Ansible Default templates.
-
Send a
POST
request toapi/v2/templates/import
:# curl -H "Accept:application/json" \ -H "Content-Type:application/json" \ -u login:password \ -k https://foreman.example.com/api/v2/templates/import \ -X POST
If the import is successful, you receive
{"message":"Success"}
.
15.4.2. Exporting Templates
Use this procedure to export templates to a git repository.
To use the CLI instead of the Foreman web UI, see the CLI procedure. To use the API, see the API Procedure.
-
In the Foreman web UI, navigate to Hosts > Sync Templates.
-
Click Export.
-
Each field is populated with values configured in Administer > Settings > TemplateSync. Change the values as required for the templates you want to export. For more information about each field, see Configuring the TemplateSync Plug-in.
-
Click Submit.
The Foreman web UI displays the status of the export. The status is not persistent; if you leave the status page, you cannot return to it.
-
To export the templates to a repository, enter the following command:
hammer export-templates \ --organization "My_Organization" \ --repo "https://git.example.com/path/to/repository"
NoteThis command clones the repository, makes changes in a commit, and pushes back to the repository. You can use the
--branch "My_Branch"
option to export the templates to a specific branch.
-
Send a
POST
request toapi/v2/templates/export
:# curl -H "Accept:application/json" \ -H "Content-Type:application/json" \ -u login:password \ -k https://foreman.example.com/api/v2/templates/export \ -X POST
If the export is successful, you receive
{"message":"Success"}
.
Note
|
You can override default API settings by specifying them in the request with the # curl -H "Accept:application/json" \ -H "Content-Type:application/json" \ -u login:password \ -k https://foreman.example.com/api/v2/templates/export \ -X POST \ -d "{\"repo\":\"git.example.com/templates\"}" |
15.5. Uninstalling the Foreman Templates Plug-in
To avoid errors after removing the foreman_templates plugin:
-
Disable the plug-in using the Foreman installer:
# foreman-installer --no-enable-foreman-plugin-templates
-
Clean custom data of the plug-in. The command does not affect any templates that you created.
# foreman-rake templates:cleanup
-
Uninstall the plug-in:
# yum remove foreman-plugin-templates
16. Managing Packages
You can use Foreman to install, upgrade, and remove packages on hosts.
16.1. Installing Packages on a Host
Use this procedure to review and install packages on a host using the Foreman web UI. The list of packages available for installation depends on the Content View and Lifecycle Environment assigned to the host.
-
In the Foreman web UI, navigate to Hosts > All Hosts and select the host you want to install packages on.
-
On the Content tab, select the Packages tab.
-
On the vertical ellipsis icon next to the upgrade button, click Install Packages.
-
In the Install packages window, select the package or packages that you want to install on the host.
-
Click Install.
By default, the packages are installed using remote execution. For more information about running remote execution jobs, see Configuring and Setting up Remote Jobs in Managing Hosts.
Create a body of the API request in the JSON format by following the instructions below.
-
Create the
"job_invocation"
object and place rest of the body inside this object. -
Create the
"inputs"
object with the"package"
field of the string type specifying the packages you want to install. If you are specifying multiple packages, separate them with a whitespace. -
Create a
"feature"
field of the string type with value"katello_package_install"
. -
Create a
"search_query"
field of the string type and input a search query matching the hosts on which you want to install the packages. -
Optional: If you want to install packages as a specific user, create an
ssh
object with the following fields of the string type:-
"effective_user"
with the name of the ssh user -
"effective_user_password"
with the password of the ssh user if this password is required
-
-
Optional: If you want to install packages at a later time, create the
"scheduling"
object. The object can contain one or both of the following fields of the string type with date, time, and a timezone in the ISO 8601 format:-
"start_at"
- sets the time to install the packages -
"start_before"
- sets the latest time to install the packages. If it is not possible to install the packages by this time, then this action is cancelled.
If you omit time, it defaults to 00:00:00. If you omit timezone, it defaults to UTC.
-
-
Optional: If you want to limit the number of hosts on which the job is run concurrently, create the
"concurrency_control"
object with the"concurrency_level"
field of the integer type. Assign the number of hosts as the field value. -
Optional: If you want to install packages at a later time and you want the host search query to be evaluated at a time of running the job, create a
"targeting_type"
field of the string type with the"dynamic_query"
value. This is useful if you expect the result of the search query to be different at the time of running the job due to changed status of the hosts. If you omit this field, it defaults to"static_query"
. -
Send a
POST
request with the created body to the/api/job_invocations
endpoint of your Foreman server and use a tool like python to see a formatted response.Example API request:
curl https://foreman.example.com/api/job_invocations \ -H "content-type: application/json" \ -X POST \ -d @Path_To_My_API_Request_Body \ -u My_Username:My_Password | python3 -m json.tool
-
In the Foreman web UI, navigate to Monitor > Jobs and see the report of the scheduled or completed remote execution job to install the packages on the selected hosts.
{
"job_invocation" : {
"concurrency_control" : {
"concurrency_level" : 100
},
"feature" : "katello_package_install",
"inputs" : {
"package" : "nano vim"
},
"scheduling" : {
"start_at" : "2023-09-21T19:00:00+00:00",
"start_before" : "2023-09-23T00:00:00+00:00"
},
"search_query" : "*",
"ssh" : {
"effective_user" : "My_Username",
"effective_user_password" : "My_Password"
},
"targeting_type" : "dynamic_query"
}
}
16.2. Upgrading Packages on a Host
You can upgrade packages on a host in bulk in the Foreman web UI.
-
In the Foreman web UI, navigate to Hosts > All Hosts.
-
Click the name of the host you want to modify.
-
Click the Content tab, then click the Packages tab.
-
Select Upgradable from the Status list.
-
Select the packages you want to upgrade.
-
Click the Upgrade button. You get a REX job notification once the remote execution job is complete.
Create a body of the API request in the JSON format by following the instructions below.
-
Create the
"job_invocation"
object and place rest of the body inside this object. -
Create the
"inputs"
object with the"package"
field of the string type specifying the packages you want to update. If you are specifying multiple packages, separate them with a whitespace. -
Create a
"feature"
field of the string type with value"katello_package_update"
. -
Create a
"search_query"
field of the string type and input a search query matching the hosts on which you want to update the packages. -
Optional: If you want to update packages as a specific user, create an
ssh
object with the following fields of the string type:-
"effective_user"
with the name of the ssh user -
"effective_user_password"
with the password of the ssh user if this password is required
-
-
Optional: If you want to update packages at a later time, create the
"scheduling"
object. The object can contain one or both of the following fields of the string type with date, time, and a timezone in the ISO 8601 format:-
"start_at"
- sets the time to update the packages -
"start_before"
- sets the latest time to update the packages. If it is not possible to update the packages by this time, then this action is cancelled.
If you omit time, it defaults to 00:00:00. If you omit timezone, it defaults to UTC.
-
-
Optional: If you want to limit the number of hosts on which the job is run concurrently, create the
"concurrency_control"
object with the"concurrency_level"
field of the integer type. Assign the number of hosts as the field value. -
Optional: If you want to update packages at a later time and you want the host search query to be evaluated at a time of running the job, create a
"targeting_type"
field of the string type with the"dynamic_query"
value. This is useful if you expect the result of the search query to be different at the time of running the job due to changed status of the hosts. If you omit this field, it defaults to"static_query"
. -
Send a
POST
request with the created body to the/api/job_invocations
endpoint of your Foreman server and use a tool like python to see a formatted response.Example API request:
curl https://foreman.example.com/api/job_invocations \ -H "content-type: application/json" \ -X POST \ -d @Path_To_My_API_Request_Body \ -u My_Username:My_Password | python3 -m json.tool
-
In the Foreman web UI, navigate to Monitor > Jobs and see the report of the scheduled or completed remote execution job to update the packages on the selected hosts.
{
"job_invocation" : {
"concurrency_control" : {
"concurrency_level" : 100
},
"feature" : "katello_package_update",
"inputs" : {
"package" : "nano vim"
},
"scheduling" : {
"start_at" : "2023-09-21T19:00:00+00:00",
"start_before" : "2023-09-23T00:00:00+00:00"
},
"search_query" : "*",
"ssh" : {
"effective_user" : "My_Username",
"effective_user_password" : "My_Password"
},
"targeting_type" : "dynamic_query"
}
}
16.3. Removing Packages from a Host
You can remove packages from a host in the Foreman web UI.
-
In the Foreman web UI, navigate to Hosts > All Hosts.
-
Click the name of the host you want to modify.
-
Click the Content tab, then click the Packages tab.
-
Click the vertical ellipsis for the package you want to remove and select Remove. You get a REX job notification once the remote execution job is complete.
Create a body of the API request in the JSON format by following the instructions below.
-
Create the
"job_invocation"
object and place rest of the body inside this object. -
Create the
"inputs"
object with the"package"
field of the string type specifying the packages you want to remove. If you are specifying multiple packages, separate them with a whitespace. -
Create a
"feature"
field of the string type with value"katello_package_remove"
. -
Create a
"search_query"
field of the string type and input a search query matching the hosts on which you want to remove the packages. -
Optional: If you want to remove packages as a specific user, create an
ssh
object with the following fields of the string type:-
"effective_user"
with the name of the ssh user -
"effective_user_password"
with the password of the ssh user if this password is required
-
-
Optional: If you want to remove packages at a later time, create the
"scheduling"
object. The object can contain one or both of the following fields of the string type with date, time, and a timezone in the ISO 8601 format:-
"start_at"
- sets the time to remove the packages -
"start_before"
- sets the latest time to remove the packages. If it is not possible to remove the packages by this time, then this action is cancelled.
If you omit time, it defaults to 00:00:00. If you omit timezone, it defaults to UTC.
-
-
Optional: If you want to limit the number of hosts on which the job is run concurrently, create the
"concurrency_control"
object with the"concurrency_level"
field of the integer type. Assign the number of hosts as the field value. -
Optional: If you want to remove packages at a later time and you want the host search query to be evaluated at a time of running the job, create a
"targeting_type"
field of the string type with the"dynamic_query"
value. This is useful if you expect the result of the search query to be different at the time of running the job due to changed status of the hosts. If you omit this field, it defaults to"static_query"
. -
Send a
POST
request with the created body to the/api/job_invocations
endpoint of your Foreman server and use a tool like python to see a formatted response.Example API request:
curl https://foreman.example.com/api/job_invocations \ -H "content-type: application/json" \ -X POST \ -d @Path_To_My_API_Request_Body \ -u My_Username:My_Password | python3 -m json.tool
-
In the Foreman web UI, navigate to Monitor > Jobs and see the report of the scheduled or completed remote execution job to remove the packages on the selected hosts.
{
"job_invocation" : {
"concurrency_control" : {
"concurrency_level" : 100
},
"feature" : "katello_package_remove",
"inputs" : {
"package" : "nano vim"
},
"scheduling" : {
"start_at" : "2023-09-21T19:00:00+00:00",
"start_before" : "2023-09-23T00:00:00+00:00"
},
"search_query" : "*",
"ssh" : {
"effective_user" : "My_Username",
"effective_user_password" : "My_Password"
},
"targeting_type" : "dynamic_query"
}
}
Appendix A: Template Writing Reference
Embedded Ruby (ERB) is a tool for generating text files based on templates that combine plain text with Ruby code. Foreman uses ERB syntax in the following cases:
- Provisioning templates
-
For more information, see Creating Provisioning Templates in Provisioning Hosts.
- Remote execution job templates
-
For more information, see Configuring and Setting Up Remote Jobs.
- Report templates
-
For more information, see Using Report Templates to Monitor Hosts.
- Templates for partition tables
-
For more information, see Creating Partition Tables in Provisioning Hosts.
- Smart Class Parameters
-
For more information, see Configuring Puppet Smart Class Parameters in Configuring Hosts Using Puppet.
This section provides an overview of Foreman-specific macros and variables that can be used in ERB templates along with some usage examples. Note that the default templates provided by Foreman (Hosts > Provisioning templates, Hosts > Job templates, Monitor > Report Templates ) also provide a good source of ERB syntax examples.
When provisioning a host or running a remote job, the code in the ERB is executed and the variables are replaced with the host specific values. This process is referred to as rendering. Foreman server has the safemode rendering option enabled by default, which prevents any harmful code being executed from templates.
Accessing the Template Writing Reference in the Foreman web UI
You can access the template writing reference document in the Foreman web UI.
-
Log in to the Foreman web UI.
-
In the Foreman web UI, navigate to Administer > About.
-
Click the Templates DSL link in the Support section.
Using Autocompletion in Templates
You can access a list of available macros and usage information in the template editor with the autocompletion option. This works for all templates within Foreman.
-
In the Foreman web UI, navigate to either Hosts > Partition tables, Hosts > Provisioning templates, or Hosts > Job templates.
-
Click the settings icon at the top right corner of the template editor and select Autocompletion.
-
Press
Ctrl
+Space
in the template editor to access a list of all available macros. You can narrow down the list of macros by typing in more information about what you are looking for. For example, if you are looking for a method to list the ID of the content source for a host, you can typehost
and check the list of available macros for content source. -
A window next to the dropdown provides a description of the macro, its usage, and the value it will return.
-
When you find the method you are looking for, hit
Enter
to input the method.
You can also enable Live Autocompletion in the settings menu to view a list of macros that match the pattern whenever you type something. However, this might input macros in unintended places, like package names in a provisioning template.
Writing ERB Templates
The following tags are the most important and commonly used in ERB templates:
All Ruby code is enclosed within <% %>
in an ERB template.
The code is executed when the template is rendered.
It can contain Ruby control flow structures as well as Foreman-specific macros and variables.
For example:
<% if @host.operatingsystem.family == "Redhat" && @host.operatingsystem.major.to_i > 6 -%> systemctl <%= input("action") %> <%= input("service") %> <% else -%> service <%= input("service") %> <%= input("action") %> <% end -%>
Note that this template silently performs an action with a service and returns nothing at the output.
This provides the same functionality as <% %>
but when the template is executed, the code output is inserted into the template.
This is useful for variable substitution, for example:
Example input:
echo <%= @host.name %>
Example rendering:
host.example.com
Example input:
<% server_name = @host.fqdn %> <%= server_name %>
Example rendering:
host.example.com
Note that if you enter an incorrect variable, no output is returned. However, if you try to call a method on an incorrect variable, the following error message returns:
Example input:
<%= @example_incorrect_variable.fqdn -%>
Example rendering:
undefined method `fqdn' for nil:NilClass
By default, a newline character is inserted after a Ruby block if it is closed at the end of a line:
Example input:
<%= "line1" %> <%= "line2" %>
Example rendering:
line1 line2
To change the default behavior, modify the enclosing mark with -%>
:
Example input:
<%= "line1" -%> <%= "line2" %>
Example rendering:
line1line2
This is used to reduce the number of lines, where Ruby syntax permits, in rendered templates. White spaces in ERB tags are ignored.
An example of how this would be used in a report template to remove unnecessary newlines between a FQDN and IP address:
Example input:
<%= @host.fqdn -%> <%= @host.ip -%>
Example rendering:
host.example.com10.10.181.216
Encloses a comment that is ignored during template rendering:
Example input:
<%# A comment %>
This generates no output.
Because of the varying lengths of the ERB tags, indenting the ERB syntax might seem messy. ERB syntax ignore white space. One method of handling the indentation is to declare the ERB tag at the beginning of each new line and then use white space within the ERB tag to outline the relationships within the syntax, for example:
<%- load_hosts.each do |host| -%> <%- if host.build? %> <%= host.name %> build is in progress <%- end %> <%- end %>
Troubleshooting ERB Templates
The Foreman web UI provides two ways to verify the template rendering for a specific host:
-
Directly in the template editor – when editing a template (under Hosts > Partition tables, Hosts > Provisioning templates, or Hosts > Job templates), on the Template tab click Preview and select a host from the list. The template then renders in the text field using the selected host’s parameters. Preview failures can help to identify issues in your template.
-
At the host’s details page – select a host at Hosts > All hosts and click the Templates tab to list templates associated with the host. Select Review from the list next to the selected template to view it’s rendered version.
Generic Foreman-Specific Macros
This section lists Foreman-specific macros for ERB templates. You can use the macros listed in the following table across all kinds of templates.
Name | Description |
---|---|
indent(n) |
Indents the block of code by n spaces, useful when using a snippet template that is not indented. |
foreman_url(kind) |
Returns the full URL to host-rendered templates of the given kind.
For example, templates of the "provision" type usually reside at |
snippet(name) |
Renders the specified snippet template. Useful for nesting provisioning templates. |
snippets(file) |
Renders the specified snippet found in the Foreman database, attempts to load it from the |
snippet_if_exists(name) |
Renders the specified snippet, skips if no snippet with the specified name is found. |
Templates Macros
If you want to write custom templates, you can use some of the following macros. Depending on the template type, some of the following macros have different requirements.
For more information about the available macros for report templates, in the Foreman web UI, navigate to Monitor > Report Templates, and click Create Template. In the Create Template window, click the Help tab.
For more information about the available macros for job templates, in the Foreman web UI, navigate to Hosts > Job Templates, and click the New Job Template. In the New Job Template window, click the Help tab.
- input
-
Using the
input
macro, you can customize the input data that the template can work with. You can define the input name, type, and the options that are available for users. For report templates, you can only use user inputs. When you define a new input and save the template, you can then reference the input in the ERB syntax of the template body.<%= input('cpus') %>
This loads the value from user input
cpus
. - load_hosts
-
Using the
load_hosts
macro, you can generate a complete list of hosts.<%- load_hosts().each_record do |host| -%> <%= host.name %>
Use the
load_hosts
macro with theeach_record
macro to load records in batches of 1000 to reduce memory consumption.If you want to filter the list of hosts for the report, you can add the option
search: input(‘Example_Host’)
:<% load_hosts(search: input('Example_Host')).each_record do |host| -%> <%= host.name %> <% end -%>
In this example, you first create an input that you then use to refine the search criteria that the
load_hosts
macro retrieves. - report_row
-
Using the
report_row
macro, you can create a formatted report for ease of analysis. Thereport_row
macro requires thereport_render
macro to generate the output.Example input:<%- load_hosts(search: input('Example_Host')).each_record do |host| -%> <%- report_row( 'Server FQDN': host.name ) -%> <%- end -%> <%= report_render -%>
Example rendering:Server FQDN host1.example.com host2.example.com host3.example.com host4.example.com host5.example.com host6.example.com
You can add extra columns to the report by adding another header. The following example adds IP addresses to the report:
Example input:<%- load_hosts(search: input('host')).each_record do |host| -%> <%- report_row( 'Server FQDN': host.name, 'IP': host.ip ) -%> <%- end -%> <%= report_render -%>
Example rendering:Server FQDN,IP host1.example.com,10.8.30.228 host2.example.com,10.8.30.227 host3.example.com,10.8.30.226 host4.example.com,10.8.30.225 host5.example.com,10.8.30.224 host6.example.com,10.8.30.223
- report_render
-
This macro is available only for report templates.
Using the
report_render
macro, you create the output for the report. During the template rendering process, you can select the format that you want for the report. YAML, JSON, HTML, and CSV formats are supported.<%= report_render -%>
- render_template()
-
This macro is available only for job templates.
Using this macro, you can render a specific template. You can also enable and define arguments that you want to pass to the template.
- truthy
-
Using the
truthy
macro, you can declare if the value passed is true or false, regardless of whether the value is an integer or boolean or string.This macro helps to avoid confusion when your template contains multiple value types. For example, the boolean value
true
is not the same as the string value"true"
. With this macro, you can declare how you want the template to interpret the value and avoid confusion.You can use
truthy
to declare values as follows:truthy?(“true”) => true truthy?(1) => true truthy?(“false”) => false truthy?(0) => false
- falsy
-
The falsy macro serves the same purpose as the truthy macro.
Using the
falsy
macro, you can declare if the value passed in is true or false, regardless of whether the value is an integer or boolean or string.You can use
falsy
to declare values as follows:falsy?(“true”) => false falsy?(1) => false falsy?(“false”) => true falsy?(0) => true
Host-Specific Variables
The following variables enable using host data within templates.
Note that job templates accept only @host
variables.
Name | Description |
---|---|
@host.architecture |
The architecture of the host. |
@host.bond_interfaces |
Returns an array of all bonded interfaces. See Parsing Arrays. |
@host.capabilities |
The method of system provisioning, can be either build (for example kickstart) or image. |
@host.certname |
The SSL certificate name of the host. |
@host.diskLayout |
The disk layout of the host. Can be inherited from the operating system. |
@host.domain |
The domain of the host. |
@host.environment Deprecated Use the |
The Puppet environment of the host. |
@host.facts |
Returns a Ruby hash of facts from Facter. For example to access the 'ipaddress' fact from the output, specify @host.facts['ipaddress']. |
@host.grub_pass |
Returns the host’s bootloader password. |
@host.hostgroup |
The host group of the host. |
host_enc['parameters'] |
Returns a Ruby hash containing information on host parameters. For example, use host_enc['parameters']['lifecycle_environment'] to get the life cycle environment of a host. |
@host.image_build? |
Returns |
@host.interfaces |
Contains an array of all available host interfaces including the primary interface. See Parsing Arrays. |
@host.interfaces_with_identifier('IDs') |
Returns array of interfaces with given identifier. You can pass an array of multiple identifiers as an input, for example @host.interfaces_with_identifier(['eth0', 'eth1']). See Parsing Arrays. |
@host.ip |
The IP address of the host. |
@host.location |
The location of the host. |
@host.mac |
The MAC address of the host. |
@host.managed_interfaces |
Returns an array of managed interfaces (excluding BMC and bonded interfaces). See Parsing Arrays. |
@host.medium |
The assigned operating system installation medium. |
@host.name |
The full name of the host. |
@host.operatingsystem.family |
The operating system family. |
@host.operatingsystem.major |
The major version number of the assigned operating system. |
@host.operatingsystem.minor |
The minor version number of the assigned operating system. |
@host.operatingsystem.name |
The assigned operating system name. |
@host.operatingsystem.boot_files_uri(medium_provider) |
Full path to the kernel and initrd, returns an array. |
@host.os.medium_uri(@host) |
The URI used for provisioning (path configured in installation media). |
host_param('parameter_name') |
Returns the value of the specified host parameter. |
host_param_false?('parameter_name') |
Returns |
host_param_true?('parameter_name') |
Returns |
@host.primary_interface |
Returns the primary interface of the host. |
@host.provider |
The compute resource provider. |
@host.provision_interface |
Returns the provisioning interface of the host. Returns an interface object. |
@host.ptable |
The partition table name. |
@host.puppet_ca_server Deprecated Use the |
The Puppet CA server the host must use. |
@host.puppetmaster Deprecated Use the |
The Puppet server the host must use. |
@host.pxe_build? |
Returns |
@host.shortname |
The short name of the host. |
@host.sp_ip |
The IP address of the BMC interface. |
@host.sp_mac |
The MAC address of the BMC interface. |
@host.sp_name |
The name of the BMC interface. |
@host.sp_subnet |
The subnet of the BMC network. |
@host.subnet.dhcp |
Returns |
@host.subnet.dns_primary |
The primary DNS server of the host. |
@host.subnet.dns_secondary |
The secondary DNS server of the host. |
@host.subnet.gateway |
The gateway of the host. |
@host.subnet.mask |
The subnet mask of the host. |
@host.url_for_boot(:initrd) |
Full path to the initrd image associated with this host. Not recommended, as it does not interpolate variables. |
@host.url_for_boot(:kernel) |
Full path to the kernel associated with this host. Not recommended, as it does not interpolate variables, prefer boot_files_uri. |
@provisioning_type |
Equals to 'host' or 'hostgroup' depending on type of provisioning. |
@static |
Returns |
@template_name |
Name of the template being rendered. |
grub_pass |
Returns a bootloader argument to set the encrypted bootloader password, such as --md5pass=#{@host.grub_pass}. |
ks_console |
Returns a string assembled using the port and the baud rate of the host which can be added to a kernel line. For example console=ttyS1,9600. |
root_pass |
Returns the root password configured for the system. |
The majority of common Ruby methods can be applied on host-specific variables. For example, to extract the last segment of the host’s IP address, you can use:
<% @host.ip.split('.').last %>
Kickstart-Specific Variables
The following variables are designed to be used within kickstart provisioning templates.
Name | Description |
---|---|
@arch |
The host architecture name, same as @host.architecture.name. |
@dynamic |
Returns |
@epel |
A command which will automatically install the correct version of the epel-release rpm. Use in a %post script. |
@mediapath |
The full kickstart line to provide the URL command. |
@osver |
The operating system major version number, same as @host.operatingsystem.major. |
Conditional Statements
In your templates, you might perform different actions depending on which value exists. To achieve this, you can use conditional statements in your ERB syntax.
In the following example, the ERB syntax searches for a specific host name and returns an output depending on the value it finds:
<% load_hosts().each_record do |host| -%> <% if @host.name == "host1.example.com" -%> <% result="positive" -%> <% else -%> <% result="negative" -%> <% end -%> <%= result -%>
host1.example.com positive
Parsing Arrays
While writing or modifying templates, you might encounter variables that return arrays.
For example, host variables related to network interfaces, such as @host.interfaces
or @host.bond_interfaces
, return interface data grouped in an array.
To extract a parameter value of a specific interface, use Ruby methods to parse the array.
The following procedure is an example that you can use to find the relevant methods to parse arrays in your template. In this example, a report template is used, but the steps are applicable to other templates.
-
To retrieve the NIC of a content host, in this example, using the
@host.interfaces
variable returns class values that you can then use to find methods to parse the array.Example input:<%= @host.interfaces -%>
Example rendering:<Nic::Base::ActiveRecord_Associations_CollectionProxy:0x00007f734036fbe0>
-
In the Create Template window, click the Help tab and search for the
ActiveRecord_Associations_CollectionProxy
andNic::Base
classes. -
For
ActiveRecord_Associations_CollectionProxy
, in the Allowed methods or members column, you can view the following methods to parse the array:[] each find_in_batches first map size to_a
-
For
Nic::Base
, in the Allowed methods or members column, you can view the following method to parse the array:alias? attached_devices attached_devices_identifiers attached_to bond_options children_mac_addresses domain fqdn identifier inheriting_mac ip ip6 link mac managed? mode mtu nic_delay physical? primary provision shortname subnet subnet6 tag virtual? vlanid
-
To iterate through an interface array, add the relevant methods to the ERB syntax:
Example input:<% load_hosts().each_record do |host| -%> <% host.interfaces.each do |iface| -%> iface.alias?: <%= iface.alias? %> iface.attached_to: <%= iface.attached_to %> iface.bond_options: <%= iface.bond_options %> iface.children_mac_addresses: <%= iface.children_mac_addresses %> iface.domain: <%= iface.domain %> iface.fqdn: <%= iface.fqdn %> iface.identifier: <%= iface.identifier %> iface.inheriting_mac: <%= iface.inheriting_mac %> iface.ip: <%= iface.ip %> iface.ip6: <%= iface.ip6 %> iface.link: <%= iface.link %> iface.mac: <%= iface.mac %> iface.managed?: <%= iface.managed? %> iface.mode: <%= iface.mode %> iface.mtu: <%= iface.mtu %> iface.physical?: <%= iface.physical? %> iface.primary: <%= iface.primary %> iface.provision: <%= iface.provision %> iface.shortname: <%= iface.shortname %> iface.subnet: <%= iface.subnet %> iface.subnet6: <%= iface.subnet6 %> iface.tag: <%= iface.tag %> iface.virtual?: <%= iface.virtual? %> iface.vlanid: <%= iface.vlanid %> <%- end -%>
Example rendering:host1.example.com iface.alias?: false iface.attached_to: iface.bond_options: iface.children_mac_addresses: [] iface.domain: iface.fqdn: host1.example.com iface.identifier: ens192 iface.inheriting_mac: 00:50:56:8d:4c:cf iface.ip: 10.10.181.13 iface.ip6: iface.link: true iface.mac: 00:50:56:8d:4c:cf iface.managed?: true iface.mode: balance-rr iface.mtu: iface.physical?: true iface.primary: true iface.provision: true iface.shortname: host1.example.com iface.subnet: iface.subnet6: iface.tag: iface.virtual?: false iface.vlanid:
Example Template Snippets
The following example checks if the host has the Puppet and Puppetlabs repositories enabled:
<% pm_set = @host.puppetmaster.empty? ? false : true puppet_enabled = pm_set || host_param_true?('force-puppet') puppetlabs_enabled = host_param_true?('enable-puppetlabs-repo') %>
The following example shows how to capture the minor and major version of the host’s operating system, which can be used for package related decisions:
<% os_major = @host.operatingsystem.major.to_i os_minor = @host.operatingsystem.minor.to_i %> <% if ((os_minor < 2) && (os_major < 14)) -%> ... <% end -%>
The following example imports the subscription_manager_registration snippet to the template and indents it by four spaces:
<%= indent 4 do snippet 'subscription_manager_registration' end %>
The following example imports the kickstart_networking_setup
snippet if the host’s subnet has the DHCP boot mode enabled:
<% subnet = @host.subnet %> <% if subnet.respond_to?(:dhcp_boot_mode?) -%> <%= snippet 'kickstart_networking_setup' %> <% end -%>
You can use the host.facts
variable to parse values from a host’s facts and custom facts.
In this example luks_stat
is a custom fact that you can parse in the same manner as dmi::system::serial_number
, which is a host fact:
'Serial': host.facts['dmi::system::serial_number'], 'Encrypted': host.facts['luks_stat'],
In this example, you can customize the Applicable Errata report template to parse for custom information about the kernel version of each host:
<%- report_row( 'Host': host.name, 'Operating System': host.operatingsystem, 'Kernel': host.facts['uname::release'], 'Environment': host.single_lifecycle_environment ? host.single_lifecycle_environment.name : nil, 'Erratum': erratum.errata_id, 'Type': erratum.errata_type, 'Published': erratum.issued, 'Applicable since': erratum.created_at, 'Severity': erratum.severity, 'Packages': erratum.package_names, 'CVEs': erratum.cves, 'Reboot suggested': erratum.reboot_suggested, ) -%>
Appendix B: Job Template Examples and Extensions
Use this section as a reference to help modify, customize, and extend your job templates to suit your requirements.
Customizing Job Templates
When creating a job template, you can include an existing template in the template editor field. This way you can combine templates, or create more specific templates from the general ones.
The following template combines default templates to install and start the nginx service on clients:
<%= render_template 'Package Action - SSH Default', :action => 'install', :package => 'nginx' %>
<%= render_template 'Service Action - SSH Default', :action => 'start', :service_name => 'nginx' %>
The above template specifies parameter values for the rendered template directly. It is also possible to use the input() method to allow users to define input for the rendered template on job execution. For example, you can use the following syntax:
<%= render_template 'Package Action - SSH Default', :action => 'install', :package => input("package") %>
With the above template, you have to import the parameter definition from the rendered template. To do so, navigate to the Jobs tab, click Add Foreign Input Set, and select the rendered template from the Target template list. You can import all parameters or specify a comma separated list.
Default Job Template Categories
Job template category | Description |
---|---|
Packages |
Templates for performing package related actions. Install, update, and remove actions are included by default. |
Puppet |
Templates for executing Puppet runs on target hosts. |
Power |
Templates for performing power related actions. Restart and shutdown actions are included by default. |
Commands |
Templates for executing custom commands on remote hosts. |
Services |
Templates for performing service related actions. Start, stop, restart, and status actions are included by default. |
Katello |
Templates for performing content related actions. These templates are used mainly from different parts of the Foreman web UI (for example bulk actions UI for content hosts), but can be used separately to perform operations such as errata installation. |
Example restorecon Template
This example shows how to create a template called Run Command - restorecon that restores the default SELinux context for all files in the selected directory on target hosts.
-
In the Foreman web UI, navigate to Hosts > Job templates. Click New Job Template.
-
Enter Run Command - restorecon in the Name field. Select Default to make the template available to all organizations. Add the following text to the template editor:
restorecon -RvF <%= input("directory") %>
The
<%= input("directory") %>
string is replaced by a user-defined directory during job invocation. -
On the Job tab, set Job category to
Commands
. -
Click Add Input to allow job customization. Enter
directory
to the Name field. The input name must match the value specified in the template editor. -
Click Required so that the command cannot be executed without the user specified parameter.
-
Select User input from the Input type list. Enter a description to be shown during job invocation, for example
Target directory for restorecon
. -
Click Submit. For more information, see Executing a restorecon Template on Multiple Hosts in Managing Hosts.
Rendering a restorecon Template
This example shows how to create a template derived from the Run command - restorecon template created in Example restorecon Template.
This template does not require user input on job execution, it will restore the SELinux context in all files under the /home/
directory on target hosts.
Create a new template as described in Setting up Job Templates, and specify the following string in the template editor:
<%= render_template("Run Command - restorecon", :directory => "/home") %>
Executing a restorecon Template on Multiple Hosts
This example shows how to run a job based on the template created in Example restorecon Template on multiple hosts.
The job restores the SELinux context in all files under the /home/
directory.
-
In the Foreman web UI, navigate to Hosts > All hosts and select target hosts. Select Schedule Remote Job from the Select Action list.
-
In the Job invocation page, select the
Commands
job category and theRun Command - restorecon
job template. -
Type
/home
in the directory field. -
Set Schedule to
Execute now
. -
Click Submit. You are taken to the Job invocation page where you can monitor the status of job execution.
Including Power Actions in Templates
This example shows how to set up a job template for performing power actions, such as reboot. This procedure prevents Foreman from interpreting the disconnect exception upon reboot as an error, and consequently, remote execution of the job works correctly.
Create a new template as described in Setting up Job Templates, and specify the following string in the template editor:
<%= render_template("Power Action - SSH Default", :action => "restart") %>