7 Install Automation Modules

To install automation modules, you must start the Application Configuration Console Server, then start the Client and log in as a member of the Administrators group.

7.1 Prerequisites

The WebSphere and WebLogic automation modules require additional software to be installed on the Core Server host system, usually before you install the automation module:

• For the WebSphere Automation Module, the WebSphere Deployment Manager must be installed on the same machine as the Core Server. It does not need to be running, but the software must be installed so that the automation module commands can run WSAdmin actions to make changes to WebSphere configurations. Make note of the Deployment Manager installation directory, because you will need to enter it for some commands.

• For the WebLogic Automation Module, the WebLogic Server software must be installed on the same machine as the Core Server. It does not need to be running, but the software must be installed so that the automation module commands can run WLST actions to make changes to WebLogic configurations. Make note of the WebLogic Server installation directory, because you will need to enter it for some commands.

7.2 Installation

To install an automation module, proceed as follows:

1. Copy the .jar file for the automation module to the Core Server host system.

2. In the Client, select Admin > Install Extension in the menu bar.

   The Install Extension dialog opens.

3. Select automation as the extension type.

4. Click Browse to locate the .jar file in the file system.

5. Click OK to install the automation module.

Some automation modules prompt for additional information during installation.

The automation module features are available immediately after installation. You do not need to restart the Application Configuration Console Server or Clients.

Note:

If you install an automation module after redeploying a secondary server, you have to port the AM installation to the secondary server. See Section D.5, "Redeployment and Automation Modules," for details.

7.3 Configuring WebSphere for SSL Authentication

This section describes a process for securing communication between wsadmin as run by the Application Configuration Console Client and the WebSphere Deployment Manager. The mechanism you will put in place enforces authentication between these components using SSL certificates. WebSphere ships with a repertoire of SSL key files that are preconfigured to support this authentication. These dummy key files, located in the \etc directory of your WAS installation, are as follows:

DummyServerKeyFile.jks
DummyServerTrustFile.jks
DummyClientKeyFile.jks
DummyClientTrustFile.jks

If you choose to create your own keystores, remember that the client and server trust files must each contain both the client and server keys. Go to the following URL for more information:

http://www.redbooks.ibm.com/redbooks/SG246573/wwhelp/wwhimpl/java/html/wwhelp.htm

7.3.1 Enable Global Security

All security checks, including SSL authentication, are disabled until you enable global security. So this is the first step to implementing an SSL solution.

1. Open the administrative console.

2. Select Security > User Registries > Local OS.

   Note:

   In a production environment, you would typically select LDAP or Custom in Step 2 to implement deeper role-based security.

3. In the Configuration tab, enter the Server User ID and Server User Password in the text boxes provided. These are valid credentials in the local OS where the Deployment Manager executes. On Windows, use Administrator or a local user with administrative privileges. On Linux, use the same user as the Deployment Manager (for example, root/ wasuser).

4. Click Apply to save these settings

5. Select Security > Authentication Mechanism > LPTA.

6. In the Configuration tab, create a new password and confirm it. This password is used to generate the LPTA keys. This is a requirement to enable global security. LPTA keys are used in trust association for reverse proxies and SSO configurations.

7. Click Apply to save these settings.

8. Select Security > Global Security.

9. In the Configuration tab, select the Enabled check box. Verify that the other settings are appropriate.

10. Click OK to save the configuration.

If you federated any nodes, you may want to synchronize these changes on the federated nodes accordingly. You will also need to restart the Deployment Manager.

7.3.2 Configure the Deployment Manager

After restarting the Deployment Manager, log in using the user name and password specified in Step 3 under Section 7.3.1, "Enable Global Security." Open the administrative console. Notice that you must now use the https protocol. If you use the old (http) URL, global security redirects you by forcing the server to use the DefaultSSLSettings for the Deployment Manager's http transport, as specified in the SSL Configuration Repository.

Now connect to the server from the wsadmin client using the user name and password specified in Step 3, as follows:

wsadmin -username serveruser -password serveruserpassword

Ensure that you can connect to the Deployment Manager using this syntax, before proceeding.

1. In the administrative console, select Security > Authentication Protocol > CSIv2 Inbound Authentication.

2. Set Basic Authentication to Never.

3. Set Client Certificate Authentication to Required.

4. Click OK to save these settings.

This makes the server force clients to authenticate using the SSL certificates specified in the SSL repertoire (DefaultSSLSettings) and to disallow basic authentication (user name and password).

7.3.3 Configure the Client

To complete configuration of the client, modify the soap.client.props file so that you will not have to pass the user name and password to wsadmin on the command line. The file is located in the properties folder of your WebSphere installation, for example:

C:\WebSphere\DeploymentManager\properties\soap.client.props

Add the user name and password specified in Step 3, underSection 7.3.1, "Enable Global Security," to the following lines:

com.ibm.SOAP.securityEnabled=true

#JMX SOAP connector identity
com.ibm.SOAP.loginUserid=serveruser
com.ibm.SOAP.loginPassword=serveruserpassword

If you want to encrypt the password, use the PropFilePasswordEncoder utility. See the instructions at the top of the soap.client.props file.

Note that if you have federated any nodes in the Deployment Manager, you may need to restart the node manager. If you synchronized the changes on your federated nodes, you will also need to make the same changes as above, to the the soap.client.props file in your application server installation.

7.4 Preserving Configuration Changes

If you reinstall an automation module, the installer checks for changes to certain configuration files that you are allowed to edit. If the installer detects differences, it displays a dialog warning that differences exist between the version that was there and the version just installed. Users often customize the save specification registry, for example, to aid in formulating meaningful comparisons. If you made changes to the wl9_save_spec_registry.xml file, the installer notifies you with a message to that effect.

You can compare the installed version to the version that you had edited to decide if you want to retain your changes.

1. In the Navigator view, locate the saveSpecRegistry file (wl9_save_spec_registry.xml):

   System Configuration > Automation Modules > automation#weblogic9AM > Resource View

2. Open the file in the Editor area and click the Versions tab.

3. Select the last two versions (post- and pre-installation).

4. Right-click and select Compare Properties to see the differences.

5. Preserve any changes you want to retain by merging your edits into the new file.

During a reinstallation, differences if any are typically detected in the saveSpecRegistry file, and less frequently, in the viewSpecRegistry file.