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.
Steps to Reproduce:
1. Set target host shell to csh
2. Run a simple command (i.e. ls) via REx against that host
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'
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,
Package ksh-20120801-26.el7.x86_64 already installed and latest version
Nothing to do
Illegal variable name.
Exit status: 1
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
Created redmine issue http://projects.theforeman.org/issues/19401 from this bug
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/19401 has been resolved.
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
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.