1. Overview of hosts in Foreman

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

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

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

1.1. Browsing Hosts in Foreman web UI

In the Foreman web UI, you can browse all hosts recognized by Foreman, grouped by type:

  • All Hosts – a list of all hosts recognized by Foreman.

  • Discovered Hosts – a list of bare-metal hosts detected on the provisioning network by the Discovery plugin.

  • 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 server.example.com, click the Content Hosts page and type server* in the Search field. Alternatively, *ver* will also find the content host server.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

Creating a host is part of the host provisioning process. There are multiple provisioning methods and each requires different configuration of Foreman and Smart Proxies. For more information, see Provisioning hosts.

2.2. Cloning hosts

You can clone existing hosts.

Procedure

  1. In the Foreman web UI, navigate to Hosts > All Hosts.

  2. In the Actions menu, click Clone.

  3. On the Host tab, ensure to provide a Name different from the original host.

  4. On the Interfaces tab, ensure to provide a different IP address.

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

Procedure

  1. In the Foreman web UI, navigate to Infrastructure > Compute Resources.

  2. Select a compute resource.

  3. On the Virtual Machines tab, click Associate VMs to associate all VMs or select Associate VM from the Actions menu to associate a single VM.

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.

Procedure

  1. In the Foreman web UI, navigate to Hosts > All Hosts.

  2. Click the name of the host you want to modify.

  3. Click the Content tab, then click the Module streams tab.

  4. 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. Enabling custom repositories on content hosts

You can enable all custom repositories on content hosts using the Foreman web UI.

Procedure

  1. In the Foreman web UI, navigate to Hosts > All Hosts and select a host.

  2. Select the Content tab, then select Repository sets.

  3. From the dropdown, you can filter the Repository type column to Custom.

  4. Select the desired number of repositories or click the Select All checkbox to select all repositories, then click the vertical ellipsis, and select Override to Enabled.

2.6. Changing the environment of a host

Use this procedure to change the environment of a host.

Procedure

  1. In the Foreman web UI, navigate to Hosts > All Hosts.

  2. Click the name of the host you want to modify.

  3. On the Content view environment card, click the options icon and select Edit content view environments.

  4. Select the environment.

  5. Select the content view.

  6. Click Save.

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

Procedure

  1. In the Foreman web UI, navigate to Hosts > All Hosts.

  2. Click the name of the host you want to modify.

  3. Click Edit.

  4. Click Manage host or Unmanage host to change the host’s status.

  5. Click Submit.

2.8. Configuring Tracer on a host

You can install Tracer on hosts and access Traces on Foreman. Tracer displays a list of outdated services and applications that need to be restarted, as well as asks you to restart the host after, for example, a kernel update. Traces is the output generated by Tracer in the Foreman web UI.

Prerequisites

  • The host is registered to Foreman.

  • Foreman Client repository is available on the host.

  • Remote execution is enabled.

Procedure

  1. In the Foreman web UI, navigate to Hosts > All Hosts.

  2. Select your host.

  3. On the Traces tab, click Enable Traces.

  4. Select the provider to install katello-host-tools-tracer from the list.

  5. Click Enable Tracer. You get a REX job notification after the remote execution job is complete.

  6. If you get a list of applications that need to be restarted, select the ones that you want to restart.

  7. Click Restart app, then click one of these buttons:

    • Restart via remote execution

    • Restart via customized remote execution

      The first option restarts the application immediately, while the second one allows you to examine and customize the REX job.

2.9. Restarting applications on a host

Use this procedure to restart applications from the Foreman web UI.

Procedure

  1. In the Foreman web UI, navigate to Hosts > All Hosts.

  2. Click the name of the hosts you want to modify.

  3. Select the Traces tab.

  4. Select applications that you want to restart.

  5. 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.10. 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 subscription-manager unregister on the host. After you assign the host to a new organization, you can re-register the host.
Procedure

  1. In the Foreman web UI, navigate to Hosts > All Hosts.

  2. Select the checkbox of the host you want to change.

  3. From the Select Action list, select Assign Organization. A new option window opens.

  4. From the Select Organization list, select the organization that you want to assign your host to. Select the checkbox Fix Organization on Mismatch.

    Note

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

  5. Click Submit.

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

Procedure

  1. In the Foreman web UI, navigate to Hosts > All Hosts.

  2. Select the checkbox of the host you want to change.

  3. From the Select Action list, select Assign Location. A new option window opens.

  4. Navigate to the Select Location list and choose the location that you want for your host. Select the checkbox Fix Location on Mismatch.

    Note

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

  5. Click Submit.

2.12. 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.13. Viewing host details from a content host

Use this procedure to view the host details page from a content host.

Procedure

  1. In the Foreman web UI, navigate to Hosts > Content Hosts

  2. Click the content host you want to view.

  3. Select the Details tab to see the host details page.

The cards in the Details tab show details for the System properties, BIOS, Networking interfaces, Operating system, Provisioning templates, and Provisioning. Registered content hosts show additional cards for Registration details, Installed products, and HW properties providing information about Model, Number of CPU(s), Sockets, Cores per socket, and RAM.

2.14. Selecting host columns

You can select what columns you want to see in the host table on the Hosts > All Hosts page. For a complete list of host columns, see Overview of the host columns.

Note

It is not possible to deselect the Name column. The Name column serves as a primary identification method of the host.
Procedure

  1. In the Foreman web UI, navigate to Hosts > All Hosts.

  2. Click Manage columns.

  3. Select columns that you want to display. You can select individual columns or column categories. Selecting or deselecting a category selects or deselects all columns in that category.

    Note

    Some columns are included in more than one category, but you can display a column of a specific type only once. By selecting or deselecting a specific column, you select or deselect all instances of that column.
Verification

  • You can now see the selected columns in the host table.

2.15. Removing a host from Foreman

Use this procedure to remove a host from Foreman. To use the CLI instead of the Foreman web UI, see the CLI procedure.

Procedure

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

  2. Select the hosts that you want to remove.

  3. From the Select Action list, select Delete Hosts.

  4. Click Submit to remove the host from Foreman permanently.

Warning

By default, the Destroy associated VM on host delete setting is set to no. If a host record that is associated with a virtual machine is deleted, the virtual machine will remain on the compute resource.

To delete a virtual machine on the compute resource, navigate to Administer > Settings and select the Provisioning tab. Setting Destroy associated VM on host delete to yes deletes the virtual machine if the host record that is associated with the virtual machine is deleted. To avoid deleting the virtual machine in this situation, disassociate the virtual machine from Foreman without removing it from the compute resource or change the setting.
CLI procedure

  • Delete your host from Foreman:

    $ hammer host delete \
--id My_Host_ID \
--location-id My_Location_ID \
--organization-id My_Organization_ID

    Alternatively, you can use --name My_Host_Name instead of --id My_Host_ID.

2.15.1. Disassociating a virtual machine from Foreman without removing it from a hypervisor

Procedure

  1. In the Foreman web UI, navigate to Hosts > All Hosts.

  2. Select the checkbox to the left of the hosts that you want to disassociate.

  3. From the Select Action list, click Disassociate Hosts.

  4. Optional: Select the checkbox to keep the hosts for future action.

  5. Click Submit.

2.16. Installing the Snapshot Management plugin

You can install the Snapshot Management plugin on your Foreman.

Procedure

  • Install the Snapshot Management plugin on your Foreman server:

    # foreman-installer --enable-foreman-plugin-snapshot-management

2.17. Creating snapshots of a host

You can use the Snapshot Management plugin to create snapshots of hosts.

Prerequisites
Procedure

  1. In the Foreman web UI, navigate to Hosts > All Hosts and select a host.

  2. In the Snapshots card, click Create Snapshot.

  3. Enter a Name.

  4. Optional: Enter a Description.

  5. Optional: In the Snapshot Mode field, select Memory if you want to include the RAM in your snapshot or Quiesce if you want to ensure the full state of the VM is written to disk before creating the snapshot.

  6. 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. Working with host groups

With Foreman, you can use host groups as a template for common host settings to apply these settings to multiple hosts.

3.1. Host groups overview

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

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

You can create nested host groups.

Important

When you change the settings of an existing host group, the new settings do not propagate to the hosts assigned to the host group. Only Puppet class settings get updated on hosts after you change them in the host group.

3.2. Nested host groups

You can create a hierarchy of host groups. Aim to have one base level host group that represents all hosts in your organization and provides general settings, and then nested groups that provide specific settings.

Foreman applies host settings in the following order when nesting host groups:

  • Host settings take priority over host group settings.

  • Nested host group settings take priority over parent host group settings.

Example 1. Nested host group hierarchy

You create a top-level host group named Base and two nested host groups named Webserver and Storage. The nested host groups are associated with multiple hosts. You also create host custom.example.com that is not associated with any host group.

You define the operating system on the top-level host group (Base) and Ansible roles on the nested host groups (Webservers and Storage).

