This guide will explain how to setup and configure an example CLM environment using WebSphere Application Server (WAS), IBM HTTP Server (IHS) and the WAS web server plugins for IHS, such that users will be able to access the various CLM applications simply by changing the context root of a central URL which is processed by IHS. IHS will take care of sending the requests to the appropriate JTS/CCM/QM/RM application servers operating behind the proxy.

Other topics in this series

Configuring the WAS Web Server plugins with WAS 8 and IHS 8

There are two methods used to deploy the WAS Web Server plugins depending on whether IHS and the WAS profiles are local or remote. To demonstrate both methods, we will assume that the JTS, RM application server profiles are co-located with the IHS server (local), with the QM and CCM applications each on their own servers (remote).

We will also configure single sign-on with WAS such that a user only needs to log into one of the products and subsequent access to the other applications will not require re-authentication.
Experienced WAS administrators will be aware that the WAS configuration steps in this guide can be carried out in different ways using "wsadmin" or the WAS Integrated Solutions console.

N.B.Note that all of the setup and configuration documented here MUST be done before running the JTS setup wizard
to ensure that the public URIs are set correctly to the external URIs.

Example server configuration

For the purposes of this article we use three separate servers configured as follows:

Firewalls on the two servers are configured appropriate, allowing access to the internal ports only between the three servers. In other words ports 9443, 9447, 9448, 9449, 8008 are not visible to the outside world

The firewall on Server 1 allows access to port 443 from the outside world

Though the steps here were carried out in a Linux enviroment, their Windows equivalents will work as well.

Procedure

1. Create a key database and self-signed certificate for IHS

In this step we create a CMS keystore database file and a self-signed certificate which are needed to authenticate IHS during an SSL handshake. Note that Self-signed certificates should only be used for test/development scenarios. In production environments use the appropriate organizational certificates provided by a trusted certificate authority. We will later add the WAS certificates to this same keystore database.

Make sure the IHS Server is stopped.
Run the "gsk7cmd" utility (alternatively use the ikeyman GUI) to create a new keystore database (ihskeys.kdb) and password stash file (ihskeys.sth) both of which will be created in the current directory.

In this step we need to first direct IHS to load the SSL support module (mod_ibm_ssl.so) and then direct IHS to listen for secure requests (on port 443 in this example). We also need to point IHS to the key database file (ihskeys.kdb) and password stash file (ihskeys.sth) that were created earlier.
Add (or uncomment) the following lines in httpd.conf, making sure that the values for the KeyFile and SSLStashFile directives match the names (and paths) of the files generated in the previous section:

Repeat the above steps, changing the value of Key File Name as appropriate for each of the CCM(ccmwaskeys.kdb), RM (rmwaskeys.kdb)and QM profiles (qmwaskeys.kdb). Note that since the CCM and QM WAS profiles are not co-located with the IHS server, we first need to copy "qmwaskeys.kdb" and "ccmwaskeys.kdb" to the IHS server.

4. Force WAS to honor host headers

To avoid a problem with Jazz redirecting to :9443 ports on the IHS Server we need to set a couple of Web Container custom properties in WAS. Failure to set these properties can also result in the "Finalize" button in the last step of the JTS setup wizard to be greyed out.

Login to the WAS Integration Solutions Console for each WAS profile and navigate to Servers -> Server Types -> WebSphere application servers -> server1

5. Single Sign-On (SSO) with WAS

To allow sharing of authentication tokens between the different WAS profiles, we need to enable the SSO property in each WAS profile, export the LTPA (Lightweight Third Party Authentication) keys from one profile and import them into each of the other profiles.

5.1Setup JTS profile for SSO and export keys

Login to the WAS Integration Solutions Console for the JTS WAS profile.

Navigate to Global Security -> Web and SIP Security -> Single sign-on (SSO) and set the following properties:EnabledDomain name: example.orgRequires SSL

Repeat the above steps for each of the CCM and QM profiles, copying the jtsssokey file to the <ccmwasprofileroot> and <qmwasprofileroot> respectively.

6. Configure WAS IHS Plug-in for JTS (Server 1)

We will now use the WAS Web Server Plug-ins Configuration Tool to configure IHS such that all requests to https://clm.example.org/jts are redirected to https://clm.example.org:9447/jts.
As noted before, for the purposes of this example,the WAS profile to which the JTS application has been deployed is co-located on the same server as IHS. We therefore use the procedure described in Configuring a Web server and an application server profile on the same machine.

The following steps are performed on "Server 1' which hosts both IHS and the WAS profile hosting the JTS, Admin and CLMHelp applications.

6.1Generate the plugin configuration file

Stop the JTS WAS profile.

Stop IHS.

Launch the Plug-ins Configuration Tool.

Click Add....

