Setting up RXA for Liberty collective operations

Liberty collective controllers use the Tivoli® Remote Execution and Access (RXA) toolkit to perform selected operations on collective members. You can use RXA to remotely start and stop servers, including servers on your local computer.

Procedure

Set up Linux, UNIX or z/OS machines

Install and enable SSH on your machine. For Linux and UNIX machines, ensure that the configuration is set according to the following instructions. For z/OS® machines, consult the following instructions for guidance.

To enable SSH, configure OpenSSH 3.6.1, OpenSSH 4.7 (on AIX), or Oracle SSH 1.1 so that it supports RXA connections. OpenSSH 3.7.1 or later contains security enhancements not available in earlier releases and is recommended.

Avoid trouble: OpenSSH Version 4.7.0.5302 for IBM® AIX® Version 5.3 is not compatible with RXA Version 2.3. If machines are running AIX Version 5.3 with OpenSSH Version 4.7.0.5302 installed, file transfers might not complete. To avoid this problem, revert from OpenSSH Version 4.7.0.5302 to Version 4.7.0.5301.
Using Secure Shell (SSH) protocol

RXA does not supply SSH code for UNIX operating systems. You must ensure that SSH is installed and enabled on all machines that include collective members.

In all UNIX environments except Solaris, the Bourne shell (sh) is used. On Solaris machines, the Korn shell (ksh) is used instead due to problems encountered with the Bourne shell (sh).

If you need to use password-based authentication for SSH communications, edit the /etc/ssh/sshd_config file on each machine that includes one or more collective members. Set the PasswordAuthentication property to yes. For example:
PasswordAuthentication yes
The default value for the PasswordAuthentication property is no.
After you change this setting, stop and restart the SSH daemon by using the following commands:
/etc/init.d/sshd stop
/etc/init.d/sshd start 

If remote access to a member machine fails, ensure that you can ssh from the controller machine to the member machine that uses the same authentication method that is used when you set up the collective. If ssh is successful and you still have problems with remote access, also ensure that you can scp or sftp from the controller machine to the member. It's possible that scp or sftp can fail even when ssh keys are set up correctly. For example, sftp might fail with the message 'Received message too long' if a .bashrc script on the remote machine prints a message. For remote access to be successful, you must either remove the message or change the sftp subsystem in the sshd_config file to use the internal_sftp subsystem.

What to do next

If you modify the server.xml of a managed server, manually start the server so that it publishes the new data to the controller.

After you enable RXA, test the host configuration and verify RXA connectivity.

[18.0.0.1 and later]You can use the testConnection command to verify connectivity. The command validates RXA connectivity between the controller and the host where the member resides.

wlp/bin/collective testConnection hostName --host=controllerHost
--port=controllerHTTPSPort --user=controllerAdmin 
--password=controllerAdminPassword--autoAcceptCertificates
[18.0.0.1 and later]Alternatively, use the simplified --controller option to provide the controller specific information
wlp/bin/collective testConnection hostName 
--controller=user[:password]@host:HttpsPort
--autoAcceptCertificates

Icon that indicates the type of topic Task topic

File name: twlp_set_rxa.html