Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 14. Configuring and setting up remote jobs


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

14.1. Remote execution in Red Hat Satellite

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

Use remote execution for the following benefits in Satellite:

  • 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 Capsule Server, which means that Satellite 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.

Satellite uses ERB syntax job templates. For more information, see Appendix B, Template writing reference.

By default, Satellite includes several job templates for shell scripts and Ansible. For more information, see Section 14.25, “Customizing job templates”.

14.2. Remote execution workflow

When you run a remote job on hosts, for every host, Satellite performs a series of actions to find a remote execution Capsule to use.

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

Satellite searches only for Capsules that have the remote execution feature enabled.

  1. Satellite finds the host’s interfaces that have the Remote execution checkbox selected.
  2. Satellite finds the subnets of these interfaces.
  3. Satellite finds remote execution Capsules assigned to these subnets.
  4. 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 by using the Capsule to which the host is registered.

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.

14.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
Copy to Clipboard Toggle word wrap

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.

14.4. Transport modes for remote execution

You can configure your Satellite to use two different modes of transport for remote job execution.

The following transport modes are available for remote execution. You can configure single Capsule to use either one mode or the other but not both.

Push-based transport

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.

This transport mode supports both Script and Ansible providers.

Pull-based transport

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

This transport mode supports the Script provider only.

To use the pull-mqtt mode, you must enable it on Capsule Server and configure the pull client on hosts.

Note

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

# satellite-installer --foreman-proxy-plugin-remote-execution-script-mode ssh
Copy to Clipboard Toggle word wrap

14.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. This does not use SSH and hosts do not require opening up any incoming firewall ports.

Prerequisites

  • You have registered the host to Satellite.
  • The Capsule through which the host is registered is configured to use pull-mqtt mode. For more information, see Configuring pull-based transport for remote execution in Installing Capsule Server.
  • Red Hat Satellite Client 6 repository for the operating system version of the host is synchronized on Satellite Server, available in the content view and the lifecycle environment of the host, and enabled for the host. For more information, see Changing the repository sets status for a host in Satellite in Managing content.
  • The AppStream repository for the operating system version of the host is synchronized on Satellite Server, available in the content view and the lifecycle environment of the host, and enabled for the host. For more information, see Changing the repository sets status for a host in Satellite in Managing content.
  • The host can communicate with its Capsule over MQTT using port 1883.
  • The host can communicate with its Capsule over HTTPS using port 9090.

Procedure

  • Install the katello-pull-transport-migrate package on your host:

    • On Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 9, and Red Hat Enterprise Linux 8 hosts:

      # dnf install katello-pull-transport-migrate
      Copy to Clipboard Toggle word wrap
    • On Red Hat Enterprise Linux 7 hosts:

      # yum install katello-pull-transport-migrate
      Copy to Clipboard Toggle word wrap

Verification

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

    $ rpm --query yggdrasil
    Copy to Clipboard Toggle word wrap
  2. Check the status of the Yggdrasil services:

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

      # systemctl status yggdrasil com.redhat.Yggdrasil1.Worker1.foreman
      Copy to Clipboard Toggle word wrap
    • If your host has yggdrasil version 0.2.z or earlier installed:

      # systemctl status yggdrasild
      Copy to Clipboard Toggle word wrap

If the services are running, you have successfully configured the host to use the pull client.

14.6. Creating a job template by using Satellite web UI

Use this procedure to create a job template from the Satellite web UI.

Procedure

  1. In the Satellite 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.
  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.

    1. Select Enable Ansible Callback to allow hosts to send facts, which are used to create configuration reports, back to Satellite after a job finishes.
    2. Select Enable Ansible Check Mode to run jobs based on the template in Ansible check mode, which executes Ansible playbooks without making changes to hosts. For more information on Ansible check mode, see Using automation execution in Red Hat Ansible Automation Platform documentation.
  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.

14.7. Creating a job template by using Hammer CLI

Use this procedure to create a job template by using Hammer CLI.

Procedure

  • Create a job template using a template-definition file:

    $ hammer job-template create \
    --file "Path_to_My_Template_File" \
    --job-category "My_Category_Name" \
    --name "My_Template_Name" \
    --provider-type SSH
    Copy to Clipboard Toggle word wrap

14.8. Importing an Ansible Playbook by name

You can import Ansible Playbooks by name to Satellite from collections installed on Capsule.

When you import an Ansible Playbook, 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

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

    $ curl \
    --header 'Content-Type: application/json' \
    --request GET \
    https://satellite.example.com/ansible/api/v2/ansible_playbooks/fetch?proxy_id=My_Capsule_ID
    Copy to Clipboard Toggle word wrap
  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://satellite.example.com/ansible/api/v2/ansible_playbooks/sync?proxy_id=My_Capsule_ID
    Copy to Clipboard Toggle word wrap

    You get a notification in the Satellite web UI after the import completes.

Next steps

14.9. Importing all available Ansible Playbooks

You can import all the available Ansible Playbooks to Satellite from collections installed on Capsule.