Enter "webserver1" for Name and "/Plugins" for Location. Click Finish.

Select the profile that the JTS application is deployed to and click Next.

Click Configure on the Plug-in Configuration Summary panel. The wizard begins configuring the Web server and the application server. Note the path of the Plug-in configuration file, which we will use later.

Verify the success on the Plug-in Configuration Summary panel and click Finish to exit the wizard.

6.2Modify keyring and stashfile properties

Open the generated plugin configuration file (C:\IBM\HTTPServer\Plugins\config\webserver1\plugin-cfg.xml in this case) and modify the keyring and stashfile properties of the HTTPS Transport attributes to use the IHS keyfile and SSL Stashfile.

First verify that you can access the JTS page using the "internal" URL: https://clm.example.org:9447/jts. Next verify that the IHS URL https://clm.example.org/jts displays the same page.

7. Configure WAS IHS Plug-in for RM application (Server 1)

As noted before, for the purposes of this example, the WAS profile to which the RM application has been deployed is co-located on the same server as IHS and the JTS profile.
This is similar to the procedure used for the JTS with the exception that we will need to merge some of the content from the plugin configuration file generated for the RM profile into the plugin configuration file already created for the JTS.

The following steps are performed on "Server 1' which hosts both IHS and the WAS profiles hosting the RM and JTS applications.

7.1 Generate plugin configuration file

Stop the RM WAS profile.

Stop IHS.

Copy the previously generated <path to plugin installdir>/config/webserver1/plugin-cfg.xml to another file such as <path to plugin installdir>/config/webserver/jts-plugin-cfg.xml.

Launch the Plug-ins Configuration Tool on server1. Since the httpd file for the IHS server already contains the plugin entries for the JTS, the Plug-in configuration tool will balk at the Web Server Configuration File Selection pane (see Step 7 in Section 6.1). To get around this we first delete the previous configration (making sure we copied the config file in the previous step).

Once the reference has been deleted , click Create and follow the same process as before

choose the same httpd.conf file

do not configure the HTTP Administration server as it has already been done

When the wizard completes, modify the keyring and stashfile properties as in Section 6.4, and copy the newly generated <path to plugin installdir>/config/webserver1/plugin-cfg.xml to <path to plugin installdir>/config/webserver/rm-plugin-cfg.xml

7.2 Merge plugin directives

We now need to merge in the appropriate sections from the plugin configuration generated for the RM profile into the plugin configuration generated for the JTS using the pluginCfgMerge tool.

Restart IHS.
First verify that you can still access the JTS page using the IHS URL https://clm.example.org/jts.
Next, verify that you can access the RM page using the "internal" URL: https://clm.example.org:9448/rm. Next verify that the IHS URL https://clm.example.org/rm displays the same page.

8. Configure WAS IHS Plug-in for the QM application (Server 2)

We will now use the WAS Web Server Plug-ins Configuration Tool to configure IHS such that all requests to https://clm.example.org/qm are redirected to https://qmserver01.example.org:9443/qm and. As noted before, for the purposes of this example, the WAS profile to which the QM application has been deployed is not co-located on the same server as IHS. We therefore use the procedure in Configuring a Web server and an application server on separate machines (remote).

The following steps are performed on "Server 1' which hosts IHS.

8.1 Generate manual plugin configuration script

Stop IHS.

Copy the previously generated <path to plugin installdir>/config/webserver/plugin-cfg.xml to another file such as <path to plugin installdir>/config/webserver/rm-jts-plugin-cfg.xml.

Launch the Plug-ins Configuration Tool on server1. Again we first remove the reference to the previous file from the Configuration tool.

Once the reference has been deleted , click Create and follow the same process as before

choose the same httpd.conf file

do not configure the HTTP Administration server as it has already been done

specify "webserver1" for the web server definition

choose (Remote) application server and enter the host name of the QM Server

Once the installation completes, the wizard generates a manual configuration script which must be run on the QM server. The path to the script is displayed in the installation summary panel.

The following steps are performed on "Server 2' which hosts the WAS profile hosting the QM application.

8.2 Run manual configuration script on Server 2

We now copy the manual configuration script generated above to the /bin directory on Server 2.
If the WAS profile hosting the QM application isn't already running start it.
Run the configurewebserver1.sh script.
If it runs successfully, a web server definition will have been created in the QM application server profile.

8.3 Propagate the QM plugin configuration file to the IHS server

Login to the WAS Integration Solutions Console for the QM WAS profile.

Navigate to Servers -> Server Types -> Web Servers

Select "webserver_qm" and click "Generate Plug-in".

Once the plugin file has been generated, select "webserver1" and click "Propagate Plug-in".

If successful WAS will generate a message such as:

InformationPLGC0048I: The propagation of the plug-in configuration file is complete for the Web server.
qm.clm.example.org-node.webserver1.

