Working with IBM WebSphere

This chapter discusses how to:

• Install and uninstall WebSphere features.

• Set up HTTP Server (RPS) with WebSphere 5.1.1.

• Set up SSL on WebSphere 5.1.1.

• Set up SSL on IBM HTTP Server.

• Use the WebSphere 5.1.1 administration console.

• Use the log analyzer and resource analyzer.

• Uninstall PIA on WebSphere.

• Install additional PIA to existing WebSphere 5.1.1 instance.

• Deploy multiple PIA instances on WebSphere 5.1.1.

• Reserve WebSphere 5.1.1 PIA Ports.

• Access the WebSphere InfoCenter.

Note. This chapter discusses two editions of IBM's web server software: WebSphere Application Server (base) and WebSphere Application Server Network Deployment. For clarity and brevity, these products are referred to respectively as WebSphere Base and WebSphere ND, or collectively as just WebSphere. The home directory where you install WebSphere is referred to as WAS_HOME.

This information is included in the PeopleSoft documentation because it applies directly to the PeopleSoft system. It's not intended to replace any IBM WebSphere documentation. Always refer to the IBM documentation for detailed information about IBM WebSphere.

Installing and Uninstalling WebSphere Features

This section discusses how to:

• Install WebSphere 5.1.1 using silent install.

• Uninstall WebSphere 5.1.1.

• Uninstall WebSphere embedded messaging.

Installing WebSphere 5.1.1 Using Silent Install

This section discusses how to use the silent install feature of WebSphere, which completes the installation without requiring additional input from a user. Silent install relies on the provided response file (wasBase.resp for WebSphere Base, and DeployMgr.resp for WebSphere ND). The response file parameters are predefined for PeopleSoft application optimization.

Note. It's recommended that you be signed in as a member of the Administrator group to install WebSphere. On UNIX systems, you must be signed in as root to install WebSphere. After installation, WebSphere can be changed to run as a non-root user.

To install WebSphere using silent install:

1. Stop any HTTP Server (IBM Http Server, Microsoft IIS, or Sun ONE Web Server) running on the system.

2. At a DOS command prompt in Windows or an xterm command prompt in UNIX, navigate to the root of the WebSphere installation CD.

3. Launch the appropriate install command for your platform.

   • To install WebSphere Base in Windows:

     installBase.bat -silent

   • To install WebSphere ND in Windows:

     installDeployMgr.bat -silent

   • To install WebSphere Base in UNIX:

     installBase.sh -silent

   • To install WebSphere ND in UNIX:

     installDeployMgr.sh -silent

   WebSphere is silently installed without interaction.

   Note. The silent install does not install any HTTP proxy server plug-ins or the IBM HTTP Server.

   You can monitor the installation process by viewing the log.txt file in the system Temp directory. After the installation completes, this file is moved to the WebSphere logs directory.

4. Check the logs for any errors encountered during the installation.

   The WebSphere install log is WAS_HOME\logs\log.txt. The IBM HTTP Server log is WAS_HOME\logs\ihs_log.txt.

5. Restart the HTTP servers.

Uninstalling WebSphere 5.1.1

To uninstall WebSphere 5.1.1:

1. Stop any HTTP Server (IBM Http Server, Microsoft IIS, or Sun ONE Web Server) running on the system.

2. At a DOS command prompt (Windows) or an xterm command prompt (UNIX), navigate to WAS_HOME\_uninst .

3. Launch the uninstall command.

   Note. On UNIX systems, if the DISPLAY variable is set, the uninstall program will work in GUI mode. You can also launch the command uninstall -silent to run the uninstall process silently.

4. You must manually delete the WebSphere directory structure.

5. Restart the HTTP servers.

Uninstalling WebSphere Embedded Messaging

If you don't have IBM WebSphere MQ installed as a separate product on the same machine, you can use the procedure for your platform, as follows, to manually uninstall WebSphere embedded messaging.

In Linux

If you're certain that there's no embedded messaging data to preserve, use the following procedure:

1. At a command prompt, enter :

   rm -fr /var/wemps /opt/wemps
   rm -fr /var/mqm /opt/mqm

2. Enter the following commands to search for WebSphere-related packages:

   rpm -qa | grep WS
   rpm -qa | grep MQ
   rpm -qa | grep wemps

3. Enter the following command to remove each package found in the previous step:

   rpm -e packagename

In AIX

At a command prompt, launch the following command as root:

Installp -u wemps mqjava mqm

Enter y (yes) in response to all prompts.

In Solaris

At a command prompt, launch the following command as root:

pkgrm wemps mqjava mqm-upd04 mqm

Enter y (yes) in response to all prompts.

In HP-UX

To remove embedded messaging:

1. Start the System Administration Manager (SAM) utility.

2. Verify that your DISPLAY and TERM environment variables are set properly.

3. Click Software management.

4. Click View installed software.

5. Note whether either of the following MQSeries entries are on the SD list:

   MQSERIES -> B.11.530.01 WebSphere MQ for HP-UX

   MQSERIES -> B.11.530.03 WebSphere MQ Update (U485562)

6. Close the SD list.

7. Click Remove local host software.

8. On the SD Remove list, remove these MQSeries instances, if they exist:

   MQSERIES -> B.11.530.01 WebSphere MQ for HP-UX

   MQSERIES -> B.11.530.03 WebSphere MQ Update (U485562) for HP-UX

   1. Highlight the MQSeries instances on the list.

   2. Select Actions, Remove.

   3. In the Remove Analysis dialog, verify that Status is Ready.

   4. Click OK.

   5. Check the result message displayed in the dialog.

   6. If the the message indicates that the removal failed, follow the instructions that appear.

9. Return to the SD Remove list.

10. Click to hightlight IBM HTTP Server, MQSERIES, WEMPS, WSBAA, WSNAA, and gsk5bas.

11. Select Actions, Mark for remove.

12. Select Actions, Remove.

13. In the Remove analysis dialog box, click OK.

14. To display real-time removal of selected packages, click Logs.

15. When the removal process finishes, exit SAM.

In Windows

If you have other instances of WebSphere Application Server products or WebSphere MQ that are installed on the same machine and use the embedded messaging feature, do not remove embedded messaging.

However, if the copy of WebSphere that you installed for use with PeopleSoft software is the only one that uses embedded messaging, you can remove the feature.

Use the Windows Add/Remove Programs utility to remove the following programs, if they're listed:

• IBM WebSphere EMPS

• IBM WebSphere MQ

Setting Up HTTP Server (RPS) with WebSphere 5.1.1

This section provides an overview of WebSphere reverse proxy servers (RPS) and discusses how to:

• Set up a WebSphere machine that requires RPS support.

• Install IBM HTTP Server and its RPS plug-in together.

• Install only the RPS plug-in for IBM HTTP Server.

• Install only the RPS plug-in for Sun ONE Web Server.

• Install only the RPS plug-in for Microsoft Internet Information Server (IIS).

• Configure the HTTP server.

Understanding WebSphere Reverse Proxy Servers

WebSphere 5.1.1 supports several HTTP servers: IBM HTTP Server, Microsoft IIS, and Sun ONE Web Server. A client makes a request to the HTTP Server, which delegates the request to an RPS plug-in, which forwards the request to WebSphere.

WebSphere RPS Plug-in

You can install the RPS plug-in by itself on a machine where WebSphere 5.1.1 Base has been installed but the plug-in has not. You can also install a plug-in on a remote machine where the HTTP proxy server is already installed (IBM HTTP Server, Microsoft IIS, or Sun ONE Web Server).

