#97 SSH job parameters issue

[Marius Z.]

Hi,

Fresh install of version 2.2.2, controller, agent and joc on single linux box.
Since I used branch 1.X for long time with ssh jobs, I tested first a ssh job and trying to pass variable from order (workflow declared) to remote ssh script on second linux machine. All the scripts are located on local (JS7) machine so the "command_script_file" parameter is used :

command_script_file=/tmp/alertes_test.sh
command_script_param=2022-03-16
create_env_vars=true
auth_file=/home/js/.ssh/id_rsa
auth_method=publickey
simulate_shell=true
host=centreon
user=root

My first observation is that "command_script_param" is not taken into account and the script is running on remote box without any parameter in the command line.

The second observation is that variables declared at workflow level are not visible in the remote ssh script.

So, after all no info can be passed from order or job variables to the remote ssh script.

Is anyone encountered this issues with ssh based workflows ?

Thank you in advance.
Marius

[Andreas]

Hi Marius,

please do not double-post. You added the same question to https://sourceforge.net/p/jobscheduler/discussion/486122/thread/7b7e514697/?limit=25#8319

The answer is simple and painful: this feature got lost from the radar when the SSHJob was migrated from JS1 to JS7. We will add an issue to our change management system for the next release (ca. 3 weeks), if feasible a patch for 2.2.3 will be provided. This includes that any variables (order variables, workflow variables, job resource variables) can be provided from environment variables JS7_VAR_* with * being the uppercase name of the variable.

We will check to make command_script_param available as well.

For the parameter reference please consider the docs at JS7 - JITL SSHJob
. The JS7 brings its own documentation, therefore none of the existing articles about JS1 applies to JS7.

Best regards
Andreas

[Marius Z.]

Hi Andreas,

Thank you for the answer, now everything has more logic.
Do you have a link where the issue is tracked and the availability of the patch is shared ?

You are doing such a great job
Best regards,
Marius

[Andreas]

Hi Marius,

thank you, the following issues have been added to our JIRA:

• JITL-684: JS7 SSH Job supports transfer of variables as Environment Variables for the SSH session
• JITL-685: JS7 SSH Job should support transfer of a script file and additional parameters for the script file

Patches for release 2.2.3 should become available by begin of next week.

Best regards
Andreas

[Andreas]

Hi Marius,

the above issues are resolved and patches for use with release 2.2.3 are available.

Best regards
Andreas

[Marius Z.]

Hi Andreas,

Very good news, I already update my installation to 2.2.3 in order to apply the patch.
I checked the link and is not yet operational:
"The requested URL /patches/patch-20220309-JOC-1256-2.2.2_2.2.3.jar was not found on this server."

Best regards,
Marius

Edit : the text of the link it's working for me but the link it's broken.

[Andreas]

HI Marius,

sorry for the inconvenience, links are now up-to-date.

Best regards
Andreas

[Marius Z.]

Hello,

After few days in test with the ssh JITL job I noted that:

• in case of using a "command_script_file" parameter, a temporary copy of the script file ( like sos-ssh-script-646927071620853577.sh) remains in /tmp folder of the issuer agent machine. I can pass a parameter from job/order but also from "Job Resource" via JS7_VAR_* environment variable
• in case of using a "command" parameter I can pass a PATTERN argument (command = ls -al ${PATTERN}) from job/order but not from a "Job Resource" :
  [End] [Error], errorState=failed, reason=disrupted, msg=No such named value: PATTERN
  I saw that JS7_VAR_PATTERN arrive in the environment of the remote machine, but cannot be used in the command line like argument.

Best Regards,
Marius

[Marius Z.]

Hello,

Another issue for JITL SSH job in 2.3.1 version : cannot add more than 1 parameter for Argument "command_script_param". Trying to add ${PRODUCT} ${FILE} triggers error :
$.jobs['get_sql_data'].executable.arguments[command_script_param]:Error in expression: Expected end-of-input:1:12, found "${FILE}"

A 2nd static parameter works fine.

Trying to pass \${PRODUCT} \${FILE} is working but the parameters passed to the script are preceded by a \

And just a reminder for the suppression of temporary scripts files in /tmp. Their number is growing fast :)

Best regards,
Marius

[Andreas]

Hi Marius,

more than 1 variable can be used in the "command_script_param" argument: the error that you faced is due to substitution of the argument as you did not quote its value. Please use single quotes as in: '${PRODUCT} ${FILE} and further arguments'

Find attached a testcase that adds some flexibility as it starts from the "command" argument that makes use of environment variables for the "command_script" and "command_script_param" values.

We will check the handling of temporary files.

Best regards
Andreas

[Marius Z.]

Hi Andreas,

Firstly, thank you for your time. These are my findings, trying to keep simple the workflow architecture :

Single quoting : '${PRODUCT} ${FILE}' does not working since PRODUCT and FILE are workflow defined parameters (order). They are sent "as is" so in the remote system they are evaluated to empty strings
[INFO] command_script_param=${PRODUCT} ${FILE} (source=JOB)

Double quoting : \"${PRODUCT} ${FILE}\" or even \"${PRODUCT}\" \"${FILE}\" does not work (files with quotes in their names are created) but sending also the quote as part of parameter, so not an option at least not for all scripts
[INFO] command_script_param=\"U1\" \"get_sql_data.csv\" (source=JOB)

Surprisingly $PRODUCT $FILE is working and discarding braces do the job without any errors and the parameters (that does not have spaces) are correctly passed to the remote script
[INFO] command_script_param=U1 get_sql_data.csv (source=JOB)

Basically I need a way to pass the parameters (from workflow level) in such a way that in the log file should be :
[INFO] command_script_param="U1" "get_sql_data.csv" (source=JOB)

Best regards,
Marius