Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1445807 - [RFE] Allow choice of target shell in Remote Execution [NEEDINFO]
[RFE] Allow choice of target shell in Remote Execution
Status: CLOSED ERRATA
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Remote Execution (Show other bugs)
6.2.8
x86_64 Linux
unspecified Severity medium (vote)
: GA
: Unused
Assigned To: Adam Ruzicka
Ivan Necas
: FutureFeature, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-04-26 10:28 EDT by Rick Dixon
Modified: 2018-02-21 07:39 EST (History)
7 users (show)

See Also:
Fixed In Version: foreman_remote_execution_core 1.0.4
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-02-21 07:39:11 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
aruzicka: needinfo? (rdixon)


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Foreman Issue Tracker 19401 None None None 2017-04-27 04:20 EDT
Red Hat Product Errata RHSA-2018:0336 normal SHIPPED_LIVE Important: Satellite 6.3 security, bug fix, and enhancement update 2018-02-21 17:43:42 EST

  None (edit)
Description Rick Dixon 2017-04-26 10:28:43 EDT
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:

Always.


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:
-------
   1:
Loaded plugins: langpacks, package_upload, product-id, search-disabled-repos,
   2:
: subscription-manager
   3:
Package ksh-20120801-26.el7.x86_64 already installed and latest version
   4:
Nothing to do
   5:
Illegal variable name.
   6:
Exit status: 1
-------
Comment 1 Adam Ruzicka 2017-04-27 04:19:22 EDT
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 04:20:08 EDT
Created redmine issue http://projects.theforeman.org/issues/19401 from this bug
Comment 5 pm-sat@redhat.com 2017-05-17 06:04:26 EDT
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 10:41:11 EDT
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:

  /usr/bin/tcsh
  anaconda-ks.cfg
  dynflow-temrinate-timeout.patch
  NETBOOT_METHOD.TXT
  original-ks.cfg
  RECIPE.TXT
  ssl-build
  Exit status: 0
Comment 9 errata-xmlrpc 2018-02-21 07:39:11 EST
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.

https://access.redhat.com/errata/RHSA-2018:0336

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