Edit
Attach
P
rintable
r12 - 2013-11-12 - 13:15:24 - Main.cglockner
You are here:
TWiki
>
Deployment Web
>
DeploymentInstallingUpgradingAndMigrating
>
InstallProxyServers
>
ConfigureCLMEnterpriseReverseProxy
<div id="header-title" style="padding: 10px 15px; border-width:1px; border-style:solid; border-color:#FFD28C; background-image: url(<nop>https://jazz.net/wiki/pub/Deployment/WebPreferences/TLASE.jpg); background-size: cover; font-size:120%"> ---+!! <img src="https://jazz.net/wiki/pub/Deployment/WebPreferences/new.png" alt="new.png" width="50" height="50" align="right"> Configuring Enterprise CLM Reverse Proxies: !WebSphere 8 and IHS 8 %DKGRAY% Authors: Main.SudhakarFrederick <br> Build basis: Rational solution for Collaborative Lifecycle Management 4.0.1, Websphere Application Server (Base) 8.0.0.2, IBM HTTP Server 8.0.0.2 %ENDCOLOR%</div></sticky> <!-- Page contents top of page on right hand side in box --> <sticky><div style="float:right; border-width:1px; border-style:solid; border-color:#DFDFDF; background-color:#F6F6F6; margin:0 0 15px 15px; padding: 0 15px 0 15px;"> %TOC{title="Page contents"}% </div></sticky> <sticky><div style="margin:15px;"></sticky> This guide will explain how to setup and configure an example CLM environment using [[http://www-01.ibm.com/software/webservers/appserv/was/][WebSphere Application Server]] (WAS), [[http://www-01.ibm.com/software/webservers/httpservers/][IBM HTTP Server]] (IHS) and the [[http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/twsv_plugin.html][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. Note that [[ConfigureCLMEnterpriseReverseProxywithWAS7][Configuring Enterprise CLM Reverse Proxies: WebSphere 7 and IHS 7]] covers this same ground with Websphere 7 and IHS 7. There have been some changes in the installation and configuration processes in !Websphere 8 and IHS 8 which are covered here. ---++ Other topics in this series * [[UnderstandingReverseProxy][Understanding reverse proxy]] * [[ConfigureCLMEnterpriseReverseProxyWithApache][Configuring Enterprise CLM Reverse Proxies: Apache and mod_proxy]] * [[ConfiguringEnterpriseCLMReverseProxiesWebSphere85NDProxy][Configuring Enterprise CLM Reverse Proxies: WebSphere 8.5 ND Proxy]] ---++ 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 [[http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/tins_webplugins_local.html][local]] or [[http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/tins_webplugins_remotesa.html][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). The user accessible Public URIs (and the actual servers they redirect to) will be:%BR% !https://clm.example.org/qm (!https://qmserver01.example.org:9443/qm)%BR% !https://clm.example.org/jts (!https://clm.example.org:9447/jts)%BR% !https://clm.example.org/rm (!https://clm.example.org:9448/rm)%BR% !https://clm.example.org/ccm (!https://ccmserver01.example.org:9449/ccm) 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.%BR% 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. <p class="message-area message-warn"> <b>N.B.</b> <span style="font-weight: bold;">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.</span> </p> ---++++ Example server configuration For the purposes of this article we use three separate servers configured as follows: * Server 1 (Host-name: clm.example.org): * IBM HTTP Server already installed, listening on port 80 with the IHS Administrative console on port 8008 * WAS profile with JTS, Admin and CLMHelp applications deployed (HTTPS port : 9447) * WAS profile with RM WAR deployed (HTTPS port : 9448) * Server 2 (Host-name: qmserver01.example.org): * WAS profile hosting QM (HTTPS port: 9443) * Server 3 (Host-name:ccmserver01.example.org): * WAS profile hosting CCM (HTTPS port: 9449) ---++++ Prerequisites and assumptions * Base Websphere Application Server profiles are used (ie. not Websphere ND, which is covered by [[https://jazz.net/library/article/1123][this article]]) * Use the instructions provided in the [[https://pic.dhe.ibm.com/infocenter/clmhelp/v4r0m1/index.jsp][CLM Infocenter]] to deploy the different applications * Each of the WAS profiles is configured to use LDAP domain *"example.org"* for authentication * A separate database server is available * The [[http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/tins_installation_plugins.html][WebSphere Plug-ins for WebSphere® Application Server Version 8.0 have been installed]] on server 1 to <plugin install dir> * Administrative console access to each WAS profile is available * [[http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/topic/com.ibm.websphere.ihs.doc/info/ihs/ihs/tihs_protconfigas.html][Username and password available for access to IHS Administrative console]] * 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 #CreateKey ---+++1. Create a key database and self-signed certificate for IHS In this step we create a [[http://tools.ietf.org/html/rfc3852][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 [[http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/topic/com.ibm.websphere.ihs.doc/info/ihs/ihs/cihs_ikeycmdline.html]["gsk7cmd"]] utility (alternatively use the [[http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/topic/com.ibm.websphere.ihs.doc/info/ihs/ihs/welc_ikeymangui.html][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. <verbatim>gskcmd -keydb -create -db ihskeys.kdb -pw secret -expire 365 -stash -type cms</verbatim> Create a self-signed certificate and add it to the the new keystore db <verbatim>gskcmd -cert -create -db ihskeys.kdb -label clm.example.org -expire 365 -dn "CN=clm.example.org" -default_cert yes -pw secret</verbatim> ---+++2. Enable SSL directives within the IBM HTTP Server's configuration file (httpd.conf) 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: <verbatim>LoadModule ibm_ssl_module modules/mod_ibm_ssl.so Listen 0.0.0.0:443 ## Uncomment for IPv6 support: #Listen [::]:443 <VirtualHost *:443> SSLEnable </VirtualHost> KeyFile /opt/IBM/HTTPServer/bin/ihskeys.kdb SSLStashFile /opt/IBM/HTTPServer/bin/ihskeys.sth SSLDisable </verbatim> #SetupSSLHandshake ---+++3. Setup SSL Handshake between the WAS profiles and IHS Now we need to proxy SSL requests from IHS to the WAS servers by exporting the WAS keys and importing them into the IHS keystore database previously created. 1. Login to the WAS Integration Solutions Console for the JTS profile. 1. Navigate to *Security -> SSL certificate and key management -> Key Stores and Certificates*, create a new Key store with the following values:%BR% *Name:* jtswaskeys%BR% *Path:* jtswaskeys.kdb%BR% *Type:* CMSKS%BR% *Password:* secret%BR% <img src="%ATTACHURLPATH%/createjtswaskeys.png" alt="createjtswaskeys.png" width="850" height="583" />%BR% 1. Click *OK* then *Save*. This will create the file %ENCODE{ "<jtswasprofileroot>/etc/jtswaskeys.kdb" type="entity" }%. 1. Navigate to *SSL certificate and key management -> Key stores and certificates -> !NodeDefaultKeyStore* 1. Choose "*Personal certificates*" from the right sidebar 1. Check the default certificate and click *Export*. 1. Specify the following values in the Export certificates pane:%BR% *Key Store Password:* !WebAS (unless this has been changed)%BR% Select the *"Key Store File"* radio button%BR% *Key File Name:* %ENCODE{ "<jtswasprofileroot>/etc/jtswaskeys.kdb" type="entity" }%%BR% *Type:* CMSKS%BR% *Password:* secret%BR% <img src="%ATTACHURLPATH%/exportjtswaskeys.png" alt="exportjtswaskeys.png" width="848" height="479" />%BR% 1. Click *OK*. This will export the default WAS personal certificates into ==<jtswasprofileroot>/etc/jtswaskeys.kdb==. 1. Add the certificates from the exported keystore (jtswaskeys.kdb) into the previously created IHS keystore(ihskeys.kdb). <verbatim>gskcmd -cert -import -db <jtswasprofileroot>/etc/jtswaskeys.kdb -pw secret -type cms -target ihskeys.kdb -target_pw secret -target_type cms -label default -new_label default_jtswas</verbatim>%BR% <p class="message-area message-warn"> <span style="font-weight: bold;">Repeat the above steps, changing the value of Key File Name as appropriate for each of the CCM</span><span style="font-weight: bold;">(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.</span></p> #ForceWAS ---+++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. 1. Login to the WAS Integration Solutions Console for each WAS profile and navigate to *Servers -> Server Types -> !WebSphere application servers -> server1* 1. Under *"Container Settings"* expand Web Container Settings. Choose *"Web Container"*.%BR% <img src="%ATTACHURLPATH%/selectwebcontainer.png" alt="selectwebcontainer.png" width="837" height="628" />%BR% 1. Add the following custom properties: <verbatim>trusthostheaderport = true com.ibm.ws.webcontainer.extracthostheaderport = true</verbatim> <img src="%ATTACHURLPATH%/webcontainercustom.png" alt="webcontainercustom.png" width="851" height="300" /> #SSOWithWAS ---+++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 1. Login to the WAS Integration Solutions Console for the JTS WAS profile. 1. Navigate to *Global Security -> Web and SIP Security -> Single sign-on (SSO)* and set the following properties:%BR% *Enabled* %BR% *Domain name*: example.org%BR% *Requires SSL* %BR% <img src="%ATTACHURLPATH%/websipssosetting.png" alt="websipssosetting.png" width="491" height="432" />%BR% 1. Click *OK* then *Save*. 1. Navigate to *Global Security*, select *LTPA* and enter the following values:%BR% *Password:* secret%BR% *Confirm Password:* secret %BR% *Fully qualified key file name:* %ENCODE{"<jtswasprofileroot>/etc/jtsssokey" type="entity"}%%BR% 1. Click *Export keys*.%BR% <img src="%ATTACHURLPATH%/LTPAexport.png" alt="LTPAexport.png" width="800" height="575" /> 1. Click *OK* then *Save*. This will create a file %ENCODE{"<jtswasprofileroot>/etc/jtsssokey" type="entity"}% which we will import into the other WAS profiles. 1. Stop and restart the JTS profile. ---++++!!5.2Setup RM, QM and CCM for SSO and import JTS keys 1. Copy the jtssokey generated above from %ENCODE{"<jtswasprofileroot>/etc" type="entity"}% to %ENCODE{"<rmwasprofileroot>/etc/jtsssokey" type="entity"}% 1. Login to the WAS Integration Solutions Console for the *RM* WAS profile. 1. Navigate to *Global Security -> Web and SIP Security -> Single sign-on (SSO)* and set the following properties:%BR% *Enabled* %BR% *Domain name:* example.org%BR% *Requires SSL* %BR% <img src="%ATTACHURLPATH%/websipssosetting.png" alt="websipssosetting.png" width="491" height="432" />%BR% 1. Click *OK* then *Save*. 1. Navigate to Global Security,select LTPA and enter the following values:%BR% *Password* : secret%BR% *Confirm Password:* secret%BR% *Fully qualified key file name:* %ENCODE{"<rmwasprofileroot>/etc/jtsssokey" type="entity"}%%BR% 1. Click *Import keys*. 1. Click *OK* then *Save*. 1. Stop and restart the RM profile. <p class="message-area message-warn"> <span style="font-weight: bold;">Repeat the above steps for each of the CCM and QM profiles, copying the jtsssokey file to the <ccmwasprofileroot> and <qmwasprofileroot> respectively.</span></p> #ConfigureJTS ---+++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 [[http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/topic/com.ibm.websphere.base.doc/info/aes/ae/tins_webplugins_local.html][Configuring a Web server and an application server profile on the same machine]]. <p class="message-area message-warn"> <span style="font-weight: bold;">The following steps are performed on "Server 1' which hosts both IHS and the WAS profile hosting the JTS, Admin and CLMHelp applications.</span></p> #GenerateJTS ---++++!!6.1Generate the plugin configuration file 1. Stop the JTS WAS profile. 1. Stop IHS. 1. Launch the Plug-ins Configuration Tool.%BR% <img src="%ATTACHURLPATH%/webserverplugininstall01.png" alt="webserverplugininstall01.png" width="701" height="427" /> 1. Click *Add....* 1. Enter *"webserver1"* for Name and "<plugin installdir>/Plugins" for *Location*. Click *Finish*. 1. Click create and choose *"IBM HTTP Server V8"* for Web server type and click *Next*.%BR% <img src="%ATTACHURLPATH%/webserverplugininstall03.png" alt="webserverplugininstall03.png" width="532" height="385" /> 1. Click *Browse* to select the configuration file for IHS, verify that the Web server port is correct, and then click *Next* when you are finished.%BR% <img src="%ATTACHURLPATH%/webserverplugininstall08.png" alt="webserverplugininstall08.png" width="542" height="418" /> 1. Optionally configure access to the IBM HTTP Administration Server. This not required but makes it easy to propagate the plugin configuration file from the application server to the web server. 1. Specify a unique nickname for the Web server. Click Next.%BR%<img src="%ATTACHURLPATH%/webserverplugininstall09.png" alt="webserverplugininstall09.png" width="548" height="486" /> 1. Select *WebSphere Application Server machine (local)*, browse to the installation directory and click *Next*.%BR% <img src="%ATTACHURLPATH%/webserverplugininstall04.png" alt="webserverplugininstall04.png" width="569" height="548" /> 1. Select the profile that the JTS application is deployed to and click *Next*.%BR% <img src="%ATTACHURLPATH%/webserverplugininstall07.png" alt="webserverplugininstall07.png" width="503" height="341" /> 1. 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.%BR% <img src="%ATTACHURLPATH%/webserverplugininstall11.png" alt="webserverplugininstall11.png" width="588" height="580" /> 1. Verify the success on the Plug-in Configuration Summary panel and click *Finish* to exit the wizard. ---++++!!6.2Modify keyring and stashfile properties 1. 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.<verbatim><Transport Hostname="clm.example.org" Port="9447" Protocol="https"> <Property Name="keyring" Value="<path to ihskeys>/ihskeys.kdb"/> <Property Name="stashfile" Value="<path to ihskeys>/ihskeys.sth"/> </Transport></verbatim> 1. Start IHS and the JTS WAS profile.%BR% 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. #ConfigureRM ---+++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.%BR% 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. <p class="message-area message-warn"> <span style="font-weight: bold;">The following steps are performed on "Server 1' which hosts both IHS and the WAS profiles hosting the RM and JTS applications.</span></p> #GenerateRM ---++++!!7.1 Generate plugin configuration file 1. Stop the RM WAS profile. 1. Stop IHS. 1. Copy the previously generated %ENCODE{"<path to plugin installdir>/config/webserver1/plugin-cfg.xml" type="entity"}% to another file such as %ENCODE{"<path to plugin installdir>/config/webserver/jts-plugin-cfg.xml" type="entity"}%. 1. 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).%BR% <img src="%ATTACHURLPATH%/webserverplugininstall12.png" alt="webserverplugininstall12.png" width="557" height="512" />%BR% 1. Once the reference has been deleted , click Create and follow the same process as before%BR% * 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 !WebSphere Application Server machine (local), browse to the installation directory and select the "RM" profile 1. When the wizard completes, modify the keyring and stashfile properties as in Section 6.4, and copy the newly generated %ENCODE{"<path to plugin installdir>/config/webserver1/plugin-cfg.xml" type="entity"}% to %ENCODE{"<path to plugin installdir>/config/webserver/rm-plugin-cfg.xml" type="entity"}% ---++++!!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. <verbatim>wasinstall_root/bin/pluginCfgMerge.sh rm-plugin-cfg.xml jts-plugin-xml plugin-cfg.xml</verbatim> ---++++!!7.3 Edit httpd.conf Open the IHS httpd.conf file in a text editor and change the !WebSpherePluginConfig directive to point to the merged plugin configuration file. <verbatim>WebSpherePluginConfig <path to plugin installdir>/config/webserver/plugin-cfg.xml</verbatim> Restart IHS.%BR% First verify that you can still access the JTS page using the IHS URL !https://clm.example.org/jts.%BR% 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. #ConfigureQM ---+++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 [[http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/tins_webplugins_remotesa.html][Configuring a Web server and an application server on separate machines (remote)]]. <p class="message-area message-warn"> <span style="font-weight: bold;">The following steps are performed on "Server 1' which hosts IHS.</spacn></p> ---++++!!8.1 Generate manual plugin configuration script 1. Stop IHS. 1. Copy the previously generated %ENCODE{"<path to plugin installdir>/config/webserver/plugin-cfg.xml" type="entity"}% to another file such as %ENCODE{"<path to plugin installdir>/config/webserver/rm-jts-plugin-cfg.xml" type="entity"}%. 1. Launch the Plug-ins Configuration Tool on server1. Again we first remove the reference to the previous file from the Configuration tool.%BR% <img src="%ATTACHURLPATH%/webserverplugininstall12.png" alt="webserverplugininstall12.png" width="557" height="512" /> 1. Once the reference has been deleted , click Create and follow the same process as before%BR% * 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%BR% <img src="%ATTACHURLPATH%/webserverplugininstall13.png" alt="webserverplugininstall13.png" width="559" height="489" /> 1. 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.%BR% <img src="%ATTACHURLPATH%/webserverplugininstall14.png" alt="webserverplugininstall14.png" width="534" height="559" /> <p class="message-area message-warn"> <span style="font-weight: bold;">The following steps are performed on "Server 2' which hosts the WAS profile hosting the QM application.</span></p> ---++++!!8.2 Run manual configuration script on Server 2 We now copy the manual configuration script generated above to the <was_install_root> /bin directory on Server 2.%BR% If the WAS profile hosting the QM application isn't already running start it.%BR% Run the configurewebserver1.sh script.%BR% If it runs successfully, a web server definition will have been created in the QM application server profile. #GenerateQM ---++++!!8.3 Propagate the QM plugin configuration file to the IHS server 1. Login to the WAS Integration Solutions Console for the QM WAS profile. 1. Navigate to Servers -> Server Types -> Web Servers 1. Select "webserver_qm" and click "Generate Plug-in".%BR% <img src="%ATTACHURLPATH%/qm_webgenerate.png" alt="qm_webgenerate.png" width="348" height="280" /> 1. Once the plugin file has been generated, select "webserver1" and click "Propagate Plug-in".%BR% <img src="%ATTACHURLPATH%/qm_webgpropagate.png" alt="qm_webgpropagate.png" width="348" height="280" /> If successful WAS will generate a message such as:<verbatim>InformationPLGC0048I: The propagation of the plug-in configuration file is complete for the Web server. qm.clm.example.org-node.webserver1.</verbatim>%BR% Note the path displayed for the generated plugin configuration file on Server 1 which is the IHS Server. <p class="message-area message-warn"> <span style="font-weight: bold;">The following steps are performed on "Server1' which hosts IHS.</span></p> ---++++!!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.%BR% Remember that in step 8.1 we copied the <path to plugin installdir>/config/webserver/plugin-cfg.xml to <path to plugin installdir>/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%BR% server.<verbatim>wasinstall_root/bin/pluginCfgMerge.sh <path to plugin installdir>/config/webserver1/plugin-cfg.xml <path to plugin installdir>/config/webserver/rm-jts-plugin-cfg.xml <path to plugin installdir>/config/webserver/plugin-cfg.xml</verbatim> ---++++!!8.5 Edit httpd.conf Open the IHS httpd.conf file in a text editor and change the !WebSpherePluginConfig directive to point to the merged plugin configuration file. <verbatim>WebSpherePluginConfig <path to plugin installdir>/config/webserver/plugin-cfg.xml"</verbatim> Restart IHS.%BR% 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.%BR% 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.%BR% Copy the %ENCODE{"<path to plugin installdir>/config/webserver/plugin-cfg.xml" type="entity"}% to another file such as %ENCODE{"<path to plugin installdir>/config/webserver/rm-jts-qm-plugin-cfg.xml" type="entity"}%. #ConfigureCCM ---+++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 [[http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/tins_webplugins_remotesa.html][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 <p class="message-area message-warn"> <span style="font-weight: bold;">The following steps are performed on "Server3' which hosts the CCM profile.</span></p> 1. Copy the previously generated cofigurewebserver1.sh from Server 1 to the %ENCODE{"<app_server_root>/bin" type="entity"}% directory. 1. Run the script:%BR% <verbatim>wasinstall_root/bin/cofigurewebserver1.sh CCM username password</verbatim>%BR% If it runs successfully, a web server definition will have been created in the CCM application server profile.%BR% #PropagateCCM ---++++!!9.2 Propagate the CCM plugin configuration file to the IHS server 1. Login to the WAS Integration Solutions Console for the CCM WAS profile. 1. Navigate to *Servers -> Server Types -> Web Servers* 1. Select "webserver1" and click "Generate Plug-in". 1. Once the plugin file has been generated, select "webserver1" and click "Propagate Plug-in".%BR% If successful, WAS will generate a message such as:%BR% <verbatim>InformationPLGC0048I: The propagation of the plug-in configuration file is complete for the Web server. ccm.clm.example.org-node.webserver1.</verbatim>%BR% <p class="message-area message-warn"> <span style="font-weight: bold;">The following steps are performed on "Server1' which hosts IHS.</span></p> #MergePluginDirectives ---++++!!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.%BR% Remember that in step 8.5 we copied %ENCODE{"<path to plugin installdir>/config/webserver/plugin-cfg.xml" type="entity"}% to %ENCODE{"<path to plugin installdir>/config/webserver/rm-jts-qm-plugin-cfg.xml type="entity"}%. Run the pluginCfgMerge tool to merge the contents of the new plugin-cfg.xml propagated from the CCM server.%BR% <verbatim>wasinstall_root/bin/pluginCfgMerge.sh <path to plugin installdir>/config/webserver1/plugin-cfg.xml "<path to plugin installdir>/config/webserver/rm-jts-qm-plugin-cfg.xml <path to plugin installdir>/config/webserver/plugin-cfg.xml</verbatim> ---++++!!9.4 Edit httpd.conf Open the IHS httpd.conf file in a text editor and change the WebSpherePluginConfig directive to point to the merged plugin configuration file.%BR% <verbatim>WebSpherePluginConfig <path to plugin installdir>/config/webserver/plugin-cfg.xml"</verbatim> Restart IHS.%BR% 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.%BR% 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 [[https://pic.dhe.ibm.com/infocenter/clmhelp/v4r0m1/topic/com.ibm.jazz.install.doc/topics/t_s_server_installation_setup_wizard.html][JTS setup wizard]] and use these URLs when registering the applications. Here are the discovery URLs that will be used:%BR% Requirements Management: !https://clm.example.org/rm/scr%BR% Quality Management: !https://clm.example.org/qm/scr%BR% Change and Configuration Management: !https://clm.example.org/ccm/scr%BR% Lifecycle Project Administration: !https://clm.example.org/admin/scr%BR% ---++ 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: 1. Deploy the RM application to WAS on rmserver01.example.org 1. Follow the instructions in the [[https://pic.dhe.ibm.com/infocenter/clmhelp/v4r0m1/topic/com.ibm.jazz.install.doc/topics/c_deploying_was.html][CLM Infocenter]], making sure to copy over the directory that contains the indexes and configuration files, located at <JazzInstallDir>/server/conf/rm for the RM application from the original server. 1. Setup SSL Handshake Between WAS profile on rmserver01.example.org and IHS on clm.example.org 1. Follow the procedure detailed in [[ConfigureCLMEnterpriseReverseProxy#SetupSSLHandshake][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). 1. Force WAS To Honor Host Headers 1. Follow the procedure in [[ConfigureCLMEnterpriseReverseProxy#ForceWAS][Force WAS to honor host headers]] on the new WAS profile hosting the RM application. 1. Setup Single Sign-On(SSO) with WAS and import JTS keys 1. Follow the procedure in [[ConfigureCLMEnterpriseReverseProxy#SSOWithWAS][Single Sign-On (SSO) with WAS]] to set the domain name and import the keys from the jtsssokey key file. 1. Configure WAS IHS Plug-in for the RM application 1. Follow the procedure in [[ConfigureCLMEnterpriseReverseProxy#ConfigureCCM][Configure WAS IHS Plug-in for the CCM application (Server 3)]] to run the plugin configuration script for the RM profile and propagate the plugin configuration back to the IHS server 1. Replace plugin directives and edit the httpd.conf 1. Finally follow the procedure in [[ConfigureCLMEnterpriseReverseProxy#MergePluginDirectives][Merge plugin directives]], edit the httpd.conf file and restart IHS. ---++ Using the command line Many of the steps documented carried out via the GUI or the WAS Admin Console also have command line or wasadmin equivalents listed below against the relevant section. [[#CreateKey][Section 1]]: wsadmin [[http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/topic/com.ibm.websphere.base.doc/info/aes/ae/rxml_atkeystore.html][AdminTask.createKeyStore]] and [[http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/topic/com.ibm.websphere.base.doc/info/aes/ae/rxml_atpersonalcert.html][AdminTask.exportCertificate]]%BR% [[#ForceWAS][Section 4]]: wsadmin [[http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/topic/com.ibm.websphere.base.doc/info/aes/ae/rxml_adminconfig1.html][AdminConfig.list]] and [[http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/topic/com.ibm.websphere.base.doc/info/aes/ae/rxml_adminconfig1.html][AdminConfig.create]]%BR% [[#SSOWithWAS][Section 5]]: wsadmin [[http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/topic/com.ibm.websphere.base.doc/info/aes/ae/rxml_7securityconfig.html][AdminTask.configureSingleSignon]] and [[http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/topic/com.ibm.websphere.base.doc/info/aes/ae/rxml_7securityconfig.html][AdminTask.exportLTPAKeys]]%BR% Sections [[#ConfigureJTS][6]], [[#ConfigureRM][7]], [[#ConfigureQM][8]], [[#ConfigureCCM][9]] : [[http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/topic/com.ibm.websphere.base.doc/info/aes/ae/tins_pctcl_using.html][Configuring a web server plug-in using the pct tool]]%BR% Sections [[#GenerateJTS][6.1]], [[#GenerateRM][7.1]] , [[#GenerateQM][8.3]] , [[#PropagateCCM][9.2]] : [[http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/topic/com.ibm.websphere.base.doc/info/aes/ae/rxml_genplugincfg1.html][GenPluginCfg command]] ---++ References * [[https://pic.dhe.ibm.com/infocenter/clmhelp/v4r0m1/topic/com.ibm.jazz.install.doc/topics/c_topology_overview.html][Collaborative Lifecycle Management 4.0.1 Information Center: Installation process and topology examples]] * [[https://jazz.net/library/article/686][jazz.net: Moving Jazz Servers and URI Stability with CLM 2011]] * [[https://pic.dhe.ibm.com/infocenter/clmhelp/v4r0m1/topic/com.ibm.jazz.install.doc/topics/c_reverse_proxy.html][Collaborative Lifecycle Management 4.0.1 Information Center: Reverse proxy servers in topologies]] * [[http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/index.jsp][WebSphere 8 Information Center]] * [[https://jazz.net/library/article/413/][Tip: Single Sign-on using WebSphere Application Server]] ---+++++!! Related topics: [[InstallProxyServers][Proxy server installation]], [[UnderstandingReverseProxy][Understanding reverse proxy]], [[ConfigureCLMEnterpriseReverseProxyWithApache][Configuring Enterprise CLM Reverse Proxies: Apache and mod_proxy]], [[ConfiguringEnterpriseCLMReverseProxiesWebSphere85NDProxy][Configuring Enterprise CLM Reverse Proxies: WebSphere 8.5 ND Proxy]] ---+++++!! Additional contributors: Main.RosaNaranjo ---+++++!! Questions and comments: %COMMENT{type="below" target="ConfigureCLMEnterpriseReverseProxyComments" button="Submit"}% %INCLUDE{"ConfigureCLMEnterpriseReverseProxyComments"}% <sticky></div></sticky>
Edit
|
Attach
|
P
rintable
|
V
iew topic
|
Backlinks:
We
b
,
A
l
l Webs
|
H
istory
:
r16
|
r14
<
r13
<
r12
<
r11
|
More topic actions...
Deployment
Deployment web
Planning and design
Installing and upgrading
Migrating and evolving
Integrating
Administering
Monitoring
Troubleshooting
Community information and contribution guidelines
Create new topic
Topic list
Search
Advanced search
Notify
RSS
Atom
Changes
Statistics
Web preferences
NOTE: Please use the Sandbox web for testing
Status icon key:
To do
Under construction
New
Updated
Constant change
None - stable page
Smaller versions of status icons for inline text:
Copyright © by IBM and non-IBM contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our
Terms of Use.
Please read the following
disclaimer
.
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more
here
.