Top-level host group Nested host group Hosts Settings inherited from host groups

Base

This host group applies the Enterprise Linux 8.8 operating system setting.

Webservers

This host group applies the linux-system-roles.selinux Ansible role.

webserver1.example.com

Hosts use the following settings:

  • Enterprise Linux 8.8 defined by host group Base

  • linux-system-roles.selinux defined by host group Webservers

webserver2.example.com

Storage

This host group applies the linux-system-roles.postfix Ansible role.

storage1.example.com

Hosts use the following settings:

  • Enterprise Linux 8.8 defined by host group Base

  • linux-system-roles.postfix defined by host group Storage

storage2.example.com

[No host group]

custom.example.com

No settings inherited from host groups.
Example 2. Nested host group settings

You create a top-level host group named Base and two nested host groups named Webserver and Storage. You also create host custom.example.com that is associated with the top-level host group Base, but no nested host group.

You define different values for the operating system and Ansible role settings on the top-level host group (Base) and nested host groups (Webserver and Storage).

Top-level host group Nested host group Host Settings inherited from host groups

Base

This host group applies these settings:

  • The Enterprise Linux 8.8 operating system

  • The linux-system-roles.selinux Ansible role

Webservers

This host group applies these settings:

  • The Enterprise Linux 8.9 operating system

  • No Ansible role

webserver1.example.com

Hosts use the following settings:

  • The Enterprise Linux 8.9 operating system from host group Webservers

  • The linux-system-roles.selinux Ansible role from host group Base

webserver2.example.com

Storage

This host group applies these settings:

  • No operating system

  • The linux-system-roles.postfix Ansible role

storage1.example.com

Hosts use the following settings:

  • The Enterprise Linux 8.8 operating system from host group Base

  • The linux-system-roles.postfix Ansible role from host group Storage

storage2.example.com

[No nested host group]

custom.example.com

Host uses the following settings:

  • The Enterprise Linux 8.8 operating system from host group Base

  • The linux-system-roles.selinux Ansible role from host group Base

3.3. Creating a host group

Create a host group to be able to apply host settings to multiple hosts.

To use the CLI instead of the Foreman web UI, see the CLI procedure.

Procedure

  1. In the Foreman web UI, navigate to Configure > Host Groups and click Create Host Group.

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

  3. Enter a Name for the new host group.

  4. Enter any further information that you want future hosts to inherit.

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

  6. Click the additional tabs and add any details that you want to attribute to the host group.

    Note

    Puppet 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

  7. Click Submit to save the host group.

CLI procedure

  • 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_"

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

Procedure

To create a host group for each lifecycle environment, run the following Bash script:

MAJOR="My_Major_Operating_System_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

3.5. Adding a host to a host group

You can add a host to a host group in the Foreman web UI.

Procedure

  1. In the Foreman web UI, navigate to Hosts > All Hosts.

  2. Click the name of the host you want to modify.

  3. Click Edit.

  4. Select the host group from the Host Group list.

  5. Click Submit.

Verification

  • The Details card under the Overview tab now shows the host group your host belongs to.

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

Procedure

  1. In the Foreman web UI, navigate to Hosts > All Hosts.

  2. Click the name of the host you want to modify.

  3. Click Edit.

  4. Select the new host group from the Host Group list.

  5. Click Submit.

Verification

  • The Details card under the Overview tab now shows the host group your host belongs to.

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

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:

4.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 and 8

  • Fedora

  • OpenSUSE

  • SUSE Linux Enterprise Server

  • Ubuntu

Supported host architectures

The hosts can use the following architectures:

  • AMD and Intel 64-bit architectures

4.2. Registering hosts by using global registration

You can register a host to Foreman by generating a curl or wget 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.

Additional resources

4.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 the insights snippet. If the parameter is set to true, the registration installs and enables the Red Hat Insights client on the host. If the parameter is set to false, it prevents Foreman and the Red Hat Insights client from uploading Inventory reports to your Red Hat Hybrid Cloud Console. The default value is false. When overriding the parameter value, set the parameter type to boolean.

  • The host_packages parameter is for installing packages on the host.

  • The host_registration_remote_execution parameter is used in the remote_execution_ssh_keys snippet. If it is set to true, the registration enables remote execution on the host. The default value is true.

  • The remote_execution_ssh_keys, remote_execution_ssh_user, remote_execution_create_user, and remote_execution_effective_user_method parameters are used in the remote_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.

4.2.2. Configuring a host for registration

Configure your host for registration to Foreman server or Smart Proxy server. You can use a configuration management tool to configure multiple hosts at once.

Prerequisites
Procedure

  1. Deploy the SSL CA file on your host so that the host can make a secured registration call.

    1. Find where Foreman stores the SSL CA file by navigating to Administer > Settings > Authentication and locating the value of the SSL CA file setting.

    2. Transfer the SSL CA file to your host securely, for example by using scp.

    3. Login to your host by using SSH.

    4. Copy the certificate to the truststore:

      • On Enterprise Linux:

        # cp My_SSL_CA_file.pem /etc/pki/ca-trust/source/anchors

    5. Update the truststore:

      • On Enterprise Linux:

        # update-ca-trust

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

Prerequisites

  • Your Foreman account has the Register hosts role assigned or a role with equivalent permissions.

  • You must have root privileges on the host that you want to register.

  • You must have installed either curl or wget on the host that you want to register.

  • You have configured your host for registration. For more information, see Configuring a host for registration.

  • 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 a Smart Proxy Server nightly on Enterprise Linux.

  • You have configured the operating system entry on Foreman for Enterprise Linux.

Procedure

  1. In the Foreman web UI, navigate to Hosts > Register Host.

  2. Enter the details for how you want the registered host to be configured.

  3. Click Generate to generate a curl command.

  4. Run the curl command as root on the host that you want to register. After registration completes, any Ansible roles assigned to a host group you specified when configuring the registration template will run on the host.

The registration details that you can specify include the following:

  • On the General tab, in the Smart Proxy field, you can select the Smart Proxy to register your host through. A Smart Proxy behind a load balancer takes precedence over a Smart Proxy selected in the Foreman web UI as the content source of the host.

  • On the General tab, in the Download utility field, you can select wget if you want to register your host by using a wget command. By default, Foreman generates a curl command.

  • On the General tab, you can select the Insecure option to make the first call insecure. During this first call, your host downloads the CA file from Foreman. Your host 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 your 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 your 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 your host using the SSH key.

  • On the Advanced tab, in the Repositories field, you can list repositories to be added before the registration is performed. You do not have to specify repositories if you provide them in an activation key.

  • On the Advanced tab, in the Token lifetime (hours) field, you can 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 registration command works.

    Note that Foreman applies the permissions of the user who generates the registration command to authorization of your host. 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.

CLI procedure

  1. Use the hammer host-registration generate-command to generate the registration command to register your host.

  2. On your host that you want to register, run the registration command as root.

For more information, see the Hammer CLI help with hammer host-registration generate-command --help.

Ansible procedure

  • Use the theforeman.foreman.registration_command module.

For more information, see the Ansible module documentation with ansible-doc theforeman.foreman.registration_command.

API procedure

  • Use the POST /api/registration_commands resource.

For more information, see the full API reference at https://foreman.example.com/apidoc/v2.html.

Next steps

4.2.4. Customizing host registration by using snippets

You can customize the registration process by creating snippets with pre-defined names. The Global Registration template includes these snippets automatically. Therefore, you do not have to edit the template.

To add custom steps to registration, create one or both of the following snippets:

before_registration

This snippet is loaded and executed by the Global Registration template before registering your host to Foreman.

after_registration

This snippet is loaded and executed by the Global Registration template after registering your host to Foreman.

Ensure you name the snippets precisely. Otherwise, the Global Registration template cannot load them.

Prerequisites

  • Your Foreman account has a role that grants the permissions view_provisioning_templates, create_provisioning_templates, assign_organizations, and assign_locations.

  • You have selected a particular organization and location context.

Procedure

  1. In the Foreman web UI, navigate to Hosts > Templates > Provisioning Templates.

  2. Click Create Template.

  3. In the Name field, enter the name of the required snippet: before_registration or after_registration.

  4. In the template editor, create your snippet.

  5. On the Type tab, select Snippet.

  6. On the Locations tab, assign the snippet to required locations.

  7. On the Organizations tab, assign the snippet to required organizations.

  8. Click Submit.

Additional resources

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

Procedure

  1. Navigate to Hosts > Templates > Provisioning Templates.

  2. Search for the template you want to edit.

  3. In the row of the required template, click Clone.

  4. Edit the template as needed. For more information, see Template writing reference.

  5. Click Submit.

  6. Navigate to Administer > Settings > Provisioning.

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

4.3. 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 by using Puppet.