When you import an Ansible Playbook, 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
    Copy to Clipboard Toggle word wrap

    You get a notification in the Satellite web UI after the import completes.

Next steps

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 subnets of the hosts 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 subnets of the hosts
  • DNS Capsule assigned to the host domain
  • Realm Capsule assigned to the host realm
  • Puppet server Capsule
  • Puppet CA Capsule
  • OpenSCAP Capsule

Procedure

  1. In the Satellite web UI, navigate to Administer > Settings.
  2. Click Remote Execution.
  3. Configure the Fallback to Any Capsule setting.

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 subnets of the hosts 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

  • Configure the Fallback to Any Capsule setting:

    $ hammer settings set \
    --name remote_execution_fallback_proxy \
    --value true
    Copy to Clipboard Toggle word wrap

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

  1. In the Satellite web UI, navigate to Administer > Settings.
  2. Click Remote Execution.
  3. Configure the Enable Global Capsule setting.

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

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

    $ hammer settings set \
    --name remote_execution_global_proxy \
    --value true
    Copy to Clipboard Toggle word wrap

By default, Satellite 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, Satellite cannot execute remote execution job scripts in this directory. You can use satellite-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
    Copy to Clipboard Toggle word wrap
  2. Copy the SELinux context from the default /var/tmp directory:

    # chcon --reference=/var/tmp /My_Remote_Working_Directory
    Copy to Clipboard Toggle word wrap
  3. Configure your Satellite Server or Capsule Server to use the new directory:

    # satellite-installer \
    --foreman-proxy-plugin-remote-execution-script-remote-working-dir /My_Remote_Working_Directory
    Copy to Clipboard Toggle word wrap

By default, Satellite 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, Satellite 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:

    $ rpm --query yggdrasil
    Copy to Clipboard Toggle word wrap

Procedure

  1. Create a new directory:

    # mkdir /My_Remote_Working_Directory
    Copy to Clipboard Toggle word wrap
  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
      Copy to Clipboard Toggle word wrap
    • If your host has yggdrasil version 0.2.z or earlier installed:

      # systemctl edit yggdrasild
      Copy to Clipboard Toggle word wrap
  3. Specify the alternative directory by adding the following line to the configuration:

    Environment=FOREMAN_YGG_WORKER_WORKDIR=/My_Remote_Working_Directory
    Copy to Clipboard Toggle word wrap
  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
      Copy to Clipboard Toggle word wrap
    • If your host has yggdrasil version 0.2.z or earlier installed:

      # systemctl restart yggdrasild
      Copy to Clipboard Toggle word wrap

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

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

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.

14.18. Adding Satellite Server SSH key to authorized keys

If you want to run remote execution jobs on Satellite Server itself, add the following SSH key to authorized keys on your Satellite Server.

Prerequisites

  • You can access your Satellite Server by using SSH as root.

Procedure

  1. If the ~root/.ssh/authorized_keys file does not exist, create it with restrictive ownership and permissions:

    1. If the ~root/.ssh directory does not exist, create it:

      # mkdir ~root/.ssh
      Copy to Clipboard Toggle word wrap
    2. Ensure that the directory is owned by the root user:

      # chown root:root ~root/.ssh
      Copy to Clipboard Toggle word wrap
    3. Ensure that the directory is accessible only to the root user:

      # chmod 700 ~root/.ssh
      Copy to Clipboard Toggle word wrap
    4. Create the authorized_keys file:

      # touch ~root/.ssh/authorized_keys
      Copy to Clipboard Toggle word wrap
    5. Ensure that the authorized_keys file is owned by the root user:

      # chown root:root ~root/.ssh/authorized_keys
      Copy to Clipboard Toggle word wrap
    6. Ensure that the authorized_keys file is accessible only to the root user:

      # chmod 600 ~root/.ssh/authorized_keys
      Copy to Clipboard Toggle word wrap
  2. Add the SSH key of the foreman-proxy user to the authorized_keys file:

    # cat ~foreman-proxy/.ssh/id_rsa_foreman_proxy.pub >>~root/.ssh/authorized_keys
    Copy to Clipboard Toggle word wrap

14.19. Distributing SSH keys for remote execution manually

You can distribute SSH keys for remote execution manually.

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
    Copy to Clipboard Toggle word wrap

    Repeat this step for each target host you want to manage.

Verification

  • On your Capsule, confirm that the key was successfully copied to the target host:

    # ssh -i ~foreman-proxy/.ssh/id_rsa_foreman_proxy root@client.example.com
    Copy to Clipboard Toggle word wrap

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
    Copy to Clipboard Toggle word wrap

Next steps

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

To use the Satellite API to download the public key from Capsule, complete this procedure on each target host.

