FEATURE AVAILABILITY STARTING FROM RELEASE 1.9

Mode of operation

The SOSSSHJob2JSAdapter can run with either the Trilead implementation (default) or the JSch implementation by JCraft.

The JSch implementation for SSH connections adds the use of return values to the already existing functionality of the SOSSSHJob2JSAdapter class.

To use the JSch implementation in JobScheduler Version 1.9.x you have to configure the following parameter in the params section of the scheduler.xml, in newer versions you don´t have to configure this parameter.

The Trilead implementation is deprecated starting with JobScheduler 1.10.0 and will be removed in future releases. If you still want to use the Trilead implementation, change the below parameter value to false in JobScheduler Releases 1.10.x.

<param name="jitl.ssh.use_jsch_impl" value="true"/>

The Job sets an environment variable to the session on the remote host with the name SCHEDULER_RETURN_VALUES which is available for the script or command to be executed on the remote machine. The value (the name of the temporary file) for this environment variable will be generated at runtime. After the execution of the script or command the jobs reads the return values from that temporary file on the remote host, returns them to the Jobscheduler for further processing and deletes the temporary file afterwards.

JITL-112 - Getting issue details... STATUS

JITL-123 - Getting issue details... STATUS

Passing variables back to the JobScheduler

To use this feature you have to make sure that your command or command script writes the key-value-pair you want to have passed back to the JobScheduler, to the temporarily created file.

Example

The command echo MYPARAM=myTestParam >> $SCHEDULER_RETURN_VALUES writes MYPARAM=myTestParam to the temporary file defined by the environment variable $SCHEDULER_RETURN_VALUES.

The environment variable will be set implicitily during the job execution.

New parameters

General information

The default values use the linux bash syntax. These parameters have to be set only if running on systems using a different syntax than the linux bash syntax. Please choose the format of the command value and it placeholders according to the operating system on the remote host.

preCommand

• format: 
  • <command> <placeholder1> = <placeholder2>
• default value: 
  • export %1s=%2s
• description: 
  • The command to set an environment variable. The values for placeholders 1 and 2 will be set implicitly at the start of the job execution. The placeholders are mandatory.

postCommandRead

• format: 
  • <command> <placeholder>
• default value: 
  • cat %s
• description:
  • The command to read the temporary file where the return values are written to through the script/command execution of the SSH job. The placeholder will be substituted during the job execution. 

postCommandDelete

• format: 
  • <command> <placeholder>
• default value: 
  • rm %s
• description:
  • The command to delete the temporary file with the return values. The placeholder will be substituted during the job execution. 

Configuration

To use the return-values-feature configure a SSH job with JOE and choose SOSSSHJob2JSAdapter. 

Example 1: A minimal SSH Job configuration

<?xml version="1.0" encoding="ISO-8859-1"?>
<job title="Launch remote commands or executable files by SSH" stop_on_error="no">
    <description >
        <include  file="jobs/JobSchedulerSSHJob.xml"/>
    </description>
    <params >
        <param  name="host" value="HOSTNAME"/>
        <param  name="port" value="22"/>
        <param  name="user" value="USERNAME"/>
        <param  name="password" value="PASSWORD"/>
        <param  name="auth_method" value="password"/>
        <param  name="command" value="printenv"/>
    </params>
    <script  language="java" java_class="sos.scheduler.job.SOSSSHJob2JSAdapter"/>
    <run_time />
</job>

Example 2: A job chain that processes return values

<?xml version="1.0" encoding="ISO-8859-1"?>
<job name="setValueRemote" title="Launch remote commands or executable files by SSH" order="yes" stop_on_error="no">
    <description >
        <include  file="jobs/JobSchedulerSSHJob.xml"/>
    </description>
    <params >
        <param  name="host" value="HOSTNAME"/>
        <param  name="port" value="22"/>
        <param  name="user" value="USERNAME"/>
        <param  name="password" value="PASSWORD"/>
        <param  name="auth_method" value="password"/>
        <param  name="command" value="echo ADD='Hallo Welt' &gt;&gt; \$SCHEDULER_RETURN_VALUES"/>
    </params>
    <script  language="java" java_class="sos.scheduler.job.SOSSSHJob2JSAdapter"/>
    <run_time />
</job>

<?xml version="1.0" encoding="ISO-8859-1"?>
<job  order="yes" name="getValue">
    <params />
    <script  language="shell">
        <![CDATA[echo %SCHEDULER_PARAM_ADD%]]>
    </script>
    <run_time />
</job>

<?xml version="1.0" encoding="ISO-8859-1"?>
<job_chain  name="test_return_values">
    <job_chain_node  state="WRITE_VALUE_REMOTE" job="setValueRemote" next_state="READ_VALUE" error_state="ERROR"/>
    <job_chain_node  state="READ_VALUE" job="getValue" next_state="SUCCESS" error_state="ERROR"/>
    <job_chain_node  state="SUCCESS"/>
    <job_chain_node  state="ERROR"/>
</job_chain>

For known limitations using the SSH Job to connect to a Windows Remote Host see Limitations when using SSH jobs for Windows.

Known issues

Connecting over SSH

Sometimes while connecting an error occurs which states "java.security.InvalidAlgorithmParameterException: Prime size must be multiple of 64, and can only range from 512 to 2048 (inclusive)".

This Java-Security issue is documented as a bug here and here.

To workaround this issue you can do as follows:

• First download the following jars from BouncyCastle at https://www.bouncycastle.org/latest_releases.html

  • bcprov-jdk15on-152.jar

  • bcprov-ext-jdk15on-152.jar

• Copy those jars to your ${JAVA_HOME}/jre/lib/ext/ folder
• Edit the ${JAVA_HOME}/jre/lib/security/java.security properties file
  • Add the JCE provider you’ve just downloaded
    
    • Search for security.provider in the configuration and add the BouncyCastleProvider as the second provider
      

After the changes your configuration should look like this:

security.provider.1=sun.security.provider.Sun
security.provider.2=org.bouncycastle.jce.provider.BouncyCastleProvider
security.provider.3=sun.security.rsa.SunRsaSign
security.provider.4=sun.security.ec.SunEC
security.provider.5=com.sun.net.ssl.internal.ssl.Provider
security.provider.6=com.sun.crypto.provider.SunJCE
security.provider.7=sun.security.jgss.SunProvider
security.provider.8=com.sun.security.sasl.Provider
security.provider.9=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.10=sun.security.smartcardio.SunPCSC