Procedure

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

  2. Enable the Puppet agent using a host parameter in global parameters or a host group.

    To use Puppet 8, add a host parameter named enable-official-puppet8-repo, select the boolean type, and set the value to true. To use Puppet 7, add a host parameter named enable-official-puppet7-repo, select the boolean type, and set the value to true.

  3. 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 as puppet.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 as puppet-ca.example.com. If puppet_ca_server is not set, the Puppet agent will use the same server as puppet_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.

  4. Navigate to Hosts > Register Host and register your host. For more information, see Registering Hosts in Managing hosts.

  5. Navigate to Infrastructure > Smart Proxies.

  6. From the list in the Actions column for the required Smart Proxy server, select Certificates.

  7. Click Sign to the right of the required host to sign the SSL certificate for the Puppet agent.

4.4. 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 by using Puppet.

Prerequisites

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

Procedure

  1. Log in to the host as the root user.

  2. Install the Puppet agent package.

    • On hosts running Enterprise Linux 8 and above:

      # dnf install puppet-agent

    • On hosts running Debian:

      # apt install puppet-agent

    • On hosts running SUSE Linux Enterprise Server:

      # zypper install puppet-agent

  3. Add the Puppet agent to PATH in your current shell using the following script:

    . /etc/profile.d/puppet-agent.sh

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

  5. Start the Puppet agent service:

    # puppet resource service puppet ensure=running enable=true

  6. Create a certificate for the host:

    # puppet ssl bootstrap

  7. In the Foreman web UI, navigate to Infrastructure > Smart Proxies.

  8. From the list in the Actions column for the required Smart Proxy server, select Certificates.

  9. Click Sign to the right of the required host to sign the SSL certificate for the Puppet agent.

  10. On the host, run the Puppet agent again:

    # puppet ssl bootstrap

4.5. Running Ansible roles during host registration

You can run Ansible roles when you are registering a host to Foreman.

Prerequisites
Procedure

  1. Create a host group with Ansible roles. For more information, see Creating a host group.

  2. Register the host by using the host group with assigned Ansible roles. For more information, see Registering a host.

4.6. Using SSL certificate for hosts

You can use SSL certificate on your hosts to enable encrypted communications between Foreman server, Smart Proxy server, and hosts. Before deploying it to your hosts, ensure that you have configured the SSL certificate to your Foreman server.

4.6.1. Deploying a SSL certificate to hosts

After you configure Foreman to use a SSL certificate, you must deploy the certificate to hosts registered to Foreman.

Procedure

  • Update the SSL certificate on each host:

    • On Debian and Ubuntu:

      # wget http://foreman.example.com/pub/katello-rhsm-consumer
# chmod +x katello-rhsm-consumer
# ./katello-rhsm-consumer

    • On Enterprise Linux 8+:

      # dnf install http://foreman.example.com/pub/katello-ca-consumer-latest.noarch.rpm

    • On OpenSUSE and SUSE Linux Enterprise Server:

      # zypper install http://foreman.example.com/pub/katello-ca-consumer-latest.noarch.rpm

4.7. Resetting SSL certificate to default self-signed certificate on hosts

To reset the SSL certificate on your hosts to default self-signed certificate, you must re-register your hosts through Global Registration. For more information, see Registering hosts by using global registration.

Additional Resources

5. Configuring 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 configuring an 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 by 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.

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

  • 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 Hosts in Installing Foreman Server nightly on Enterprise Linux.

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 /etc/sysconfig/network-scripts/ifcfg-interface_id.

5.1. Configuring a physical interface

You can configure a physical interface for a host.

Procedure

  1. Navigate to the Add Interface form:

    1. In the Foreman web UI, navigate to Hosts > All Hosts.

    2. Click Edit next to the host you want to edit.

    3. On the Interfaces tab, click Add Interface.

  2. Specify the general interface settings:

    1. Specify a MAC address. This setting is required.

    2. Specify the Device Identifier, for example eth0.

  3. Configure network and DNS settings:

    1. Specify the DNS name associated with the host’s IP address.

    2. Select a domain from the Domain list.

    3. Select a subnet in the IPv4 Subnet or IPv6 Subnet list.

    4. Specify the IPv4 address or IPv6 address.

      Note

      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.

  4. Specify interface management options:

    1. Select whether the interface is Managed.

    2. Select whether this is the Primary interface for the host.

    3. Select whether this is the Provision interface for the host.

    4. Select whether to use the interface for Remote execution.

  5. Click OK to save the interface configuration.

  6. Click Submit to apply the changes to the host.

5.2. Configuring a virtual interface

You can configure a virtual interface for a host. This can be either a VLAN or an alias interface.

  • A VLAN interface allows the host to connect to separate network segments using a single physical 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.

Note

Virtual interfaces currently require a MAC address of a physical device. Therefore, the configuration of these interfaces works only on bare-metal hosts.
Procedure

  1. Navigate to the Add Interface form:

    1. In the Foreman web UI, navigate to Hosts > All Hosts.

    2. Click Edit next to the host you want to edit.

    3. On the Interfaces tab, click Add Interface.

  2. Specify the general interface settings:

    1. If the virtual interface is managed, specify a MAC address.

    2. Specify ID in the Device Identifier field.

      • For a VLAN, use the eth1.10 format.

      • For an alias, use the eth1:10 format.

  3. Configure a virtual NIC:

    1. Select the Virtual NIC checkbox.

    2. Optionally, specify a VLAN Tag.

    3. Specify the identifier of the physical interface to which the virtual interface is Attached to, for example eth1. This setting is required.

  4. Click OK to save the interface configuration.

  5. Click Submit to apply the changes to the host.

5.3. Configuring a bonded interface

You can combine multiple physical interfaces together by configuring a bonded interface for the host.

Note

Bonded interfaces currently require a MAC address of a physical device. Therefore, the configuration of these interfaces works only on bare-metal hosts.
Procedure

  1. Navigate to the Add Interface form:

    1. In the Foreman web UI, navigate to Hosts > All Hosts.

    2. Click Edit next to the host you want to edit.

    3. On the Interfaces tab, click Add Interface.

  2. Select Bond from the Type list.

  3. Specify the general interface settings:

    1. In the Device Identifier field, specify the interface ID in the bond0 format .

    2. Specify a MAC address.

    3. If you are configuring a secondary interface, select Managed. Otherwise, Foreman does not apply the configuration.

  4. Add the configuration specific to bonded interfaces:

    1. Mode: Select the bonding mode.

    2. Attached devices: Specify a comma-separated list of identifiers of attached devices. These can be physical interfaces or VLANs.

    3. Bond options: Specify a space-separated list of configuration options, for example miimon=100.

  5. Click OK to save the interface configuration.

  6. Click Submit to apply the changes to the host.

CLI procedure

  • To create a host with a bonded interface, enter the following command:

    $ hammer host create \
--ask-root-password yes \
--hostgroup My_Host_Group \
--ip=My_IP_Address \
--mac=My_MAC_Address \
--managed true \
--interface="identifier=My_NIC_1, mac=_My_MAC_Address_1, managed=true, type=Nic::Managed, domain_id=My_Domain_ID, subnet_id=My_Subnet_ID" \
--interface="identifier=My_NIC_2, mac=My_MAC_Address_2, managed=true, type=Nic::Managed, domain_id=My_Domain_ID, subnet_id=My_Subnet_ID" \
--interface="identifier=bondN, ip=My_IP_Address_2, type=Nic::Bond, mode=active-backup, attached_devices=[My_NIC_1,My_NIC_2], managed=true, domain_id=My_Domain_ID, subnet_id=My_Subnet_ID" \
--location "My_Location" \
--name "My_Host_Name" \
--organization "My_Organization" \
--subnet-id=My_Subnet_ID

    Replace bondN with bond and the ID of your device identifier, for example, bond0.

5.4. Configuring a bridge interface

You can configure traffic forwarding between networks by configuring a bridge interface.

Procedure

  1. In the Foreman web UI, navigate to Hosts > All Hosts.

  2. Click Edit next to the host you want to edit.

  3. On the Interfaces tab, click Add Interface.

  4. Select Bridge from the Type list.

  5. Specify a MAC address.

  6. In the Device Identifier field, specify the interface ID in the bridge0 format.

  7. If you are configuring a secondary interface, select Managed.

  8. In the Attached devices field, specify a comma-separated list of identifiers of attached devices. These can be physical or virtual Ethernet devices, bonds, or VLAN devices.

  9. Click OK to save the interface configuration.

  10. Click Submit to apply the changes to the host.

5.5. 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.6. Configuring a baseboard management controller (BMC) interface

To control the power status of bare-metal hosts from Foreman, you can configure a baseboard management controller (BMC) interface for hosts that support this feature.

Prerequisites

  • You know the MAC address, IP address, and other details of the BMC interface on the host, and authentication credentials for that interface.

    Note

    You only need the MAC address for the BMC interface if the BMC interface is managed, so that it can create a DHCP reservation.
Procedure

  1. Enable BMC power management on your Smart Proxy:

    # foreman-installer \