Procedure

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

    # mkdir ~/.ssh
    Copy to Clipboard Toggle word wrap
  2. Download the SSH key from Capsule:

    # curl https://capsule.example.com:9090/ssh/pubkey >> ~/.ssh/authorized_keys
    Copy to Clipboard Toggle word wrap
  3. Configure permissions for the ~/.ssh directory:

    # chmod 700 ~/.ssh
    Copy to Clipboard Toggle word wrap
  4. Configure permissions for the authorized_keys file:

    # chmod 600 ~/.ssh/authorized_keys
    Copy to Clipboard Toggle word wrap

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' %>
    Copy to Clipboard Toggle word wrap

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

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

    # id -u foreman-proxy
    Copy to Clipboard Toggle word wrap
  2. Modify the umask value so that new files have the permissions 600:

    # umask 077
    Copy to Clipboard Toggle word wrap
  3. Create the directory for the keytab:

    # mkdir -p "/var/kerberos/krb5/user/My_User_ID"
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap
  5. Change the directory owner to the foreman-proxy user:

    # chown -R foreman-proxy:foreman-proxy "/var/kerberos/krb5/user/My_User_ID"
    Copy to Clipboard Toggle word wrap
  6. Ensure that the keytab file is read-only:

    # chmod -wx "/var/kerberos/krb5/user/My_User_ID/client.keytab"
    Copy to Clipboard Toggle word wrap
  7. Restore the SELinux context:

    # restorecon -RvF /var/kerberos/krb5
    Copy to Clipboard Toggle word wrap

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 (TGT)

Procedure

  1. Enable Kerberos authentication for remote execution:

    # satellite-installer --foreman-proxy-plugin-remote-execution-script-ssh-kerberos-auth true
    Copy to Clipboard Toggle word wrap
  2. 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.
  3. Navigate to remote_execution_effective_user and edit the second column to add the user name for the Kerberos account.

Verification

14.25. Customizing job templates

Satellite provides default job templates that you can use for executing jobs. Default job templates are locked for editing but you can clone them and edit the clone.

Job templates use the Embedded Ruby (ERB) syntax. Ansible job templates use YAML syntax.

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.

Procedure

  1. In the Satellite web UI, navigate to Hosts > Templates > Job templates.
  2. To clone a template, in the Actions column, select Clone.
  3. Enter a unique name for the clone and click Submit to save the changes.
  4. In the list of job templates, click the cloned template to start editing it.

    Note

    An Ansible template must begin 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.

14.26. Executing a remote job by using Satellite web UI

You can execute a job that is based on a job template against one or more hosts from the Satellite web UI.

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.

Procedure

  1. In the Satellite 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*"
    Copy to Clipboard Toggle word wrap

    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 Section 14.28, “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.

14.27. Executing a remote job by using Hammer CLI

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.

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

Procedure

  1. Enter the following command on Satellite:

    $ hammer settings set \
    --name remote_execution_global_proxy \
    --value false
    Copy to Clipboard Toggle word wrap
  2. Find the ID of the job template you want to use:

    $ hammer job-template list
    Copy to Clipboard Toggle word wrap
  3. Show the template details to see parameters required by your template:

    $ hammer job-template info --id My_Template_ID
    Copy to Clipboard Toggle word wrap
  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"
    Copy to Clipboard Toggle word wrap

    Replace My_Search_Query with the filter expression that defines hosts, for example "name ~ My_Pattern".

14.28. 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 Satellite.
  • If your SSH user and effective user are identical, Satellite 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.

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

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

14.30. 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.
  • Ensure you have assigned at least one Ansible role to your host.

Procedure

  1. In the Satellite web UI, navigate to Hosts > All Hosts.
  2. Select your host.
  3. On the Ansible tab, select Jobs.
  4. Click Schedule recurring job.
  5. In the Repeat list, select the interval.
  6. In the Start time field, enter the start time of the recurring job.
  7. In the Start date field, enter the start date of the recurring job.
  8. Click Submit.

14.31. Scheduling a recurring Ansible job for a host group

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

Prerequisites

  • Ensure that you have assigned at least one Ansible role to your host group.
  • Ensure that you have assigned at least one host to your host group.

Procedure

  1. In the Satellite 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. In the Repeat list, select the interval.
  5. In the Start time field, enter the start time of the recurring job.
  6. In the Start date field, enter the start date of the recurring job.
  7. Click Submit.

14.32. Using Ansible provider for package and errata actions

By default, Satellite 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 Satellite 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 Satellite 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.

    Satellite 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 Satellite web UI as well as by using hammer job-invocation create with the same remote execution features that you have changed.

14.33. Setting the job rate limit on Capsule

You can limit the maximum number of active jobs on a Capsule at a time to prevent performance spikes.

The job is active from the time Capsule 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 Capsule Server. By default, the maximum number of active jobs is unlimited.

Procedure

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

    # satellite-installer \
    --foreman-proxy-plugin-remote-execution-script-mqtt-rate-limit MAX_JOBS_NUMBER
    Copy to Clipboard Toggle word wrap

    For example:

    # satellite-installer \
    --foreman-proxy-plugin-remote-execution-script-mqtt-rate-limit 200
    Copy to Clipboard Toggle word wrap
Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2026 Red Hat