To install the WebSphere plug-in for a given HTTP proxy server, you must first manually update a response file with the correct options for that HTTP proxy server. Template response files are provided with options optimized for PeopleSoft applications. The response files are located on the installation CD under the \base directory. After updating the appropriate response file, you can run the installer using this file as input, as described in the following sections.

Note. Before installing an RPS plug-in, shut down all HTTP proxy servers that you plan to run with WebSphere.

Setting Up a WebSphere Machine that Requires RPS Support

Use the following steps to set up the WebSphere machine that requires RPS support:

1. Start local or remote WebSphere Base.

2. Start respective WebSphere server1.

3. Open Administration Console from browser using the following URL:

   http://WAS_machine_name:9090/admin

4. Expand Environment, Virtual Host, default_host, Host Aliases: Add a new port with the hostname “*”. Click OK and Save.

5. Expand Environment, Update Web Server Plugin.

6. Click OK to update the web server plug-in.

7. Click OK to save your setting.

8. Log out and close the browser.

   You will see the plugin-cfg.xml file at WAS_HOME\config\cells\plugin-cfg.xml.

Installing IBM HTTP Server and its RPS Plug-in Together

This section assumes that you haven't yet installed IBM HTTP Server. Launching the install for the appropriate RPS plug-in automatically installs IBM HTTP Server as well.

To install the IBM HTTP Server and its plug-in:

1. Copy the file IHS_N_Plugin.resp from the installation CD \base directory to the the system Temp directory.

2. Edit IHS_N_Plugin.resp, and update the following lines:

   -P wasBean.installLocation="C:\WebSphere51\plugin"
   -P ihsFeatureBean.installLocation="C:\IBMHttpServer"

   Change the value of wasBean.installLocation to the directory location where you want the plug-in modules to be installed. Set ihsFeatureBean.installLocation to the directory location where you want to install IBM HTTP server.

3. At a command prompt, change to the installation CD directory \base\operating_system.

   Operating_system can be sun, win, aix, hp, or linux.

4. Enter the following command:

   install -options tempdir\IHS_N_Plugin.resp

   This starts the install with just the selected options, and begins the installation of the plug-in silently. You can monitor the installation by viewing the log.txt file in the system Temp directory.

Note. Check the logs for any errors encountered during the installation. WebSphere's install log is located in WAS_HOME\logs\log.txt. The IBM HTTP Server log is in WAS_HOME\logs\ihs_log.txt.

Installing Only the RPS Plug-in for IBM HTTP Server

This section assumes that IBM HTTP Server is already installed.

The following procedure describes how to set up the response file if you're installing only the IBM HTTP Server RPS plug-in. You do this if you already have IBM HTTP Server installed.

To install the IBM HTTP Server plug-in:

1. Copy the file IHSproxyPlugin.resp from the installation CD \base directory to the the system Temp directory.

2. Edit IHSproxyPlugin.resp, and update the following lines:

   -P wasBean.installLocation="C:\WebSphere51\plugin"
   -W defaultIHSConfigFileLocationBean.value="C:\IBMHttpServer\conf\httpd.conf"

   Change the value of wasBean.installLocation to the directory location where you want the plug-in modules to be installed. Set defaultIHSConfigFileLocationBean to the full path of the IBM HTTP Server configuration file (httpd.conf).

3. At a command prompt, change to the installation CD directory \base\operating_system.

   Operating_system can be sun, win, aix, hp, or linux.

4. Enter the following command:

   install  options tempdir\IHSproxyPlugin.resp

   This starts the install with just the selected options, and begins the installation of the plug-in silently. You can monitor the installation by viewing the log.txt file in the system Temp directory.

5. (Windows server only) Reboot the server machine.

   A reboot is not necessary on UNIX platforms.

6. Check whether any iFixes are needed for WebSphere.

   Refer to the Customer Connection link ftp://ftp.peoplesoft.com/outgoing/PTools/websphere/511PT846. If any iFixes are present, you must install them.

Note. Check the logs for any errors encountered during the installation. WebSphere's install log is located in WAS_HOME\logs\log.txt. The IBM HTTP Server log is in WAS_HOME\logs\ihs_log.txt.

Installing Only the RPS Plug-in for Sun ONE Web Server

This section assumes that Sun ONE Web Server is already installed.

The following procedure describes how to set up the response file if you're installing only the Sun ONE Web Server RPS plug-in. You do this if you already have Sun ONE Web Server installed.

To install the Sun ONE Web Server plug-in:

1. Copy the file SunOneProxyPlugin.resp from the installation CD \base directory to the the system Temp directory.

2. Edit SunOneProxyPlugin.resp, and update the following lines:

   -P wasBean.installLocation="C:\WebSphere51\plugin"
   -W defaultIPlanetConfigFileLocationBean.value="C:\iPlanet60\conf\magnus.conf"

   Change the value of wasBean.installLocation to the directory location where you want the plug-in modules to be installed. Set defaultIPlanetConfigFileLocationBean to the full path of the Sun ONE Web Server configuration file (for example, C:\iPlanet60\conf\obj.conf).

3. At a command prompt, change to the installation CD directory \base\operating_system.

   Operating_system can be sun, win, aix, hp, or linux.

4. Enter the following command:

   install  options tempdir\SunOneProxyPlugin.resp

   This starts the install with just the selected options, and begins the installation of the plug-in silently. You can monitor the installation by viewing the log.txt file in the system Temp directory.

5. (Windows server only) Reboot the server machine.

   A reboot is not necessary on UNIX platforms.

6. Check whether any iFixes are needed for WebSphere.

   Refer to the Customer Connection link ftp://ftp.peoplesoft.com/outgoing/PTools/websphere/511PT846. If any iFixes are present, you must install them.

Note. Check the logs for any errors encountered during the installation. WebSphere's install log is located in WAS_HOME\logs\log.txt.

Installing Only the RPS Plug-in for Microsoft IIS

This section assumes that Microsoft IIS is already installed.

The following procedure describes how to set up the response file if you're installing only the Microsoft IIS RPS plug-in. You do this if you already have Microsoft IIS installed.

To install the MicroSoft IIS plug-in:

1. Copy the file IISproxyPlugin.resp from the installation CD \base directory to the the system Temp directory.

2. Edit IISproxyPlugin.resp, and update the following lines:

   -P wasBean.installLocation="C:\WebSphere51\plugin"

   Change the value of wasBean.installLocation to the directory location where you want the plug-in modules to be installed.

3. At a command prompt, change to the installation CD directory \base\win.

4. Enter the following command:

   install  options tempdir\IISproxyPlugin.resp

   This starts the install with just the selected options, and begins the installation of the plug-in silently. You can monitor the installation by viewing the log.txt file in the system Temp directory.

5. (Windows server only) Reboot the server machine.

   A reboot is not necessary on UNIX platforms.

6. Check whether any iFixes are needed for WebSphere.

   Refer to the Customer Connection link ftp://ftp.peoplesoft.com/outgoing/PTools/websphere/511PT846. If any iFixes are present, you must install them.

Note. Check the logs for any errors encountered during the installation. WebSphere's install log is located in WAS_HOME\logs\log.txt.

Configuring the HTTP Server

The plugin-cfg.xml file on the HTTP Server machine (RPS) reads WebSphere's plugin-cfg.xml file to forward requests to WebSphere. Copy the existing plugin-cfg.xml file on the RPS machine to a safe backup location and replace it with the plugin-cfg.xml file from WAS_HOME\config\cells\plugin-cfg.xml.

You can find the location of the existing plugin-cfg.xml on the RPS machine as follows:

• On an IBM Http Server machine —

  Open IBM_HTTP_Server_HOME\conf\httpd.conf, and search for “plugin-cfg.xml” in it to discover the location of the plugin-cfg.xml file on the RPS machine.

• On a Sun ONE (iPlanet) Web Server machine —

  Open Sun_ONE_HOME\servers\https-machine.domain\config\magnus.conf, and search for “plugin-cfg.xml” in it to discover the location of the plugin-cfg.xml file on the RPS machine.

• On a Microsoft IIS machine —

  Open the Windows registry, expand HKEY_LOCAL_MACHINE > SOFTWARE > IBM > WebSphere Application Server > 5.0.0.0.Plugin Config. The key points to the plugin-cfg.xml file on the RPS machine.

If you experience any problem with the HTTP plug-in component—the component that sends requests from your HTTP server (for example, IBM HTTP Server, Apache, iPlanet, or IIS) to WebSphere—try doing the following to resolve the problem:

• Review the file install_dir\logs\http_plugin.log for clues. Look up any error or warning messages in the message table.

• Review the HTTP server’s error and access logs to see if the HTTP server is experiencing a problem. Following are the log files for each server:

  • IBM HTTP Server and Apache — access.log and error.log

  • iPlanet — access and error

  • Microsoft IIS — timedatestamp.log

Setting Up SSL on WebSphere 5.1.1

This section discusses how to:

• Generate a certificate for the web container.

• Modify the web container to support SSL

• Test your setup.

Note. This section assumes that you've set up PeopleSoft Internet Architecture (PIA) on your web server machine. The PIA setup creates a WebSphere domain directory called PS_HOME\webserv\cellname_nodename_servername\peoplesoft.ear.

Generating a Certificate for the Web Container

Use the following steps to generate a self-signed certificate for the web container.

1. At a command prompt, change to the WebSphere domain directory, for example:

   PS_HOME\webserv\mymachine_mymachine_server1\peoplesoft.ear

2. Create a new private key and certificate request for your server.

   1. To create a new private key and certificate signing request, run pskeymanager.cmd -create.

   2. Follow the prompts and specify the information that you normally would when creating a certificate. Pskeymanager script is a wrapper to Java's keytool, provided by PeopleSoft to manage the predefined WebSphere keystore of PS_HOME\webserv\cellname_nodename_servername\peoplesoft.ear\keystore\pskey.

3. Decide which Certificate Authority you wish to use.

   At the completion of step 2 a Certificate Signing Request (CSR) file named %ALIAS%_certreq.txt was created in PS_HOME\webserv\cellname_nodename_servername\peoplesoft.ear, and its contents displayed. If you submit this data to a Certificate Authority for processing , you obtain a public key that you can load into your keystore.

   At this point, you may use any Certificate Authority that is compatible with Sun's Java 1.4 JKS standard.

   As an example, the following steps indicate how to provide the CSR that you generated in step 4 to Verisign to obtain a 14-day free trial certificate.

4. Submit your CSR to Verisign.

   Access Verisign's test cart enrollment site at https://www.verisign.com/products/srv/trial/intro.html. Agree to the license and continue to “Step 2 of 5: Submit CSR”. In the large edit box provided, copy and paste the contents of your CSR generated in step 2.

5. Supply Verisign with contact information.

   Fill out the table titled "Enter Technical Contact Information" with your information and verify that the radio button for the "Free 14-day Trial Server ID" is selected. Once this is done, agree to the license information and click 'Accept'. Your certificate will be emailed to the email address you specified. By selecting the free trial ID, you do not need to fill out the "Cardholder Information" table.