--foreman-proxy-bmc-default-provider=ipmitool \
--foreman-proxy-bmc=true

  2. In the Foreman web UI, navigate to Infrastructure > Subnets.

  3. Select the subnet of your host.

  4. On the Proxies tab, select your Smart Proxy as BMC Proxy.

  5. Click Submit.

  6. Navigate to the Add Interface form:

    1. Navigate to Hosts > All Hosts.

    2. Click Edit next to the host you want to edit.

    3. On the Interfaces tab, click Add Interface.

  7. Select BMC from the Type list.

  8. Specify the general interface settings:

    1. If the BMC is managed, specify a MAC address.

    2. Specify the Device Identifier.

  9. Specify the configuration options specific to BMC interfaces:

    1. Username and Password: Specify any authentication credentials required by BMC.

    2. Provider: Specify the BMC provider.

  10. Click OK to save the interface configuration.

  11. Click Submit to apply the changes to the host.

5.7. Network interface configuration options

When adding a network interface, you need to specify several configuration options. The following lists provide information on the relevant options for the different types of interfaces.

Physical interface settings
Device Identifier

The identifier is used to specify this physical interface when creating bonded interfaces, VLANs, and aliases.

DNS name

Foreman saves this name in the 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.

Domain

Specifies the domain associated with the network interface. To create and manage domains, navigate to Infrastructure > Domains.

Subnet

Specifies the subnet associated with the network interface. To create and manage subnets, navigate to Infrastructure > Subnets.

Managed interface

If the interface is managed, configuration is pulled from the associated Smart Proxy server during provisioning, and DNS and DHCP entries are created. If you use provisioning with installer automation, a configuration file is automatically created for the interface.

Primary interface

The DNS name from the primary interface is used as the host portion of the FQDN.

Provision

Network boot uses the provisioning interface. For image-based provisioning, the script to complete the provisioning is executed through the provisioning interface.

Virtual interface settings
Tag

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

Bonded interface settings
Mode

The bonding mode defines a policy for fault tolerance and load balancing. See Bonding modes available in Foreman for a brief description of each bonding mode.

6. Upgrading hosts to next major Enterprise Linux release

You can use a job template to upgrade your Enterprise Linux hosts to the next major release. Below upgrade paths are possible:

  • Enterprise Linux 7 to Enterprise Linux 8

  • Enterprise Linux 8 to Enterprise Linux 9

Prerequisites
Procedure

  1. On Foreman, enable the Leapp plugin:

    # foreman-installer --enable-foreman-plugin-leapp

  2. If you are using a custom job template for the Leapp pre-upgrade check, configure the leapp_preupgrade remote execution feature to point to your template:

    1. In the Foreman web UI, navigate to Administer > Remote Execution Features.

    2. Click leapp_preupgrade.

    3. In the Job Template dropdown menu, select your template.

    4. Click Submit.

  3. In the Foreman web UI, navigate to Hosts > All Hosts.

  4. Select the hosts that you want to upgrade to the next major Enterprise Linux version.

  5. From the Schedule Remote Job list, select Preupgrade check with Leapp.

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

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

    2. After you selected any issues with remediation commands, click Fix Selected and submit the job.

    3. After the issues are fixed, click Rerun, 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.

  7. If the pre-upgrade check verifies that the hosts do not have any issues, click Run Upgrade and click Submit to start the upgrade. Alternatively, you can upgrade your host by selecting Upgrade with Leapp in the Schedule Remote Job drop down menu.

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 Convert2RHEL utilities to simplify the conversion process.

The Convert2RHEL utilities in Foreman contain 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 by 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

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

Prerequisites

  • Review Supported conversion paths in Red Hat Enterprise Linux 8 Converting from a Linux distribution to RHEL using the Convert2RHEL utility.

  • You must have completed the steps 1. – 5. of the procedure Preparing for a RHEL conversion in Red Hat Enterprise Linux 8 Converting from a Linux distribution to RHEL using the Convert2RHEL utility.

  • 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 Exporting and downloading a manifest in Creating and managing manifests for a connected Satellite Server.

  • Ensure that you have enabled and synchronized Red Hat repositories in Foreman for the minor Red Hat Enterprise Linux version to which you convert your hosts. For more information, see Enabling Red Hat Repositories and Synchronizing Repositories in Managing content.

High-level conversion steps

  1. Import the theforeman.foreman.convert2rhel Ansible role and variables. For more information, see Importing Ansible Roles and Variables in Configuring hosts by using Ansible.

  2. Configure Ansible variables for generation of conversion data. For more information, see Ansible variables for conversion.

  3. 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 by using Ansible.

  4. Run the Ansible role on Foreman server. For more information, see Running Ansible Roles on a Host in Configuring hosts by 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, or rhel-8-for-x86_64-baseos-rpms and rhel-8-for-x86_64-appstream-rpms, or both, depending on which variables you have set in the previous steps.

  5. Register a host for conversion by 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 7 converting if you convert the host from CentOS 7. For more information, see Registering hosts by using global registration.

  6. Run the pre-conversion analysis on the host group to verify if your hosts are ready for the conversion. Execute a remote job with the following settings:

    • Job category: Convert 2 RHEL

    • Job template: Convert2RHEL analyze

      For more information, see Executing a remote job.

    Review pre-conversion analysis reports and resolve all issues that are blocking the conversion. Repeat this step until you resolve all blocking issues. For more information, see Reviewing the pre-conversion analysis report in Red Hat Enterprise Linux 8 Converting from a Linux distribution to RHEL using the Convert2RHEL utility.

  7. Run the Convert2RHEL playbook on the host group. Execute a remote job with the following settings:

    • Job category: Convert 2 RHEL

    • Job template: Convert to RHEL

    • Activation key:

      • convert2rhel_rhel7 if you convert to Red Hat Enterprise Linux 7

      • convert2rhel_rhel8 if you convert to Red Hat Enterprise Linux 8

    For more information, see Executing a remote job.

Additional resources

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.

Table 1. Required variables for conversion
Name Type Intent and value

foreman_server_url *

string

URL of your Foreman server, such as https://foreman.example.com

foreman_username *

string

Your user name

foreman_password *

string

Your password

foreman_organization *

string

Name of your organization

foreman_content_rhel_wait_for_syncs *

boolean

Set to false if you do not want Foreman server to wait until repository sync finishes before continuing with data generation. (default: true)

foreman_validate_certs *

boolean

Set to true if you want to enable certificate checks in Ansible. (default: true)

foreman_convert2rhel_manage_subscription

boolean

Set to false if you already have a manifest on your Foreman server. If you upload a new manifest from disk, the current manifest will be overwritten. (default: true)

foreman_content_rhel_enable_rhel7 *

boolean

Enables Red Hat Enterprise Linux 7 repositories. Set to false if you do not intend to convert hosts to Red Hat Enterprise Linux 7. (default: true)

foreman_convert2rhel_enable_oracle7

boolean

Set to true if you want to prepare conversion data for Oracle Linux 7. Otherwise, you must set the value to false.

foreman_content_rhel_enable_rhel8 *

boolean

Enables Red Hat Enterprise Linux 8 repositories. Set to false if you do not intend to convert hosts to Red Hat Enterprise Linux 8. (default: true)

foreman_convert2rhel_enable_oracle8

boolean

Set to true if you want to prepare conversion data for Oracle Linux 8. Otherwise, you must set the value to false.
Table 2. Optional variables for conversion
Name Type Intent and value

foreman_manifest_path *

string

Path to a manifest to upload from disk, such as ~/manifest.zip. You must set this path if you upload a new manifest from disk using foreman_convert2rhel_manage_subscription.

foreman_content_rhel_rhel8_releasever *

string

Minor release version, such as 8.5. Set this variable if the minor release version of your system differs from the latest Red Hat Enterprise Linux release to prevent conversion issues. (default: latest)

8. Host management and monitoring by using Cockpit

You can use the Cockpit interactive web interface 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 on Foreman server.

Procedure

  • Enable Cockpit on your Foreman server:

    # foreman-installer --enable-foreman-plugin-remote-execution-cockpit --reset-foreman-plugin-remote-execution-cockpit-ensure

8.2. Managing and monitoring hosts using Cockpit

You can access the Cockpit UI through the Foreman web UI and use the functionality to manage and monitor hosts in Foreman.

Prerequisites

  • You have enabled Cockpit in Foreman.

  • You have installed Cockpit on the host that you want to manage and monitor.

    Foreman provides a job template named Service Action – Enable Web Console under the Ansible Services job category that you can use to install Cockpit. For more information about running remote jobs, see Configuring and setting up remote jobs.

  • Foreman or Smart Proxy can authenticate to the host with SSH keys. For more information, see Distributing SSH keys for remote execution.

Procedure

  1. In the Foreman web UI, navigate to Hosts > All Hosts and select the host that you want to manage and monitor with Cockpit.

  2. In the upper right of the host window, click the vertical ellipsis and select Web Console.

