Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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
-------
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
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