UPDATED: 10 June 2014 This is the most recent pattern available. Documentation for older versions of the patterns can be found here http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Getting_started_with_IBM_WebSphere_Portal_and_IBM_Web_Content_Manager_Hypervisor_with_PureSystems
This document details the deployment instructions for IBM® WebSphere® Portal and Web Content ManagerTM Hypervisor Edition in the form of an Open Virtual Archive (hereafter referred to as "OVA", or "image") for deploying through IBM PureApplication Systems.
IBM PureSystems is a product family of expertly integrated systems from IBM that combine software and hardware to give you a pre-configured, efficient virtualization platform. The offering from PureSystems that function with the WebSphere Portal Hypervisor Edition is the IBM PureApplication System (PureApp), and includes IBM middleware images and patterns to customize and deploy, relying on the pattern engine to handle image and instance management.
The Digital Experience Pattern lets you experience the fully functional WebSphere Portal Server and Web Content Manager instance deployed through PureApp. The image also includes definitions and configurations for multiple parts of a typical WebSphere Portal and Web Content Manager deployment, allowing you to build very-simple-to-more complex topologies quickly and easily.
This document guides you through the steps of deploying this pattern, as well as how to build new images based on an instance created from the original image. You may wish to build new OVAs to contain your own custom WebSphere Portal and Web Content Manager solutions that can be used to build deployment patterns of your own design.
We focus on the process of setting up an instance of WebSphere Portal Hypervisor, covering the following topics in detail:
- Initializing a new instance based on the OVA, using deployment patterns created by the user
- Accessing and managing WebSphere Portal
- Building a new OVA based on an instance you customize
This documentation is intended for users who have a general knowledge of UNIX and how it works. To get the most from this article, you should have a good understanding of commands and how to manipulate input and output. You should also have a good working knowledge of the PureApp function, its administrative console, and how to deploy patterns using it.
We provide a basic overview of how to manage WebSphere Portal and include links to product documentation for more detailed information and guidance on how to use the product to build a Web site.
OVA contents and configuration
The WebSphere Portal OVA is a pre-installed and pre-configured instance of the product. Instances created based on this OVA are ready to use and pre-configured with certain features to make it easier to get started. The product configuration includes:
Security enablement - WebSphere Application Server security is enabled with the virtuser user ID, serving as both the WebSphere Portal administrator and WebSphere Application Server administrator id. During the deployment of the OVA, you will be required to set the password for the virtuser user id.
HTTP Server enablement - The IBM HTTP Server is configured to provide port 80 access to WebSphere Portal. The IBM HTTP Server is configured in its own part definition, so that it can be set up as a remote virtual machine for certain topologies instead of running on the same machine as WebSphere Portal. Section 3.3 covers how to use the HTTP Server.
External DB2 database - An instance of IBM® DB2 is installed and configured as WebSphere Portal's external database, providing an enterprise-class and highly performing database environment. It's configured in its own part definition, so that it can be set up as a remote virtual machine if desired.
Deployment Manager - A Deployment Manager part is defined to be run in its own virtual machine for managing a cell containing a WebSphere Portal / Web Content Manager cluster.
Web Content Manager enablement - The OVA has Web Content Manager configured for rendering and authoring. Several sample content libraries are also provided, including support for blogs and wikis.
Adding the OVA to PureSystems
There are separate pattern package available for the PureApplication System WR1500 (Intel) and the WR1700 (PowerVM). Ensure you have downloaded the appropriate package for your platform. There are two methods for adding the Portal OVA into the pattern engine: the Web interface and the command line.
To import the image, patterns, and script packages using importPatterns.py
- Uncompress and extract the downloaded WebSphere Portal Hypervisor Edition to a temporary directory. You should have file named patterns.json and 3 subdirectories: ./images, ./add_ons, and ./script_packages in the /tmp/portalPattern directory. For example:
tar -zxvf image.tgz -C /tmp/portalPattern
tar -xvf image.tar -C /tmp/portalPattern
- Determine the hostname, username and password for your PureApp appliance. Download and install the Command Line Interface
- Execute the pure command for your platform with the parameters as shown
cli_home/bin/pure -u username -p password -h hostname -f ../samples/importPatterns.py -s /tmp/portalPattern
/tmp/portalPattern is the temporary directory where the Portal package was extracted
cli_home is the location of the PureApp Command Line Interface
username is the PureApp administrator username
password is the PureApp password
hostname is the PureApp appliance hostname
To import just the image using the PureApp Web interface
- Extract the WebSphere_Portal.ova file from the downloaded package under the images subdirectory and make it accessible via and HTTP or SCP server. Click the link "Catalog", then "Virtual Images" menu located on the PureApp Workload page. This takes you to a page containing all the virtual images in the catalog.
- Click the New Virtual Image icon ( ) and enter the requested information to add the Portal OVA into the catalog.
- For remote access, specify either an SCP or HTTP URL in the Location field and, optionally, a user ID and password, if the URL is protected (see figure 1).
Figure 1. Creating a new OVA
To manually import the script packages PureApp Web interface
- Extract the script package tar files from the downloaded package under the script_packages sub-directory. Click the link Add Script Packages located under the PureApp System Console, Catalog, Script Packages page. This takes you to a page containing all the script packages in the catalog.
- Click the New Script Package icon and enter the requested information to add the script package into the catalog.
- Select the zip or tgz file on the local filesystem using the Browse field, and select Upload (see figure 2).
Figure 2. Creating a new script package
Initializing a new instance of the OVA
The following sections outline prerequisite information and steps for creating a new instance or pattern of an image. Details of how to use the PureApp administrative console, set up an account, and a cloud of hypervisors are not provided here. For more information on the PureApp, refer to the PureSystem Infocenters
If you imported the package with the importPatterns.py described , there are several pre-defined patterns representing various deployment options. You can view them on the Patterns, Virtual Systems page. If you did not import the patterns, or to create new patterns:
1. Click the new pattern icon ( ) on the patterns tab of the Web interface to create a new pattern for the Portal image (see figure 3).
Figure 3. Creating a new pattern
2. Enter the required information and optional description. The pattern engine then creates a new blank pattern with the information specified (see figure 4).
Figure 4. New blank pattern
3. Click the edit pattern icon ( ). A list of all the parts, Add-ons, and script packages provided by the virtual image that are available for the pattern to use are in the Pattern Editor (see figure 5). The canvas is where you drag parts over to model virtual machines that will be created.
Figure 5. The pattern editor
4. To create a standalone WebSphere Portal instance in a single virtual machine that runs DB2 and the IBM HTTP Server locally, simply drag the Standalone server part over into the canvas. A single box containing the part appears (figure 6), representing a single virtual image, which is the simplest to deploy for standalone systems.
Figure 6. A simple pattern
5. To build a more complex pattern, such as a portal vm instance with a remote DB2 instance, or a portal cluster, use the Portal Part instead of the Standalone server part and add additional machines to the deployment, simply by dragging over multiple parts (see figure 7).
The pattern engine automatically detects and creates links between various machines and configures them accordingly at deployment. The Portal Part is used over the Standalone Server Part to provide for more configuration options when supporting more complex configurations.
Figure 7. Portal cluster of two nodes
6. You can make additional changes, such as memory, CPU, and passwords for each VM, and set specific ordering requirements on the deployment operations. Click Done editing to save a your pattern. You can then make your pattern read-only, or deploy it.
Parts of the OVA
The WebSphere Portal and Web Content Manager OVA contains six parts that can be used for defining patterns for deployment:
Standalone server - Configures a self-contained virtual machine for setting up simple single-server deployments and for extending and capturing a new virtual image (see Section 5).
Deployment Manager - A virtual machine configured to run the Deployment Manager, for managing a cell containing a WebSphere Portal cluster.
IHS Part - Sets up a remote IBM HTTP Server to load-balance Web access to the portal cluster.
Portal Part - The most versatile part, this creates a self-contained Portal instance with a local DB2 instance and HTTP Server, or is linked to a Deployment Manager as a part of a cluster pattern. It can also link to the remote IHS and DB2 parts. Selecting a Portal Part instead of a Standalone server provides for more configuration options at deployment. The Portal Part also contains more links with other parts than the Standalone, making it the desired part to use with clustering. Note: A Portal cluster pattern should have only 1 Portal part, representing the Primary node
Secondary Portal Part - In a Portal cluster, operations on secondary cluster members are different than those on the Primary node. This part should be used in patterns as secondary Portal cluster members, and can be incremented to increase the total number of Portal cluster members
Remote DB2 - Creates a remote DB2 instance for either a single-server instance (using a single Portal Part) or a cluster of portal instances.
Included Script packages
The WebSphere Portal and Web Content Manager package also includes optional script packages that can be used with your patterns for enhanced function.
Cleanup VM - may be placed on all nodes in the pattern and will clean filesystem files and directories not in use on that node. For example, it will remove DB2 from DMGR nodes. For each node, select the type using the script package drop down.
Additional script packages
Other commonly needed script packages are available as part of this wiki page in the Attachments section . These packages can be placed on various parts of your patterns for various, related configuration steps beyond what the base deployment provides. These are meant to be samples only and are a starting point to your own pattern customizations. For more details on script packages and patterns, see the PureApp Infocenters.
Current Script packages
Update IHS Plugin - placed on the IHS Part in a portal cluster pattern. This script package communicates with the deployment manager node to trigger a regeneration of the webserver plugin, capturing all newly deployed applications, or additional cluster members, copies the configuration back to the webserver node, and restarts the webserver. Because there may be multiple updates to a virtual system deployment, we recommend this script package be set to run "When I initiate it"
Script packages that are currently under development to be available soon
Add LDAP Configuration - placed on the Portal Part and Secondary Portal part. This script package augments the out of the box file-based registry with a proper LDAP server that exists on your network. Some updates to LDAP properties, such as hostname, suffixes, schemas, etc will be required in the included wkplcParent.properties
Modify HTTP Server working threads - placed on the IHS Only part. This script package modifies the number of worker threads in use by the IBM HTTP Server component in your deployment.
Performance Tuning - configures and tunes portal specifically for a high performing content rendering environment
ConfigEngine - Executes a specified ConfigEngine task, and allows additional arguments to be used in the task execution. A specific example of this includes calling the delete-passwords task to mask clear-text passwords in wkplc.properties.
Deploy PAA - Installs anddDeploys a Portal Application Archive
Content Template Catalog (CTC) - installs the CTC 4.2 set of templates, showcasing the
Script Portlet - installs the Script Portlet PAA
To deploy a pattern:
- Select a pattern to deploy, and then click the "Deploy in the cloud..." icon (). A prompt displays in which you can configure the deployment by setting the virtual system name, scheduling the deployment, and configuring each virtual machine. For the Digital Experience Patterns, the configuration consists of setting passwords and the cell and node names, determining whether to federate the node if it's the primary node, and enabling VNC.
- On the initial deployment window (see figure 9), specify a name for this deployment. Select a Cloud Group on which to deploy the pattern, and then click the "Configure virtual parts" link to provide the missing configuration details for the portal pattern, on a per-part basis.
Figure 9. Deploying a virtual system
3. As you click each part in the virtual system description window, a resulting window displays to set the required parameters for each part (see an example in figure 10). This include setting machine sizes, required passwords, node and cell identities.
Figure 10. Configuring the virtual machine
4. Click OK after filling out each part's required values in the window, and then click the OK button to start the deployment. The pattern engine will optionally notify you via email when the deployment has completed.
Working with an OVA instance
Congratulations on completing the deployment of a WebSphere Portal and Web Content Manager Patterns on PureApplication Systems.
We now brief you on how to get started with the system. For more information on how to administer, customize, and develop applications for the WebSphere Portal platform, refer to the WebSphere Portal and Web Content Manager product documentation page.
File system locations
Table 1 summarizes the locations for the file systems.
|WebSphere Portal installation directory||/opt/IBM/WebSphere/PortalServer|
|WebSphere Application Server installation directory||/opt/IBM/WebSphere/AppServer|
|Application server configuration profile for portal||/opt/IBM/WebSphere/Profiles/wp_profile |
|Deployment Manager configuration profile||/opt/IBM/WebSphere/Profiles/Dmgr01|
|DB2 install directory||/opt/ibm/db2 |
|DB2 instance directory||/home/db2inst1/db2inst1|
|WebSphere Portal log directory||/opt/IBM/WebSphere/Profiles/wp_profile/logs|
|IBM HTTP Server installation directory||/opt/IBM/HTTPServer|
|Portal Config Engine installation directory||/opt/IBM/WebSphere/ConfigEngine|
|Portal Config Wizard profile||/opt/IBM/WebSphere/Profiles/cw_profile|
|Installation Manager directory||/opt/IBM/InstallationManager|
Starting and stopping WebSphere Portal
You can start and stop WebSphere Portal by using the WebSphere Application Server startServer.sh and stopServer.sh shell scripts, respectively. By default WebSphere Portal is started at the end of deployment. For a cluster of WebSphere Portal instances, it is easier to start and stop instances and manage other resources from the Deployment Manager's administration console.
To manage individual server instances, even in a cluster, open a secure shell session with your new instance and change to the /opt/IBM/WebSphere/Profiles/wp_profile/bin directory. To start WebSphere Portal, run the following command as virtuser from within this directory:
Where server_Name is WebSphere_Portal for a standalone server, or the cluster member name running on this machine.
Likewise, stop WebSphere Portal using the following command within the same directory:
./stopServer.sh <server_name> -user virtuser -password <password>
Note that with the stopServer.sh script, you must specify the administrative user (virtuser) and password that were provided in the password configuration windows during initial setup of this instance.
Accessing the Deployment Manager console
To access the Deployment Manager administration console, in which individual cluster members can be managed centrally, open a browser and point it to the server where the Deployment Manager part was deployed, logging in as virtuser:
Starting and stopping the HTTP Server
The OVA comes pre-configured with the IBM HTTP Server to allow port 80 and 443 access to WebSphere Portal. By default, the HTTP Server is started only on cluster patterns with a remote IHS part. To stop the HTTP Server, change to the /opt/IBM/HTTPServer/bin directory and run the following command:
Likewise, to start the HTTP Server, run the command:
The HTTP Server reads its application server plug-in configuration from /opt/IBM/HTTPServer/Plugins/config/webserver1/plugin_cfg.xml, which is automatically refreshed during pattern deployment.
On standalone server deployments, the HTTP Server is on the same server as WebSphere Portal. In cluster pattern deployments, the HTTP Server is on the machine running the IHS Part.
Accessing the site from a browser
Different versions of the WebSphere Portal product use different ports in WebSphere Application Server for administration and direct access to the portal JVM. With the most current version of the Pattern, after WebSphere Portal has started, you can access it using the following URLs:
WebSphere Portal home page (if HTTP Server is stopped):
http://<public host name>:10039/wps/portal
WebSphere Portal home page (if HTTP Server is active):
http://<public host name>/wps/portal
WebSphere Application Server admin console (standalone pattern):
http://<public host name>:10042/ibm/console
WebSphere Application Server admin console (cluster pattern):
http://<public host name>:9060/ibm/console
Launching a deployment of WebSphere Portal using PureApp will create your portal using a default locale setting of English, however, there are several ways that Portal can present the web page in other locales. Browser settings can trigger page views in various locales without any change to the default setting. For more information on locale detection and on changing the default locale used in Portal, see the Language Support section in the IBM WebSphere Portal Information Center.
A WebSphere Portal Server and Web Content Manager instance based on this OVA can be serviced just like any other native installation of this software. Corrective service packages in the form of iFixes (or "interim fixes" that address a particular product issue) or CFs (regular, cumulative roll-ups of iFixes into a single installable unit) are available for download from the IBM Support Web sites:
From these sites you can search on problem symptoms and obtain information from Technotes, Redbooks publications, and fixes that can address problems. To install iFixes and fixpacks, you can use the Installation Manager already included.
Alternatively, you may wish to re-apply your customizations to a new instance created from an OVA that has been updated to a more recent service level by IBM. To do this, you must have extracted all custom artifacts from the instance so that they can be applied again, such as:
- Exported content libraries using the ConfigEngine's export-wcm-data configuration task
- Exported portal configuration using the xmlaccess utility
- Collecting all portlet WAR files and other J2E resources
These artifacts can be imported into the new instance using the appropriate administration utilities. Refer to the WebSphere Portal / WCM InfoCenter for topics on administering WebSphere Portal and the use of the xmlaccess utility and importing libraries:
Extending and capturing an OVA
After customizing an instance of a WebSphere Portal Server and Web Content Manager OVA with custom applications, site designs, and content libraries, you may want to build a new OVA based on this instance from which new instances can be created. Follow the instructions to prepare and capture a new OVA.
Extending a virtual image
To do this:
- Go to the virtual images catalog and select the OVA you wish to extend. It is recommended you use the Standalone server image.
- Click the extend icon (), enter the requested information, and click OK. A new virtual image is created, along with a single virtual machine of that image.
- Once the virtual machine is deployed, you can make any changes you wish to the virtual machine. These changes are what you will capture as a part of your new virtual image.
Capturing a virtual image
To do this:
- Capture the virtual image by clicking the capture icon ( ). When the capture is finished the virtual image will contain all the changes you made. Those changes will be reflected in any patterns you deploy that use that virtual image. WCA will automatically reset the virtual machine before capturing.
- You can recapture your virtual machine as many times as you like. When you are finished with your changes, you can mark the virtual image as read-only by clicking the Make read-only icon ().
Paging space adjustments (AIX only)
For memory intensive operations in extend/capture mode, it may be necessary to increase the AIX OS paging size. The following code will increase the paging size to 4G:
#show existing paging space
#reduce filesystem in tmp, which also shrinks the logical volume for reuse by
#the paging lv
chfs -a size=6G /tmp
#increase page space
chps -s 64 hd6
To reduce complexity, the WebSphere Portal Standalone pattern sets the password of the DB2 users to passw0rd on Intel patterns, and password on Power patterns. Depending on your scenario, consider changing the password at the OS and in the WebSphere datasource definitions
Passwords in wkplc.properties
By default, after deploying any Portal or WCM pattern, the WAS and Portal passwords are preserved in wkplc.properties. Use the ConfigEngine delete-passwords task, or the Portal Delete Passwords script package referenced above to mask these passwords
Some problems were uncovered during testing on current PureApp firmware. These will be fixed in future fixpacks of that firmware, and workarounds are listed if possible.
Pattern Editor Problems on Windows XP clients with Internet Explorer 8.0
Various problems, such as obsolete content, disappearing parts, etc occur when interacting with the pattern editor.
Pattern Editor "order" is not honored
When creating a multi-node cluster portal pattern in the PureApp Pattern Editor, the default order shows the HTTP Server starting last, as desired, but the virtual machine history shows the HTTP Server VM starting before the Secondary portal part. A workaround is to explicitly reposition the HTTP Server part as last in the ordering list
Unicode values for Cell and Node names cause instance failure
When deploing a pattern, specifying Unicode characters for the Cell and/or Node names cause problems during instance startup and the system in not correctly initialized.
Warning message when placing parts on a pattern
If you add the Portal Part to a blank pattern before the DMGR part, a warning message indicating "There are no custom nodes federated to the deployment manager",even after the DMGR node is added. Workaround is to remove all the parts and begin the pattern with the DMGR part
WebSphere monitoring does not detect the Portal Deployment manager or WebSphere_Portal JVMs
Selecting the monitor link inside a deployment virtual machine does show the OS, HTTP Server monitors, but the Portal Java processes are not detected. This should be fixed in PureApp fixpack 4
Prerequisite PureApp fix levels
For large cluster deployments on heavily used PureApp systems, a time limit may be reach causing deployments to fail with a virtual system instance status of "Some virtual machines within the virtual system did not initialize correctly". The time limit is increased with PureApp fixpack 2