Overriding Liberty server host information
The collectiveMember-1.0 feature enables a server to be managed by the collective controller. Most server host information can be automatically detected. In certain scenarios, however, provide additional host information so the collective controller can establish a connection to the server.
Note: The collectiveController-1.0 feature and its capabilities are available only in WebSphere Application Server Liberty Network Deployment and WebSphere Application Server Liberty for z/OS .
The feature is not available in WebSphere Application Server Liberty, WebSphere Application Server Liberty - Express , or WebSphere Application Server Liberty Core.
If we have a WebSphere Application Server Liberty Network Deployment installation, we can use its collectiveController-1.0 feature to work with collective members from WebSphere Application Server Liberty, WebSphere Application Server Liberty - Express, or WebSphere Application Server Liberty Core installations.
To enable the host information override, add the following element to server.xml:
<hostAuthInfo rpcPort="ssh_port" rpcUser="user_ID" rpcUserPassword="password" rpcUserHome="user_home" rpcHost="host_name" sudoUser="sudo_user" sudoPassword="sudo_user_password" sshPublicKeyPath="public_key_path" sshPrivateKeyPath="private_key_path" sshPrivateKeyPassword="private_key_password" useHostCredentials="true_or_false"/>
- rpcPort
- Port for the RPC mechanism, which is SSH port 22 by default. If the system uses a nonstandard port, set this value accordingly. If this value is not specified, the default value is 22.
- rpcUser
- User ID that the collective controller will use to connect to the server. If the host does not support SSH or using SSH keys is not desired, we can use this parameter to specify an operating system login user. For example, if you log in to the host with the myID user, then we specify rpcUser="myID". If this value is not specified, the default value is System.getProperty("user.name").
- rpcUserPassword
- Password for the specified user ID. For example, if you log in to the host with the myID user and the myPwd password, then we specify rpcUser="myID" and rpcUserPassword="myPwd". If this value is not specified, the server will either generate an SSH key pair or use the SSH key pair for the connection specified using the privateKeyPath and publicKeyPath parameters. If SSH is not installed on the server (such as on a Windows or OS/400 operating system), the password is required.
- rpcUserHome
- Home directory of the user. If this value is not specified, the default value is System.getProperty("user.home"). If rpcUser is specified, we should specify rpcUserHome.
- rpcHost
- Host on which the RPC mechanism is configured to listen. If this value is not specified, the default value is the value of the defaultHostName variable. If the system uses a host other than the defaultHostName, set this value accordingly.
- sudoUser
- If specified, it allows the collective controller to run commands as another, or "sudo", user instead of as the user ID used for the connection. This parameter applies only to servers that have an SSH server installed. This parameter has no default value.
- sudoPassword
- Password for the sudo user specified by the sudoUser parameter. This parameter applies only to servers that have an SSH server installed. This parameter has no default value.
- sshPublicKeyPath
- Path and file name of a user-specified public key file. If this value is not specified, the default is ${server.output.dir}/resources/security/ssh/id_rsa.pub. If the specified file (or default file) does not exist, a new public key file will be generated.
- sshPrivateKeyPath
- Path and file name of a user-specified private key file. If this value is not specified, the default is ${server.output.dir}/resources/security/ssh/id_rsa. If the specified file (or default file) does not exist, a new private key file will be generated.
- sshPrivateKeyPassword
- Password for the private key. This parameter has no default value.
useHostCredentials
This parameter specifies whether collective member server commands inherit RPC credentials from the host. The default is false, requiring the user to specify RPC credentials for the controller to remotely start or stop the member. When set to true, collective member server commands inherit RPC credentials from the host registration and ignore all other RPC credentials in the hostAuthInfo configuration element.
Examples
Scenario 1: Server is on Windows operating system, no SSH is installed
<hostAuthInfo rpcUserPassword="myPassword"/>
Scenario 2: Server has SSH installed, SSH is running on port 2222
<hostAuthInfo rpcPort="2222"/>
Scenario 3: Need to run commands as another user
<hostAuthInfo sudoUser="anotherUser" sudoPassword="anotherPassword"/>
Scenario 4: Server is on a Windows operating system and ssh (e.g. Cygwin) is installed. With the following server configuration, the controller connects the member server with ssh. In this case, the requirement to disable Windows User Account Control (UAC) does not apply. The parameter <user's home directory> is the user default home directory, for example: C:\cygwin\home\bob
<hostAuthInfo rpcUserHome="<user's home directory>" />
Scenario 5: The collective controller and member are on separate hosts, and not on the same host.
To specify that the member inherit RPC credentials from the host, set useHostCredentials to true in server.xml of the member...
- Create, configure, and start a collective controller named myController as shown in step 1 of Configure a Liberty collective.
- Register the host for the member with the collective. The member and the collective controller are on different hosts.
In this scenario, the registerHost command uses the collective controller host hostA.ibm.com with port number 9443, user admin, and password adminpwd. The command registers the member host hostB.ibm.com with the collective, and sets rpcUser to an operating system login user ID for the member host osUser1, and rpcUserPassword to the operating system login password for the user ID for the member host osUser1Pwd.
Run the registerHost command on the collective controller host.
wlp/bin/collective registerHost hostB.ibm.com --host=hostA.ibm.com --port=9443 --user=admin --password=adminpwd --rpcUser=osUser1 --rpcUserPassword=osUser1Pwd
Enter y (yes) when prompted to accept the certificate chain. After registration, the Host hostB.ibm.com successfully registered. message displays. The collective controller host now has the operating system user ID and password of the member host.
- On the member host, create a server named myMember to use as a collective member.
wlp/bin/server create myMember
- Add the myMember server to the collective controller, specifying to use host credentials. In the join command, which is run on the member host, specify --useHostCredentials so the member inherits RPC credentials from the host registration.
wlp/bin/collective join myMember --host=hostA.ibm.com --port=9443 --user=admin --password=adminpwd --keystorePassword=memberKSPassword --useHostCredentials
- Update the member server.xml file as shown in step 2 of Configure a Liberty collective.
Because you specified --useHostCredentials in the join command, the configuration generated for the member server.xml file sets useHostCredentials to true:
<!-- Remote host authentication configuration --> <hostAuthInfo useHostCredentials="true" />
With the --useHostCredentials option, we do not need to specify the operating system user ID and password in the member server.xml file because the member inherits credentials from the host. Later, if the operating system user ID or password of the member server changes, run the updateHost command to change the user ID or password.
Concepts:
Collective architecture
File transfer in a Liberty collective
Collective security
File transfer
Liberty collective troubleshootingTasks:
Set the default host name of a Liberty server
Register host computers with a Liberty collective.Reference:
Example of setting up a JMX routing environment
List of provided MBeans