It’s been a while between posts and it hasn’t been for lack of stuff to write about. Just the usually frenetic activity that goes with Q4 and the end-of-year holiday period.
It’s also been a while since I wrote Configuring Enterprise CLM Reverse Proxies, Part 3: WebSphere and IHS Plugin method and contributed to Configuring Enterprise CLM Reverse Proxies: WebSphere and IHS Plugin method Separating JTS and CCM where the JTS and CCM were originally deployed using different ports. Websphere and CLM have moved on since then : Websphere Application Server is now up to version 8.5 and CLM is at 4.0.1. In general the principles and processes documented in both those articles are still valid but the interfaces used to execute them have changed somewhat. So without going into all the details here’s a quick and dirty update focusing on getting IHS to front WAS when the CLM apps are deployed in an Enterprise topology.
One way to do this is using the GUI tools that Websphere provides: the Web Server Plug-ins Configuration Tool and the Admin console. The Admin Console is nothing new but the Configuration Tool replaces the “Webserver Plugins Installation Wizard” from 7.x and separates the installation of the plugin binaries (now done through IBM Installation Manager) from the configuration of the plugin to support application servers. The process is well documented at Installing and configuring web server plug-ins and is very straightforward so I won’t bother repeating the steps here.
What is interesting though is working out how to repeat this process more than once. In other words getting the same IHS server to front multiple remote app server profiles. Looking through the Installing and configuring web server plug-ins topic, at first glance it appears that this scenario isn’t even considered. Visually here are the different topologies for which procedures are documented:
The astute reader (or experienced WAS admin) will notice that I’ve ignored the topologies that use the Network Deployment edition of WAS. I’m assuming here (as I did in the Jazz.net articles) that we’re using standalone Base WAS profiles.
What we want to achieve is this:
There is a clue hidden in the Infocentre that pointed me in the right direction : the statement in Configuring a web server and an application server on separate machines (remote) :
- Select the profile to configure with the current web server plug-in, and click Next.This panel does not display if you selected the remote scenario in the previous step.
It certainly threw me for a bit. The whole topic is on configuring a web server that isn’t co-located with the app server (ie. selecting Remote in the wizard) so why throw this line in at all? I had to assume that there is a way to do this.
Creating the configuration for the first app server went according to plan. However if I just repeated the procedure in Configuring a web server and an application server on separate machines (remote) for the second app server, the wizard balked when it found that the httpd.conf already had plug-in entries.
To get around this I:
- made a copy of the existing plugin-cfg.xml which had the entries from the first app server
- ran the previously generated manual web server definition script on the second app server changing the parameters to suit
- generated and propagated the plugin-cfg.xml from the admin console on the second app-server to the web server machine
- used the pluginCfgMerge tool (I had to do this manually in v7 until Fix Pack 17 came out) to merge the newly generated plugin entries with the ones from the first app server
- popped the merged plugin-cfg.xml into the appropriate location
and I had a single web server fronting two (or more) app servers.
If you don’t or can’t use the GUI, you can do all the above using the command line. Simply use the WCT Command line utility instead of the WCT GUI, GenPluginCfg instead of the Admin Console, and copy across (ftp, rsync, WinSCP) the generated plugin-cfg.xml.