Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.
Chapter 4. Configuring and Setting Up Remote Jobs
Use this section as a guide to configuring Satellite to execute jobs on remote hosts.
Any command that you want to apply to a remote host must be defined as a job template. After you have defined a job template you can execute it multiple times.
4.1. About Running Jobs on Hosts
You can run jobs on hosts remotely from Capsules using shell scripts or Ansible tasks and playbooks. This is referred to as remote execution.
For custom Ansible roles that you create, or roles that you download, you must install the package containing the roles on the Capsule base operating system. Before you can use Ansible roles, you must import the roles into Satellite from the Capsule where they are installed.
Communication occurs through Capsule Server, which means that Satellite Server does not require direct access to the target host, and can scale to manage many hosts. For more information, see Section 4.4, “Transport Modes for Remote Execution”.
Satellite uses ERB syntax job templates. For more information, see Template Writing Reference in Managing Hosts.
Several job templates for shell scripts and Ansible are included by default. For more information, see Setting up Job Templates in Managing Hosts.
Any Capsule Server base operating system is a client of Satellite Server’s internal Capsule, and therefore this section applies to any type of host connected to Satellite Server, including Capsules.
You can run jobs on multiple hosts at once, and you can use variables in your commands for more granular control over the jobs you run. You can use host facts and parameters to populate the variable values.
In addition, you can specify custom values for templates when you run the command.
For more information, see Executing a Remote Job in Managing Hosts.
4.2. Remote Execution Workflow
When you run a remote job on hosts, for every host, Satellite performs the following actions to find a remote execution Capsule to use.
Satellite searches only for Capsules that have the Ansible feature enabled.
- Satellite finds the host’s interfaces that have the Remote execution checkbox selected.
- Satellite finds the subnets of these interfaces.
- Satellite finds remote execution Capsules assigned to these subnets.
- From this set of Capsules, Satellite selects the Capsule that has the least number of running jobs. By doing this, Satellite ensures that the jobs load is balanced between remote execution Capsules.
If you have enabled Prefer registered through Capsule for remote execution, Satellite runs the REX job using the Capsule the host is registered to.
By default, Prefer registered through Capsule for remote execution is set to No. To enable it, in the Satellite web UI, navigate to Administer > Settings, and on the Content tab, set Prefer registered through Capsule for remote execution
to Yes. This ensures that Satellite performs REX jobs on hosts by the Capsule to which they are registered to.
If Satellite does not find a remote execution Capsule at this stage, and if the Fallback to Any Capsule setting is enabled, Satellite adds another set of Capsules to select the remote execution Capsule from. Satellite selects the most lightly loaded Capsule from the following types of Capsules that are assigned to the host:
- DHCP, DNS and TFTP Capsules assigned to the host’s subnets
- DNS Capsule assigned to the host’s domain
- Realm Capsule assigned to the host’s realm
- Puppet server Capsule
- Puppet CA Capsule
- OpenSCAP Capsule
If Satellite does not find a remote execution Capsule at this stage, and if the Enable Global Capsule setting is enabled, Satellite selects the most lightly loaded remote execution Capsule from the set of all Capsules in the host’s organization and location to execute a remote job.
4.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 Capsules 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 Red Hat Satellite and Capsule registered as hosts to Red Hat Satellite 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 Red Hat Satellite and Capsule hosts.
For more information on working with roles and permissions, see Creating and Managing Roles in Administering Red Hat Satellite.
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.
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.
4.4. Transport Modes for Remote Execution
You can configure your Satellite to use two different modes of transport for remote job execution.
On Capsules 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 Capsule must have access to the SSH port on the target hosts. Unless you have a different setting, the standard SSH port is 22.
On Capsules in pull-mqtt
mode, remote execution uses Message Queueing Telemetry Transport (MQTT) to publish jobs it receives from Satellite Server. The host subscribes to the MQTT broker on Capsule for job notifications using the yggdrasil
pull client. After the host receives a notification, it pulls job details from Capsule over HTTPS, runs the job, and reports results back to Capsule.
To use the pull-mqtt
mode, you must enable it on Capsule Server and configure the pull client on the target hosts.
Additional resources
- To enable pull mode on Capsule Server, see Configuring Remote Execution for Pull Client in Installing Capsule Server.
- To enable pull mode on an existing host, continue with Section 4.5, “Configuring a Host to Use the Pull Client”.
- To migrate a host from Katello Agent, see Migrating from Katello Agent to Remote Execution in Managing Hosts.
To enable pull mode on a new host, continue with either of the following procedures in Managing Hosts:
4.5. Configuring a Host to Use the Pull Client
For Capsules configured to use pull-mqtt
mode, hosts can subscribe to remote jobs using the remote execution pull client. Managed hosts do not require an SSH connection to their Capsule Server.
Prerequisites
- You have registered the host to Satellite.
-
The host’s Capsule is configured to use
pull-mqtt
mode. For more information, see Configuring Remote Execution for Pull Client in Installing Capsule Server. - The Red Hat Satellite Client 6 repository is enabled and synchronized on Satellite Server, and enabled on the host.
-
The host is able to communicate with its Capsule over MQTT using port
1883
. - The host is able to communicate with its Capsule over HTTPS.
The katello-pull-transport-migrate
package was created to help users migrate from Katello Agent to remote execution with the pull client. However, having Katello Agent installed on the host is not a requirement. You can use katello-pull-transport-migrate
regardless of whether Katello Agent is installed.
Procedure
Install the
katello-pull-transport-migrate
package on your host:On Red Hat Enterprise Linux 8 and Red Hat Enterprise Linux 9 hosts:
# dnf install katello-pull-transport-migrate
On Red Hat Enterprise Linux 7 hosts:
# yum install katello-pull-transport-migrate
The package installs
foreman_ygg_worker
andyggdrasil
as dependencies and enables the pull mode on the host. The host’ssubscription-manager
configuration and consumer certificates are used to configure theyggdrasil
client on the host, and the pull mode client worker is started.Optional: To verify that the pull client is running and configured properly, check the status of the
yggdrasild
service:# systemctl status yggdrasild
Optional: After the package is installed, you can remove
katello-agent
from the host.WarningIf your host is installed on Red Hat Virtualization version 4.4 or lower, do not remove the
katello-agent
package because the removed dependencies corrupt the host.
4.6. Creating a Job Template
Use this procedure to create a job template. To use the CLI instead of the Satellite web UI, see the CLI procedure.
Procedure
- In the Satellite web UI, navigate to Hosts > Job templates.
- Click New Job Template.
- Click the Template tab, and in the Name field, enter a unique name for your job template.
- Select Default to make the template available for all organizations and locations.
- Create the template directly in the template editor or upload it from a text file by clicking Import.
- Optional: In the Audit Comment field, add information about the change.
- Click the Job tab, and in the Job category field, enter your own category or select from the default categories listed in Default Job Template Categories in Managing Hosts.
-
Optional: In the Description Format field, enter a description template. For example,
Install package %{package_name}
. You can also use%{template_name}
and%{job_category}
in your template. - From the Provider Type list, select SSH for shell scripts and Ansible for Ansible tasks or playbooks.
- Optional: In the Timeout to kill field, enter a timeout value to terminate the job if it does not complete.
- Optional: Click Add Input to define an input parameter. Parameters are requested when executing the job and do not have to be defined in the template. For examples, see the Help tab.
- Optional: Click Foreign input set to include other templates in this job.
-
Optional: In the Effective user area, configure a user if the command cannot use the default
remote_execution_effective_user
setting. - Optional: If this template is a snippet to be included in other templates, click the Type tab and select Snippet.
- Click the Location tab and add the locations where you want to use the template.
- Click the Organizations tab and add the organizations where you want to use the template.
- Click Submit to save your changes.
You can extend and customize job templates by including other templates in the template syntax. For more information, see Template Writing Reference and Job Template Examples and Extensions in Managing Hosts.
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
4.7. Importing an Ansible Playbook by Name
You can import Ansible playbooks by name to Satellite from collections installed on Capsule. Satellite 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 Satellite account has a role that grants the
import_ansible_playbooks
permission.
Procedure
Fetch the available Ansible playbooks by using the following API request:
# curl -X GET -H 'Content-Type: application/json' https://satellite.example.com/ansible/api/v2/ansible_playbooks/fetch?proxy_id=My_capsule_ID
- Select the Ansible playbook you want to import and note its name.
Import the Ansible playbook by its name:
# curl -X PUT -H 'Content-Type: application/json' -d '{ "playbook_names": ["My_Playbook_Name"] }' https://satellite.example.com/ansible/api/v2/ansible_playbooks/sync?proxy_id=My_capsule_ID
You get a notification in the Satellite 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 Section 4.21, “Executing a Remote Job”.
4.8. Importing All Available Ansible Playbooks
You can import all the available Ansible playbooks to Satellite from collections installed on Capsule. Satellite 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 Satellite 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://satellite.example.com/ansible/api/v2/ansible_playbooks/sync?proxy_id=My_capsule_ID
You get a notification in the Satellite 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 Section 4.21, “Executing a Remote Job”.
4.9. Configuring the Fallback to Any Capsule Remote Execution Setting in Satellite
You can enable the Fallback to Any Capsule setting to configure Satellite to search for remote execution Capsules from the list of Capsules 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 Capsules that do not have the remote execution feature enabled.
If the Fallback to Any Capsule setting is enabled, Satellite adds another set of Capsules to select the remote execution Capsule from. Satellite also selects the most lightly loaded Capsule from the set of all Capsules assigned to the host, such as the following:
- DHCP, DNS and TFTP Capsules assigned to the host’s subnets
- DNS Capsule assigned to the host’s domain
- Realm Capsule assigned to the host’s realm
- Puppet server Capsule
- Puppet CA Capsule
- OpenSCAP Capsule
Procedure
- In the Satellite web UI, navigate to Administer > Settings.
- Click Remote Execution.
- Configure the Fallback to Any Capsule setting.
CLI procedure
Enter the
hammer settings set
command on Satellite to configure the Fallback to Any Capsule setting. To set the value totrue
, enter the following command:# hammer settings set \ --name=remote_execution_fallback_proxy \ --value=true
4.10. Configuring the Global Capsule Remote Execution Setting in Satellite
By default, Satellite searches for remote execution Capsules in hosts' organizations and locations regardless of whether Capsules are assigned to hosts' subnets or not. You can disable the Enable Global Capsule setting if you want to limit the search to the Capsules that are assigned to hosts' subnets.
If the Enable Global Capsule setting is enabled, Satellite adds another set of Capsules to select the remote execution Capsule from. Satellite also selects the most lightly loaded remote execution Capsule from the set of all Capsules in the host’s organization and location to execute a remote job.
Procedure
- In the Satellite web UI, navigate to Administer > Settings.
- Click Remote Execution.
- Configure the Enable Global Capsule setting.
CLI procedure
Enter the
hammer settings set
command on Satellite to configure theEnable Global Capsule
setting. To set the value totrue
, enter the following command:# hammer settings set \ --name=remote_execution_global_proxy \ --value=true
4.11. Configuring Satellite to Use an Alternative Directory to Execute Remote Jobs on Hosts
Ansible puts its own files it requires on the server side into the /tmp
directory. You have the option to set a different directory if required.
Procedure
On your Satellite Server or Capsule Server, create a new directory:
# mkdir /My_Remote_Working_Directory
Copy the SELinux context from the default
/tmp
directory:# chcon --reference=/tmp /My_Remote_Working_Directory
Configure your Satellite Server or Capsule Server to use the new directory:
# satellite-installer \ --foreman-proxy-plugin-ansible-working-dir /My_Remote_Working_Directory
4.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 Satellite settings.
Prerequisites
-
Your user account has a role assigned that grants the
view_settings
andedit_settings
permissions. -
If you want to use
dzdo
for Ansible jobs, ensure thecommunity.general
Ansible collection, which contains the required dzdo become plug-in, is installed. For more information, see Installing collections in Ansible documentation.
Procedure
- Navigate to Administer > Settings.
- Select the Remote Execution tab.
- Click the value of the Effective User Method setting.
- Select the new value.
- Click Submit.
4.13. Distributing SSH Keys for Remote Execution
For Capsules in ssh
mode, remote execution connections are authenticated using SSH. The public SSH key from Capsule 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 Capsule to target hosts:
- Section 4.14, “Distributing SSH Keys for Remote Execution Manually”.
- Section 4.16, “Using the Satellite API to Obtain SSH Keys for Remote Execution”.
- Section 4.17, “Configuring a Kickstart Template to Distribute SSH Keys During Provisioning”.
- For new Satellite hosts, you can deploy SSH keys to Satellite hosts during registration using the global registration template. For more information, see Registering a Host to Red Hat Satellite Using the Global Registration Template in Managing Hosts.
Satellite distributes SSH keys for the remote execution feature to the hosts provisioned from Satellite by default.
If the hosts are running on Amazon Web Services, enable password authentication. For more information, see New User Accounts.
4.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 Capsule 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 Capsule:
# ssh -i ~foreman-proxy/.ssh/id_rsa_foreman_proxy root@client.example.com
4.15. Adding a Passphrase to SSH Key Used for Remote Execution
By default, Capsule 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 Satellite Server or Capsule 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.
4.16. Using the Satellite API to Obtain SSH Keys for Remote Execution
To use the Satellite API to download the public key from Capsule, complete this procedure on each target host.
Procedure
On the target host, create the
~/.ssh
directory to store the SSH key:# mkdir ~/.ssh
Download the SSH key from Capsule:
# curl https://capsule.example.com:9090/ssh/pubkey >> ~/.ssh/authorized_keys
Configure permissions for the
~/.ssh
directory:# chmod 700 ~/.ssh
Configure permissions for the
authorized_keys
file:# chmod 600 ~/.ssh/authorized_keys
4.17. 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 Satellite ships include this snippet by default. Satellite 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' %>
4.18. Configuring a keytab for Kerberos Ticket Granting Tickets
Use this procedure to configure Satellite to use a keytab to obtain Kerberos ticket granting tickets. If you do not set up a keytab, you must manually retrieve tickets.
Procedure
Find the ID of the
foreman-proxy
user:# id -u foreman-proxy
Modify the
umask
value so that new files have the permissions600
:# umask 077
Create the directory for the keytab:
# mkdir -p "/var/kerberos/krb5/user/My_User_ID"
Create a keytab or copy an existing keytab to the directory:
# cp My_Client.keytab /var/kerberos/krb5/user/My_User_ID/client.keytab
Change the directory owner to the
foreman-proxy
user:# chown -R foreman-proxy:foreman-proxy "/var/kerberos/krb5/user/My_User_ID"
Ensure that the keytab file is read-only:
# chmod -wx "/var/kerberos/krb5/user/My_User_ID/client.keytab"
Restore the SELinux context:
# restorecon -RvF /var/kerberos/krb5
4.19. Configuring Kerberos Authentication for Remote Execution
You can use Kerberos authentication to establish an SSH connection for remote execution on Satellite hosts.
Prerequisites
- Enroll Satellite Server on the Kerberos server
- Enroll the Satellite target host on the Kerberos server
- Configure and initialize a Kerberos user account for remote execution
- Ensure that the foreman-proxy user on Satellite has a valid Kerberos ticket granting ticket
Procedure
To install and enable Kerberos authentication for remote execution, enter the following command:
# satellite-installer --scenario satellite \ --foreman-proxy-plugin-remote-execution-script-ssh-kerberos-auth true
- To edit the default user for remote execution, in the Satellite web UI, navigate to Administer > Settings and click the Remote Execution tab. In the SSH User row, edit the second column and add the user name for the Kerberos account.
- Navigate to remote_execution_effective_user and edit the second column to add the user name for the Kerberos account.
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 Configurations Using Ansible Integration in Red Hat Satellite.
4.20. Setting up Job Templates
Satellite provides default job templates that you can use for executing jobs. To view the list of job templates, navigate to Hosts > Job templates. If you want to use a template without making changes, proceed to Executing a Remote Job in Managing Hosts.
You can use default templates as a base for developing your own. Default job templates are locked for editing. Clone the template and edit the clone.
Procedure
- To clone a template, in the Actions column, select Clone.
- Enter a unique name for the clone and click Submit to save the changes.
Job templates use the Embedded Ruby (ERB) syntax. For more information about writing templates, see the Template Writing Reference in Managing Hosts.
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 Satellite. 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.
4.21. Executing a Remote Job
You can execute a job that is based on a job template against one or more hosts.
To use the CLI instead of the Satellite web UI, see the CLI procedure.
Procedure
- In the Satellite web UI, navigate to Hosts > All Hosts and select the target hosts on which you want to execute a remote job. You can use the search field to filter the host list.
- From the Select Action list, select Schedule a Job.
- On the Job invocation page, define the main job settings:
- Select the Job category and the Job template you want to use.
- Optional: Select a stored search string in the Bookmark list to specify the target hosts.
- Optional: Further limit the targeted hosts by entering a Search query. The Resolves to line displays the number of hosts affected by your query. Use the refresh button to recalculate the number after changing the query. The preview icon lists the targeted hosts.
- The remaining settings depend on the selected job template. See Creating a Job Template for information on adding custom parameters to a template.
Optional: To configure advanced settings for the job, click Display advanced fields. Some of the advanced settings depend on the job template, the following settings are general:
- Effective user defines the user for executing the job, by default it is the SSH user.
- Concurrency level defines the maximum number of jobs executed at once, which can prevent overload of systems' resources in a case of executing the job on a large number of hosts.
- Timeout to kill defines time interval in seconds after which the job should be killed, if it is not finished already. A task which could not be started during the defined interval, for example, if the previous task took too long to finish, is canceled.
- Type of query defines when the search query is evaluated. This helps to keep the query up to date for scheduled tasks.
Execution ordering determines the order in which the job is executed on hosts: alphabetical or randomized.
Concurrency level and Timeout to kill settings enable you to tailor job execution to fit your infrastructure hardware and needs.
- To run the job immediately, ensure that Schedule is set to Execute now. You can also define a one-time future job, or set up a recurring job. For recurring tasks, you can define start and end dates, number and frequency of runs. You can also use cron syntax to define repetition. For more information about cron, see Automate your Linux system tasks with cron.
- Click Submit. You can view status of the jobs in the Recent Jobs section on the same page.
CLI procedure
Enter the following command on Satellite:
# hammer settings set \ --name=remote_execution_global_proxy \ --value=false
Find the ID of the job template you want to use:
# hammer job-template list
Show the template details to see parameters required by your template:
# hammer job-template info --id My_Template_ID
Execute a remote job with custom parameters:
# hammer job-invocation create \ --inputs My_Key_1="My_Value_1",My_Key_2="My_Value_2",... \ --job-template "My_Template_Name" \ --search-query "My_Search_Query"
Replace
My_Search_Query
with the filter expression that defines hosts, for example"name ~ My_Pattern"
. For more information about executing remote commands with hammer, enterhammer job-template --help
andhammer job-invocation --help
.
4.22. Scheduling a Recurring Ansible Job for a Host
You can schedule a recurring job to run Ansible roles on hosts.
Prerequisite
-
Ensure you have the
view_foreman_tasks
,view_job_invocations
, andview_recurring_logics
permissions.
Procedure
- In the Satellite web UI, navigate to Hosts > All Hosts and select the target host on which you want to execute a remote job.
- On the Ansible tab, select Jobs.
- Click Schedule recurring job.
- Define the repetition frequency, start time, and date of the first run in the Create New Recurring Ansible Run window.
- Click Submit.
- Optional: View the scheduled Ansible job in host overview or by navigating to Ansible > Jobs.
4.23. Scheduling a Recurring Ansible Job for a Host Group
You can schedule a recurring job to run Ansible roles on host groups.
Procedure
- In the Satellite web UI, navigate to Configure > Host groups.
- In the Actions column, select Configure Ansible Job for the host group you want to schedule an Ansible roles run for.
- Click Schedule recurring job.
- Define the repetition frequency, start time, and date of the first run in the Create New Recurring Ansible Run window.
- Click Submit.
4.24. Monitoring Jobs
You can monitor the progress of a job while it is running. This can help in any troubleshooting that may be required.
Ansible jobs run on batches of 100 hosts, so you cannot cancel a job running on a specific host. A job completes only after the Ansible playbook runs on all hosts in the batch.
Procedure
-
In the Satellite web UI, navigate to Monitor > Jobs. This page is automatically displayed if you triggered the job with the
Execute now
setting. To monitor scheduled jobs, navigate to Monitor > Jobs and select the job run you wish to inspect. - On the Job page, click the Hosts tab. This displays the list of hosts on which the job is running.
- In the Host column, click the name of the host that you want to inspect. This displays the Detail of Commands page where you can monitor the job execution in real time.
- Click Back to Job at any time to return to the Job Details page.
CLI procedure
Find the ID of a job:
# hammer job-invocation list
Monitor the job output:
# hammer job-invocation output \ --host "My_Host_Name" \ --id My_Job_ID
Optional: To cancel a job, enter the following command:
# hammer job-invocation cancel \ --id My_Job_ID