The Remote Command Line Function Component (Remote CLFC) enables command line system calls to be executed on remote machines. The design and implementation uses the RXA toolkit v2.2 to connect to remote machines, execute the commands and return the results. The returned output can then be parsed to be consumed one value at a time and detect any problems with the executed command.
The Remote CLFC has the ability to connect to remote machines using any of the following protocols: RSH, REXEC, SSH, AS400 or Windows. We can select which of the protocols will be used; however, if left to the default value of 'ANY', the FC will attempt to connect to the remote machine using each of the available protocols one-by-one until a successful connection is made.
The RXA libraries used by this FC support interactive SSH sessions only; non-interactive SSH sessions are not supported.
We will need to provide information about the remote machine including hostname, username and password. If the connection is being made using the SSH protocol then we have the option of providing a keystore name and passphrase instead of using a password for authentication.
SSH Connections are typically associated with Linux/UNIX and z/OS hosts. However, by installing Cygwin and the Cygwin openssh package on the Windows target machine the SSH protocol can be used with those targets as well. In addition, z/OS targets can be reached using the SSH protocol also.
The timeout is a measure of the CPU clock time of the Remote CLFC process, not a measure of the actual time elapsed since process initiation. Commands that are not computationally intensive will not timeout in the specified time if they have not reached their computational time limit.
The default value is unchecked.
Some of the parameters configured in the Configuration screen of the Remote CLFC can be provided as Attributes mapped from the work Entry in the Input Map. When present and non-empty, they take precedence over the parameters in the Configuration screen:
In other words, if an attribute called command.line is provided in the input entry object then any command that was entered in the Config Editor will be disregarded. This allows us to call the Remote CLFC repeatedly by other components in the AssemblyLine to perform different commands.
Once the Remote CLFC has executed the command specified by either the command.line attribute or the Command configuration parameter as discussed above, the FC makes the following attributes available for attribute mapping:
The Remote CLFC may be used within an AssemblyLine containing other TDI components such as Connectors and other Function Components. To function correctly, configure the Remote CLFC correctly using the Config Editor. When it is initialized it will establish a connection with the remote machine and then when its perform() method is called (normally when it is reached in the AssemblyLine it is part of), it will execute its command on the target.
Upon completion, the perform() method will return an Entry object containing the three output attributes described above: command.returnCode, command.error and command.out. These attributes will then be available to other TDI components further down in the AssemblyLine.
If we use the FC to perform a command that returns a list of messages in Standard Out such as a directory listing then the Remote CLFC would need to be used in conjunction with other TDI components, like a Parser, in order to extract the individual entries from the command.out String object and process them one at a time.
The target machines must satisfy the following requirements:
To disable Simple File Sharing, we need to start Windows Explorer and click Tools->Folder Options. Select the View tab, scroll through the list of settings until you find Use Simple File Sharing. Remove the check mark next to Use Simple File Sharing, then click Apply and OK.
Windows XP includes a built-in firewall called the Internet Connection Firewall (ICF). By default, ICF is disabled on Windows XP systems, except on Windows XP Service Pack 2 where it is on by default. If either firewall is enabled on a Windows XP target, it will block attempted accesses by Remote Execution and Access. On Service Pack 2, we can select the File and Printer Sharing box in the Exceptions tab of the Windows Firewall configuration to allow access.
The target machine must have remote registry administration enabled (which is the default configuration) in order for Remote Execution and Access to run commands and execute scripts on the target machine.
The default hidden administrative disk shares (such as C$, D$, etc) are required for proper operation of Remote Execution and Access.
To use Remote Execution and Access applications on Cygwin targets, you will need to install up to two additional Cygwin packages that are not part of the default Cygwin installation. From http://cygwin.com, download and install openssh, which is in the net category of Cygwin packages. openssh contains the ssh daemon that is needed to support SSH logins on Cygwin targets. Another package, cygrunsrv, which is in the admin category of packages, provides the ability to run the ssh daemon as a Windows service. If we do not wish to run the ssh daemon as a service, this package is optional.
If connecting to a secure shell service or daemon that is derived from the OpenSSH version of secure shell (such as the secure shell service (sshd) from MKS Toolkit), the protocol version 1 RSA keys must be appended to the hosts's ~/.ssh/authorized_keys file and protocol version 2 RSA and DSA keys to the host's ~/.ssh/authorized_keys2 file where ~/ is the home directory of the account on the remote host.
RXA cannot establish connections with any UNIX target that has all remote access protocols (rsh, rexec, or ssh) disabled.
In all UNIX environments except Solaris, the Bourne shell (sh) is used as the target shell in UNIX environments. On Solaris targets, the Korn shell (ksh) is used instead due to problems encountered with sh.
In order for RXA to communicate with Linux and other SSH targets using password authentication, edit the file /etc/ssh/sshd_config file on target machines and set:
PasswordAuthentication yes (the default is 'no')
After changing this setting, stop and restart the SSH daemon using the following commands:
/etc/init.d/sshd stop /etc/init.d/sshd start
When using the rsh / rexec connection protocol, the TDI Server must be running as a privileged user (root on Unix or a user with Administrator privileges on Windows). The connection will fail if this requirement is not met. The rsh and rexec connection protocols require that the source port be "trusted" (port number less than 1024), however these platforms restrict creation of trusted port connections to privileged users.
For further details on how to configure SSH between the local machine and the target, either using password authentication or a keystore, please refer to the relevant OpenSSH documentation at http://www.openssh.com.
The target TDI Server we run this on should be in ASCII mode as required by the underlying RXA libraries. Refer to "ASCII Mode" in IBM TDI V7.1 Installation and Administrator Guide for more information.
When enabling the AS400 SSL connection option, additional configuration is required for self signed certificates. In this case, the signing certificate must be added to the Java Security CA Certificate store (jre_directory/lib/security/cacerts). Further information can be found here: http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html.
Command line Connector,
z/OS TSO/E Command Line Function Component.