Note the path displayed for the generated plugin configuration file on Server 1 which is the IHS Server.

The following steps are performed on "Server1' which hosts IHS.

8.4 Merge plugin directives

We now need to merge in the appropriate sections from the plugin configuration generated for the QM profile into the plugin configuration that contains the merged directives for the JTS and RM profiles.
Remember that in step 8.1 we copied the /config/webserver/plugin-cfg.xml to /config/webserver/rm-jts-plugin-cfg.xml. Run the pluginCfgMerge tool to merge the contents of the new plugin-cfg.xml propagated from the QM server.

Restart IHS.
First verify that you can still access the JTS and RM pages using the IHS URL https://clm.example.org/jts and https://clm.example.org:9448/rm.
Next verify that you can access the QM page using the "internal" URL: https://qmserver01.example.org:9443/qm. and then verify that the IHS URL https://clm.example.org/qm displays the same page.
Copy the <path to plugin installdir>/config/webserver/plugin-cfg.xml to another file such as <path to plugin installdir>/config/webserver/rm-jts-qm-plugin-cfg.xml.

9. Configure WAS IHS Plug-in for the CCM application (Server 3)

We will now configure IHS such that all requests to https://clm.example.org/ccm are redirected to https://ccmserver01.example.org:9443/ccm. As noted before, for the purposes of this example, the WAS profile to which the QM application has been deployed is not co-located on the same server as IHS. We therefore use the procedure in Configuring a Web server and an application server on separate machines (remote). However we have already generated the manual configuration script for the QM profile in Section 7. Since the script is designed to accept the WAS profile name, administrative username and password as parameters we can simply reuse it.

9.1 Run manual configuration script generated for QM on Server 3

The following steps are performed on "Server3' which hosts the CCM profile.

Copy the previously generated cofigurewebserver1.sh from Server 1 to the <app_server_root>/bin directory.

Run the script:

wasinstall_root/bin/cofigurewebserver1.sh CCM username password

If it runs successfully, a web server definition will have been created in the CCM application server profile.

9.2 Propagate the CCM plugin configuration file to the IHS server

Login to the WAS Integration Solutions Console for the CCM WAS profile.

Navigate to Servers -> Server Types -> Web Servers

Select "webserver1" and click "Generate Plug-in".

Once the plugin file has been generated, select "webserver1" and click "Propagate Plug-in". If successful, WAS will generate a message such as:

InformationPLGC0048I: The propagation of the plug-in configuration file is complete for the Web server.
ccm.clm.example.org-node.webserver1.

The following steps are performed on "Server1' which hosts IHS.

9.3 Merge plugin directives

We now need to merge in the appropriate sections from the plugin configuration generated for the CCM profile into the plugin configuration that contains the merged directives for the JTS, RM and QM profiles.
Remember that in step 8.5 we copied <path to plugin installdir>/config/webserver/plugin-cfg.xml to %3cpath%20to%20plugin%20installdir%3e/config/webserver/rm-jts-qm-plugin-cfg.xml%20type%3d%22entity. Run the pluginCfgMerge tool to merge the contents of the new plugin-cfg.xml propagated from the CCM server.

Restart IHS.
First verify that you can still access the JTS, QM and RM pages using the IHS URL https://clm.example.org/jts, https://clm.example.org/rm and https://clm.example.org/qm.
Next verify that you can access the CCM page using the "internal" URL: https://ccmserver01.example.org:9449/ccm. and then verify that the IHS URL https://clm.example.org/ccm displays the same page.

Running the JTS setup wizard

Now that we have URLs that are server agnostic we can run the JTS setup wizard and use these URLs when registering the applications. Here are the discovery URLs that will be used:
Requirements Management: https://clm.example.org/rm/scr
Quality Management: https://clm.example.org/qm/scr
Change and Configuration Management: https://clm.example.org/ccm/scr
Lifecycle Project Administration: https://clm.example.org/admin/scr

Moving an application

Now suppose that we wish to redeploy the RM application to it's own separate server (for example, rmserver01.example.org) without affecting users' ability to access it through https://clm.example.org/rm. Here is a summary of the steps, previously detailed, to be repeated:

Deploy the RM application to WAS on rmserver01.example.org

Follow the instructions in the CLM Infocenter, making sure to copy over the directory that contains the indexes and configuration files, located at /server/conf/rm for the RM application from the original server.

Setup SSL Handshake Between WAS profile on rmserver01.example.org and IHS on clm.example.org

Follow the procedure detailed in Setup SSL Handshake between the WAS profiles and IHS, creating a new "rmwaskeys.kdb" keystore from the new WAS profile, copying this keystore over to the IHS server and using gscmd to import it into the IHS keystore (ihskeys.kdb).