You can now access the full range of features available for host monitoring and management, for example, Lorax Composer, through Cockpit.

Additional resources

8.3. Disabling Cockpit on Foreman

Perform the following procedure if you want to disable Cockpit on Foreman.

Procedure

  • Disable Cockpit on your Foreman server:

    # foreman-installer --foreman-plugin-remote-execution-cockpit-ensure absent
Important

You can enable or disable Cockpit integration independently on Smart Proxy servers. To prevent enabling Cockpit integration on a Smart Proxy server, enter the following command after completing the procedure:

# foreman-installer --foreman-proxy-plugin-remote-execution-script-cockpit-integration false

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

9.1. Generating host monitoring reports

To view the report templates in the Foreman web UI, navigate to Monitor > Reports > Report Templates. To schedule reports, configure a cron job or use the Foreman web UI.

Procedure

  1. In the Foreman web UI, navigate to Monitor > Reports > Report Templates. For example, the Host – Installed Products template generates a report with installed product information along with other metrics, including system purpose attributes.

  2. To the right of the report template that you want to use, click Generate.

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

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

  5. Optional: Apply search query filters. To view all available results, do not populate the filter field with any values.

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

CLI procedure

  1. List all available report templates:

    $ hammer report-template list

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

    Note

    If you want to generate the Subscription - General report, you have to use the Days from Now option to specify the latest expiration time of general subscriptions.

    Show all subscriptions
    $ hammer report-template generate \
--inputs "Days from Now=no limit" \
--name "Subscription - General Report"
    Show all subscriptions that are going to expire within 60 days
    $ hammer report-template generate \
--inputs "Days from Now=60" \
--name "Subscription - General Report"

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

Procedure

  1. In the Foreman web UI, navigate to Monitor > Reports > Report Templates.

  2. Click Create Template.

  3. In the Name field, enter a unique name for your report template.

  4. If you want the template to be available to all locations and organizations, select Default.

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

  6. Optional: In the Audit Comment field, you can add any useful information about this template.

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

  8. Select whether the input value is mandatory. If the input value is mandatory, select the Required checkbox.

  9. From the Value Type list, select the type of input value that the user must input.

  10. Optional: If you want to use facts for template input, select the Advanced checkbox.

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

  12. Optional: In the Default field, enter a value, for example, a host name, that you want to set as the default template input.

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

  14. Optional: Click the Type tab, and select whether this template is a snippet to be included in other templates.

  15. Click the Location tab and add the locations where you want to use the template.

  16. Click the Organizations tab and add the organizations where you want to use the template.

  17. Click Submit to save your changes.

Additional resources

9.3. Exporting report templates

You can export report templates that you create in Foreman.

Procedure

  1. In the Foreman web UI, navigate to Monitor > Reports > Report Templates.

  2. Locate the template that you want to export, and from the list in the Actions column, select Export.

  3. Repeat this action for every report template that you want to download.

An .erb file that contains the template downloads.

CLI procedure

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

  2. To export a report template, enter the following command:

    $ hammer report-template dump --id My_Template_ID > example_export.erb

9.4. Exporting report templates using the Foreman API

You can use the Foreman report_templates API to export report templates from Foreman.

Procedure

  1. Use the following request to retrieve a list of available report templates:

    Example request:
    $ curl \
--insecure \
--user My_User_Name:My_Password \
--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
        }
    ]
}

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

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

Prerequisites

  • You must have exported templates from Foreman to import them to use in new templates. For more information see Exporting report templates.

Procedure

  1. In the Foreman web UI, navigate to Monitor > Reports > Report Templates.

  2. In the upper right of the Report Templates window, click Create Template.

  3. On the upper right of the Editor tab, click the folder icon, and select the .erb file that you want to import.

  4. Edit the template to suit your requirements.

  5. Click Submit.

For more information about customizing your new template, see Template writing reference.

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

Prerequisites
Procedure

  1. 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 %>
"
}

  2. Use the following request to import the template:

    $ curl \
--insecure \
--user My_User_Name:My_Password \
--data @Example_Template.json \
--header "Content-Type:application/json" \
--request POST \
--config https://foreman.example.com/api/report_templates/import

  3. Use the following request to retrieve a list of report templates and validate that you can view the template in Foreman:

    $ curl \
--insecure \
--user My_User_Name:My_Password \
--request GET \
--config https://foreman.example.com/api/report_templates | json_reformat

9.7. Generating a list of installed packages

Use this procedure to generate a list of installed packages in Report Templates.

Procedure

  1. In the Foreman web UI, navigate to Monitor > Reports > Report Templates.

  2. To the right of Host - All Installed Packages, click Generate.

  3. Optional: Use the Hosts filter search field to search for and apply specific host filters.

  4. Click Generate.

  5. If the download does not start automatically, click Download.

Verification

  • You have the spreadsheet listing the installed packages for the selected hosts downloaded on your machine.

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

10. Configuring and setting up remote jobs

Foreman supports remote execution of commands on hosts. Using remote execution, you can perform various tasks on multiple hosts simultaneously.

10.1. Remote execution in Foreman

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

Use remote execution for the following benefits in Foreman:

  • Run jobs on multiple hosts at once.

  • Use variables in your commands for more granular control over the jobs you run.

  • Use host facts and parameters to populate the variable values.

  • Specify custom values for templates when you run the command.

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

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

Foreman uses ERB syntax job templates. For more information, see Template writing reference.

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

Additional resources

10.2. Remote execution workflow

For custom Ansible roles that you create, or roles that you download, you must install the package containing the roles on your Smart Proxy server. Before you can use Ansible roles, you must import the roles into Foreman from the Smart Proxy where they are installed.

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.

  1. Foreman finds the host’s interfaces that have the Remote execution checkbox selected.

  2. Foreman finds the subnets of these interfaces.

  3. Foreman finds remote execution Smart Proxies assigned to these subnets.

  4. 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 by using the Smart Proxy to which the host is registered.

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.

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

10.4. Transport modes for remote execution

You can configure your Foreman to use two different modes of transport for remote job execution. You can configure single Smart Proxy to use either one mode or the other but not both.

Push-based transport

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.

This transport mode supports both Script and Ansible providers.

Pull-based transport

On Smart Proxies in pull-mqtt mode, remote execution uses Message Queueing Telemetry Transport (MQTT) to initiate the job execution it receives from Foreman server. The host subscribes to the MQTT broker on Smart Proxy for job notifications by using the yggdrasil pull client. After the host receives a notification from the MQTT broker, it pulls job details from Smart Proxy over HTTPS, runs the job, and reports results back to Smart Proxy.

This transport mode supports the Script provider only.

To use the pull-mqtt mode, you must enable it on Smart Proxy server and configure the pull client on hosts.

Note

If your Smart Proxy already uses the pull-mqtt mode and you want to switch back to the ssh mode, run this foreman-installer command:

# foreman-installer --foreman-proxy-plugin-remote-execution-script-mode=ssh
Additional resources

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

Procedure

  1. In the Foreman web UI, navigate to Hosts > Templates > Job templates.

  2. Click New Job Template.

  3. Click the Template tab, and in the Name field, enter a unique name for your job template.

  4. Select Default to make the template available for all organizations and locations.

  5. Create the template directly in the template editor or upload it from a text file by clicking Import.

  6. Optional: In the Audit Comment field, add information about the change.

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

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

  9. From the Provider Type list, select SSH for shell scripts and Ansible for Ansible tasks or playbooks.

  10. Optional: In the Timeout to kill field, enter a timeout value to terminate the job if it does not complete.

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

  12. Optional: Click Foreign input set to include other templates in this job.

  13. Optional: In the Effective user area, configure a user if the command cannot use the default remote_execution_effective_user setting.

  14. Optional: If this template is a snippet to be included in other templates, click the Type tab and select Snippet.

  15. Optional: If you use the Ansible provider, click the Ansible tab. Select Enable Ansible Callback to allow hosts to send facts, which are used to create configuration reports, back to Foreman after a job finishes.

  16. Click the Location tab and add the locations where you want to use the template.

  17. Click the Organizations tab and add the organizations where you want to use the template.

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

CLI procedure

  • 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

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

Prerequisites

  • Ansible plugin is enabled.

  • Your Foreman account has a role that grants the import_ansible_playbooks permission.

Procedure

  1. Fetch the available Ansible Playbooks by using the following API request:

    $ curl \
--header 'Content-Type: application/json' \
--request GET \
https://foreman.example.com/ansible/api/v2/ansible_playbooks/fetch?proxy_id=My_smart-proxy_ID

  2. Select the Ansible Playbook you want to import and note its name.

  3. Import the Ansible Playbook by its name:

    $ curl \
--data '{ "playbook_names": ["My_Playbook_Name"] }' \
--header 'Content-Type: application/json' \
--request PUT \
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.

Next steps

  • You can run the playbook by executing a remote job from the created job template. For more information, see Executing a remote job.

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

