HCL Workload Automation, Version 9.4

Remote UNIX access method

The Remote UNIX access method can be used to designate a non-HCL Workload Automation workstation to run jobs scheduled by HCL Workload Automation. You can use unixrsh or unixssh:
The unixrsh access method
When HCL Workload Automation sends a job to a remote UNIX extended agent, the access method, unixrsh, creates a /tmp/maestro directory on the non-HCL Workload Automation workstation. It then transfers a wrapper script to the directory and runs it. The wrapper then runs the scheduled job. The wrapper is created only once, unless it is deleted, moved, or is outdated.

To run jobs using the unixrsh access method, the job logon users must be given appropriate access on the non-HCL Workload Automation UNIX workstation. To give appropriate access, a .rhost, /etc/host.equiv, or equivalent file must be set up on the workstation. On extended agents, if opens file dependencies are to be checked, root access must also be permitted. Contact your system administrator for help. For more information about the access method, examine the script file <TWA_home>/TWS/methods/unixrsh on an extended agent's host.

The unixssh access method
The unixssh access method works like unixrsh but uses a secure remote shell to connect to the remote host. The files used by this method are:
The unixssh method uses the ssh key. You can generate this keyword with any tools that are compatible with the secure remote shell.
Note: The passphrase must be blank.
The following scenario gives an example of how to set up the method:
You installed a HCL Workload Automation, fault-tolerant agent or dynamic agent with the TWS_user: twsuser. You want to run a remote shell in the remote host "REMOTE_HOST" with the user "guest". The procedure is as follows:
  1. Create the public and private key for the usertwsuser, The following is an example using rsa:
    1. Log on as twsuser
    2. Run
      ssh-keygen -t rsa
    3. When the tool asks for the passphrase, press Enter (leaving the passphrase blank.) The keys are saved as follows:
      Key Location Comment
      Public <TWA_home>/TWS/.ssh/id_rsa.pub  
      Private <TWA_home>/TWS/.ssh/id_rsa Do not send this file!
      Note: Different tools store the key in different places.
  2. At the remote host, perform the following actions:
    1. Telnet to the remote host.
    2. Log on as "guest".
    3. Change to the .ssh directory in the user home directory, or create it if it does not exist (the directory permissions must be adequate: for example, 700 for the directory and 600 for its contents).
    4. Append the public key you created in step 1 to the authorized_keys file (create the file if it does not exist), using the command:
      cat id_rsa.pub >> authorized_keys
  3. At the fault-tolerant agent or dynamic agent, make the remote host "known" before attempting to let HCL Workload Automation processes use the connection. This action can be achieved in one of two ways:
    • Log on as twsuser and connect to the host using the command:
      ssh -l guest <remote_host_name> ls
      A prompt is displayed saying that the host is not known, and asking permission to access it. Give permission, and the host is added to the list of known hosts.
    • Alternatively, use the ssh documentation to add the remote host to the file of known hosts.