How to change the working directory of the remote execution plugin in Red Hat Satellite 6?

Environment

• Red Hat Satellite 6
• Red Hat Capsule

Issue

• When running a remote execution job, the job is failing with Error: A sub task failed. Using plain ssh to test and verify the connectivity everything is working.
• Why does my remote execution job not work, when ssh connection is working?
• Where can I change the working directory for the remote execution plugin in Red Hat Satellite 6?

Resolution

• See the Establishing a Secure Connection for Remote Commands section of the Satellite Managing Hosts which documents the following options in the /etc/foreman-proxy/settings.d/remote_execution_ssh.yml file.

• ssh_identity_file: File to load the SSH key from. By default, set to /usr/share/foreman-proxy/.ssh/id_rsa_foreman_proxy.
• local_working_dir: Directory used on the Red Hat Satellite or Capsule to run the scripts necessary for remote execution. By default, set to /var/tmp.
• remote_working_dir: Directory on the client system that is used to execute the remote execution jobs. By default, set to /var/tmp.

  • If the client system has noexec set for the /var/ volume or file system, change the remote_working_dir as otherwise the remote execution job will fail since the script cannot be executed.

  • For the workaround follow below steps:

    1. Check if the settings are reflected in the /etc/foreman-proxy/settings.d/remote_execution_ssh.yml file.

       :enabled: https
       :ssh_identity_key_file: /usr/share/foreman-proxy/.ssh/id_rsa_foreman_proxy
       :local_working_dir: /var/tmp
       :remote_working_dir: /remotedir <<<<<<<<<<<< Change this directory location as per client system settings

       Note: Make sure new remote working directory has executable permission.

    2. Execute below commands on the Red Hat Satellite server:

mkdir /etc/smart_proxy_dynflow_core/settings.d

ln -s /etc/foreman-proxy/settings.d/remote_execution_ssh.yml

        /etc/smart_proxy_dynflow_core/settings.d/smart_proxy_remote_execution_ssh_core.yml

    3) Restart smart proxy to take effect: 

For Satellite 6.9 and older versions

        systemctl restart smart_proxy_dynflow_core

For Satellite 6.10 and later versions

        systemctl restart foreman-proxy
       

    4) Now try to schedule the remote command and confirm whether it works properly or not. For any further help feel free to contact [Red Hat Technical Support](https://access.redhat.com/support/contact/technicalSupport/).

• Additional information:
  To make the path permanent, Execute the following command:

  • For Red Hat Satellite\Capsule 6.11 and below:

    # satellite-installer --foreman-proxy-plugin-remote-execution-ssh-remote-working-dir=/var/remote
    

  • For Red Hat Satellite\Capsule 6.12 and later:

    # satellite-installer --foreman-proxy-plugin-remote-execution-script-remote-working-dir=/var/remote
    

For more KB articles/solutions related to Red Hat Satellite 6.x Remote Execution Issues, please refer to the Red Hat Satellite Consolidated Troubleshooting Article for Red Hat Satellite 6.x Remote Execution Issues

Root Cause

• When we perform a remote execution task, ssh user creates a temporary file on the path /var/tmp/ and the effective user performs the task as per remote execution setup on Red Hat Satellite.
• The remote execution task uses /var/tmp/ directory as the default remote working directory on the content host. On the same directory, default permission is set as 777(full permission) so that any user can create a file on the same path.
• There's sticky bit permission is also set on /var/tmp directory. This directory uses to create temporary files only and any other user can create files on this location for temporary purposes.
• If we are changing the remote working directory with a custom directory then, the directory should have similar permission and SELinux context or we can assign ssh user ownership as well.
• When a directory's sticky bit is set, the filesystem treats the files in such directories in a special way so only the file's owner, the directory's owner, or root user can rename or delete the file. Without the sticky bit set, any user with write and execute permissions for the directory can rename or delete contained files, regardless of the file's owner.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.