Prerequisites

  • Ansible plugin is enabled.

  • Your Foreman account has a role that grants the import_ansible_playbooks permission.

Procedure

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

Next steps

  • You can run the playbooks by executing a remote job from the created job templates. For more information, see Executing a remote job.

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

Procedure

  1. In the Foreman web UI, navigate to Administer > Settings.

  2. Click Remote Execution.

  3. Configure the Fallback to Any Smart Proxy setting.

CLI procedure

  • Enter the hammer settings set command on Foreman to configure the Fallback to Any Smart Proxy setting. To set the value to true, enter the following command:

    $ hammer settings set \
--name=remote_execution_fallback_proxy \
--value=true

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

Procedure

  1. In the Foreman web UI, navigate to Administer > Settings.

  2. Click Remote Execution.

  3. Configure the Enable Global Smart Proxy setting.

CLI procedure

  • Enter the hammer settings set command on Foreman to configure the Enable Global Smart Proxy setting. To set the value to true, enter the following command:

    $ hammer settings set \
--name=remote_execution_global_proxy \
--value=true

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

Procedure

  1. On your host, create a new directory:

    # mkdir /My_Remote_Working_Directory

  2. Copy the SELinux context from the default /var/tmp directory:

    # chcon --reference=/var/tmp /My_Remote_Working_Directory

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

10.11. 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 Yggdrasil service to set an alternative directory for executing remote execution jobs in pull mode.

Prerequisite

  • Determine which version of the yggdrasil package is installed on the host:

    • On Enterprise Linux and SUSE Linux Enterprise Server hosts:

      $ rpm --query yggdrasil
Procedure

  1. Create a new directory:

    # mkdir /My_Remote_Working_Directory

  2. Access the Yggdrasil service configuration:

    • If your host has yggdrasil version 0.4.z or later installed:

      # systemctl edit com.redhat.Yggdrasil1.Worker1.foreman

    • If your host has yggdrasil version 0.2.z or earlier installed:

      # systemctl edit yggdrasild

  3. Specify the alternative directory by adding the following line to the configuration:

    Environment=FOREMAN_YGG_WORKER_WORKDIR=/My_Remote_Working_Directory

  4. Restart the Yggdrasil services:

    • If your host has yggdrasil version 0.4.z or later installed:

      # systemctl restart yggdrasil com.redhat.Yggdrasil1.Worker1.foreman

    • If your host has yggdrasil version 0.2.z or earlier installed:

      # systemctl restart yggdrasild

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

Prerequisites

  • Your user account has a role assigned that grants the view_settings and edit_settings permissions.

  • If you want to use dzdo for Ansible jobs, ensure the community.general Ansible collection, which contains the required dzdo become plugin, is installed. For more information, see Installing collections in Ansible documentation.

Procedure

  1. Navigate to Administer > Settings.

  2. Select the Remote Execution tab.

  3. Click the value of the Effective User Method setting.

  4. Select the new value.

  5. Click Submit.

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

  1. Distributing SSH keys for remote execution manually.

  2. Using the Foreman API to obtain SSH keys for remote execution.

  3. Configuring a Kickstart template to distribute SSH keys during provisioning.

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

10.14. Distributing SSH keys for remote execution manually

To distribute SSH keys manually, complete the following steps:

Procedure

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

Verification

  • 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

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

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
Next steps

  • Users now must use a passphrase when running remote execution jobs on hosts.

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

Procedure

  1. On the target host, create the ~/.ssh directory to store the SSH key:

    # mkdir ~/.ssh

  2. Download the SSH key from Smart Proxy:

    # curl https://smartproxy.example.com:8443/ssh/pubkey >> ~/.ssh/authorized_keys

  3. Configure permissions for the ~/.ssh directory:

    # chmod 700 ~/.ssh

  4. Configure permissions for the authorized_keys file:

    # chmod 600 ~/.ssh/authorized_keys

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

Procedure

  • 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' %>

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

Procedure

  • 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' %>

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

Procedure

  • 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' %>

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

Procedure

  1. Find the ID of the foreman-proxy user:

    # id -u foreman-proxy

  2. Modify the umask value so that new files have the permissions 600:

    # umask 077

  3. Create the directory for the keytab:

    # mkdir -p "/var/kerberos/krb5/user/My_User_ID"

  4. Create a keytab or copy an existing keytab to the directory:

    # cp My_Client.keytab /var/kerberos/krb5/user/My_User_ID/client.keytab

  5. Change the directory owner to the foreman-proxy user:

    # chown -R foreman-proxy:foreman-proxy "/var/kerberos/krb5/user/My_User_ID"

  6. Ensure that the keytab file is read-only:

    # chmod -wx "/var/kerberos/krb5/user/My_User_ID/client.keytab"

  7. Restore the SELinux context:

    # restorecon -RvF /var/kerberos/krb5

10.21. Configuring Kerberos authentication for remote execution

You can use Kerberos authentication to establish an SSH connection for remote execution on Foreman hosts.

Prerequisites

  • 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

Procedure

  1. To install and enable Kerberos authentication for remote execution, enter the following command:

    # foreman-installer --foreman-proxy-plugin-remote-execution-script-ssh-kerberos-auth true

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

  3. Navigate to remote_execution_effective_user and edit the second column to add the user name for the Kerberos account.

Verification

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

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

Procedure

  1. To clone a template, in the Actions column, select Clone.

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

Ansible considerations

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.

Parameter variables

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.

10.23. Executing a remote job

You can execute a job that is based on a job template against one or more hosts.

Note

Ansible jobs run in batches on multiple 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.

To use the CLI instead of the Foreman web UI, see the CLI procedure.

Procedure

  1. In the Foreman web UI, navigate to Monitor > Jobs and click Run job.

  2. Select the Job category and the Job template you want to use, then click Next.

  3. Select hosts on which you want to run the job. If you do not select any hosts, the job will run on all hosts you can see in the current context.

    Note

    If you want to select a host group and all of its subgroups, it is not sufficient to select the host group as the job would only run on hosts directly in that group and not on hosts in subgroups. Instead, you must either select the host group and all of its subgroups or use this search query:

    hostgroup_fullname ~ "My_Host_Group*"

    Replace My_Host_Group with the name of the top-level host group.

  4. If required, provide inputs for the job template. Different templates have different inputs and some templates do not have any inputs. After entering all the required inputs, click Next.

  5. Optional: To configure advanced settings for the job, fill in the Advanced fields. To learn more about advanced settings, see Advanced settings in the job wizard.

  6. Click Next.

  7. Schedule time for the job.

    • To execute the job immediately, keep the pre-selected Immediate execution.

    • To execute the job in future time, select Future execution.

    • To execute the job on regular basis, select Recurring execution.

  8. Optional: If you selected future or recurring execution, select the Query type, otherwise click Next.

    • Static query means that job executes on the exact list of hosts that you provided.

    • Dynamic query means that the list of hosts is evaluated just before the job is executed. If you entered the list of hosts based on some filter, the results can be different from when you first used that filter.

    Click Next after you have selected the query type.

  9. Optional: If you selected future or recurring execution, provide additional details:

    • For Future execution, enter the Starts at date and time. You also have the option to select the Starts before date and time. If the job cannot start before that time, it will be canceled.

    • For Recurring execution, select the start date and time, frequency, and the condition for ending the recurring job. You can choose the recurrence to never end, end at a certain time, or end after a given number of repetitions. You can also add Purpose - a special label for tracking the job. There can only be one active job with a given purpose at a time.

    Click Next after you have entered the required information.

  10. Review job details. You have the option to return to any part of the job wizard and edit the information.

  11. Click Submit to schedule the job for execution.

CLI procedure

  1. Enter the following command on Foreman:

    $ hammer settings set \
--name=remote_execution_global_proxy \
--value=false

  2. Find the ID of the job template you want to use:

    $ hammer job-template list

  3. Show the template details to see parameters required by your template:

    $ hammer job-template info --id My_Template_ID

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

Additional resources

  • For more information about creating, monitoring, or canceling remote jobs with Hammer CLI, enter hammer job-template --help and hammer job-invocation --help.

10.24. Advanced settings in the job wizard

Some job templates require you to enter advanced settings. Some of the advanced settings are only visible to certain job templates. Below is the list of general advanced settings.

SSH user

A user to be used for connecting to the host through SSH.

Effective user

A user to be used for executing the job. By default it is the SSH user. If it differs from the SSH user, su or sudo, depending on your settings, is used to switch the accounts.

  • If you set an effective user in the advanced settings, Ansible sets ansible_become_user to your input value and ansible_become to true. This means that if you use the parameters become: true and become_user: My_User within a playbook, these will be overwritten by Foreman.

  • If your SSH user and effective user are identical, Foreman does not overwrite the become_user. Therefore, you can set a custom become_user in your Ansible Playbook.

Description

A description template for the job.

Timeout to kill

Time in seconds from the start of the job after which the job should be killed if it is not finished already.

