|
| |
| Sun Java Enterprise System 5 Upgrade Guide for UNIX | |
Chapter 15
Portal ServerThis chapter describes how to upgrade Portal Server to Java ES 5 (Release 5): Sun Java System Portal Server 7.1.
The chapter provides an overview of upgrade considerations for the different upgrade paths supported by Release 5. The chapter covers upgrades on both the Solaris and Linux operating systems:
Overview of Portal Server UpgradesThis section describes the following general aspects of Portal Server that impact upgrading to Java ES 5 (Release 5):
About Java ES Release 5 Portal Server
Java ES Release 5 Portal Server represents a major release with respect to Release 4, with many new enhancements and features. Many of these changes were made in an Interim Feature Release (IFR) subsequent to Release 4. Release 5 represents only minor feature changes with respect to the IFR. For information about the IFR enhancements and new features, see the Sun Java System Portal Server 7.1 Release Notes, http://docs.sun.com/doc/819-4986/6n4l3f365?a=view. In particular, the Release 4 command line administrative interface has been replaced by the psadmin command.
Portal Server Upgrade Roadmap
Table 15-2 shows the supported Portal Server upgrade paths to Java ES Release 5. The table applies to both Solaris and Linux operating systems.
Portal Server Data
The following table shows the type of data that could be impacted by an upgrade of Portal Server software.
Portal Server Upgrade Strategy
Your strategy for upgrading Portal Server generally depends on the many considerations discussed in Chapter 1, "Planning for Upgrades": upgrade path, dependencies between Java ES components, selective upgrade versus upgrade all, multi-instance deployments, and so forth.
This section is to particularize that general discussion to Portal Server by presenting issues that might influence your Portal Server upgrade plan.
Compatibility Issues
Release 5 Portal Server introduces public interface changes in the psadmin command used to administer Portal Server and Portal Server Secure Remote Access components. See the Sun Java System Portal Server 7.1 Command-Line Reference, http://docs.sun.com/doc/819-5030.
Hence, Release 5 Portal Server is not backwardly compatible with earlier versions, or with earlier versions of Portal Server Secure Remote Access components (including the SRA Gateway, the Rewriter Proxy, and the Netlet Proxy), except for a transitional period in which multi-instance deployments are undergoing a rolling upgrade. All Portal Server instances need to be synchronized, along with Portal Server Secure Remote Access component instances, at Java ES Release 5.
Also, individual Portal Server components, including the mobile access component, are not backwardly compatible with earlier versions; all need to be synchronized to Java ES Release 5.
In addition, there is an incompatibility between the Directory Server data structures used by Release 5 Portal Server and earlier Portal Server versions. This incompatibility impacts a rolling upgrade of multiple Portal Server instances using the same Directory Server data.
Portal Server Dependencies
Portal Server dependencies on other Java ES components can impact your procedure for upgrading and re-configuring Portal Server software. Changes in Portal Server interfaces or functions, for example, could require upgraded version of components upon which Portal Server depends. The need to upgrade such components depends upon the specific upgrade path.
Portal Server has dependencies on the following Java ES components:
- Shared components. Portal Server has dependencies on specific Java ES shared components (see Table 1-9).
- Web Container. Portal Server has a mandatory dependency on web container services, which can be provided either by Java ES Web Server, Java ES Application Server, or by third-party web containers from Weblogic and WebSphere.
- Access Manager (or Access Manager SDK). Portal Server has a mandatory dependency on Access Manager to provide authentication and authorization services for end users, including single sign-on. If Access Manager is run on a remote computer, then Access Manager SDK must be available locally.
- Directory Server. Portal Server has a mandatory dependency on Directory Server, which stores user data accessed by way of Access Manager. As a result, Portal Server upgrades might require extensions of directory schema.
- Portal Server Secure Remote Access. Portal Server has an optional dependency on Portal Server Secure Remote Access, which provides secure remote access through the Gateway, Rewriter Proxy, and Netlet Proxy components.
- Java DB. Portal Server has an optional dependency on Java DB, which provides support for several portlet applications.
- Service Registry. Portal Server has a mandatory dependency on Service Registry, which provides libraries needed for compilation.
- Communications Express. Portal Server has an optional dependency on Communications Express, a Sun Java Communications Suite component, which is used to provide messaging and calendar channels to end users. Communications Express is no longer a Java ES product component.
Selective Upgrade Issues
While, in general, Java ES Release 5 supports selective upgrade of all components on a computer, the fact that Portal Server has dependencies on so many other Java ES components makes it very difficult to certify arbitrary combinations of components across various Java ES release versions.
For this reason, Portal Server supports a restricted set of upgrade scenarios with respect to Access Manager and web containers.
- If you are upgrading Portal Server from Java ES Release 4. You can either upgrade Directory Server, Access Manager, and web container (Web Server or Application Server) to Release 5 before upgrading Portal Server, or you can upgrade only Portal Server to Release 5 (leaving the other components at their Release 4 levels), but you cannot leave some dependencies at Release 4 and upgrade others to Release 5.
- If you are upgrading Portal Server from Java ES Release 3. You have to upgrade Directory Server, Access Manager, and web container (Web Server or Application Server) to Release 4 or to Release 5 before upgrading Portal Server, but you cannot leave any dependencies at Release 3, nor upgrade some dependencies to Release 4 and others to Release 5.
- If you are upgrading Portal Server from Java ES Release 2. You have to upgrade Directory Server, Access Manager, and web container (Web Server or Application Server) to Release 4 or to Release 5 before upgrading Portal Server. You cannot leave any dependencies at Release 2, nor upgrade some dependencies to Release 4 and others to Release 5.
Web Container Upgrade Scenarios
Portal Server can be deployed in a web container provided by either Web Server or Application Server. As a result, the upgrade of Portal Server to Release 5 can be complicated by the possibility of also having upgraded to Release 5 the web container in which it is deployed. In this regard, there are a number of web container upgrade scenarios possible, enumerated in the following table.
You must be careful when upgrading Portal Server (for example when using the psupgrade script) to provide values appropriate to the upgrade scenario in Table 15-4 that applies, especially when there is a major version upgrade of the web container.
Dual Upgrade
Dual upgrades, in which both Portal Server and operating system are upgraded (as described in Dual Upgrades: Java ES and Operating System Softwared) can be performed using the in-place operating system upgrade approach:
- Back up existing Portal Server data.
See Portal Server Data for the location of essential data.
- Upgrade the operating system.
The upgrade leaves the existing file system in place.
- Upgrade to Release 5 Portal Server.
See the appropriate section of this chapter, depending on upgrade path.
Upgrading Portal Server from Java ES Release 4This section includes information about upgrading Portal Server from Java ES 2005Q4 (Release 4) to Java ES 5 (Release 5).
The section covers the following topics:
Introduction
When upgrading Java ES Release 4 Portal Server to Release 5, consider the following aspects of the upgrade process:
- General Upgrade Approach. The upgrade is performed using an upgrade script, psupgrade. The script installs new packages, migrates configuration data when necessary, updates localization files, and re-deploys Portal Server web applications to the web container.
- Upgrade Dependencies. Portal Server has dependencies on a number of Java ES shared components (see Table 1-9). While Release 5 Portal Server is compatible with the Release 4 version of these shared components, upgrade of shared components is nevertheless necessary because the psupgrade script used to upgrade Portal Server requires the Release 5 version of the ANT shared component.
Release 5 Portal Server also has dependencies upon a web container, Access Manager, and Directory Server, as described in Portal Server Dependencies. Two approaches to upgrading these dependencies are supported (see Selective Upgrade Issues):
- Backward Compatibility. Release 5 Portal Server is not backwardly compatible with the Release 4 version.
- Upgrade Rollback. Rollback of the Release 5 upgrade of Portal Server to Release 4 consists of restoring Release 4 packages, restoring Release 4 Directory data, and redeploying Portal Server web applications to the web container.
- Platform Issues. The general approach for upgrading Portal Server is the same on both Solaris and Linux operating systems, however release 5 Portal Server is installed in a new path on Solaris OS, but in the same Release 4 path on Linux OS.
Release 4 Portal Server Upgrade
This section describes how to perform an upgrade of Portal Server from Java ES Release 4 to Java ES Release 5 on both the Solaris and Linux platform. Where a topic depends on platform-specific procedures, the topic will indicate the operating system to which it applies. The section covers the following topics:
Release 4 Pre-Upgrade Tasks
Before you upgrade Portal Server, you should perform the following tasks:
Verify Current Version Information
You can verify the current version of Portal Server using the following command:
PortalServer6-base/bin/version
Table 15-5 Portal Server Version Verification Outputs
Java ES Release
Portal Server Version Number
Release 2
6.3
Release 3
6.3.1
Release 4
6.3.11
IFR Release
7.0
Release 5
7.1
1The only difference between Release 3 and Release 4 is a patch. You can check for the Release 4 patches using the Solaris showrev -p | grep patch_ID command and the Linux rpm -qa sun-portal-core command and comparing the versions to those listed in the Java ES Release 4 Upgrade Guide.
Upgrade Portal Server Dependencies
It is generally recommended that all Java ES components on a computer system (and in a computing environment) be upgraded to Java ES Release 5.
While Release 5 Portal Server is compatible with the Release 4 version of Java ES shared components, upgrade of shared components is nevertheless necessary because the psupgrade script used to upgrade Portal Server requires the Release 5 version of the ANT shared component.
If you choose to upgrade any of the Portal Server product component dependencies to Release 5, they all need to be upgraded (see Selective Upgrade Issues). The dependencies should be upgraded in the order below (skipping any that might already have been upgraded), before you upgrade Portal Server.
- Shared Components. Instructions for synchronizing Java ES shared components to Release 5 are provided in Upgrading Java ES Shared Components.
- Directory Server. Instructions for upgrading Directory Server to Release 5 are provided in Chapter 5, "Directory Server".
- Web Container Software. Instructions for upgrading Web Server or Application Server are provided in Chapter 7, "Web Server" and Chapter 11, "Application Server", respectively.
- Access Manager (Access Manager SDK). Instructions for upgrading Access Manager to Release 5 are provided in Chapter 14, "Access Manager".
- Portal Server Secure Remote Access. Instructions for upgrading Portal Server Secure Remote Access to Release 5 are provided in Chapter 16, "Portal Server Secure Remote Access".
- Java DB. Instructions for upgrading Java DB to Release 5 are provided in Chapter 8, "Java DB".
- Service Registry. Instructions for upgrading Service Registry to Release 5 are provided in Chapter 12, "Service Registry".
- Communications Express. Instructions for upgrading Communications Express to Release 5 are provided in the Sun Java Communications Suite Upgrade Guide, http://docs.sun.com/doc/819-7561.
Obtain Required Configuration Information and Passwords
Depending on the web container upgrade scenario (see Table 15-4), the psupgrade script requires you to input information about passwords and other web container configuration data. The information required for different web container upgrade scenarios is shown in Table 15-6. Be sure to assemble the relevant information before beginning the Portal Server upgrade.
Table 15-6 Information Required by psupgrade Script per Web Container Upgrade Scenario
Information
Upgrade Scenario1
Web Server 7.x Example Values:
Scenario 2Application Server 8.x Example Values:
Scenario 52Upgrade Portal Server on Web Server 7.0 (yes/no)
2
Yes
N/A
Web Container Install Directory
2 and 5
WebServer7-base
AppServer8Install-base
Web Container Virtual Server Instance Name
2
https-configName2
N/A
Web Container Instance Name
5
N/A
server1
Web Container Instance Directory
2
WebServer7Config-base/
https-configName4/N/A
Portal Instance Deploy Directory
5
N/A
AppServer8Config-base/
domains/domainNameWeb Container Instance Port
2 and 5
80
80
Web Container Instance Protocol
2 and 5
http
http
Web Container Config Name
2
configName4
N/A
Web Container Domain Name
5
N/A
domain1
Web Container Docs Root Directory
2 and 5
WebServer7Config-base/
https-configName4/docs/AppServer8Config-base/
domains/domainName/
docrootWeb Container Admin Hostname
2 and 5
localhost
localhost
Web Container Admin Port
2 and 5
8989
4848
Web Container Admin Protocol
2 and 5
https
https
Web Container Admin User ID
2 and 5
admin
admin
Web Container Admin Password
2 through 5
Web Container Master Password
3 through 5
N/A
Directory Manager (cn=Directory manager) Password
1 through 5
SRA Log User Password3
1 through 5
Access Manager Admin Password
1 through 5
Directory Server ldapuser Password
1 through 5
Portal Instance ID4
1 through 5
1Web Container Upgrade Scenario #5 applies to upgrading Portal Server from Release 2.
2The default value of configName is hostName.domainName.
3This information is needed to configure Portal Server Secure Remote Access components when installed with Portal Server.
4A unique, non-null, value must be provided for this parameter. Values must be alpha numeric, and can include a hyphen (-).
Back Up Release 4 Portal Server Configuration Information
Upgrade of Portal Server to Release 5 does not require the reconfiguration of Portal Server software. However, as a safety measure the psupgrade script will back up the following directories where configuration information is stored:
Record Java Virtual Machine (JVM) Settings
Please record the following web container JVM settings, if different from the default values, before upgrading Portal Server:
The location of the JVM settings depends on web container, as indicated in the following table.
You will need to check later that these JVM settings have not been changed as a result of the Portal Server upgrade procedure.
Remove Configuration for Load Balancer
In cases in which Portal Server instances are accessed through a load balancer, the value of the LOAD_BALANCER_URL property used to configure such access can interfere with Portal Server upgrade. This setting must therefore be modified before performing the upgrade. To modify the LOAD_BALANCER_URL property setting:
- Note which of the following configuration files are locally resident (some of which support Portal Server Secure Remote Access components that might be locally installed):
PortalServer6Config-base/PSConfig.properties
PortalServer6Config-base/GWConfig.properties (if Gateway is local)
PortalServer6Config-base/RWPConfig.properties (if Rewriter Proxy is local)
PortalServer6Config-base/NLPConfig.properties (if Netlet Proxy is local)- Record the current value of the LOAD_BALANCER_URL property in these configuration files.
- Modify the value of the LOAD_BALANCER_URL property to point to the relevant Portal Server instance:
LOAD_BALANCER_URL=portalHostName:port/portal
Remove Configuration for Directory Proxy Server
In cases in which Portal Server instances access Directory Server through a Directory Proxy Server instance, the Directory Proxy Server host and port number settings must be modified before performing the upgrade and then restored to their original values after upgrade is complete.
To modify the appropriate settings:
Upgrading Release 4 Portal Server (Solaris)
This section discusses considerations that impact the upgrade procedure for Portal Server followed by a description of the procedure itself.
Upgrade Considerations (Solaris)
The upgrade of Portal Server software to Release 5 takes into account the following considerations:
- All Portal Server instances corresponding to the same installed Portal Server image are upgraded at the same time.
- Portal Server software consists of subcomponents that perform a number of different roles, but are all upgraded together:
- Portal-base. Includes administrative Mbeans and accompanying administrative software, Logging Framework, and monitoring-related software, all of which are packaged together.
- Portal Server web applications. Consists of a number of web applications that are deployed in a web container. At least some of these web applications require support from Access Manager and, in turn, Directory Server.
- Secure Remote Access core. Software that supports Portal Server Secure Remote Access: some servlets and applets embedded in jar files and some supporting files that cannot be deployed in a web container.
- The psupgrade script automatically detects which Portal Server subcomponents and which web container dependencies are installed on the host computer. For example, the script queries the system to detect the version of Application Server or Web Server to which you are deploying Portal Server web applications, and tailors the information it requests depending on the information it can detect.
Upgrade Procedure (Solaris)
The procedure documented below applies to Portal Server on the computer where the upgrade is taking place.
- Log in as root or become superuser.
su -
- If you have not already done so, synchronize all shared components to Release 5.
Instructions are provided in Chapter 2, "Upgrading Java ES Shared Components".
This step is a necessary prerequisite to running the psupgrade script in Step 8.
- Stop any instances of the Portal Server Secure Remote Access Gateway, Rewriter Proxy, or Netlet Proxy that might be running locally.
PortalServer6-base/bin gateway stop
PortalServer6-base/bin netletd stop
PortalServer6-base/bin rwproxyd stopCheck that the processes have stopped:
Gateway: netstat -an | grep 443
Rewriter Proxy: netstat -an | grep 10443
Netlet Proxy: netstat -an | grep 10555- Make sure Access Manager is running if it is deployed to a web container different from the one to which Portal Server is deployed.
- If not already running, start Portal Server by starting the web container to which it is deployed.
Web Server 6.x:
WebServer-base/https-instanceName/startWeb Server 7.0:
Admin Server--
WebServer7Config-base/admin-server/bin/startserv
Instance Server--
WebServer7Config-base/https-configName/bin/startservApplication Server 8.x:
AppServer8-base/bin/asadmin start-domain --user admin_ID
--password password domainName- Set two environment variables (ANT_HOME and JAVA_HOME) needed by the psupgrade script. For example,
export ANT_HOME=/usr/sfw
export JAVA_HOME=/usr/jdk/entsys-j2se- Make sure you have adequate swap space on your computer.
As a guideline, the swap space should be set to twice the amount of physical ram.
- Run the psupgrade script from the Java ES Release 5 distribution.
cd os_arch/Products/portal_svr/Tools/upgrade/bin
./psupgradewhere os_arch matches your platform, such as Solaris_sparc.
Note
If you inadvertently run psupgrade from the wrong os_arch directory, you need to back out the procedure as follows:
The psupgrade script detects installed Portal Server components and localization packages, invokes the Java ES installer to install new packages, and queries the system to detect the location and port number and other information regarding the web container to which you are deploying Portal Server web applications. Depending on web container upgrade scenario (see Table 15-4), the script requests you to input additional information required to deploy Portal Server to the appropriate web container.
Table 15-6 shows the information requested for the different web container upgrade scenarios in Table 15-4.
- If necessary, restore web container JVM settings.
To make sure that JVM settings support Release 5 Portal Server, perform the following steps:
- Check that the web container JVM settings for Portal Server that you recorded before upgrade have not changed as a result of the upgrade procedure.
See Record Java Virtual Machine (JVM) Settings.
- If the settings have changed, restore them to the values you recorded before upgrade.
Make sure the following JVM settings are included even if they were not previously set:
<jvm-options>-XX:MaxPermSize=256m</jvm-options>
<jvm-options>-XX:+CMSPermGenSweepingEnabled</jvm-options>
<jvm-options>-XX:+CMSClassUnloadingEnabled</jvm-options>- Stop and restart the web container.
While not required in all situations, restarting the web container ensures that Portal Server starts in a clean state.
- Stop the web container as follows:
Web Server 6.x:
WebServer-base/https-instanceName/stopWeb Server 7.0:
Admin Server--
WebServer7Config-base/admin-server/bin/stopserv
Instance Server--
WebServer7Config-base/https-configName/bin/stopservApplication Server 8.x:
AppServer8-base/bin/asadmin stop-domain --user admin_ID
--password password domainName- Restart the web container using the commands in Step 5.
Upgrading Release 4 Portal Server (Linux)
This section discusses considerations that impact the upgrade procedure for Portal Server followed by a description of the procedure itself.
Upgrade Considerations (Linux)
The upgrade of Portal Server software to Release 5 on the Linux platform takes into account the same considerations as on the Solaris platform (see Upgrade Considerations (Solaris)), except that Release 5 Portal Server is installed in the same path as Release 4 on Linux OS. As a result, the psupgrade script removes the previous RPMs when installing the Release 5 RPMs.
Upgrade Procedure (Linux)
The procedure documented below applies to Portal Server on the computer where the upgrade is taking place.
Caution
An upgrade from Java ES Release 4 to Release 5 on Linux cannot be rolled back. Make sure you back up your system before performing the following procedure.
- Log in as root or become superuser.
su -
- If you have not already done so, synchronize all shared components to Release 5.
Instructions are provided in Chapter 2, "Upgrading Java ES Shared Components".
This step is a necessary prerequisite to running the psupgrade script in Step 8.
- Stop any instances of the Portal Server Secure Remote Access Gateway, Rewriter Proxy, or Netlet Proxy that might be running locally.
PortalServer6-base/bin gateway stop
PortalServer6-base/bin netletd stop
PortalServer6-base/bin rwproxyd stopCheck that the processes have stopped:
Gateway: netstat -an | grep 443
Rewriter Proxy: netstat -an | grep 10443
Netlet Proxy: netstat -an | grep 10555- Make sure Access Manager is running if it is deployed to a web container different from the one to which Portal Server is deployed.
- If not already running, start Portal Server by starting the web container to which it is deployed.
Web Server 6.x:
WebServer-base/https-instanceName/startWeb Server 7.0:
Admin Server--
WebServer7Config-base/admin-server/bin/startserv
Instance Server--
WebServer7Config-base/https-configName/bin/startservApplication Server 8.x:
AppServer8-base/bin/asadmin start-domain --user admin_ID
--password password domainName- Set two environment variables (ANT_HOME and JAVA_HOME) needed by the psupgrade script. For example,
export ANT_HOME=/opt/sun
export JAVA_HOME=/usr/jdk/entsys-j2se- Make sure you have adequate swap space on your computer.
As a guideline, the swap space should be set to twice the amount of physical ram.
- Run the psupgrade script from the Java ES Release 5 distribution.
cd os_arch/Products/portal_svr/Tools/upgrade/bin
./psupgradewhere os_arch matches your platform, such as Linux_x86.
The psupgrade script detects installed Portal Server components and localization packages, invokes the Java ES installer to install new packages, and queries the system to detect the location and port number and other information regarding the web container to which you are deploying Portal Server web applications. Depending on web container upgrade scenario (see Table 15-4), the script requests you to input additional information required to deploy Portal Server to the appropriate web container.
Table 15-6 shows the information requested for the different web container upgrade scenarios in Table 15-4.
- Modify the PortalServer7Config-base/platform.conf.default configuration file.
Copy the line with gateway.logging.password from the following file, which was backed up by psupgrade:
PortalServer6Config-base.bak/platform.conf.default
and place the line in PortalServer7Config-base/platform.conf.default.
- If necessary, restore web container JVM settings.
To make sure that JVM settings support Release 5 Portal Server, perform the following steps:
- Check that the web container JVM settings for Portal Server that you recorded before upgrade have not changed as a result of the upgrade procedure.
See Record Java Virtual Machine (JVM) Settings.
- If the settings have changed, restore them to the values you recorded before upgrade.
Make sure the following JVM settings are included even if they were not previously set:
<jvm-options>-XX:MaxPermSize=256m</jvm-options>
<jvm-options>-XX:+CMSPermGenSweepingEnabled</jvm-options>
<jvm-options>-XX:+CMSClassUnloadingEnabled</jvm-options>- Stop and restart the web container.
While not required in all situations, restarting the web container ensures that Portal Server starts in a clean state.
- Stop the web container as follows:
Web Server 6.x:
WebServer-base/https-instanceName/stopWeb Server 7.0:
Admin Server--
WebServer7Config-base/admin-server/bin/stopserv
Instance Server--
WebServer7Config-base/https-configName/bin/stopservApplication Server 8.x:
AppServer8-base/bin/asadmin stop-domain --user admin_ID
--password password domainName- Restart the web container using the commands in Step 5.
Verifying the Upgrade
You can verify the installation of Release 5 packages using the following command:
See Table 15-5 for output values.
To verify the full upgrade, confirm that the Portal Desktop comes up and the psadmin administration utility functions as documented.
You can also check the following upgrade log files:
Release 4 Post-Upgrade Tasks
Please note the post-upgrade procedures required to address the following situations:
Migrate Custom web-src Data
If you have added custom data, such as images, javascript files or any other files for constructing portal.war to the following directory:
PortalServer6-base/web-src
you have to copy these additional files to the corresponding directory in Release 5 Portal Server:
PortalServer7-base/web-src
Redeploy Custom Portlet Applications
If you have created and deployed custom portlet applications, then these portlets must be manually redeployed after upgrade to Release 5 Portal Server. Even though display profile entries will exist and the channel name will be displayed, content will not be seen until you redeploy your custom portlets.
Redeploy portlets using the following command:
PortalServer7-base/bin/psadmin deploy-portlet
You can confirm redeployment by looking for the corresponding .war and XML files in the following location:
PortalServer7Data-base/portals/Upgraded/war
Migrate Customized Portlet Applications
Portlet applications based on the user interface framework provided by Sun Java Web Console (SJWC) need to be manually migrated to Release 5 and redeployed.
In particular, this requirement applies to four web applications distributed with Portal Server as sample portlet applications meant to be customized and installed into a portal: filesharing, surveys, wiki, rssportlet. During upgrade, bug-fixed versions of these sample portlet applications are placed on disk in the portlet applications area. If you have customized these portlet applications for your own use, you need to manually migrate them to Release 5 and redeploy them; they are not handled by the Portal Server upgrade process.
By default, some of these portlet applications (filesharing and surveys) are deployed and available for users when a community is created.
You can upgrade, customize, and redeploy SJWC-based portlet applications using the following procedure. The filesharing portlet application is used as an example:
- Extract the Release 5 SJWC jar files.
- mkdir /tmp/lh
- cd /tmp/lh
- /usr/jdk/entsys-j2se/bin/jar xvf PortalServer7-base/portlet/communityportlets.war
WEB-INF/lib/commons-beanutils.jar
WEB-INF/lib/commons-collections-3.1.jar
WEB-INF/lib/commons-digester.jar
WEB-INF/lib/commons-logging.jar
WEB-INF/lib/dataprovider.jar WEB-INF/lib/jsf-api.jar
WEB-INF/lib/jsf-impl.jar WEB-INF/lib/webui.jar- Rename one of the files.
mv WEB-INF/lib/commons-collections-3.1.jar
WEB-INF/lib/commons-collections.jar- Locate the filesharing portlet application.
cd PortalServer7Config-base/portals/portal1/portletapps/filesharing
- Inject the updated SJWC libraries.
jar uvf src/filesharing.war.tokenized -C /tmp/lh WEB-INF
- Customize the filesharing portlet application.
ant customize
- Redeploy the filesharing portlet application.
- PortalServer7-base/bin/psadmin undeploy-portlet -u amadmin
-f passwordfile -p portal_id -i instance_id -g filesharing- ant deploy
- Go to the following directory (depending on web container):
Application Server 8.x:
AppServer8Config-base/domains/domain1/applications/j2ee-modules/
communityportlets/WEB-INFWeb Server 6.x:
WebServer6-base/https-instanceName/webapps/https-instanceName/
communityportlets/WEB-INFWeb Server 7.x:
WebServer7Config-base/https-configName/web-app/https-configName/
communityportlets/WEB-INF- Open the sun-web.xml file and add the following line just before the last line (that is, before the sun-web-app end tag):
<class-loader delegate="false"/>
- Repeat Step 2 through Step 5 for surveys and any other custom portlet application based on the SJWC framework.
- Restart the web container.
Correct Links in Bookmark and Application Channels
When upgrading Release 4 Portal Server to Release 5, the bookmark and application channels have duplicate and spurious links. To fix these links, perform the following procedure.
- Log in to PSConsole.
- From the Common Tasks tab, click on Manage Channels & Containers.
- Choose DeveloperSample [Org] as DN and click OK.
- Select JSPTabContainer [default] as the View Type.
- Under MyFrontPageTabPanelContainer, click on App Channel.
App channel properties will be displayed on the right-hand side frame.
To view properties for a specific locale, Click on Table Preferences and provide the Locale value: de, fr, es, ja, ko, zh, zh_CN, zh_TW.
- Edit the userApps property.
- Edit the target property.
- In target property click on [Edit Values...] link
A pop-up window with existing targets will appear.
- Remove the following targets from the list:
NetMailLite|
NetMailServlet?nsid=newHTMLSessionNetMailLite|
NetMailServlet?nsid=newHTMLSessionNetMail|NetMailServlet?nsid=newAppletSession
- Remove the duplicate occurrence of the following targets:
Instant Messenger (Java WebStart)|
IMLaunch?provider=IMChannel&launch=jnlp&last=falseCorrect Access to Search Server
When upgrading Release 4 Portal Server to Release 5, the search server is separated from Portal Server and URL access to the search server is therefore changed.
As a result, you have to manually modify the Display Profiles for all portal channels that implement the SearchProvider or DiscussionProvider interfaces, such as Search, DiscussionLite, Discussions, and Instant Messaging Channel. In particular, you have to modify the searchServer property of these channels, at whatever organizational or role level they might occur within the Display Profile, to correctly reference the search server. Modify the searchServer value as follows:
Also, for the Instant Messaging Channel, the Instant Messaging Server configuration property, iim_arch.portal.search, needs to be updated with the new search server URL.
Restore Configuration for Directory Proxy Server
If Portal Server instances have accessed Directory Server through a Directory Proxy Server instance, the Directory Proxy Server host and port number settings must be restored to their original values before upgrade. See Remove Configuration for Directory Proxy Server, in which the values of these properties was modified in preparation for upgrade.
Manually Register Portal Server Secure Remote Access Components
If you encounter a Null Pointer exception issue reported to the standard output at the end of the upgrade procedure, it means registration of Portal Server Secure Remote Access components, if any, has failed.
In this situation, you can manually register (enable) the Portal Server Secure Remote Access components by executing the following command:
PortalServer7-base/bin/psadmin provision-sra -u amadminUser -f passwordFile
-p Portal_ID --gateway-profile profileName --enableEnable the URLScrapper Channel
When upgrading from Release 4 to Release 5, you have to enable the URLScrapper channel. Use the following procedure:
- Log in to Portal Server Console
Click on Portal tab and then click on upgraded portal.
- From the Select DN drop down menu, select TopLevel (Global) and click on Download Display Profile link.
Store the downloaded file in some temporary location
- Locate com.sun.portal.providers.urlscraper.URLScraperProvider.
- Locate the XML portion starting with:
<Provider advanced="false" class="com.sun.portal.providers.urlscraper.URLScraperProvider"
and ending with:
</Provider>
- Replace the XML portion in Step 4 with the following:
<Provider advanced="false" class="com.sun.portal.providers.urlscraper.URLScraperProvider" container="false" lock="false" merge="fuse" name="URLScraperProvider" version="2">
<Properties advanced="false" lock="false" merge="fuse" name="_properties" propagate="true">
<String advanced="false" lock="false" merge="replace" name="title" propagate="true" value="UrlScraper Channel"/>
<String advanced="false" lock="false" merge="replace" name="description" propagate="true" value="This is a test for urlscraper"/>
<Boolean advanced="true" lock="false" merge="replace" name="isEditable" propagate="true" value="false"/>
<Boolean advanced="true" lock="false" merge="replace" name="isTopLevel" propagate="true" value="false"/>
<String advanced="true" lock="false" merge="replace" name="editType" propagate="true" value="edit_subset"/>
<Boolean advanced="true" lock="false" merge="replace" name="enableUBT" propagate="true" value="false"/>
<String advanced="false" lock="false" merge="replace" name="urlScraperRulesetID" propagate="true" value="default_ruleset"/>
<String advanced="false" lock="false" merge="replace" name="width" propagate="true" value="thick"/>
<String advanced="true" lock="false" merge="replace" name="refreshTime" propagate="true" value="0"/>
<String advanced="true" lock="false" merge="replace" name="helpURL" propagate="true" value="en/desktop/urlscrpr.htm"/>
<String advanced="false" lock="false" merge="replace" name="url" propagate="true" value=""/>
<String advanced="false" lock="false" merge="replace" name="fontFace1" propagate="true" value="Sans-serif"/>
<String advanced="false" lock="false" merge="replace" name="productName" propagate="true" value="Sun JavaTM System Portal Server 7"/>
<Boolean advanced="false" lock="false" merge="replace" name="cookiesToForwardAll" propagate="true" value="true"/>
<String advanced="false" lock="false" merge="replace" name="inputEncoding" propagate="true" value="UTF-8"/>
<Collection advanced="false" lock="false" merge="fuse" name="cookiesToForwardList" propagate="true"/>
<Integer advanced="false" lock="false" merge="replace" name="timeout" propagate="true" value="100"/>
<String advanced="true" lock="false" merge="replace" name="formData" propagate="true" value=""/>
<Boolean advanced="true" lock="false" merge="replace" name="isHttpAuth" propagate="true" value="false"/>
<String advanced="true" lock="false" merge="replace" name="loginUrl" propagate="true" value=""/>
<String advanced="true" lock="false" merge="replace" name="loginFormData" propagate="true" value=""/>
<String advanced="true" lock="false" merge="replace" name="uid" propagate="true" value=""/>
<String advanced="true" lock="false" merge="replace" name="password" propagate="true" value=""/>
<ConditionalProperties advanced="false" condition="client" lock="false" merge="fuse" propagate="true" value="HTML">
<ConditionalProperties advanced="false" condition="locale" lock="false" merge="fuse" propagate="true" value="en">
<String advanced="true" lock="false" merge="replace" name="helpURL" propagate="true" value="en/desktop/urlscrpr.htm"/>
<String advanced="false" lock="false" merge="replace" name="url" propagate="true" value=""/>
</ConditionalProperties>
<String advanced="true" lock="false" merge="replace" name="helpURL" propagate="true" value="en/desktop/urlscrpr.htm"/>
<String advanced="false" lock="false" merge="replace" name="url" propagate="true" value=""/>
</ConditionalProperties>
<ConditionalProperties advanced="false" condition="locale" lock="false" merge="fuse" propagate="true" value="en">
<String advanced="false" lock="false" merge="replace" name="title" propagate="true" value="UrlScraper Channel"/>
<String advanced="false" lock="false" merge="replace" name="description" propagate="true" value="This is a test for urlscraper"/>
</ConditionalProperties>
</Properties>
</Provider>
- Save and upload the modified file.
Change in Logout Page
The Release 5 Portal Server logout page has been changed from the previous Access Manager logout page. Please note that this change does not represent a defect in the software.
Rolling Back the Upgrade (Solaris)
This section describes considerations that impact the upgrade rollback procedure for Portal Server followed by the procedure itself.
Rollback Considerations (Solaris)
The procedure for rolling back the upgrade to Release 5 consists of reverting back to the Release 4 installation at PortalServer6-base and redeploying the Release 4 web applications.
Rollback Procedure (Solaris)
- Log in as root or become superuser.
su -
- Restore Directory Server to the state it was in before upgrade.
Use the Directory Server backup/restore command line and GUI utilities. See the Directory Server Backup and Restore chapter of the Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide, http://docs.sun.com/doc/819-0995.
- Stop Portal Server by stopping its web container.
Web Server 6.x:
WebServer-base/https-instanceName/stopWeb Server 7.0:
Admin Server--
WebServer7Config-base/admin-server/bin/stopserv
Instance Server--
WebServer7Config-base/https-configName/bin/stopservApplication Server 8.x:
AppServer8-base/bin/asadmin stop-domain --user admin_ID
--password password domainName- Remove the Release 5 Portal Server packages.
- Restart Portal Server by restarting its web container.
Web Server 6.x:
WebServer-base/https-instanceName/startWeb Server 7.0:
Admin Server--
WebServer7Config-base/admin-server/bin/startserv
Instance Server--
WebServer7Config-base/https-configName/bin/startservApplication Server 8.x:
AppServer8-base/bin/asadmin start-domain --user admin_ID
--password password domainName- Re-deploy the Release 4 Portal Server web applications using the following command from the Java ES Release 5 distribution:
cd os_arch/Products/portal_svr/Tools/upgrade/bin
./psupgrade rollbackwhere os_arch matches your platform, such as Solaris_sparc.
The psupgrade rollback command un-deploys Release 5 Portal Server web applications and re-deploys Release 4 Portal Server web applications.
The command redeploys content from PortalServer6-base/web-src to /var/PortalServe6-base/https-hostName/deploy-dir/web-apps. Any customizations to the Portal Server web application should therefore be first made to /web-src and then deployed to /web-apps. Any changes you might make under /web-apps should be replicated in /web-src before running the psupgrade rollback command, or such changes will be overwritten.
- Stop and restart the web container.
While not required in all situations, restarting the web container ensures that Portal Server starts in a clean state.
Rolling Back the Upgrade (Linux)
Because the upgrade to Release 5 requires the removal of the Release 4 binaries, it is very difficult to roll back the upgrade on Linux.
One approach to rollback would be to create a parallel system before upgrading and testing that system before attempting an upgrade. If you need to roll back the upgrade, you can revert back to that parallel system.
Multiple Instance Upgrades
In some deployment architectures Portal Server is deployed on multiple computer systems to provide for scalability and to improve availability. For example, you might have Portal Server instances running on multiple computers with a load balancer to distribute the load.
In the case of load-balanced instances of Portal Server, you can perform a rolling upgrade in which you upgrade the Portal Server instances sequentially without interrupting service, as described below. The procedure takes into account the following constraint: Release 4 Portal Server does not work with Release 5 Portal Server directory data.
The deployment architecture shown in Figure 15-1 will be used to illustrate the procedure for a rolling upgrade of Release 4 Portal Server instances to Release 5.
Note
For architectures that include Portal Server Secure Remote Access components, see Multiple Instance Upgrades.
In the architecture of Figure 15-1, multiple Portal Server instances are accessed by way of a load balancer to provide for availability and scalability. The Portal Server instances, in turn, access Access Manager instances through a load balancer. The The Access Manager and Access Manager SDK instances access a directory that is set up for multi-master replication (MMR). While other Directory Server replication schemes are possible, MMR is representative of highly available and scalable directory services.
In Figure 15-1, the multiple instances of Portal Server, Access Manager, and Directory Server are grouped to facilitate explanation of the upgrade procedure. Portal Server 2, for example, is representative of the second through nth instances of Portal Server.
Figure 15-1 Example Deployment Architecture for Multiple Portal Server Instances
Rolling upgrade of Release 4 Portal Server to Release 5 is performed as follows:
- If you are upgrading Release 4 Access Manager to Release 5, perform a rolling upgrade as documented in Multiple Instance Upgrades. Note that in upgrading Release 4 Portal Server to Release 5, you are not required to upgrade Release 4 Access Manager to Release 5.
- Configure Portal Server 2 to point to Directory Server 2 rather than Directory Server 1.
For brevity, in this and succeeding steps, “Portal Server 2” will mean Portal Server 2 through Portal Server n.
- Upgrade Portal Server 1.
- Disable Portal Server 1 in Load Balancer B.
Requests will no longer be routed to Portal Server 1.
- Disable Directory Server MMR.
Directory Server 2 will no longer by synchronized with Directory Server 1.
- Upgrade Access Manager SDK 1B to Release 5.
Use the procedure in Release 4 Access Manager SDK-only Upgrades.
- Upgrade Portal Server 1 to Release 5.
Perform the upgrade of the Portal Server instance as described in Release 4 Portal Server Upgrade, noting the following:
- Make special note of the following pre-upgrade task: Remove Configuration for Load Balancer.
- Confirm, before performing the upgrade, that the value of am.encryption.pwd in the AccessManagerConfig-base/config/AMConfig.properties file is the same for the local Access Manager SDK as for its associated remote Access Manager instance.
- Make sure that you provide a non-null, unique value for the Portal Instance ID parameter requested by psupgrade for each Portal Server instance that you are upgrading.
Portal Server data for Directory Server 1 is updated to Release 5.
- Enable Portal Server 1 in Load Balancer B.
Requests will be once again routed to Portal Server 1.
- Upgrade Portal Server 2.
- Disable Portal Server 2 in Load Balancer B.
Requests will no longer be routed to Portal Server 2.
- Restore the configuration of Portal Server 2 to point to Directory Server 1.
- Upgrade Access Manager SDK 2B to Release 5.
Use the same procedure as in Step c.
- Upgrade Portal Server 2 to Release 5.
Use the same procedure as in Step d.
- Enable Portal Server 2 in Load Balancer B.
Requests will be once again routed to Portal Server 2.
- Enable Directory Server MMR.
The Portal Server data for Directory Server 2, is now synchronized with Directory Server 1.
Upgrading Portal Server from Java ES Release 3The procedure for upgrading Java ES 2005Q1 (Release 3) Portal Server to Release 5 is the same as that for upgrading Release 4 Portal Server to Release 5, with the following exceptions:
Release 3 Pre-Upgrade Task: Upgrading Portal Server Dependencies
However, when upgrading Portal Server from Release 3, you have to upgrade both Access Manager and web container (Web Server or Application Server) to Release 4 or to Release 5 before upgrading Portal Server, but you cannot leave any dependencies at Release 3, nor upgrade some dependencies to Release 4 and others to Release 5. For more information, see Selective Upgrade Issues.
The following dependencies need to be upgraded in the order shown below.
- Shared Components. Instructions for upgrading Java ES shared components to Release 5 are provided in Chapter 2, "Upgrading Java ES Shared Components".
- Directory Server. Instructions for upgrading Directory Server to Release 5 are provided in Chapter 5, "Directory Server".
- Web Container Software. Instructions for upgrading Web Server or Application Server are provided in Chapter 7, "Web Server" and Chapter 11, "Application Server", respectively.
- Access Manager (Access Manager SDK). Instructions for upgrading Access Manager to Release 5 are provided in Chapter 14, "Access Manager".
Upgrading Release 3 Portal Server
To upgrade Release 3 Portal Server to Release 5, use the instructions in Upgrading Portal Server from Java ES Release 4, except substitute Release 3 wherever Release 4 is referenced.
Release 3 Post-Upgrade Tasks
When upgrading Portal Server from Release 3 to Release 5, you must perform, in addition to the post-upgrade procedures documented in Release 4 Post-Upgrade Tasks, the post-upgrade procedures required to address the following situations:
Subscribing a Discussion
Subscribing a discussion in a community will not succeed unless you first edit the global display profile top level properties to add the following String property:
helpURL=en/desktop/usedesk.htm
Use the following procedure:
- Create a display profile XML snippet file, helpUrl.xml:
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE DisplayProfile SYSTEM "jar://resources/psdp.dtd">
<Properties>
<String name="helpURL" value="en/desktop/usedesk.htm" />
</Properties>- Run the Global display profile properties using the following command:
./psadmin modify-dp -u amadminUser -f /tmp/passwordFile -p portal_ID
-m -g helpUrl.xmlwhere the -m option is required to not overwrite the entire Global display profile.
Multiple Instance Upgrades
In some deployment architectures Portal Server is deployed on multiple computer systems to provide for scalability and to improve availability. For example, you might have Portal Server instances running on multiple computers with a load balancer to distribute the load.
In the case of load-balanced instances of Portal Server, you can perform a rolling upgrade in which you upgrade the Portal Server instances sequentially without interrupting service, as described below. The procedure takes into account the following constraint: Release 3 Portal Server does not work with Release 5 Portal Server directory data.
To perform a rolling upgrade from Release 3 Portal Server to Release 5, use the same procedure documented in Multiple Instance Upgrades, except substitute Release 3 wherever Release 4 is referenced. In addition, you must also upgrade Access Manager, as described in Step 1.
Upgrading Portal Server from Java ES Release 2This section includes information about upgrading Java ES 2004Q2 (Release 2) Portal Server to Release 5. The upgrade procedure is similar to that for upgrading Release 4 Portal Server to Release 5, except for some changes as documented in the following sections:
Note
If you are upgrading from Release 2 Portal Server on the Linux platform, then you will have to perform a dual upgrade, in which both Portal Server and the operating system are upgraded (Release 5 Portal Server is not supported on RHEL 2.1). See Dual Upgrade for more information.
Release 2 Pre-Upgrade Tasks
The pre-upgrade tasks for upgrading Portal Server from Release 2 are the same as those documented in Release 4 Pre-Upgrade Tasks, except for upgrading Portal Server dependencies.
When upgrading Portal Server from Release 2, you have to upgrade both Access Manager and web container (Web Server or Application Server) to Release 4 or to Release 5 before upgrading Portal Server, but you cannot leave any dependencies at Release 2, nor upgrade some dependencies to Release 4 and others to Release 5. For more information, see Selective Upgrade Issues.
In particular, the web container software must be upgraded from Release 2, meaning that only Scenario 2 and Scenario 5 from Table 15-4 are supported when running the psupgrade script.
The following dependencies need to be upgraded in the order shown below.
- Shared Components. Instructions for upgrading Java ES shared components to Release 5 are provided in Chapter 2, "Upgrading Java ES Shared Components".
- Directory Server. Instructions for upgrading Directory Server to Release 5 are provided in Upgrading Directory Server from Java ES Release 2.
- Web Container Software. Instructions for upgrading Web Server or Application Server are provided in Chapter 7, "Web Server" and Chapter 11, "Application Server", respectively.
- Access Manager (Access Manager SDK). Instructions for upgrading Access Manager to Release 5 are provided in Chapter 14, "Access Manager".
Upgrading Release 2 Portal Server
The procedure for upgrading Portal Server from Release 2 to Release 5 depends on the web container in which you are deploying Portal Server software, as described in the following sections.
Upgrading Release 2 Portal Server: Web Server Web Container
To upgrade Release 2 Portal Server to Release 5, when deploying into a Web Server web container, follow the instructions in Upgrading Portal Server from Java ES Release 4, except substitute Release 2 wherever Release 4 is referenced.
However, if Portal Server is deployed to Release 5 Web Server (Web Server 7.0), then you must perform the following steps before upgrading Release 2 Web Server:
Upgrading Release 2 Portal Server: Application Server Web Container
When upgrading Release 2 Portal Server to Release 5, when deploying into an Application Server web container, the Application Server has been upgraded from Release 2 to Release 5.
The Release 2 Application Server instance in which Portal Server was originally deployed (instanceName), when upgraded to Release 5, was migrated under a node agent created by the Application Server upgrade process. Upgrade of Portal Server in this upgraded Application Server instance requires the following steps:
- Log in as root or become superuser.
su -
- If you have not already done so, synchronize all shared components to Release 5.
Instructions are provided in Chapter 2, "Upgrading Java ES Shared Components".
This step is a necessary prerequisite to running the psupgrade script in Step 9.
- Stop any instances of the Portal Server Secure Remote Access Gateway, Rewriter Proxy, or Netlet Proxy that might be running locally.
PortalServer6-base/bin gateway stop
PortalServer6-base/bin netletd stop
PortalServer6-base/bin rwproxyd stopCheck that the processes have stopped:
Gateway: netstat -an | grep 443
Rewriter Proxy: netstat -an | grep 10443
Netlet Proxy: netstat -an | grep 10555- Make sure Access Manager is running if it is deployed to a web container different from the one to which Portal Server is deployed.
- If not already running, start Portal Server by starting the web container to which it is deployed.
- Start the Domain Administration Server (DAS) if it is not already started.
AppServer8-base/bin/asadmin start-domain --user admin_ID
--password password domainName- Start the upgraded Application Server instance in which Portal Server is deployed (instanceName), if that server instance is not already running.
Do this by starting the node agent under which the upgraded Application Server instance has been migrated:
AppServer8-base/bin/asadmin start-node-agent --user admin_ID
--password password nodeagentNameIn the above commands, and in subsequent steps, the following conventions are used:
- where nodeagentName has the form hostName_domainName, but is simply hostName by default.
- The default domainName is domain1
- The default instanceName is server1
- Undeploy Portal Server components.
AppServer8-base/bin/asadmin undeploy --user admin_ID
--password password --target instanceName portalAppServer8-base/bin/asadmin undeploy --user admin_ID
--password password --target instanceName portletsamples- Set two environment variables (ANT_HOME and JAVA_HOME) needed by the psupgrade script. For example,
Solaris OS:
export ANT_HOME=/usr/sfw
export JAVA_HOME=/usr/jdk/entsys-j2seLinux OS:
export ANT_HOME=/opt/sun
export JAVA_HOME=/usr/jdk/entsys-j2se- Make sure you have adequate swap space on your computer.
As a guideline, the swap space should be set to twice the amount of physical ram.
- Run the psupgrade script from the Java ES Release 5 distribution.
cd os_arch/Products/portal_svr/Tools/upgrade/bin
./psupgradewhere os_arch matches your platform, such as Solaris_sparc.
Note
If you inadvertently run psupgrade from the wrong os_arch directory, you need to back out the procedure as follows:
The psupgrade script invokes the Java ES installer to install new packages and queries the system to detect the location and port number and other information regarding the web container to which you are deploying Portal Server web applications. Depending on web container upgrade scenario (see Table 15-4), in this case Scenario 5, the script requests you to input information required to deploy Portal Server to the appropriate web container.
Table 15-6 shows the information requested when Release 2 Application Server has been upgraded to Release 5 (Scenario 5).
- Stop the Domain Administration Server (DAS) and node agent that were started in Step 5.
AppServer8-base/bin/asadmin stop-domain --user admin_ID
--password password domainNameAppServer8-base/bin/asadmin stop-node-agent --user admin_ID
--password password nodeagentName- Restart the Domain Administration Server (DAS), node agent, and server instance that were stopped in Step 10.
Note
Be sure to separately start the node agent using the startinstances=false option before starting the server instance, as shown below.
AppServer8-base/bin/asadmin start-domain --user admin_ID
--password password domainNameAppServer8-base/bin/asadmin start-node-agent --port DASportNumber --startinstances=false --user admin_ID --password password nodeagentName
AppServer8-base/bin/asadmin start-instance --port DASportNumber --user admin_ID --password password instanceName
The default value for DASportNumber is 4848.
Release 2 Post-Upgrade Tasks
When upgrading Portal Server from Release 2 to Release 5, you must perform, in addition to the post-upgrade procedures documented in Release 4 Post-Upgrade Tasks, the post-upgrade procedures required to address the following situations:
Single Sign-on Configuration
After upgrade of Portal Server from Release 2, Portal desktop communication channels, such as Mail, Calendar, and Address Book, that use the ssoadapter meta-template to access a back-end server will fail.
For example, if you have modified the Release 2 mail ssoadapter meta-template, SUN-UWC-MAIL, with settings specific to your Messaging Server, then after upgrade to Release 5, two SUN-UWC-MAIL ssoadapter meta-templates will exist: one is your Release 2 version, which has not been changed, and the other is the new Release 5 version. You will observe duplicate ssoadapter meta-templates in the Portal Server Console and psadmin command line interface, both with the same name.
Channels that use the ssoadapter meta-templates will be unable to establish a connection with the back-end server and retrieve data.
To fix this problem you have to retrieve the ssoadapter meta-template data, rename the duplicate entries, and then replace the modified data. Use the following procedure:
- Export the ssoadapter meta-template data.
You use the amadmin utility to export Access Manager service data, as follows:
- Create an amadmin request file, /tmp/ssoadapter-template-gets.xml.
This file will be used by the utility to retrieve the ssoadapter meta-template data:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Requests
PUBLIC "-//iPlanet//iDSAME 5.0 Admin CLI DTD//EN"
"jar://com/iplanet/am/admin/cli/amAdmin.dtd"
>
<Requests>
<SchemaRequests serviceName="SunSSOAdapterService" SchemaType="global">
<GetServiceDefaultValues>
<Attribute name="sunConfigurationTemplates" />
</GetServiceDefaultValues>
</SchemaRequests>
</Requests>- Execute the following asadmin command:
AccessManager-base/bin/amadmin -u amadminUser -w password
-t ssoadapter-templates-get.xml > /tmp/ssoadapter-templates.xmlThe output of the command is saved to /tmp/ssoadapter-templates.xml.
The /tmp/ssoadapter-templates.xml file has the following format:
sunConfigurationTemplates=
[<ssoadapter meta-template1>, <ssoadapter meta-template2>, ...]and each <ssoadapter meta-template> has the following syntax:
default|imap:/?configName=SUN-UWC-MAIL
&proxyAdminPassword=%5BPROXY-ADMIN_PASSWORD%5D&subType=sun-one
&enableProxyAuth=false ...- Modify the /tmp/ssoadapter-templates.xml file to rename the duplicate ssoadapter meta-templates.
- Find each template in the /tmp/ssoadapter-templates.xml file.
Look for the default|imap:/?configName= string.
- Replace duplicate ssoadapter meta-template names with unique values.
For example, if there are two SUN-UWC-MAIL ssoadapter meta-templates, replace the configName value for one of them with SUN-UWC-MAIL2, resulting in two uniquely named templates:
default|imap:/?configName=SUN-UWC-MAIL ...
default|imap:/?configName=SUN-UWC-MAIL2 ...- Create an amadmin request file that will import the modified ssoadapter meta-templates, overwriting the original data.
- Copy /tmp/ssoadapter-templates.xml to /tmp/ssoadapter-new-templates.xml
- In /tmp/ssoadapter-new-templates.xml, replace the string:
sunConfigurationTemplates=[
with:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Requests
PUBLIC "-//iPlanet//iDSAME 5.0 Admin CLI DTD//EN"
"jar://com/iplanet/am/admin/cli/amAdmin.dtd"
>
<Requests>
<SchemaRequests serviceName="SunSSOAdapterService" SchemaType="Global">
<ModifyDefaultValues>
<AttributeValuePair>
<Attribute name="sunConfigurationTemplates"/>- Replace all ampersands ("&") with "&".
For example, the line:
default|imap:/?configName=SUN-UWC-MAIL
&proxyAdminPassword=%5BPROXY-ADMIN_PASSWORD%5D
&subType=sun-one&enableProxyAuth=false...would become:
default|imap:/?configName=SUN-UWC-MAIL
&proxyAdminPassword=%5BPROXY-ADMIN_PASSWORD%5D
&subType=sun-one&enableProxyAuth=false ...- Remove the commas (",") at the end of each ssoadapter meta-template.
- Wrap each ssoadapter meta-template with a beginning <Value> tag and ending </Value> tag.
For example:
<Value>default|imap:/?configName=SUN-UWC-MAIL
&proxyAdminPassword=%5BPROXY-ADMIN_PASSWORD%5D
&subType=sun-one&enableProxyAuth=false ...</Value>- Remove the closing bracket ("]") from the last ssoadapter meta-template.
- Add the following lines at the end of the file:
</AttributeValuePair>
</ModifyDefaultValues>
</SchemaRequests>
</Requests>The resulting ssoadapter-new-templates.xml file for the single template used in the above steps should look like the following:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Requests
PUBLIC "-//iPlanet//iDSAME 5.0 Admin CLI DTD//EN"
"jar://com/iplanet/am/admin/cli/amAdmin.dtd"
>
<Requests>
<SchemaRequests serviceName="SunSSOAdapterService" SchemaType="Global">
<ModifyDefaultValues>
<AttributeValuePair>
<Attribute name="sunConfigurationTemplates"/>
<Value>default|imap:/?configName=SUN-UWC-MAIL
&proxyAdminPassword=%5BPROXY-ADMIN_PASSWORD%5D
&subType=sun-one&enableProxyAuth=false ...</Value>
</AttributeValuePair>
</ModifyDefaultValues>
</SchemaRequests>
</Requests>- Import the new ssoadapter-new-templates.xml file.
AccessManager-base/bin/amadmin -u amadminUser -w password -v
-t ssoadapter-new-templates.xmlAt this point, you can access the ssoadapter tab in the Portal Server Console to see the updated ssoadapters.
Enabling the URLScrapper Channel
When upgrading from Release 3 to Release 5, you have to enable the URLScrapper channel. See Enable the URLScrapper Channel.
Delete Gateway Service Entry
The amService-srapGateway user entry must be manually deleted when upgrading Portal Server from Release 2, otherwise the Portal Server Secure Remote Access Gateway component, if used, will fail to start after upgrade. Perform the following steps:
Multiple Instance Upgrades
Multiple instance rolling upgrades (seeMultiple Instance Upgrades) are not supported in upgrading Release 2 Portal Server to Release 5.
Upgrading Portal Server from the Interim Feature Release 7.0This section includes information about upgrading Portal Server from the Interim Feature Release (IFR) 7.0 2005Q4 to Java ES 5 (Release 5).
The section covers the following topics:
Portal Server IFR Upgrade Introduction
When upgrading Portal Server IFR 7.0 to Release 5 Portal Server, consider the following aspects of the upgrade process:
- The Portal Server IFR is not supported on Application Server 7.x, hence Upgrade Scenario 5 in Table 15-4 does not apply.
- The psupgrade script, used for upgrading Portal Server IFR to Release 5, does not install new packages, as in the case of upgrade from Release 4. Instead, the upgrade procedure will require you to apply the following patches:
Table 15-8 Patches1 to Upgrade Portal Server IFR to Release 5
Description
Patch ID: Solaris 9 & 10
Patch ID: Linux
Portal Server 7.1
121465-28 (SPARC)
121466-28 (x86)
121467-28
Portal Server 7.1
localization123254-02 (SPARC)
124590-02 (x86)
123255-02
1Patch revision numbers are the minimum required for upgrade to Java ES Release 5. If newer revisions become available, use the newer ones instead of those shown in the table.
- The psupgrade script does not support upgrade of Portal Server IFR to Release 5 for Release 5 Web Server. There are two implications of this limitation:
- If Web Server has already been upgraded to Release 5, you cannot upgrade the Portal Server IFR software deployed in the earlier Web Server container. Web container upgrade Scenario 2 in Table 15-4 is therefore not supported. Note the warning in Special Cases.
- If Web Server has not already been upgraded to Release 5, you can first upgrade the Portal Server IFR software in the earlier Web Server (6.x) container to Release 5, as documented in Portal Server IFR 7.0 Upgrade, below, and then subsequently upgrade Web Server (and, if necessary, Access Manager) to Release 5. If this is your upgrade scenario, also see Upgrade in Release 5 Web Server (7.0) Web Container for additional post-upgrade instructions.
Portal Server IFR 7.0 Upgrade
This section describes how to perform an upgrade of Portal Server from the IFR to Java ES Release 5 on both the Solaris and Linux platform. Where a topic depends on platform-specific procedures, the topic will indicate the operating system to which it applies. The section covers the following topics:
IFR 7 Pre-Upgrade Tasks
Pre-upgrade tasks for the IFR upgrade are the same as for the Release 4 upgrade (see Release 4 Pre-Upgrade Tasks), with the following exceptions:
Obtain Required Configuration Information
The information required by the psupgrade script, as detailed in Obtain Required Configuration Information and Passwords, does not fully apply to upgrade from Portal Server IFR. Because Portal Server IFR is not supported on Application Server 7.x, web container upgrade Scenario 5 in Table 15-6 is not applicable.
Configuration of Common Agent Container
Common Agent Container is a shared component that provides container services for Java ES monitoring and management agents. Portal Server administrative tools such as Portal Server Console and the psadmin command line interface use a set of monitoring and management agents, collectively called the Portal Administration Server, that are deployed in Common Agent Container.
If Java ES shared components have been upgraded to Release 5 before you perform the upgrade of Portal Server IFR 7.0, then the following additional steps are required for you to log in to Release 5 Portal Server Console and to use the psadmin command line interface. (If Java ES shared components have not been upgraded to Release 5 before you perform the upgrade of Portal Server IFR 7.0, then ignore the following additional steps.)
- Reconfigure Common Agent Container.
PortalServer7-base/bin/psconfig --config PortalServer7-base/samples/example2.xml
The example2.xml file provides reconfiguration information. You must first edit the example2.xml file to provide necessary passwords before running the psconfig command. If you are using non-default Portal Server locations, you must also provide the correct directories.
- Edit the web container’s classpath to reference Common Agent Container.
The web container’s classpath will contain a reference to the location of the previous Common Agent Container release: (rel4CAC-base-dir/lib/cacao_cacao.jar).
Replace this reference with the Release 5 location: (rel5CAC-admin-dir/lib/cacao_cacao.jar).
- Check that the property file, pasconnect.properties has been created in the PortalServer7Config-base directory with the following property:
pas.host=
The property value can be null, localhost, or the actual Portal Server host name.
- Restart Common Agent Container.
rel5CAC-admin-dir/bin/cacaoadm start
Upgrading Portal Server IFR 7.0 (Solaris)
This section discusses considerations that impact the upgrade procedure for Portal Server IFR followed by a description of the procedure itself.
IFR 7 Upgrade Considerations (Solaris)
The Portal Server IFR upgrade to Java ES Release 5 takes into account the same considerations as the Release 4 upgrade (see Upgrade Considerations (Solaris)).
In addition, see the issues raised in Portal Server IFR Upgrade Introduction.
IFR 7 Upgrade Procedure (Solaris)
The procedure documented below applies to Portal Server on the computer where the upgrade is taking place.
- Log in as root or become superuser.
su -
- Stop any instances of the Portal Server Secure Remote Access Gateway, Rewriter Proxy, or Netlet Proxy that might be running locally.
PortalServer7-base/bin/psadmin stop-sra-instance -u amadminUser
-f passwordFile -t gateway -N gatewayProfileNamePortalServer7-base/bin/psadmin stop-sra-instance -u amadminUser
-f passwordFile -t rwproxy -N gatewayProfileNamePortalServer7-base/bin/psadmin stop-sra-instance -u amadminUser
-f passwordFile -t nlproxy -N gatewayProfileNameCheck that the processes have stopped:
Gateway: netstat -an | grep 443
Rewriter Proxy: netstat -an | grep 10443
Netlet Proxy: netstat -an | grep 10555- Make sure Access Manager is running if it is deployed to a web container different from the one to which Portal Server is deployed.
- If not already running, start Portal Server by starting the web container to which it is deployed.
Web Server 6.x:
WebServer-base/https-instanceName/startApplication Server 8.x:
AppServer8-base/bin/asadmin start-domain --user admin_ID
--password password domainName- Obtain the required patch, based on Table 15-8.
Always use the latest patch revision available, unless directed to use a specific revision.
Patches can be downloaded to /tmp from: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
- Apply the appropriate Portal Server patch and, if needed, localization patch in Table 15-8.
patchadd /tmp/patch_ID
- Confirm that the patch upgrades were successful:
showrev -p | grep patch_ID
The output should return the versions of patch IDs applied in Step 6.
- In cases where localization packages have been upgraded in Step 6, set the Portal Server Console JVM's locale to UTF-8.
export LC_ALL=ja_JP.UTF-8
export LANG=ja_JP.UTF-8- Set two environment variables (ANT_HOME and JAVA_HOME) needed by the psupgrade script:
export ANT_HOME=/usr/sfw
export JAVA_HOME=/usr/jdk/entsys-j2se- Make sure you have adequate swap space on your computer.
As a guideline, the swap space should be set to twice the amount of physical ram.
- Run the psupgrade script.
cd PortalServer7-base/bin
./psupgradeThe psupgrade script is not run from the Java ES Release 5 distribution and does not invoke the Java ES installer (the packages were already patched).
The script queries the system to detect the location and port number and other information regarding the web container to which you are deploying Portal Server web applications. Depending on web container upgrade scenario (see Table 15-4), the script requests you to input additional information required to deploy Portal Server to the appropriate web container.
Table 15-6 shows the information requested for the different web container upgrade scenarios in Table 15-4.
Note
Be sure you enter correct values for psupgrade parameters, as you can't go back and change them, and it is also very difficult to roll back changes made by the psupgrade script.
- Stop and restart the web container.
While not required in all situations, restarting the web container ensures that Portal Server starts in a clean state.
Upgrading IFR 7 Portal Server (Linux)
This section discusses considerations that impact the upgrade procedure for Portal Server followed by a description of the procedure itself.
IFR 7 Upgrade Considerations (Linux)
The upgrade of Portal Server IFR software to Release 5 on the Linux platform takes into account the same considerations as on the Solaris platform (see IFR 7 Upgrade Considerations (Solaris)), except that installing the Release 5 patches on Linux OS removes the previous RPMs.
IFR 7 Upgrade Procedure (Linux)
The procedure documented below applies to Portal Server on the computer where the upgrade is taking place.
Caution
An upgrade from Portal Server IFR to Release 5 on Linux cannot be rolled back. Make sure you back up your system before performing the following procedure.
- Log in as root or become superuser.
su -
- Stop any instances of the Portal Server Secure Remote Access Gateway, Rewriter Proxy, or Netlet Proxy that might be running locally.
PortalServer7-base/bin/psadmin stop-sra-instance -u amadminUser
-f passwordFile -t gateway -N gatewayProfileNamePortalServer7-base/bin/psadmin stop-sra-instance -u amadminUser
-f passwordFile -t rwproxy -N gatewayProfileNamePortalServer7-base/bin/psadmin stop-sra-instance -u amadminUser
-f passwordFile -t nlproxy -N gatewayProfileNameCheck that the processes have stopped:
Gateway: netstat -an | grep 443
Rewriter Proxy: netstat -an | grep 10443
Netlet Proxy: netstat -an | grep 10555- Make sure Access Manager is running if it is deployed to a web container different from the one to which Portal Server is deployed.
- If not already running, start Portal Server by starting the web container to which it is deployed.
Web Server 6.x:
WebServer-base/https-instanceName/startApplication Server 8.x:
AppServer8-base/bin/asadmin start-domain --user admin_ID
--password password domainName- Obtain the required patch using the patch numbers and RPM names from Table 15-8.
Always use the latest patch revision available, unless directed to use a specific revision.
Patches can be downloaded to /tmp from: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
- Apply the Portal Server patch and, if needed, localization RPMs for Portal Server in Table 15-8, in that order.
See the Readme file for the Portal Server patch, which describes how to use a script to apply the patch’s RPMs:
cd /tmp
where /tmp is the directory to which you download the patch.
./upgradeportalrpm
The update script installs the RPM’s.
For the localization patch, install each RPM using the following command:
rpm -Fvh patchName-version.rpm
- Confirm that the patch upgrade was successful:
rpm -qa | grep sun-portal
The upgrade revision numbers of the RPMs should be returned.
- In cases where localization packages have been upgraded in Step 6, set the Portal Server Console JVM's locale to UTF-8.
export LC_ALL=ja_JP.UTF-8
export LANG=ja_JP.UTF-8- Set two environment variables (ANT_HOME and JAVA_HOME) needed by the psupgrade script:
export ANT_HOME=/opt/sun
export JAVA_HOME=/usr/jdk/entsys-j2se- Make sure you have adequate swap space on your computer.
As a guideline, the swap space should be set to twice the amount of physical ram.
- Run the psupgrade script.
cd PortalServer7-base/bin
./psupgradeThe psupgrade script is not run from the Java ES Release 5 distribution and does not invoke the Java ES installer (the packages were already patched).
The script queries the system to detect the location and port number and other information regarding the web container to which you are deploying Portal Server web applications. Depending on web container upgrade scenario (see Table 15-4), the script requests you to input additional information required to deploy Portal Server to the appropriate web container.
Table 15-6 shows the information requested for the different web container upgrade scenarios in Table 15-4.
Note
Be sure you enter correct values for psupgrade parameters, as you can't go back and change them, and it is also very difficult to roll back changes made by the psupgrade script.
- Stop and restart the web container.
While not required in all situations, restarting the web container ensures that Portal Server starts in a clean state.
Verifying the Upgrade
You can verify the patching of Portal Server packages to Release 5 using the following command:
See Table 15-5 for output values.
To verify the full upgrade, confirm that the Portal Desktop comes up and the psadmin administration utility functions as documented.
You can also check the following upgrade log files at /var/sadm/install/logs:
IFR 7 Post-Upgrade Tasks
When upgrading Portal Server from IFR 7 to Release 5, you must perform the post-upgrade procedures required to address the following situations:
Enabling the Java ES Monitoring Framework
Enabling the Java ES Monitoring Framework (MFWK shared component) lets Portal Server administrative tools, such as Portal Server Console and the psadmin command line interface, report metrics like the number of visitors and the portals they frequent. To enable MFWK:
- Locate the following two files:
MFWK-base/template/jesmf/desktopmfwk.properties
MFWK-base/template/jesmf/com.sun.cmm.ps.xmlwhere MFWK-base is the following path:
/opt/SUNWmfwk (Solaris)
/opt/sun/mfwk (Linux)
- Copy the two files to the following directory:
PortalServer7Data-base/portals/portal_ID/config/Portal_Instance/
- In the desktopmfwk.properties file, replace
com.sun.portal.ProductCollectionId=%PS_DIR%
with
com.sun.portal.ProductCollectionId=Portal_Installed_Location
- Add the following two jar files:
MFWK-base/lib/mfwk_instrum_tk.jar
MFWK-base/lib/mfwk_agent.jarto the appropriate web container classpath (server.xml file for Web Server and domain.xml for Application Server)
- Restart the corresponding web container.
Upgrade in Application Server Web Container
If Portal Server is deployed in an Application Server web container, then you must perform the following additional procedure to successfully redeploy Portal Server:
- Find the section that defines psconsole settings in the AppServer8Config-base/domains/domainName/config/server.policy file:
- Add the following line at the end of that section:
permission java.lang.RuntimePermission “getProtectionDomain”
- Restart the Application Server instance.
AppServer8-base/bin/asadmin start-domain --user admin_ID
--password passworddomainNameAppServer8-base/bin/asadmin start-node-agent --user admin_ID
--password password nodeagentNamewhere nodeagentName has the form hostName_domainName, but is simply hostName by default.
Connections Hang in Application Server Web Container
When the upgraded Portal Server is deployed in an Application Server web container, portal applications can hang waiting to get Java DB connections. To address this problem, perform the following steps:
- Remove settings in PortalServer7Data-base/derby/derby.properties for the following 2 parameters:
derby.drda.maxThreads
derby.drda.timeslice- Restart Java DB.
ANT_HOME/bin/ant
-DPS_CONFIG=PortalServer7Config-base/PSConfig.properties
-buildfile PortalServer7-base/lib/derby.xml
[stop-instance|start-instance]where ANT_HOME is /usr/sfw (on Solaris) and /opt/sun (on Linux).
- Change Java DB configuration settings for Application Server.
Using the Application Server Console, change attribute values for the following connection pool resources: communitymcPool, FileSharingDBPool, PointBasePool, SurveyDBPool.
Change the following attribute values as follows:
Idle Timeout to 300 or more
Resource Type to javax.sql.ConnectionPoolDataSource
Datasource classname to
org.apache.derby.jdbc.ClientConnectionPoolDataSource- Restart the Application Server instance in which Portal Server is deployed.
Upgrade in Release 5 Web Server (7.0) Web Container
In the case where you have upgraded Portal Server IFR in a Web Server that has not already been upgraded to Release 5 because the psupgrade script does not support upgrade of Portal Server IFR on Release 5 Web Server (see Portal Server IFR Upgrade Introduction), you must perform the following additional post-upgrade steps:
- Upgrade Web Server (and, if necessary, Access Manager) to Release 5.
- Reconfigure Web Server container values needed by Portal Server Console and the psadmin command line interface.
- Open an LDAP browser.
Configuration values are stored in Directory Server.
- Under DN, look for:
sunPortalAdminPortalDomainID=defaultDomain
->sunPortalAdminPortalDomainPortalID=portal1
->sunPortalAdminPortalDomainPortalServerInstanceIn=host-port- Perform edits as follows.
Note that all entries are prefaced by the following string: sunPortalAdminPortalDomainPortalServerInstance
- Delete the entry for WebContainerInstanceDir.
- Add an entry for WebContainerDomainName and assign it the value of Web Container Config Name from Table 15-6.
- Edit entries such as InstallDir, WebContainerType, DocRoot, and other parameters shown in Table 15-6 to correspond to Release 5 Web Server (7.0) values.
- Create a Release 5 Portal Server instance.
PortalServer7-base/bin/psadmin create-instance newInstance_ID
If the value of newInstance_ID already exits, an error will be thrown, so it is advantageous to perform this step before Step 4 below.
- Delete the Portal Server IFR instance.
PortalServer7-base/bin/psadmin delete-instance oldInstance_ID
Redeploy Custom Portlet Applications
If you have created and deployed custom portlet applications, then these portlets must be manually redeployed after upgrade to Release 5 Portal Server. Even though display profile entries will exist and the channel name will be displayed, content will not be seen until you redeploy your custom portlets.
Redeploy portlets using the following command:
PortalServer7-base/bin/psadmin deploy-portlet
You can confirm redeployment by looking for the corresponding .war and XML files in the following location:
PortalServer7Data-base/portals/Upgraded/war
Migrate Customized Portlet Applications
Portlet applications based on the user interface framework provided by Sun Java Web Console (SJWC) need to be manually migrated to Release 5 and redeployed.
In particular, this requirement applies to four web applications distributed with Portal Server as sample portlet applications meant to be customized and installed into a portal: filesharing, surveys, wiki, rssportlet. During upgrade, bug-fixed versions of these sample portlet applications are placed on disk in the portlet applications area. If you have customized these portlet applications for your own use, you need to manually migrate them to Release 5 and redeploy them; they are not handled by the Portal Server upgrade process.
By default, some of these portlet applications (filesharing and surveys) are deployed and available for users when a community is created.
You can upgrade, customize, and redeploy SJWC-based portlet applications using the following procedure. The filesharing portlet application is used as an example:
- Extract the Release 5 SJWC jar files.
- mkdir /tmp/lh
- cd /tmp/lh
- /usr/jdk/entsys-j2se/bin/jar xvf PortalServer7-base/portlet/communityportlets.war
WEB-INF/lib/commons-beanutils.jar
WEB-INF/lib/commons-collections-3.1.jar
WEB-INF/lib/commons-digester.jar
WEB-INF/lib/commons-logging.jar
WEB-INF/lib/dataprovider.jar WEB-INF/lib/jsf-api.jar
WEB-INF/lib/jsf-impl.jar WEB-INF/lib/webui.jarIf PortalServer7-base/portlet/communityportlets.war
is not found, use PortalServer7-base/portlet/core/communityportlets.war.- Rename one of the files.
mv WEB-INF/lib/commons-collections-3.1.jar
WEB-INF/lib/commons-collections.jar- Locate the filesharing portlet application.
cd PortalServer7Config-base/portals/portal1/portletapps/filesharing
- Inject the updated SJWC libraries.
jar uvf src/filesharing.war.tokenized -C /tmp/lh WEB-INF
- Customize the filesharing portlet application.
ant customize
- Redeploy the filesharing portlet application.
- PortalServer7-base/bin/psadmin undeploy-portlet -u amadmin
-f passwordfile -p portal_id -i instance_id -g filesharing- ant deploy
- Go to the following directory (depending on web container):
Application Server 8.x:
AppServer8Config-base/domains/domain1/applications/j2ee-modules/
communityportlets/WEB-INFWeb Server 6.x:
WebServer6-base/https-instanceName/webapps/https-instanceName/
communityportlets/WEB-INFWeb Server 7.x:
WebServer7Config-base/https-configName/web-app/https-configName/
communityportlets/WEB-INF- Open the sun-web.xml file and add the following line just before the last line (that is, before the sun-web-app end tag):
<class-loader delegate="false"/>
- Repeat Step 2 through Step 5 for surveys and any other custom portlet application based on the SJWC framework.
- Restart the web container.
Correct Links in Bookmark and Application Channels
When upgrading Release 4 Portal Server to Release 5, the bookmark and application channels have duplicate and spurious links. To fix these links, perform the following procedure.
- Log in to PSConsole.
- From the Common Tasks tab, click on Manage Channels & Containers.
- Choose DeveloperSample [Org] as DN and click OK.
- Select JSPTabContainer [default] as the View Type.
- Under MyFrontPageTabPanelContainer, click on App Channel.
App channel properties will be displayed on the right-hand side frame.
To view properties for a specific locale, Click on Table Preferences and provide the Locale value: de, fr, es, ja, ko, zh, zh_CN, zh_TW.
- Edit the userApps property.
- Edit the target property.
Manual Migration of Struts-based Portlets
If you have custom portlets that use code based on the Struts framework, then these portlets need to be manually updated to use the struts.jar file included in Release 5 Portal Server. Use the following procedure:
- Undeploy the struts-based portlet application.
PortalServer7-base/bin psadmin undeploy-portlet
- Update the .war file with the correct version of the struts.jar file.
Copy PortalServer7-base/lib/struts.jar to strutsbasedPortlet/WEB-INF/lib/struts.jar
where strutsbasedPortlet is the directory in which the struts-based portlet files reside.
- Create a .war archive of the strutsbasedPortlet directory.
- Redeploy the portlet application.
PortalServer7-base/bin psadmin deploy-portlet
Rolling Back the Upgrade (Solaris)
This section describes considerations that impact the upgrade rollback procedure for Portal Server followed by the procedure itself.
Rollback Considerations (Solaris)
The procedure for rolling back the upgrade to Release 5 consists of reverting back to the IFR installation at PortalServer7-base and redeploying the IFR web applications.
Rollback Procedure (Solaris)
- Log in as root or become superuser.
su -
- Restore Directory Server to the state it was in before upgrade.
Use the Directory Server backup/restore command line and GUI utilities. See the Directory Server Backup and Restore chapter of the Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide, http://docs.sun.com/doc/819-0995.
- Undeploy the Release 5 Portal Server web applications that were re-deployed during the upgrade to Release 5.
Use the web container’s administration utilities (command line or console) to undeploy the following packages:
portal
psconsole
search1
wsssoportlet
guessnumber
portletsamples- Stop Portal Server by stopping its web container.
Web Server 6.x:
WebServer-base/https-instanceName/stopWeb Server 7.0:
Admin Server--
WebServer7Config-base/admin-server/bin/stopserv
Instance Server--
WebServer7Config-base/https-configName/bin/stopservApplication Server 8.x:
AppServer8-base/bin/asadmin stop-domain --user admin_ID
--password password domainName- Back out the Portal Server 7.1 patch in Table 15-8.
patchrm patch_ID
- Restart Portal Server by restarting its web container.
Web Server 6.x:
WebServer-base/https-instanceName/startWeb Server 7.0:
Admin Server--
WebServer7Config-base/admin-server/bin/startserv
Instance Server--
WebServer7Config-base/https-configName/bin/startservApplication Server 8.x:
AppServer8-base/bin/asadmin start-domain --user admin_ID
--password password domainName- Deploy the Release 5 Portal Server web applications that were un-deployed during Step 3.
Use the web container’s administration utilities (command line or console) to deploy the packages.
- Stop and restart the web container.
While not required in all situations, restarting the web container ensures that Portal Server starts in a clean state.
Rolling Back the Upgrade (Linux)
Rollback of the upgrade cannot be performed on Linux.
However, you can create a parallel system before upgrading and testing that system before attempting an upgrade. If you need to roll back the upgrade, you can revert back to that parallel system.
Multiple Instance Upgrades
In some deployment architectures Portal Server is deployed on multiple computer systems to provide for scalability and to improve availability. For example, you might have Portal Server components running on multiple computers with a load balancer to distribute the load.
In the case of load-balanced instances of Portal Server, you can perform a rolling upgrade in which you upgrade the Portal Server instances sequentially without interrupting service. You upgrade each instance of Portal Server while the others remain running. To perform a rolling upgrade from the IFR to Release 5, use the same procedure documented in Multiple Instance Upgrades, except substitute the IFR wherever Release 4 is referenced.