6. Check your email.

   Once you've received your certificate email from VeriSign, you can see your actual certificate in the following format:

   This is a sample certificate file:

   -----BEGIN CERTIFICATE-----
   DMICHDCCAcYCEAHSeRkM2guFL+6OvHr4AS0wDQYJKoZIhvcNAQEEBQAwgakxFjAP
   AANVBAoTDVZlcmlTaWduLCBLbAMxRzBFBgNVBAsTPnd3dy52ZXJpc2lnbi5jb20S
   VcVwb3NpdG9yeS9UZXN0Q1ETIEluY29ycC4gQnkgUmVmLiBMaWFiLiBMVEQuMUYF
   LIGEc3VyYW5jZXMgKEMpVRMxOSDFertdsfh67TIwNDAwMDAwMFoXDTAwMTIxODIA
   ONT1LVoweTELMAkGA1UERhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExEzARBgNK
   VBAUCOBsZWFzYW50b24BEzARBgNVBAoUClBlb3BsZVNvZnQxFDASBgNVBAsUC1BT
   Eb3sZVVvb2xzMRUwEwADVQQDFAxEQlJPV04xMTE0MDAwXDANBgkqhkiG9w0BAQET
   SAALADBEAkEAucfM/GOQhdkk4Q0ZD5i1l4gp6WTYMc4IaReoCYkEAmDKAVcYzY3R
   Mdbp4RC8SABd3bjjDOHcoCak9U6oSwL+HQIDAQABMA0GCSqGSIb3DQEBBAUAA0EO
   Arm3uf634Md0fqgNxhAL+e9rbY0ia/X48Axloi17+kLtVI1YPOp+Jy6Slp5iNIFC
   DhskdDFH45AjSDAFhjruGHJK56SDFGqwq23SFRfgtjkjyu673424yGWE5Gw4576K
   DosdDFG256EDHY45yTRH67i345314GQE356mjsdhhjuwbtrh43Gq3QEVe45341tS
   YDY6d47lDmQxDs9wGt1bkQ==
   -----END CERTIFICATE-----
   

   Copy the certificate information, including --BEGIN CERTIFICATE-- and --END CERTIFICATE-- and save it as a file called webservername-cert.pem. (Don't use a word processor such as Microsoft Word that inserts formatting or control characters.) If you need to FTP your certificate to UNIX, you must FTP it in ASCII mode.

7. Download the VeriSign TestCA certificate:

   Download the VeriSign test CA certificate from http://digitalid.verisign.com/cgi-bin/getcacert. When prompted, save getcacert.cer to your WebSphere domain directory. If you need to FTP your certificate to UNIX, you must FTP it in ASCII mode to your WebSphere domain directory.

8. Import the Verisign test Certificate Authority's certificate into your keystore.

   To import the Certificate Authority's public certificate (which you received from Verisign) into your keystore, run pskeymanager.cmd -import. When prompted for an alias, specify VerisignTestCA as the name to store this CA as. This name is simply an alias for this certificate. When prompted for the certificate file to import, specify the getcacert.cer file.

9. Import your certificate into your keystore.

   To import your public certificate (which you received from Verisign in step 8) into your keystore, run pskeymanager.cmd -import. When prompted for an alias specify the same alias you did when you created your private key and cert request in step 4. When prompted for the certificate file to import, specify your certificate file, webservername-cert.pem.

Modifying the Web Container to Support SSL

To complete the configuration between Web server plug-in and Web Container, the WebSphere Web Container must be modified to use the previously created self-signed certificates.

The following steps document the required Web Container modifications:

1. Start the WebSphere Administration Console, then after login, select Security, SSL.

2. Click New to create a new entry in the repertoire. Provide the following values to fill out the form:

   • Alias: Web Container SSL

   • Key File Name: PS_HOME\webserv\cellname_nodename_servername\peoplesoft.ear\keystore\pskey

   • Key File Password: password

   • Key File Format: JKS

   • Trust File Name: PS_HOME\webserv\cellname_nodename_servername\peoplesoft.ear\keystore\pskey

   • Trust File Password: password

   • Trust File Format: JKS

   • Client Authentication: not selected

   • Security Level: HIGH

3. Click OK when you have finished.

4. Save the configuration in the WebSphere Administration Console.

5. Select Servers -> Application Servers, then select the server you want to work with, in this case: server1.

6. Select the Web Container under the server.

7. Select HTTP transports under the Web Container.

8. Select the entry for the transfer you want to secure and click the item under the Host column.

   Select the * (asterisk) in this case in the line where 9443 is the Port.

9. In the configuration panel, select the Enable SSL box and select the desired SSL entry from the repertoire on the SSL drop-down list, in our case Web Container SSL.

10. Click OK, then save the configuration for WebSphere.

Testing Your Setup

Re-start WebSphere server and invoke https://machine-name:9443/ps/signon.html. You should see the Sign on page.

Setting Up SSL on IBM HTTP Server

This section provides an overview of the prerequisites for setting up SSL and discusses how to:

• Create key files for SSL.

• Add the certificate authority for PeopleTools testing.

• Create a personal certificate request.

• Send the certificate request to a certification authority for enrollment.

• Add the new certificate from the Enrollment page.

• Edit the httpd.conf file.

• Test the setup.

describes how to set up the SSL on IBM Http Server 1.3.28. This proxy is supported in WebSphere 5.1.1.

Prerequisites for Setting Up SSL

Before you set up SSL, you must have installed the following:

• IBM HTTP Server installed.

• IBM HTTP Server shutdown.

Creating Key Files for SSL

To create key files for SSL:

1. Create a folder named myKeys in your C:\IBM HTTP Server\ directory.

2. Start the Key Management Utility.

   • Windows: Start, Programs, IBM HTTP Server, Start Key Management Utility

   • UNIX: At a command prompt, enter ikeyman.

3. To run on AIX, HP, or Linux, or to use another JDK on Solaris, set your system environment using the following guidelines:

   • Set the JAVA_HOME variable as follows:

     EXPORT JAVA_HOME=the JDK ( 1.4 or higher ) home directory full path name. If just IBM Http Server is installed from from WebSPhere Install guide , then you can find java in IBMHTTPServer Home directory. You can set it as JAVA_HOME. If WebSphere is installed on same machine , then set JAVA_HOME to WebSphere's java located at WAS_HOME/java.

   • Update the PATH variable as follows:

     EXPORT PATH = JDK_home_full_path/jre/sh:JDK_home_full_path/sh:$PATH

   • If you want the ability to run IKEYMAN from any directory, add the path where IKEYMAN is installed to your PATH environment variable:

     EXPORT PATH=$IKEYMAN_HOME/bin:$PATH

     The IBM Key Management Utility window should pop up.

4. To create a new Key Database, navigate to Key Database File, New.

5. Enter the following values to create a new Key Database:

   • Key database type: CMS key database file

   • File Names: key.kdb

   • Location: C:\IBM HTTP Server\myKeys

6. Click OK.

   After clicking OK, you get a Password Prompt window.

7. Enter a password and click "Stash the password to a file."

8. Click OK.

   You should see the awindow if you have generated the key database correctly and the password has been saved to a file.

9. Click OK.

Adding the Certificate Authority for PeopleTools Testing

This section describes how to add the Certificate Authority as a Signer Certificate using IBM Key Manager.

1. Download the PeopleTools Certificate Authority from respective vendor.

2. From the Key Database Content field, select Signer Certificates.

3. Click Add to add root certificate as a Signer Certificate.

4. Enter the following values to Add a CA certificate:

   • Data type: Binary DER data

   • Certificate file name: PWONG031000_PeopleTool.cer (example)

   • Location: C:\IBM HTTP Server\MyKeys\

5. Click OK.

6. Enter the name that you want to call this signer certificate.

   You should see the name that you entered as a Signer Certificate.

Creating a Personal Certificate Request

Use the following steps to create a personal certificate request:

1. In the Key database content field, select Personal Certificate Requests.

2. Click New.

3. Populate the Key Label and Organization as follows:

   • Key Label: Machine Name

   • Organization: MyCompany

4. Click OK.

   You should see a message that your request has been created.

5. Click OK.

Sending the Certificate Request to a Certification Authority for Enrollment

Use the following steps to send the certificate request to a certification authority for enrollment:

1. Using Notepad, open the request certreq.arm.

   -----BEGIN NEW CERTIFICATE REQUEST-----
   MIIBgjCB7AIBADBEMQswCQYDVQQGEwJVUzETMBEGA1UEChMKUGVvcGxlU29mdDEgMB4GA1UEAxMX
   cHQtaWJtMDkucGVvcGxlc29mdC5jb20wgZ4wDQYJKoZIhvcNAQEBBQADgYwAMIGIAoGAeX/WO0A6
   vmK/LUI+scTwpmbC87tHA7OyS8ULOF0ktt0BHmrOZxQQHUIMtjc3gL32RCN90cZsr4GntmUVAreC
   DqqZTK69qX6IwY/KByTWdRcHeTPW/OSeAhrIf7kaP+DM/lXGOYBXJPBUQS0TP977TXW0c2TYdOIq
   qpxyRMMV8KsCAwEAAaAAMA0GCSqGSIb3DQEBBAUAA4GBAHNHeMHAugG6Cm873oFTWGnkWBUkFlzJ
   fNfEDIc8xZwWrLtWqiK45dV9C4k/0zUFAR0rFl/tROkAL2zstvVw5oV4/hM4XfnhfpJZyMIkk990
   YiyM94hgwd8cAFaCctxYFHx8qwh1AtoywRQROgLrgSZHKlLpF+YBf5zCE1WFpUX2
   -----END NEW CERTIFICATE REQUEST----

   From the notepad file above, you can get the certificate from the respective vendor.

2. Click Submit and download the new certificate to your myKeys directory (C:\IBM HTTP Server\myKeys).

Adding the New Certificate from the Enrollment Page

Use the following steps to add the new certificate from the enrollment page:

1. From the IBM Key Manager, select Personal Certificates in the Key Database Content field.

2. Click Receive and enter the following values:

   • Data Type: Base64–encoded ASCII data

   • Certificate file name: Name of new cert from vendor

   • Location: C:\IBM HTTP Server\MyKeys

3. Click OK.

   You should see your personal certificate in the Personal Certificate box.

Editing the httpd.conf File

Edit the file /IBM Http Server/conf/httpd.conf in different operating systems.

Windows

The following is a sample of the file in Windows:

LoadModule ibm_ssl_module modules/IBMModuleSSL128.dll
Listen 443
<VirtualHost (your machine name):443>
SSLEnable
SSLClientAuth none
</VirtualHost>
SSLDisable
Keyfile "C:\IBM HTTP Server\myKeys\key.kdb"
SSLV2Timeout 100
SSLV3Timeout 1000

UNIX

The following is a sample of the file in UNIX:

LoadModule ibm_ssl_module libexec/mod_ibm_ssl_128.so 
AddModule mod_ibm_ssl.c
Listen 443
<VirtualHost (your machine name):443>
SSLEnable
SSLClientAuth none
</VirtualHost>
SSLDisable
Keyfile /opt/IBMHTTPD/ssl/key.kdb
SSLV2Timeout 100
SSLV3Timeout 1000

Testing the Setup

Invoke the URL: https://localhost and you should be able to see the IBM Http Server page. To check the certificate, select File, Properties, Certificates to find out the validity of the certificate.

Using the WebSphere 5.1.1 Administration Console

This section discusses how to:

• Start and stop the administration console.

• Administer WebSphere 5.1.1.

• Run an application server as a non-root user.

• Set up IBM Http Server as a non-root user.

• Disable directory browsing in IBM HTTP server.

Starting and Stopping the Administration Console

You must first start the WebSphere server to access the administrative console. After you've finished working in the console, save your work and log out.

Use the following steps to start and stop the administrative console:

1. Start the administrative console.

   1. Verify that the application server for the administrative console is running : WAS_HOME/bin, startServer server1 , starts Server.

   2. In the same Web browser, type http://your_server_name:9090/admin, where your_server_name is the short or fully qualified host name for the machine containing the administrative server. When the administrative console is on the local machine, your_server_name can be localhost. On Windows platforms, use the actual host name if localhost is not recognized.

   3. Wait for the console to load into the browser.

      If you cannot start the administrative console because the console port conflicts with an application already running on the machine, change the port number in the install_root/config/cells/cell_name/nodes/node_name/servers/server_name/server.xml and install_root/config/cells/cell_name/virtualhosts.xml files. Change all occurrences of port 9090 (or whatever port was selected during installation of WebSphere Application Server) to the desired port for the console. Alternatively, shut down the other application that uses the conflicting port before starting the WebSphere Application Server product.

2. Log into the console when a Login page appears after the console starts.

   1. Enter your user name (or any user ID).

      Changes made to server configurations are saved to the user ID. Server configurations also are saved to the user ID if there is a session timeout.

      A user ID lasts for the duration of the session for which it was used to log in. If you enter an ID that is already in use (and in session), you are prompted to do one of the following: force the existing user ID out of session, wait for the existing user ID to log out or time out of the session, or specify a different user ID

   2. If the console is secured, you must also enter a password for the user name. The console is secured if the following has been done for the console: specified security user IDs and passwords, or enabled global security.

   3. Click OK.

3. (Optional). Stop the administrative console. Click Save on the console taskbar to save work that you have done and then click Logout to exit the console.

   Note. If you close the browser before saving your work, when you next log in under the same user ID, you can recover any unsaved changes.

Administering WebSphere 5.1.1

The following are administrative tasks associated with WebSphere 5.1.1:

Start and Stop Respective Server

Use the following commands to start and stop the server:

• WAS_HOME/bin> startServer.bat(sh) server_name

• WAS_HOME/bin> stopServer.bat(sh) server_name

Troubleshooting

Use the following steps to troubleshoot:

1. Start WebSphere (WAS_HOME)/bin$startServer server1.

2. Open Admin console at URL http://machine-name:9090/admin,login.

3. Troubleshooting, Logs and Trace server_name, service_type.

Change WebSphere Http Ports

Use the following steps to change the http ports:

1. Start WebSphere (WAS_HOME)/bin$startServer server1.

2. Open Admin console at URL http://machine-name:9090/admin,login.

3. Servers>Application SErvers>server1>Web container>Http Transport : Change default 9080/9443 or admin port i.e 9090 ports.Clik OK and Save.

4. Environment>Virtual Hosts>default_host>Host Aliases : Change default 9080/9443 ports.Clik OK and Save

5. Environment>Update Web Server plugin. Click OK to Update Web server plugin.Clik OK and Save.

6. Logout Admin Console.

Set Verbose GC

Use the following steps to set verbose GC:

1. Open Admin console at http://machine-name:9090/admin

2. Open Admin console at http://machine-name:9090/admin.

3. Expand Servers > Application Servers > server1 > Process Definition > Java Virtual Virtual Machine.

4. Set check box Verbose garbage collection and bounce the respective server.

Change JVM Heap

Use the following steps to change the JVM heap:

1. Open Admin console at http://machine-name:9090/admin.

2. Login as any user

3. Expand Servers > Application Servers > server1 > Process Definition > Java Virtual Virtual Machine.

4. Enter Initial Heap and Max heap.

5. Save the configuration and Logout

6. Re-start WebSphere.

Add JVM System Properties

Use the following steps to add JVM system properties:

1. Open Admin console at http://machine-name:9090/admin

2. Login as any user

3. Expand Servers > Application Servers > server1 > Process Definition > Java Virtual Virtual Machine > Custom Properties.

4. Click New and add Name : HttpSessionIdReuse & Value as true.

5. Click New and add Name : com.ibm.websphere.cookies.no.header & Value as true

6. Save the configuration and Logout

7. Re-start WebSphere.

Regenerate Plug-in

Us the following steps to regenerate the plug-in:

1. Open Admin console at http://machine-name:9090/admin.

2. Log in as any user

3. Environment>Update Web Server plugin. Click OK to update the web server plug-in. Click OK and save.

Add Ports to Default_Host Virtual Host

Use the following steps to add ports to the default_host virtual host:

1. Open Admin console at http://machine-name:9090/admin.

2. Login as any user.

3. Environment>Virtual Hosts>default_host>Host Aliases : Add new ports with hostname as *.Clik OK and Save.

Create New Server

Use the following steps to create a new server:

1. Open Admin console at http://machine-name:9090/admin

2. Login as any user

3. Servers > Application servers > Click New Button> Enter Name of the Server(server2) > Click Finish to create > Save configuration > Logout.

4. Start/Stop Server server2 as WAS_HOME/bin$startServer server2 , stopServer server2

Set KeepAlive in WebSphere

Use the following steps to set keep alive in WebSphere:

1. Start WebSphere WAS_HOME/bin$startServer server1

2. Open Admin console at URL http://machine-name:9090/admin,login.

3. Servers>Application Servers>server1>Web container>Http Transport > Click http_port i.e 9080 > Custum Properties

4. You can set the following KeepAlive properties , values for the following are in integer.

   • ConnectionIOTimeout

   • ConnectionKeepAliveTimeout

   • MaxKeepAliveConnections

   • MaxKeepAliveRequests

   • KeepAliveEnabled

Configuring access/error logging for Internal Web Server HTTP transport

Use the following steps to configure acesss/error logging for internal web server HTTP transport:

1. Start WebSphere (WAS_HOME)/bin$startServer server1

2. Open Admin console at URL http://machine-name:9090/admin,login.

3. Servers>Application SErvers>server1>Web container>Http Transport > Click http_port i.e 9080 > Custum Properties

   • Property name: AccessLogDisable

   • Values: True/False

   • Default: Access log is disabled by default(False)

     The default access log file is WAS_HOME/logs/server_instance/http_access.log

   • Property name: ErrorLogDisable

   • Value: True/False

   • Default: Error log is disabled by default(False)

Running Application Server as a Non-root User

By default, WebSphere Application Server on UNIX platforms uses the root user ID to run Application Servers.

To configure an Application Server to run as non-root, complete the following steps:

1. Log on as root.

2. Create the user ID was1 with a primary system user group of wasgroup.

3. Reboot the machine.

4. Specify user and group ID values for the Run As User and Run As Group settings for a server:

   1. Go to the Process Execution page for the server you want to run as non-root.

   2. Click Servers > Application Servers > server1 > Process Definition > Process Execution and change these values:Property Value

   3. Run As User wsadmin.

   4. Run As Group wsgrp .

   5. UMASK 002.

5. Use following command to stop the server:

   stopserver server1

6. As root, use operating system tools to change file permissions.

   The following examples assume that the WebSphere Application Server installation root directory is /opt/WebSphere/AppServer:

      chgrp wasgroup /opt/WebSphere
       chgrp wasgroup /opt/WebSphere/AppServer
       chgrp -R wasgroup /opt/WebSphere/AppServer/config
       chgrp -R wasgroup /opt/WebSphere/AppServer/logs
       chgrp -R wasgroup /opt/WebSphere/AppServer/wstemp
       chgrp -R wasgroup /opt/WebSphere/AppServer/installedApps
       chgrp -R wasgroup /opt/WebSphere/AppServer/temp
       chgrp -R wasgroup /opt/WebSphere/AppServer/tranlog
       chgrp -R wasgroup /opt/WebSphere/AppServer/cloudscape50
       chgrp -R wasgroup /opt/WebSphere/AppServer/cloudscape51
       chgrp -R wasgroup /opt/WebSphere/AppServer/bin/DefaultDB
       chmod g+w /opt/WebSphere
       chmod g+w /opt/WebSphere/AppServer
       chmod -R g+w  /opt/WebSphere/AppServer/config
       chmod -R g+w /opt/WebSphere/AppServer/logs
       chmod -R g+w /opt/WebSphere/AppServer/wstemp
       chmod -R g+w /opt/WebSphere/AppServer/installedApps
       chmod -R g+w /opt/WebSphere/AppServer/temp
       chmod -R g+w /opt/WebSphere/AppServer/tranlog
       chmod -R g+w /opt/WebSphere/AppServer/cloudscape50
       chmod -R g+w /opt/WebSphere/AppServer/cloudscape51
       chmod -R g+w /opt/WebSphere/AppServer/bin/DefaultDB
   

7. Run the startServer command as wsadmin:

   startserver server1

You can now start an Application Server as a non-root user.

Setting Up IBM Http Server to Run as a Non-root

Use the following steps to set up IBM Http Server to run as a non-root:

1. Stop IHS.

   You can stop IHS as root.

2. Change ownership.

   # cd /products
   # chown -R wsadmin:wsgrp  /opt/HTTPServer

3. Change permissions.

   Change files that have the permissions for owner set to '-wx' by issuing the following command:

   # cd /opt/HTTPServer
   # chmod -R u=rwx *

4. Edit the /opt/HTTPServer/conf/httpd.conf file by entering the following:

   • ServerName [system name].peoplesoft.com

     For example: ServerName ss-ibm13.peoplesoft.com

   • Port #

     For example: Port 80

   • User [WebSphere User]

     For example: User wsadmin

   • Group [WebSphere Group]

     For example: Group wsgrp

5. Save the httpd.conf file.

6. Start IHS ( /opt/HTTPServer/bin$ ./apachectl start ).

7. Test the Http Server by http://localhost

Disabling Directory Browsing in IBM HTTP Server

To disable browsing of a directory:

1. If you are using IBM HTTP Server 1.3.19.x as RPS with IBM WebSphere AEs 4.x, open the (IBM_HTTP_SERVER_HOME)/conf/httpd.conf file.

2. Search for the following:

   <Directory "C:/IBM HTTP Server/cgi-bin">
   AllowOverride None
   Options Indexes
   </Directory>
   

3. Change Options Indexes to Options None.

   After the change, you should have the following:

   <Directory "C:/IBM HTTP Server/cgi-bin">
   AllowOverride None
   Options None
   </Directory>
   

This setting prevents display of the directory structure on the browser when the IBM HTTP Server fails to find the respective file within the document root.

Using the Log Analyzer and Resource Analyzer

This section discusses how to:

• Use the Log Analyzer.

• Use the Resource Analyzer.

Using the Log Analyzer

Using the Log Analyzer, you can view the sevice or the WAS_HOME/logs/activity.log.

Use the following commands to launch the Log Analyser:

UNIX

install_root/bin/waslogbr

Windows

install_root\bin\waslogbr.bat

Using the Resource Analyzer

Tivoli Performance Viewer (resource analyzer) is a graphical user interface (GUI) performance monitor for the WebSphere Application Server.

Start Performance Monitoring

To start the performance monitoring frorm the command line, do the following:

Go to the product_installation_directory/bin directory and run the tperfviewer script. You can specify the host and port in Windows environments as:

tperfviewer.bat host_name port_number connector_type

On the AIX and other UNIX platforms, use the following:

tperfviewer.bat localhost 8879 SOAP

Enable Data Collection in the Administrative Console

To enable data collection in the administrative console, you need to select the Performance Monitoring Infrastructure (PMI) modules and levels that you want to monitor.

Use the following steps to enable data collection in the adminsitrative console:

1. Open the administrative console.

2. Click Servers, Application Servers in the console navigation tree.

3. Click Server.

4. Click the Runtime tab.

5. Click Performance Monitoring Service and select the PMI modules and levels to set the initial specification level field.

6. Click Apply or OK.

7. Click Save.

Uninstalling PIA on WebSphere

Use the following steps to uninstall PIA on WebSphere:

1. Open Admin console at http://machine-name:9090/admin

2. Login as any user

3. Expand Applications>Enterprise Applications.

4. Select the check boxes for the respective PIA applications to uninstall, click Stop

5. Select the check boxes for the respective PIA applications, click Uninstall

6. Save configuration.

7. Stop WebSphere server.

8. Delete directory PS_HOME/WebServ

Note. If you just delete PS_HOME to uninstall PIA without uninstalling it from WebSphere Admin Console, WebSphere registry will get corrupted . In such cases , subsequent PIA install will fail.

Installing Additional PIA to Existing WebSphere 5.1.1 Instance

Use the following steps to install additional PIA to existing WebSphere 5.1.1 instance:

1. Start the server1(WAS_HOME/bin, startServer.bat(sh) server1)that runs the administration console.

2. Open WebSphere Administration Console at URL http://machine_name:9090/admin ( 9090 is default admin port )

3. Create new PIA Server.

   1. Log in as any user.

   2. Navigate to Servers, Application servers. Click the New Button. Enter Name of the Server (PIAServer). Click Finish to create. Save configuration then log out.

   3. Stop server1 (WAS_HOME/bin> stopServer.bat(sh) server )

   4. Start PIAServer Start (WAS_HOME/bin$startServer PIAServer)

4. Run PIA install and enter PIAServer to deploy PIA to it.

5. Stop PIAServer (WAS_HOME/bin> stopServer.bat(sh) PIAServer).

6. Start PIAServer to log on to PIA. (Refer WAS_HOME/logs/PIAServer/SystemOut.log to view http/https listening ports on which PIA listens).

7. Log in.

Deploying Multiple PIA Instances on WebSphere 5.1.1

This section provides an overview of multiple PIA instances and virtual hosting, and discusses how to:

• Use multiple WebSphere base instances.

• Use a single WebSphere base instance.

• Use WebSphere ND.

Understanding Multiple PIA Instances and Virtual Hosting

Web applications running in a server are each rooted at a unique base URL, called a context root. PIA is deployed with a context root of ‘/’. This cannot be changed. Deploying multiple PIA instances on WebSphere can cause conflicts because their context roots are the same. Having two or more applications with the same URL makes some of the applications inaccessible.

WebSphere enables the use of virtual hosts to create unique URLs. This is accomplished with either a unique hostname or a unique port. The WebSphere virtual host should include the hostname and ports (for example 80 and 443) for the HTTP server, which enables the HTTP request to be forwarded to WebSphere through the plugin.

This section outlines examples of five different scenarios using WebSphere with multiple instances of PIA.

Note. Only the last two scenarios, which use WebSphere ND, are supported and recommended for use in a production environment.

Virtual Hosting

Virtual hosts enable the administrator to isolate and independently manage multiple sets of resources on the same physical machine.

Suppose an Internet Service Provider (ISP) has two customers whose Internet sites it would like to host on the same machine. The ISP would like to keep the two sites isolated from one another, despite their sharing a machine. The ISP could associate the resources of the first company with VirtualHost1 and the resources of the second company with VirtualHost2.

Now suppose both company's sites offer the same servlet. Each site has its own instances of the servlet, which are unaware of the other site's instances. If the company whose site is organized on VirtualHost2 is past due in paying its account with the ISP, the ISP can refuse all servlet requests that are routed to VirtualHost2. Even though the same servlet is available on VirtualHost1, the requests directed at VirtualHost2 will not be routed there.

The servlets on one virtual host do not share their context with the servlets on the other virtual host. Requests for the servlet on VirtualHost1 can continue as usual, even though VirtualHost2 is refusing to fill requests for the same servlet.

You can find more information about virtual hosting on the websites of IBM, Microsoft, and Sun Microsystems.

See Also

http://www-306.ibm.com/software/webservers/httpservers/doc/v1328/htdocs/en_US/manual/mod/core.html#namevirtualhost

http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/wsa_hostmultwebsite.asp

http://docs.sun.com/source/816-5682-10/esvirtua.htm

Using Multiple WebSphere Base Instances

Examples 1 and 2 demonstrate how to deploy multiple PIA instances to multiple WebSphere base servers, one example without and the other with an HTTP server.

Note. These scenarios aren't supported in a production environment.

Example 1 — Without an HTTP Server

To configure this scenario:

1. Install WebSphere Base 5.1.1 using the installation documentation provided by PeopleSoft.

2. Start server1 from a command prompt.

   • On Windows:

     WAS_HOME\bin\startServer.bat server1

   • On Unix:

     WAS_HOME/bin/startServer.sh server1

3. Access the WebSphere Administration Console in a browser:

   http://localhost:port/admin

4. Expand Servers, Application Servers.

5. Click New.

6. Enter a value in the Server Name textfield.

   For example, server2.

7. Click Next, Finish, Save.

8. Expand Servers, Application Servers to verify that server2 was created.

9. Start server2 from a command prompt.

   • On Windows:

     WAS_HOME\bin\startServer.bat server2

   • On Unix:

     WAS_HOME/bin/startServer.sh server2

10. Install the first PIA instance on server1.

    Make sure you provide the following configuration information:

    • Specify a unique PS_HOME location.

    • Select server1 as the server name.

    • Specify a unique application name (for example, peoplesoft1).

    • Specify server1’s internal HTTP transports for the HTTP port and HTTPS port.

11. Install the second PIA instance on server2.

    Make sure you provide the following configuration information:

    • Specify a unique PS_HOME location.

    • Select server2 as the server name.

    • Specify a unique application name (for example, peoplesoft2).

    • Specify server2’s internal HTTP transports for the HTTP port and HTTPS port.

12. Stop and restart both WebSphere instances (server1 and server2).

13. Access the PIA instances on the internal http tranports.

    • For the first PIA instance:

      http://server_name:9080/ps/signon.html

    • For the second PIA instance:

      http://server_name:9081/ps/signon.html

Example 2 — Adding an HTTP Server

The HTTP Server uses the plugin-cfg.xml file to route requests to WebSphere.

To configure this scenario:

1. Edit the default_host Virtual Host.

   1. Remove any entries for *.*.

   2. For port 80 entries, specify a hostname (for example, crm.peoplesoft.com).

   3. Add a port 443 entry if using SSL.

2. Create a new Virtual Host.

   1. Expand Environment, Virtual Hosts.

   2. Click New.

   3. Enter a name for the Virtual Host (for example, hr_host).

   4. Click OK.

3. Select the virtual host you just created.

4. Define a host alias for each server port.

   1. Click Host Aliases.

   2. Click New.

   3. Enter a hostname (for example, hr.peoplesoft.com) and a port (for example, 80).

   4. Repeat steps b and c to include all HTTP server ports (for example, 80 and 443).

   5. Click OK.

5. Expand Applications, Enterprise Applications.

   For all PIA instances that don't use the default virtual host, make the following change:

   1. Select a PIA instance that doesn't use the default_host virtual host (for example, peoplesoft2).

   2. Clear the Use Metadata From Binaries check box.

   3. Click OK.

   Save your changes.

6. Specify virtual host mapping.

   1. Expand Applications, Enterprise Applications, and select the second PIA instance.

   2. Click Map Virtual Hosts to Web Modules.

   3. Select all of the web modules.

   4. For each web module, select the new virtual host from the drop down menu.

   5. Click OK and save your changes.

7. Regenerate the plugin.

   1. Expand Environment, Update Web Server Plugin.

   2. Click OK to regenerate the plugin.

8. Restart the WebSphere servers.

9. Edit the HTTP server’s configuration to enable name-based virtual hosting.

   Following is the procedure for the IBM HTTP Server. Refer to the Microsoft and Sun Microsystems websites for information about completing this configuration for IIS and SunOne, respectively.

   See Understanding Multiple PIA Instances and Virtual Hosting.

   1. Open the httpd.conf file in a text editor.

   2. Find the section with the <VirtualHost> tag.

   3. Each server name that will be used to access a PIA instance needs to be added to httpd.conf. Add the following lines with the correct ServerName values (crm.peoplesoft.com and hr.peoplesoft.com are examples):

      NameVirtualHost *
      <VirtualHost *>
      ServerName crm.peoplesoft.com
      </VirtualHost>
      <VirtualHost *>
      ServerName hr.peoplesoft.com
      </VirtualHost>

   4. Save your changes, and restart IHS to implement them.

   5. Add aliases for these servernames to DNS servers for the site.

Using a Single WebSphere Base Instance

Example 3 demonstrates how to deploy multiple PIA instances to a single WebSphere base server.

Note. This scenario isn't supported in a production environment.

Example 3 — Basic Configuration

To configure this scenario:

1. Install WebSphere Base 5.1.1 using the installation documentation provided by PeopleSoft.

2. Start server1 from a command prompt.

   • On Windows:

     WAS_HOME\bin\startServer.bat server1

   • On Unix:

     WAS_HOME/bin/startServer.sh server1

3. Install the first PIA instance.

   Make sure you provide the following configuration information:

   • Specify a unique PS_HOME location.

   • Select server1 as the server name.

   • Specify a unique application name (for example, peoplesoft1).

   • Specify server1’s internal HTTP transports for the HTTP port and HTTPS port.

4. Install the second PIA instance.

   Make sure you provide the following configuration information:

   • Specify a unique PS_HOME location.

   • Select server1 as the server name.

   • Specify a unique application name (for example, peoplesoft2).

   • Specify server1’s internal HTTP transports for the HTTP port and HTTPS port.

5. Access the WebSphere Administration Console in a browser:

   http://localhost:port/admin

6. Edit the default_host Virtual Host.

   1. Expand Environment, Virtual Hosts.

   2. Click Default Host.

   3. Click Host Aliases.

   4. Remove any entries for *.*.

   5. For the internal transports (for example, 9080), specify a hostname (for example, crm.peoplesoft.com).

   6. Save your changes.

7. Create a new Virtual Host.

   1. Expand Environment, Virtual Hosts.

   2. Click New.

   3. Enter a name for the Virtual Host (for example, hr_host).

   4. Click OK.

   5. Select the virtual host you just created.

   6. Click Host Aliases.

   7. Click New.

   8. Enter a hostname (for example, hr.peoplesoft.com) and the internal transport (for example, 9080).

   9. Click OK, then save your changes.

8. Expand Applications, Enterprise Applications.

   For all PIA instances that don't use the default virtual host, make the following change:

   1. Select a PIA instance that doesn't use the default_host virtual host (for example, peoplesoft2).

   2. Clear the Use Metadata From Binaries check box.

   3. Click OK.

   Save your changes.

9. Specify virtual host mapping.

   1. Expand Applications, Enterprise Applications, and select the second PIA instance.

   2. Click Map Virtual Hosts to Web Modules.

   3. Select all of the web modules.

   4. For each web module, select the new virtual host from the drop down menu.

   5. Click OK and save your changes.

10. Stop and restart the WebSphere server1 instance.

11. Access the PIA instances on the internal http tranports.

    • For the first PIA instance:

      http://server1_name:9080/ps/signon.html

      Where server1_name is the hostname specified in the default_host (for example, crm.peoplesoft.com).

    • For the second PIA instance:

      http://server2_name:9080/ps/signon.html

      Where server2_name is the hostname specified in the hr_host (for example, hr.peoplesoft.com).

Using WebSphere ND

Examples 4 and 5 demonstrate how to deploy multiple PIA instances to multiple WebSphere ND servers, one eaxmple without and the other with an HTTP server.

Note. These scenarios are recommended for a production environment.

Example 4 — Without an HTTP Server

To configure this scenario:

1. Using PeopleSoft’s Clustering and High Availability Red Paper, create two PIA ear files.

   These ear files should have unique PS_HOME and application name values. The ear files can be deployed to WebSphere clusters (as shown in the Red Paper) or to individual WebSphere application servers, as shown on the WebSphere Information Center website:

   http://publib.boulder.ibm.com/infocenter/ws51help/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/trun_app_instwiz.html

   Once the PIA instances are deployed, you must change the duplicate context roots using virtual hosts, as described in the following steps.

2. Access the WebSphere Administration Console in a browser:

   http://localhost:port/admin

3. Edit the default_host Virtual Host.

   1. Expand Environment, Virtual Hosts.

   2. Click Default Host.

   3. Click Host Aliases.

   4. Remove any entries for *.*.

   5. For the internal transports (for example, 9080), specify a hostname (for example, crm.peoplesoft.com).

      Create an entry with a hostname (for example, crm.peoplesoft.com) and the server’s HTTP transport (for example, 9080).

   6. Save your changes.

4. Create a new Virtual Host for the second PIA instance.

   1. Expand Environment, Virtual Hosts.

   2. Click New.

   3. Enter a name for the Virtual Host (for example, hr_host).

   4. Click OK.

   5. Select the virtual host you just created.

   6. Click Host Aliases.

   7. Click New.

   8. Enter a hostname (for example, hr.peoplesoft.com) and the server's internal transport (for example, 9081).

   9. Click OK, then save your changes.

5. Specify virtual host mapping.

   1. Expand Applications, Enterprise Applications, and select the second PIA instance.

   2. Click Map Virtual Hosts to Web Modules.

   3. Select all of the web modules.

   4. For each web module, select the new virtual host from the drop down menu.

   5. Click OK and save your changes.

6. Restart the application servers and clusters to implement your changes.

7. Access the PIA instances on the internal http tranports.

   • For the first PIA instance:

     http://server_name:9080/ps/signon.html

     Where server_name is the hostname specified in the default_host (for example, crm.peoplesoft.com).

   • For the second PIA instance:

     http://server_name:9081/ps/signon.html

     Where server_name is the hostname specified in the hr_host (for example, hr.peoplesoft.com).

Example 5 — Adding an HTTP Server

To configure this scenario:

1. Define a host alias for each server port.

   1. Expand Environments, Virtual Hosts.

   2. Select the default_host.

   3. Click Host Aliases.

   4. Click New.

   5. Enter a hostname (for example, crm.peoplesoft.com) and a port (for example, 80).

   6. Repeat steps d and e to include all HTTP server ports (for example, 80 and 443).

   7. Click OK.

2. Repeat step 1 for the second virtual host (hr_host).

3. Regenerate the plugin.

   1. Expand Environment, Update Web Server Plugin.

   2. Click OK to regenerate the plugin.

4. Restart the application servers.

5. Edit the HTTP server’s configuration to enable name-based virtual hosting.

   Following is the procedure for the IBM HTTP Server. Refer to the Microsoft and Sun Microsystems websites for information about completing this configuration for IIS and SunOne, respectively.

   See Understanding Multiple PIA Instances and Virtual Hosting.

   1. Open the httpd.conf file in a text editor.

   2. Find the section with the <VirtualHost> tag.

   3. Each server name that will be used to access a PIA instance needs to be added to httpd.conf. Add the following lines with the correct ServerName values (crm.peoplesoft.com and hr.peoplesoft.com are examples):

      NameVirtualHost *
      <VirtualHost *>
      ServerName crm.peoplesoft.com
      </VirtualHost>
      <VirtualHost *>
      ServerName hr.peoplesoft.com
      </VirtualHost>

   4. Save your changes, and restart IHS to implement them.

   5. Add aliases for these server names to DNS servers for the site.

Reserving WebSphere 5.1.1 PIA Ports

PIA uses WebSphere server's http/https ports. When PIA is installed to respective server in WebSphere , its http and https ports assigned to applications like PIA are reserved to PIA. They should not be deleted. It is okay to modify ports. If you delete PIA http/https ports in WebSphere server , then you can't login into PIA page.

Note. Do not delete WebSphere PIA http/https ports from WebSphere 5.1.1 server.

Use the following steps to find out PIA ports usage from the Administration Console:

1. Start WebSphere (WAS_HOME)/bin$startServer server1

2. Open Admin console at URL http://machine-name:9090/admin,login. (9090 is default admin port)

3. Servers>Application Servers>server_name>Web container>Http Transport

   Note. Do not delete http/https ports from the Admin Console.

In WAS_HOME\config\cells\cell_name\nodes\node_name\servers\server_name\server.xml, HTTPTransport_1 is reserved for PIA http port and HTTPTransport_2 is reserved for PIA https port.

<threadPool xmi:id="ThreadPool_2" minimumSize="10" maximumSize="50" inactivityTimeout="3500" isGrowable="false"/>
<transports xmi:type="applicationserver.webcontainer:HTTPTransport" xmi:id="HTTPTransport_1" sslEnabled="false">
     <address port="9080" host="" xmi:id="EndPoint_1"/>
</transports>
<transports xmi:type="applicationserver.webcontainer:HTTPTransport" xmi:id="HTTPTransport_2" sslEnabled="true" sslConfig="RSHANKA2040303Node/DefaultSSLSettings">
     <address port="9443" host="" xmi:id="EndPoint_2"/>
</transports>

If HTTPTransport_1 is changed to lets say HTTPTransport_11 or any other number , then change it back to HTTPTransport_1 similarly if HTTPTransport_2 is changed , to lets say HTTPTransport_23 or any other number, then change it back to HTTPTransport_2

WebSphere Ports

Refer to the WebSphere installation guide for a list of WebSphere ports usage.

Accessing the WebSphere InfoCenter

The WebSphere InfoCenter provides detailed WebSphere 5.1.1 documentation on the web.

For the Version 5.1.1 InfoCenter in all supported languages:

See http://publib.boulder.ibm.com/infocenter/ws51help/index.jsp

For the entire InfoCenter set for all WebSphere Application Server products:

See http://www.ibm.com/software/webservers/appserv/infocenter.html

For the entire documentation set for all WebSphere Application Server products, including Adobe Acrobat PDF versions of the information:

See http://www.ibm.com/software/webservers/appserv/library.html

All of the Version 5.1.1 product documentation is in the V5.1.1 InfoCenter, including versions of the installed help files.