Time to pickup

Time in seconds after which the job is canceled if it is not picked up by a client. This setting only applies to hosts using pull-mqtt transport.

Password

Is used if SSH authentication method is a password instead of the SSH key.

Private key passphrase

Is used if SSH keys are protected by a passphrase.

Effective user password

Is used if effective user is different from the ssh user.

Concurrency level

Defines the maximum number of jobs executed at once. This can prevent overload of system resources in a case of executing the job on a large number of hosts.

Execution ordering

Determines the order in which the job is executed on hosts. It can be alphabetical or randomized.

10.25. Using extended cron lines

When scheduling a cron job with remote execution, you can use an extended cron line to specify the cadence of the job. The standard cron line contains five fields that specify minute, hour, day of the month, month, and day of the week. For example, 0 5 * * * stands for every day at 5 AM. If you want to learn more about the standard cron line, check crontab guru.

The extended cron line provides the following features:

You can use # to specify a concrete week day in a month

For example:

  • 0 0 * * mon#1 specifies first Monday of the month

  • 0 0 * * fri#3,fri#4 specifies 3rd and 4th Fridays of the month

  • 0 7 * * fri#-1 specifies the last Friday of the month at 07:00

  • 0 7 * * fri#L also specifies the last Friday of the month at 07:00

  • 0 23 * * mon#2,tue specifies the 2nd Monday of the month and every Tuesday, at 23:00

You can use % to specify every n-th day of the month

For example:

  • 9 0 * * sun%2 specifies every other Sunday at 00:09

  • 0 0 * * sun%2+1 specifies every odd Sunday

  • 9 0 * * sun%2,tue%3 specifies every other Sunday and every third Tuesday

You can use & to specify that the day of the month has to match the day of the week

For example:

  • 0 0 30 * 1& specifies 30th day of the month, but only if it is Monday

10.26. Scheduling a recurring Ansible job for a host

You can schedule a recurring job to run Ansible roles on hosts.

Prerequisites

  • Ensure you have the view_foreman_tasks, view_job_invocations, and view_recurring_logics permissions.

Procedure

  1. In the Foreman web UI, navigate to Hosts > All Hosts and select the target host on which you want to execute a remote job.

  2. On the Ansible tab, select Jobs.

  3. Click Schedule recurring job.

  4. Define the repetition frequency, start time, and date of the first run in the Create New Recurring Ansible Run window.

  5. Click Submit.

  6. Optional: View the scheduled Ansible job in host overview or by navigating to Ansible > Jobs.

10.27. Scheduling a recurring Ansible job for a host group

You can schedule a recurring job to run Ansible roles on host groups.

Procedure

  1. In the Foreman web UI, navigate to Configure > Host groups.

  2. In the Actions column, select Configure Ansible Job for the host group you want to schedule an Ansible roles run for.

  3. Click Schedule recurring job.

  4. Define the repetition frequency, start time, and date of the first run in the Create New Recurring Ansible Run window.

  5. Click Submit.

10.28. Using Ansible provider for package and errata actions

By default, Foreman is configured to use the Script provider templates for remote execution jobs. If you prefer using Ansible job templates for your remote jobs, you can configure Foreman to use them by default for remote execution features associated with them.

Note

Remember that Ansible job templates only work when remote execution is configured for ssh mode.
Procedure

  1. In the Foreman web UI, navigate to Administer > Remote Execution Features.

  2. Find each feature whose name contains by_search.

  3. Change the job template for these features from Katello Script Default to Katello Ansible Default.

  4. Click Submit.

Foreman now uses Ansible provider templates for remote execution jobs by which you can perform package and errata actions. This applies to job invocations from the Foreman web UI as well as by using hammer job-invocation create with the same remote execution features that you have changed.

10.29. Setting the job rate limit on Smart Proxy

You can limit the maximum number of active jobs on a Smart Proxy at a time to prevent performance spikes. The job is active from the time Smart Proxy first tries to notify the host about the job until the job is finished on the host.

The job rate limit only applies to mqtt based jobs.

Note

The optimal maximum number of active jobs depends on the computing resources of your Smart Proxy server. By default, the maximum number of active jobs is unlimited.
Procedure

  • Set the maximum number of active jobs using foreman-installer:

    # foreman-installer \
--foreman-proxy-plugin-remote-execution-script-mqtt-rate-limit MAX_JOBS_NUMBER

    For example:

    # foreman-installer \
--foreman-proxy-plugin-remote-execution-script-mqtt-rate-limit 200

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

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

Search syntax

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 in Administering Foreman, and then build your searches out by 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

11.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 plugins 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 to true, 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.

Only applies if you have the Remote Execution plugin installed.

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
Search syntax

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

12. Managing packages

You can use Foreman to install, upgrade, and remove packages and to enable or disable repositories on hosts.

Packages actions use remote execution. For more information about running remote execution jobs, see Configuring and setting up remote jobs in Managing hosts.

12.1. Enabling and disabling repositories on hosts

Use this procedure to enable and disable repositories on hosts.

Procedure

  1. In the Foreman web UI, navigate to Hosts > All Hosts,

  2. Select a host.

  3. On the Content tab, click the Repository sets tab.

  4. Click the vertical ellipsis to choose Override to disabled or Override to enabled to disable or enable repositories on hosts.

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

Procedure

  1. In the Foreman web UI, navigate to Hosts > All Hosts.

  2. Select a host.

  3. On the Content tab, click the Packages tab.

  4. On the vertical ellipsis icon next to the upgrade button, click Install packages.

  5. In the Install packages window, select the package or packages that you want to install on the host.

  6. Click Install. The Foreman web UI shows a notification for the remote execution job.

API procedure

  1. Supply the API request body in the JSON format:

    Example API request body:

{
  "job_invocation" : { (1)
    "concurrency_control" : {
      "concurrency_level" : 100 (2)
    },
    "feature" : "katello_package_{PackageAction}", (3)
    "inputs" : {
      "package" : "nano vim" (4)
    },
    "scheduling" : { (5)
      "start_at" : "2023-09-21T19:00:00+00:00",
      "start_before" : "2023-09-23T00:00:00+00:00"
    },
    "search_query" : "*", (6)
    "ssh" : { (7)
      "effective_user" : "My_Username",
      "effective_user_password" : "My_Password"
    },
    "targeting_type" : "dynamic_query" (8)
  }
}

  1. The "job_invocation" object, which contains the API request.

  2. Optional: Limit the number of hosts on which the job is run concurrently.

  3. The "feature" field with value "katello_package_install".

  4. The "inputs/package" object that specifies the packages to install. Separate multiple packages with a whitespace.

  5. Optional: Time boundaries for when to start to install packages.

    • You can specify one or both boundaries in the ISO 8601 format.

    • The action is canceled if it is not possible to install the packages by this time.

    • If you omit time, it defaults to 00:00:00.

    • If you omit time zone, it defaults to UTC.

  6. The search query that matches the hosts on which you want to install the packages.

  7. Optional: Credentials of an SSH user, if you want to install packages as that user.

  8. Optional: If you supplied the "scheduling" object, you can make the search query be evaluated when the job runs by specifying the "targeting_type/dynamic_query" field.

    • This is useful if you expect the query to produce a different result at the time of running the job.

    • If you omit this field, it defaults to "static_query".

    1. Send a POST request with the created body to the /api/job_invocations endpoint of your Foreman server and 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
Verification

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

12.3. Upgrading packages on a host

You can upgrade packages on a host in bulk in the Foreman web UI.

Procedure

  1. In the Foreman web UI, navigate to Hosts > All Hosts.

  2. Select a host.

  3. On the Content tab, click the Packages tab.

  4. Select Upgradable from the Status list.

  5. In the Upgradable to column, select the package version that you want to upgrade to.

  6. Select the packages you want to upgrade.

  7. Click Upgrade. The Foreman web UI shows a notification for the remote execution job.

API procedure

  1. Supply the API request body in the JSON format:

    Example API request body:

{
  "job_invocation" : { (1)
    "concurrency_control" : {
      "concurrency_level" : 100 (2)
    },
    "feature" : "katello_package_{PackageAction}", (3)
    "inputs" : {
      "package" : "nano vim" (4)
    },
    "scheduling" : { (5)
      "start_at" : "2023-09-21T19:00:00+00:00",
      "start_before" : "2023-09-23T00:00:00+00:00"
    },
    "search_query" : "*", (6)
    "ssh" : { (7)
      "effective_user" : "My_Username",
      "effective_user_password" : "My_Password"
    },
    "targeting_type" : "dynamic_query" (8)
  }
}

  1. The "job_invocation" object, which contains the API request.

  2. Optional: Limit the number of hosts on which the job is run concurrently.

  3. The "feature" field with value "katello_package_update".

  4. The "inputs/package" object that specifies the packages to update. Separate multiple packages with a whitespace.

  5. Optional: Time boundaries for when to start to update packages.

    • You can specify one or both boundaries in the ISO 8601 format.

    • The action is canceled if it is not possible to update the packages by this time.

    • If you omit time, it defaults to 00:00:00.

    • If you omit time zone, it defaults to UTC.

  6. The search query that matches the hosts on which you want to update the packages.

  7. Optional: Credentials of an SSH user, if you want to update packages as that user.

  8. Optional: If you supplied the "scheduling" object, you can make the search query be evaluated when the job runs by specifying the "targeting_type/dynamic_query" field.

    • This is useful if you expect the query to produce a different result at the time of running the job.

    • If you omit this field, it defaults to "static_query".

    1. Send a POST request with the created body to the /api/job_invocations endpoint of your Foreman server and 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
