Bug 1445807 - [RFE] Allow choice of target shell in Remote Execution
Summary: [RFE] Allow choice of target shell in Remote Execution
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Remote Execution
Version: 6.2.8
Hardware: x86_64
OS: Linux
medium vote
Target Milestone: Unspecified
Assignee: Adam Ruzicka
QA Contact: Ivan Necas
Depends On:
TreeView+ depends on / blocked
Reported: 2017-04-26 14:28 UTC by Rick Dixon
Modified: 2021-06-10 12:20 UTC (History)
7 users (show)

Fixed In Version: foreman_remote_execution_core 1.0.4
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-02-21 12:39:11 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 19401 0 Normal Closed Allow choice of target shell in Remote Execution 2020-04-24 02:19:44 UTC
Red Hat Product Errata RHSA-2018:0336 0 normal SHIPPED_LIVE Important: Satellite 6.3 security, bug fix, and enhancement update 2018-02-21 22:43:42 UTC

Description Rick Dixon 2017-04-26 14:28:43 UTC
Description of problem:

Executing remote commands against hosts using cshell (csh) yields the following results:

  - The command executes fine
  - However, the exit code is 1
  - "Illegal variable name" is output regardless of variable definitions 
  - Job status reverts to failed

This makes determining which jobs have failed on which hosts nearly impossible in an environment running primarily csh.

How reproducible:


Steps to Reproduce:
1. Set target host shell to csh
2. Run a simple command (i.e. ls) via REx against that host

Actual results:

The output indicates that the 'ls' command actually succeeded, however the job will always return as failed and the output shown will always complain about an 'Illegal variable name'

Expected results:

These results are "expected" given that REx templates appear to be written for bash, however it would be helpful in some environments if there were a set of script template equivalents with command syntax which could be used for different shells.

Below is the output received when sending a simple package installation task to a host:
Loaded plugins: langpacks, package_upload, product-id, search-disabled-repos,
: subscription-manager
Package ksh-20120801-26.el7.x86_64 already installed and latest version
Nothing to do
Illegal variable name.
Exit status: 1

Comment 1 Adam Ruzicka 2017-04-27 08:19:22 UTC
The root issue is that we apparently rely on some "bashisms" when executing the script provided by the user. We should probably rewrite those behind-the-scenes things to be /bin/sh compatible to be able to run anywhere.

Would this work for you? This way there would be no need to explicitly select a shell in the UI. If the users want to have the script by another shell/interpreter they can always provide a shebang in the job template

Comment 2 Adam Ruzicka 2017-04-27 08:20:08 UTC
Created redmine issue http://projects.theforeman.org/issues/19401 from this bug

Comment 5 Satellite Program 2017-05-17 10:04:26 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/19401 has been resolved.

Comment 6 Ivan Necas 2017-08-16 14:41:11 UTC
Version Tested: Satellite-6.3 Snap 11

1. installed tcsh package on remote client, set root's default to tcsh
2. run `echo $SHELL;ls;` job
3. job succeeded with:

  Exit status: 0

Comment 9 errata-xmlrpc 2018-02-21 12:39:11 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.