Managing Websphere Plugin Config Files

In some recent customers we’ve had to install various IBM CLM components on different servers to balance workload for a large user base. When doing this, you need to route traffic through a proxy HTTP server. We’ve touched on why you need to use an HTTP server before, and remain adamant about it. IBM also strongly encourages as well. The following process steps are barely documented in any IBM literature, and you have to dig to find it. Hopefully this will make it easy for you admins out there.

Let’s take a sample Jazz architecture:

In the example above (a typical setup for customers using Rational Team Concert IBM Engineering Workflow Management for enterprise source code management on z/OS), we have a three Jazz servers (in purple):

• JTS – The Jazz Team Server
• CCM – The Change and Configuration Management app (EWM/RTC).
• A reporting server for DCC (Data Collection Component) and RS (Jazz Reporting Services)

If you install these apps on three servers without using an HTTP server to front end them, you will have to re-authenticate with each server every time the host name of the URL changes.

To make configure the WebSphere plugin, you need to get the plugin-cfg.xml file that is generated when the Jazz server is first started. This is typically written to <JazzServerHome>/server/logs/state/plugin-cfg.xml. However, when you have three of them, you have to merge them together so the HTTP server knows to route CCM traffic to the CCM server, and JTS traffic to the JTS server and so forth. This can be done using the pluginCfgMerge tool that comes with WebSphere Application Server (WAS). Note that WAS is bundled with the Jazz server tools in Passport Advantage, although we strongly recommend you only run it on WebSphere Liberty, which comes out of the box and is much easier to configure. You might have to install WAS temporarily just to use this tool if needed. The tool is found in the WebSphere/AppServer/bin/pluginCfgMerge.bat(sh), and takes the commands:

pluginCfgMerge.sh /home/kenny/plugin-ccm.xml /home/kenny/plugin-jts.xml /home/kenny/plugin-dcc.xml /home/kenny/plugin-cfg.xml

The last argument is always the file name of the merged plugin configuration, which will be written to the directory you specified (this will be a new file). All the other arguments are the explicit file names of the plugins you need to merge.

Once merged, you’ll still need to make a few changes. First of all, you need to change the location of the plugin directory which may not match the location of the IBM HTTP Server.

<Property Name="PluginInstallRoot" Value="/opt/IBM/WebSphere/Plugins"/>
<! --- It defaults to a Linux file path, even on Windows! Change! -->
<Property Name="PluginInstallRoot" Value="C:\Program Files\IBM\IHS\plugin"/>

Find and replace the root across the board. Then, you must do the same for the location of the SSL/TLS keystores.

<Transport Hostname="dng.strongback.com" Port="9443" Protocol="https">
  <Property Name="keyring" Value="/opt/IBM/WebSphere/Plugins/conf/webserver1/plugin-key.kdb"/>
  <Property Name="stashfile" Value="/opt/IBM/WebSphere/Plugins/conf/webserver1/plugin-key.sth"/>
</Transport>

Since the plugins should be on the same server as the IBM HTTP server, you can change this point to the SSL keystore specified in the httpd.conf file. That way you don’t have to maintain two keystores on the same server. Yes, the HTTP Server and Plugin can use the same keystore. It must be a CMS based keystore.

<Transport Hostname="dng.strongback.com" Port="9443" Protocol="https">
   <Property Name="keyring" Value="/opt/IBM/IHS/ihsserverkey.kdb"/>
   <Property Name="stashfile" Value="/opt/IBM/IHS/ihsserverkey.sth"/       </Transport>

Lastly, you must configure the SSL certificates. This can be a wildcard based certificate. Either acquire one from a known CA, or if your company maintains its own CA, generate it from there. You’ll need to setup the keystore in four locations:

• The IBM HTTP Server conf directory (/opt/IBM/IHS/conf)
• The JTS Server (<JazzTeamServer>/server/liberty/servers/clm/resources/security/ibm-team-ssl.keystore)
• The CCM Server
• The reporting server

The servers must have been started at least once in order for the clm server directory (in bold above) to exist. If you don’t find it, you likely did not start the server. You can use ikeyman to update the keystores using a graphical interface. Note, that on the IHS server, you will need to have a Java runtime as IHS does not come with one. If you don’t have one on the IHS server, you can always create it on one of the Liberty based servers first, then copy it over to the IHS server. We recommend you use a certificate with a common root. If you are using all self-signed certificates, then you will have a really fun (not) time exchanging signer certificates so that they all trust each other with communications.

If by chance this is too complex for you, and you need help, then well….that is what we are in business for. Just Contact Us.