Verification

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

12.4. Removing packages from a host

You can remove packages from a host in the Foreman web UI.

Procedure

  1. In the Foreman web UI, navigate to Hosts > All Hosts.

  2. Select a host.

  3. On the Content tab, click the Packages tab.

  4. Click the vertical ellipsis for the package you want to remove.

  5. Select Remove. The Foreman web UI shows a notification for the remote execution job.

API procedure

  1. Supply the API request body in the JSON format:

    Example API request body:

{
  "job_invocation" : { (1)
    "concurrency_control" : {
      "concurrency_level" : 100 (2)
    },
    "feature" : "katello_package_{PackageAction}", (3)
    "inputs" : {
      "package" : "nano vim" (4)
    },
    "scheduling" : { (5)
      "start_at" : "2023-09-21T19:00:00+00:00",
      "start_before" : "2023-09-23T00:00:00+00:00"
    },
    "search_query" : "*", (6)
    "ssh" : { (7)
      "effective_user" : "My_Username",
      "effective_user_password" : "My_Password"
    },
    "targeting_type" : "dynamic_query" (8)
  }
}

  1. The "job_invocation" object, which contains the API request.

  2. Optional: Limit the number of hosts on which the job is run concurrently.

  3. The "feature" field with value "katello_package_remove".

  4. The "inputs/package" object that specifies the packages to remove. Separate multiple packages with a whitespace.

  5. Optional: Time boundaries for when to start to remove packages.

    • You can specify one or both boundaries in the ISO 8601 format.

    • The action is canceled if it is not possible to remove the packages by this time.

    • If you omit time, it defaults to 00:00:00.

    • If you omit time zone, it defaults to UTC.

  6. The search query that matches the hosts on which you want to remove the packages.

  7. Optional: Credentials of an SSH user, if you want to remove packages as that user.

  8. Optional: If you supplied the "scheduling" object, you can make the search query be evaluated when the job runs by specifying the "targeting_type/dynamic_query" field.

    • This is useful if you expect the query to produce a different result at the time of running the job.

    • If you omit this field, it defaults to "static_query".

    1. Send a POST request with the created body to the /api/job_invocations endpoint of your Foreman server and 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
Verification

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

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 by 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 > Templates > Provisioning Templates, Hosts > Templates > Job templates, Monitor > Reports > 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.

Procedure

  1. Log in to the Foreman web UI.

  2. In the Foreman web UI, navigate to Administer > About.

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

Procedure

  1. In the Foreman web UI, navigate to either Hosts > Templates > Partition tables, Hosts > Templates > Provisioning Templates, or Hosts > Templates > Job templates.

  2. Click the settings icon at the top right corner of the template editor and select Autocompletion.

  3. 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 type host and check the list of available macros for content source.

  4. A window next to the dropdown provides a description of the macro, its usage, and the value it will return.

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

Indentation in ERB templates

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 > Templates > Partition tables, Hosts > Templates > Provisioning Templates, or Hosts > Templates > 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.

Table 3. Generic macros
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 http://HOST/unattended/provision.

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 unattended/snippets/ directory if it is not found in the database.

snippet_if_exists(name)

Renders the specified snippet, skips if no snippet with the specified name is found.

Template 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 > Reports > 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 > Templates > 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 the each_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. The report_row macro requires the report_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.

Table 4. Host-specific variables and macros
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 host_puppet_environment variable instead.

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 boot loader 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 lifecycle environment of a host.

@host.image_build?

Returns true if the host is provisioned using an image.

@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 false if the specified host parameter evaluates to false.

host_param_true?('parameter_name')

Returns true if the specified host parameter evaluates to true.

@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 host_puppet_ca_server variable instead.

The Puppet CA server the host must use.

@host.puppetmaster Deprecated Use the host_puppet_server variable instead.

The Puppet server the host must use.

@host.pxe_build?

Returns true if the host is provisioned using the network or PXE.

@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 true if a DHCP proxy is configured for this host.

@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 true if the network configuration is static.

@template_name

Name of the template being rendered.

grub_pass

Returns a boot loader argument to set the encrypted boot loader 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.

Table 5. Kickstart-specific variables
Name Description

@arch

The host architecture name, same as @host.architecture.name.

@dynamic

Returns true if the partition table being used is a %pre script (has the #Dynamic option as the first line of the table).

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

Example input
<% load_hosts().each_record do |host| -%>
<% if @host.name == "host1.example.com" -%>
<%      result="positive" -%>
<%  else -%>
<%      result="negative" -%>
<%  end -%>
<%= result -%>
Example rendering
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.

Finding the correct method to parse an 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.

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

  2. In the Create Template window, click the Help tab and search for the ActiveRecord_Associations_CollectionProxy and Nic::Base classes.

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

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

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

Checking if a host has Puppet and Puppetlabs enabled

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')
%>
Capturing major and minor versions of a host’s operating system

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 -%>
Importing snippets to a template

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 %>
Conditionally importing a Kickstart snippet

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 -%>
Parsing values from host custom facts

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.

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.

Procedure

  1. In the Foreman web UI, navigate to Hosts > Templates > Job templates.

  2. Click New Job Template.

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

  4. On the Job tab, set Job category to Commands.

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

  6. Click Required so that the command cannot be executed without the user specified parameter.

  7. Select User input from the Input type list. Enter a description to be shown during job invocation, for example Target directory for restorecon.

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

Procedure

  1. In the Foreman web UI, navigate to Monitor > Jobs and click Run job.

  2. Select Commands as Job category and Run Command – restorecon as Job template and click Next.

  3. Select the hosts on which you want to run the job. If you do not select any hosts, the job will run on all hosts you can see in the current context.

  4. In the directory field, provide a directory, for example /home, and click Next.

  5. Optional: To configure advanced settings for the job, fill in the Advanced fields. To learn more about advanced settings, see Advanced settings in the job wizard. When you are done entering the advanced settings or if it is not required, click Next.

  6. Schedule time for the job.

    • To execute the job immediately, keep the pre-selected Immediate execution.

    • To execute the job in future time, select Future execution.

    • To execute the job on regular basis, select Recurring execution.

  7. Optional: If you selected future or recurring execution, select the Query type, otherwise click Next.

    • Static query means that the job executes on the exact list of hosts that you provided.

    • Dynamic query means that the list of hosts is evaluated just before the job is executed. If you entered the list of hosts based on some filter, the results can be different from when you first used that filter.

      Click Next after you have selected the query type.

  8. Optional: If you selected future or recurring execution, provide additional details:

    • For Future execution, enter the Starts at date and time. You also have the option to select the Starts before date and time. If the job cannot start before that time, it will be canceled.

    • For Recurring execution, select the start date and time, frequency, and condition for ending the recurring job. You can choose the recurrence to never end, end at a certain time, or end after a given number of repetitions. You can also add Purpose - a special label for tracking the job. There can only be one active job with a given purpose at a time.

      Click Next after you have entered the required information.

  9. Review job details. You have the option to return to any part of the job wizard and edit the information.

  10. Click Submit to schedule the job for 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") %>

Appendix C: Overview of the host columns

Below is the complete overview of columns that can be displayed in the host table divided into content categories. Some columns fall under more than one category. For more information on how to customize columns in the host table, see Selecting host columns.

General

  • Power – Whether the host is turned on or off, if available

  • Name – name of the host

  • Operating system – operating system of the host

  • Model – host hardware model (or compute resource in case of virtual hosts)

  • Owner – user or group owning the host

  • Host group – host group of the host

  • Last report – time of the last host report

  • Comment – comment given to host

Network

  • IPv4 – IPv4 address of the host

  • IPv6 – IPv6 address of the host

  • MAC – MAC address of the host

Reported data

  • Sockets – number of host sockets

  • Cores – number of host processor cores

  • RAM – amount of memory

  • Boot time – last boot time of the host

  • Virtual – whether or not the host is recognized as a virtual machine

  • Disks total space – total host storage space

  • Kernel Version – Kernel version of the host operating system

  • BIOS vendor – vendor of the host BIOS

  • BIOS release date – release date of the host BIOS

  • BIOS version – version of the host BIOS

Puppet (only if the Puppet plugin is installed)

  • Environment name – name of the Puppet environment of the host