Sun Java logo     Previous      Contents      Index      Next     

Sun logo
Sun Java Enterprise System 2005Q4 Upgrade Guide 

Chapter 17
Portal Server

This chapter describes how to upgrade Portal Server to Java ES 2005Q4 (Release 4): Sun Java System Portal Server 6.3.1 2005Q4. The chapter provides a general overview of upgrade issues and procedures for the different upgrade paths supported by Java ES Release 4. The chapter covers upgrades on both the Solaris and Linux operating systems:

Overview of Portal Server Upgrades

This section describes the following general aspects of Portal Server that impact upgrading to Java ES 2005Q4 (Release 4):

About Java ES Release 4 Portal Server

Java ES Release 4 Portal Server is functionally the same as Release 3, but contains bug fixes made since Release 3.

Portal Server Upgrade Roadmap

Table 17-1 shows the supported Portal Server upgrade paths to Java ES Release 4. The table applies to both Solaris and Linux operating systems.

Table 17-1  Upgrade Paths to Java ES Release 4: Sun Java System Portal Server 6.3.1 2005Q4 

Java ES Release

Portal Server Version

General Approach

Re-configuration Required

Release 3

Sun Java System Portal Server 6.3.1 2005Q1

Direct upgrade:
Performed by applying patches. Some limitations apply (see procedures).

None

Release 2

Sun Java System Portal Server 6.3 2004Q2

Direct upgrade:
Performed by applying patches to upgrade to Release 4, reconfiguring the software, and redeploying to the web container.

Configuration data

Release 1

Sun ONE Portal Server 6.2 (2003Q4)

No direct upgrade:
But can be performed by upgrading first to Release 3 and then applying patches to upgrade to Release 4. Some limitations apply (see procedures).

Configuration data

Pre-dates Java ES releases

 

No direct upgrade.

 

Portal Server Data

The following table shows the type of data that could be impacted by an upgrade of Portal Server software.

Table 17-2  Portal Server Data Usage 

Type of Data

Location

Usage

Configuration data

PortalServerConfig-base/

Configuration of Portal Server.

Web container configuration

Web Server:
server.policy and server.xml files in
WebServer-base/https-hostname/config

Application Server (Java ES Release 3 and 4):
server.policy and domain.xml files in
AppServer8Config-base/domains/domainName/config

Application Server (Java ES Release 2):
server.policy and server.xml files in
AppServer7Config-base/domains/domainName/config

Configuration of Portal Server web container instance.

Customization data

PortalServerConfig-base/desktop

JAR files for customized modules

Customized sample Portal Server desktop

Directory schema

Services configuration

User data

Directory Server

Portal Server depends on services configurations, such as the portal desktop, and user profile data that is stored in a directory.

Dynamic application data

None

Portal Server does not persistently store application data such as session state.

Compatibility Issues

Release 4 Portal Server does not introduce any interface changes. Portal Server components, including the mobile access component, are backwardly compatible with earlier versions.

Portal Server Dependencies

Portal Server dependencies on other Java ES components can impact the 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:

Upgrading Portal Server from Java ES Release 3

This section includes information about upgrading Portal Server from Java ES 2005Q1 (Release 3) to Java ES 2005Q4 (Release 4).

Note

This section does not apply to the special case in which Portal Server is deployed in an Application Server web container and has been upgraded from Release 2 to Release 3 prior to being upgraded to Release 4. The aforementioned upgrade path is not currently supported.

The section covers the following topics:

Introduction

When upgrading Java ES Release 3 Portal Server to Release 4, consider the following aspects of the upgrade process:

Release 3 Portal Server Upgrade

This section describes how to perform an upgrade of Portal Server from Java ES Release 3 to Java ES Release 4 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:

Pre-Upgrade Tasks

Before you upgrade Portal Server you should perform the tasks described below.

Verify Current Version Information

You can verify the current version of Portal Server using the following command:

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 4. However, Portal Server has a hard upgrade dependency only on the Mobile Access Core (MA Core) shared component. Upgrading of otherJava ES Release 3 components upon which Portal Server depends is therefore optional.

However, if you choose to upgrade all Portal Server dependencies, they should be upgraded in the following order, all before you upgrade Portal Server. You can skip any that might already have been upgraded.

  1. Shared Components.  Instructions for upgrading Java ES shared components to Release 4 are provided in Upgrading Java ES Shared Components.
  2. Directory Server.  Instructions for upgrading Directory Server to Release 4 are provided in Chapter 4, "Directory Server and Administration Server".
  3. Web Container Software.  Instructions for upgrading Web Server or Application Server are provided in Chapter 6, "Web Server" and Chapter 9, "Application Server", respectively.

    4. Note

    Upgrading third-party web containers, such as those from WebLogic and WebSphere can cause Portal Server to break because customizations made to these containers to support Portal Server are overwritten by the container upgrade.

    In these cases you have to reinstall and re-configure Portal Server for the upgraded web container environments.

  4. Access Manager (Access Manager SDK).  Instructions for upgrading Access Manager to Release 4 are provided in Chapter 11, "Access Manager".
Back Up Release 3 Portal Server Configuration Information

Upgrade of Portal Server to Release 4 does not require the re-configuration of Portal Server software. However, as a safety measure you can back up the following directories where configuration information is stored:

Obtain Required Configuration Information and Passwords

You have to log in as superuser to perform the upgrade. If you are using Web Server as a web container, no configuration information is needed. However if you are using Application Server as a web container, you will need the Application Server administrator user ID and password.

Upgrading Release 3 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 Java ES Release 4 takes into account the following considerations:

Upgrade Procedure (Solaris)

The procedure documented below applies to Portal Server on the computer where the upgrade is taking place.

  1. Obtain the required patches, based on Table 17-4.

    2. 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

  2. Log in as root or become superuser.

    3. su -

  3. Stop Portal Server by stopping its web container.

    4. Web Server:
    WebServer-base    /https-instanceName/stop

    Application Server:
    AppServer8-base    /bin/asadmin stop-domain domainName

  4. If you have not already done so, upgrade the MA Core shared component and any others you wish to upgrade.

    5. See Upgrade Portal Server Dependencies.

  5. Apply the appropriate Portal Server patch in Table 17-4.

    6. Be sure to apply the Portal Server core patch before applying the two Portal Server localization patches.

    patchadd patch_ID

  6. Confirm that the patch upgrade was successful:

    7. showrev -p | grep patch_ID

    The output should return the versions of patch IDs applied in Step 5.

  7. Restart Portal Server by restarting its web container.

    8. Web Server:
    WebServer-base    /https-instanceName/start

    Application Server:
    AppServer8-base    /bin/asadmin start-domain --user admin_ID
         --password     password domainName

  8. Re-deploy the Portal Server web application to your web container.

    9. PortalServer-base/bin/deploy redeploy

    The redeploy command redeploys content from PortalServer-base/web-src to /var/PortalServer-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 deploy command, or such changes will be overwritten.

  9. Stop and restart the web container.

    10. While not required in all situations, restarting the web container ensures that Portal Server starts in a clean state.

Upgrading Release 3 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 Java ES Release 4 on the Linux platform takes into account the same considerations as on the Solaris platform (see Upgrade Considerations (Solaris)), except that the Linux Release 4 upgrade patches differ from the Solaris patches.

The Release 4 Portal Server upgrade patches for Linux OS are shown in the following table:

Table 17-5  Patches1 to Upgrade Portal Server on Linux 

Description

Patch ID and RPM names

Portal Server core

118952-12

  • sun-portal-core-6.3-25.12.i386.rpm

and a number of other RPMs for the Portal desktop and Portal Server mobile access.

Portal Server localization

119426-07

  • sun-portal-core-Locale-6.3-24.i386.rpm

and a large number of other RPMs for the Portal Server mobile access, configuration, identity, and other components.

Portal Server
localization configurator

118116-08

  • sun-portal-l10n-configurator-6.3-24.i386.rpm

1Patch revision numbers are the minimum required for upgrade to Java ES Release 4. If newer revisions become available, use the newer ones instead of those shown in the table.

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 3 to Java ES Release 4 on Linux cannot be rolled back.

  1. Obtain the required patches using the patch numbers and RPM names from Table 17-5. Use this information to obtain the version numbers for the RPM.

    2. Patches can be downloaded to /tmp from: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access

  2. Log in as root or become superuser.

    3. su -

  3. Stop Portal Server by stopping its web container.

    4. Web Server:
    WebServer-base    /https-instanceName/stop

    Application Server:
    AppServer8-base    /bin/asadmin stop-domain domainName

  4. If you have not already done so, upgrade the MA Core shared component and any others you wish to upgrade.

    5. See Upgrade Portal Server Dependencies.

  5. Apply the RPMs for the Portal Server core patch in Table 17-5.

    6. cd /tmp

    where /tmp is the directory to which you downloaded the patch in Step 1.

    ./update

    The update script installs the RPMs and also ensures that the correct configurational changes occur as the result of the patch.

  6. Confirm that the patch upgrade was successful:

    7. rpm -qa | grep sun-portal-core-6.3-25

    The upgrade revision numbers of the RPMs should be returned.

  7. Apply the RPMs for the two Portal Server localization patches in Table 17-5.

    8. rpm -Fvh --replacefiles sun-portal-*-Locale-6.3-24.i386.rpm
    rpm -Fvh --replacefiles
         sun-portal-l10n-configurator-6.3-24.i386.rpm

  8. Confirm that the patch upgrade was successful:

    9. rpm -qa | grep sun-portal-l10n-configurator-6.3-24

    The upgrade revision numbers of the RPMs should be returned.

  9. Restart Portal Server by restarting its web container.

    10. Web Server:
    WebServer-base    /https-instanceName/start

    Application Server:
    AppServer8-base    /bin/asadmin start-domain --user admin_ID
         --password     password domainName

  10. Re-deploy the Portal Server web application to your web container.

    11. PortalServer-base/bin/deploy redeploy

    The redeploy command redeploys content from PortalServer-base/web-src to /var/PortalServer-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 deploy command, or such changes will be overwritten.

  11. Stop and restart the web container.

    12. While not required in all situations, restarting the web container ensures that Portal Server starts in a clean state.

Verifying the Upgrade

The upgrade of Portal Server to Release 4 is verified by confirming that the upgrade patches have been properly applied. The steps for this verification were included in Upgrade Procedure (Solaris) and Upgrade Procedure (Linux).

In addition, you can use the following command:

See Table 17-3 for output values.

Beyond these tests of the patch upgrade you can verify that what previously worked still works and that bug fixes of interest have actually been fixed.

Post-Upgrade Tasks

There are no post-upgrade tasks beyond the steps described in Upgrade Procedure (Solaris) and Upgrade Procedure (Linux).

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 4 of Portal Server is pretty much the reverse of the procedure for upgrading to Release 4. The re-configurations are rolled back and the patches are removed.

Rollback Procedure (Solaris)
  1. Log in as root or become superuser.

    2. su -

  2. Stop Portal Server by stopping its web container.

    3. Web Server:
    WebServer-base    /https-instanceName/stop

    Application Server:
    AppServer8-base    /bin/asadmin start-domain --user admin_ID
         --password     password domainName

  3. Remove the patches in Table 17-4.

    4. patchrm patch_ID

  4. Restart Portal Server by restarting its web container.

    5. Web Server:
    WebServer-base    /https-instanceName/start

    Application Server:
    AppServer8-base    /bin/asadmin start-domain domainName
         --user admin_ID --password password

  5. Re-deploy the Portal Server web application to your web container.

    6. PortalServer-base/bin/deploy redeploy

    The redeploy command redeploys content from PortalServer-base/web-src to /var/PortalServer-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 deploy command, or such changes will be overwritten.

  6. Stop and restart the web container.

    7. While not required in all situations, restarting the web container ensures that Portal Server starts in a clean state.

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. You perform the upgrade of each instance as described in Release 3 Portal Server Upgrade.

Upgrading Portal Server from Java ES Release 2

This section includes information about upgrading Portal Server from Java ES 2004Q2 (Release 2) to Java ES 2005Q4 (Release 4).

Because of the complexity involved in a Release 2 Portal Server upgrade, and the likelihood of considerable down time, you might choose to perform a parallel upgrade on another computer rather than an in-place upgrade on a production system. Such an approach is advisable for business critical or complex Portal Server solutions where only limited downtime is acceptable. The duration of the upgrade procedure will also depend on the time required for you to re-implement and test any required Portal Server customizations.

It might also be necessary to modify or adapt the instructions in this section to accommodate your particular upgrade scenario. In such cases it would be advisable to contact Sun Microsystems support services for assistance in performing the upgrade.

This section covers the following topics regarding the upgrade from Release 2 to Release 4:

Introduction

When upgrading Java ES Release 2 Portal Server to Release 4, consider the following aspects of the upgrade process:

Release 2 Portal Server Upgrade

This section describes how to perform an upgrade of Portal Server from Java ES Release 2 to Java ES Release 4 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:

Pre-Upgrade Tasks

Before you upgrade Portal Server you should perform the tasks described below.

Verify Current Version Information

You can verify the current version of Portal Server using the following command:

See Table 17-3 for output values.

Upgrade Portal Server Dependencies

Java ES Release 4 does not support the coexistence of Release 2 and Release 4 shared components on a single computer.

You are therefore required to upgrade all local Java ES Release 2 components on which Portal Server depends to Release 4. When you upgrade all local Portal Server dependencies on a computer, they should be upgraded in the following order, all before you upgrade Portal Server. Note that there are special requirements for specific upgrade scenarios.

  1. Shared Components.  Instructions for upgrading Java ES shared components to Release 4 are provided in Upgrading Java ES Shared Components.
  2. Directory Server.  Portal Server is rarely dependent on a local Directory Server. However, instructions for upgrading Directory Server to Release 4 are provided in Chapter 4, "Directory Server and Administration Server".
  3. Web Container Software.   Portal Server can be running in a web container provided by either Web Server or Application Server.
    • Web Server: Upgrade to Release 4 Web Server using the procedure in Upgrading Web Server from Java ES Release 2.
    • Application Server: Upgrade to Release 4 Application Server by performing a fresh install of Application Server using the Java ES installer rather than by using the procedure in Upgrading Application Server from Java ES Release 2. Be sure to obtain the admin port and server instance port from the Release 2 Application Server 7 before installing Release 4 Application Server 8.

      • Note

      Upgrading third-party web containers, such as those from WebLogic and WebSphere can cause Portal Server to break because customizations made to these containers to support Portal Server are overwritten by the container upgrade.

      In these cases you have to reinstall and re-configure Portal Server for the upgraded web container environments.

  4. Access Manager (Access Manager SDK).  Portal Server can be running in the same web container as Access Manager or in a different web container.
Back Up Release 2 Portal Server Configuration Information

Upgrade of Portal Server to Release 4 does requires the re-configuration of Portal Server software. As a safety measure you can back up the following directories where configuration information is stored:

Obtain Required Configuration Information and Passwords

You have to log in as superuser to perform the upgrade. If you are using Web Server as a web container, no administrator password is required. However if you are using Application Server as a web container, you will need the Application Server administrator user ID and password.

Upgrading Release 2 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 Java ES Release 4 takes into account the following considerations:

Upgrade Procedure (Solaris: Web Server)

The procedure documented below applies to Portal Server on the computer where the upgrade is taking place.

  1. Obtain the required patches, based on Table 17-6.

    2. Be sure to download the exact patch revisions shown in Table 17-6, except for the Portal Server fixes, for which a later patch might be available.

    Patches can be downloaded to /tmp from: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access

  2. Log in as root or become superuser.

    3. su -

  3. Stop Portal Server by stopping its web container.

    4. WebServer-base/https-instanceName/stop

  4. If you have not already done so, upgrade all shared components, the web container, and Access Manager (or Access Manager SDK).

    5. See Upgrade Portal Server Dependencies.

  5. If not yet running, start Directory Server and Access Manager.
  6. Apply the appropriate Portal Server patches in Table 17-6.

    7. Be sure to apply the patches in the order in which they are shown in Table 17-6, from top to bottom.

    patchadd patch_ID

  7. Confirm that the patch upgrade was successful:

    8. showrev -p | grep patch_ID

    The output should return the versions of patch IDs applied in Step 7.

  8. Re-configure Portal Server software:

    9. ksh

    $ cd PortalServer-base/lib
    $ ./upgradePS04Q205Q1

  9. Restart Portal Server by restarting its web container.

    10. WebServer-base/https-instanceName/start

  10. Re-deploy the Portal Server web application to your web container.

    11. PortalServer-base/bin/deploy redeploy

    The redeploy command redeploys content from PortalServer-base/web-src to /var/PortalServer-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 deploy command, or such changes will be overwritten.

  11. Stop and restart the web container.

    12. While not required in all situations, restarting the web container ensures that Portal Server starts in a clean state.

Upgrade Procedure (Solaris: Application Server)

The procedure documented below applies to Portal Server on the computer where the upgrade is taking place.

  1. Obtain the required patches, based on Table 17-6.

    2. Be sure to download the exact patch revisions shown in Table 17-6, except for the Portal Server fixes, for which a later patch might be available.

    Patches can be downloaded to /tmp from: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access

  2. Log in as root or become superuser.

    3. su -

  3. Make sure that Portal Server is no longer running in its Release 2 Application Server instance.

    4. AppServerConfig7-base/domains/domainName/instanceName/bin/stopserv

    In the above command, and in subsequent steps, the following conventions are used:

    • The default domainName is domain1
    • The default instanceName is server1
  4. If you have not already done so, upgrade all shared components, the web container, and Access Manager (or Access Manager SDK).

    5. See Upgrade Portal Server Dependencies.

  5. Make sure that the upgraded Access Manager is not running in its Release 4 Application Server instance.

    6. AppServer8-base/bin/asadmin stop-domain domainName

  6. Make sure the Access Manager configuration file,

    7. AccessManagerConfig-base/config/AMConfig.properties

    contains the following property values:

    com.iplanet.am.notification.url=
        http://    hostName:port/amserver/notificationservice
    com.sun.identity.webcontainer=IAS8.1
    com.iplanet.am.cookie.encode=true

    where hostName:port is the computer and port hosting the Access Manager instance.

  7. Apply the appropriate Portal Server patches in Table 17-6.

    8. Be sure to apply the patches in the order in which they are shown in Table 17-6, from top to bottom.

    patchadd patch_ID

  8. Confirm that the patch upgrade was successful:

    9. showrev -p | grep patch_ID

    The output should return the versions of patch IDs applied in Step 7.

  9. Make sure the Portal Server configuration file,

    10. PortalServerConfig-base/PSConfig.properties

    contains the following property values, which reference the Application Server’s Domain Administration Server (DAS) instance:

    DEPLOY_TYPE=SUNONE8  DEPLOY_INSTANCE_DIR=AppServer8Config-base/domains/domainName
    DEPLOY_DOMAIN=AppServer8Config-base/domains/domainName
    DEPLOY_PRODUCT_DIR=AppServer8Config-base/domains/domainName
    DEPLOY_ADMIN_PROTOCOL=https
      DEPLOY_ADMIN_PORT=    DAS_adminPort (for example, default=4848)
      DEPLOY_ADMIN_HOST=DAS_hostName
      LOAD_BALANCER_URL=http://DAS_hostName:DAS_hostPort/portal
    DEPLOY_DOCROOT=    AppServer8Config-base/domains/domainName/docroot
      PS_PORT=    DAS_hostPort (for example, default=80)
      DEPLOY_DIR=AppServer8-base
      PS_PROTOCOL=http

    Assuming that the port values assigned to the fresh Release 4 Application Server 8 installation were the same as those of the Release 2 Application Server 7 installation, and that those were the default port values, then the default values shown above would apply.

  10. Modify the PSconfig.properties file as follows:

    11. DEPLOY_INSTANCE=temporary_instanceName

    where temporary_instanceName is an unused temporary value.

  11. Make sure that the DAS is running.

    12. AppServer8-base/bin/asadmin start-domain --user admin_ID
         --password password domainName

  12. Perform the following commands:

    13. cd PortalServer-base/bin
    ./multiserverinstance

    A number of the questions asked by the multiserverinstance script use the values set in the PSConfig.properties file shown in Step 9 as defaults, and the following instructions assume these defaults are correct.

    Respond to the questions asked by the multiserverinstance script as follows:

    1. Select option 1 for Create a new portalserver instance.
    2. Select option 3 for Sun Java System Application Server 8.1.
    3. Where is the Web Container installed? Hit return.
    4. What is the domain name? Hit return.
    5. What is the domain (DAS) path? Enter the same value that was shown as the default for question #4.
    6. What is the Web Container instance path? Enter the same value as was entered for #5.
    7. What is the Web Container administrator? Hit return.
    8. What is the Web Container administration port? Hit return.
    9. Is the Web Container administration port secure? Hit return.
    10. Instance name? Enter a value of server.
    11. Instance port? Enter the same value as was entered for the PS_PORT value in the PSConfig.properties file.
    12. Is the instance port secure? Hit return.
    13. What is the Web Container document root directory? Hit return.
    14. What is the Application Server administration password? Enter password.
    15. What is the Identity Server administration password? Enter password.

  13. Modify the PSconfig.properties file as follows:

    14. DEPLOY_INSTANCE=server

    where the value server is the default instance name of the DAS instance.

  14. Restart the DAS.

    15. AppServer8-base/bin/asadmin stop-domain domainName

    AppServer8-base/bin/asadmin start-domain --user admin_ID
         --password password domainName

  15. Deploy the Portal Server web application.

    16. cd PortalServer-base/bin
    ./deploy redeploy

    Ignore messages indicating there might be errors in deploy.log.

    The redeploy command redeploys content from PortalServer-base/web-src to /var/PortalServer-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 deploy command, or such changes will be overwritten.

  16. Re-configure Portal Server software:

    17. ksh

    $ cd PortalServer-base/lib
    $ ./postinstall_PortletSamples
    $ ./upgradePS04Q205Q1

    Ignore CLI137-related errors and (un)deploy-related errors issued by the upgradePS04Q205Q1 script.

  17. Restart the DAS.

    18. AppServer8-base/bin/asadmin stop-domain domainName

    AppServer8-base/bin/asadmin start-domain --user admin_ID
         --password password domainName

    While not required in all situations, restarting the web container ensures that Portal Server starts in a clean state.

  18. Update the Portal Server Display Profile
    1. Execute the following command:

      2. PortalServer-base/bin/dpadmin list -g -u amadminDN
           -w amadminPassword /tmp/GlobalDP.xml

      Where the value for amadminDN can be found in the property com.sun.identity.authentication.super.user in the AccessManagerConfig-base/config/AMConfig.properties file.

    2. Open the file /tmp/GlobalDP.xml for editing
    3. Modify the value of:

      4. org.apache.xalan.xsltc.trax.TransformerFactoryImpl
      to
      com.sun.org.apache.xalan.internal.xsltc.trax.
           TransformerFactoryImpl

    4. Modify all occurrences of the value:

      5. Sun JavaTM System Portal Server 6 2004Q2
      to
      Sun JavaTM System Portal Server 6 2005Q4

    5. Execute the following command:

      6. PortalServer-base/bin/dpadmin modify -g -u amadminDN
           -w amadminPassword /tmp/GlobalDP.xml

      Where the value for amadminDN is the same as in Step a.

Upgrading Release 2 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 Java ES Release 4 on the Linux platform takes into account the same considerations as on the Solaris platform (see Upgrade Considerations (Solaris)), except that the Linux Release 4 upgrade patches differ from the Solaris patches.

The Release 4 Portal Server upgrade patches for Linux OS are shown in the following table:

Table 17-7  Patches to Upgrade Portal Server to Release 4 on Linux 

Description

Patch ID and RPM names

Portal Server core

118020-16

sun-portal-module-6.3-25.i386.rpm

where module is any of about 70 different software modules

Mobile Access core

119529-02

  • sun-mobileaccess-1.0-25.2.i386.rpm
  • sun-mobileaccess-config-1.0-25.2.i386.rpm

Portal Server fixes

118952-15 (or higher)

  • sun-portal-core-6.3-xx.y.i386.rpm
  • sun-portal-configurator-6.3-xx.y.i386.rpm
  • sun-portal-mobileaccess-6.3-xx.y.i386.rpm
  • sun-portal-desktop-6.3-xx.y.i386.rpm
  • sun-portal-sample-6.3-xx.y.i386.rpm
  • sun-portal-mobileaccess-config-6.3-xx.y.i386.rpm

Upgrade Procedure (Linux: Web Server)

The procedure documented below applies to Portal Server on the computer where the upgrade is taking place.

  1. Obtain the required patches using the patch numbers and RPM names from Table 17-7. Use this information to obtain the version numbers for the RPM.

    2. Patches can be downloaded to /tmp from: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access

  2. Log in as root or become superuser.

    3. su -

  3. Stop Portal Server by stopping its web container.

    4. WebServer-base/https-instanceName/stop

  4. If you have not already done so, upgrade all shared components, the web container, and Access Manager (or Access Manager SDK).

    5. See Upgrade Portal Server Dependencies.

  5. If not yet running, start Directory Server and Access Manager.
  6. Apply the RPMs for Portal Server in Table 17-7.
    1. cd /tmp

      2. where /tmp is the directory to which you downloaded the patch in Step 1.

    2. Unzip the 118020 patch file, read the README file and run the following script:

      3. ./upgradeportalrpms

      The upgradeportalrpms script installs the RPMs and also ensures that the correct configurational changes occur as the result of the patch.

    3. Unzip the 119529 patch file, and run the ./update script from within the directory that was created when the patch was unzipped.
    4. Unzip the 118952 patch file, and run the ./update script from within the directory that was created when the patch was unzipped.
  7. Confirm that the patch upgrade was successful:

    8. rpm -qa | grep sun-portal
    rpm -qa | grep sun-mobileaccess

    The new version numbers of the RPMs should be returned.

  8. Re-configure Portal Server software:

    9. ksh

    $ cd PortalServer-base/lib
    $ ./upgradePS04Q205Q1

  9. Edit the PortalServer-base/export/deploy.import file as follows:

    10. If the following is present:

    %JATO_LIB_DIR%/jato.tld %WEB_SRC_DIR%/WEB-INF/jato.tld
    %JATO_LIB_DIR%/jato.jar %WEB_SRC_DIR%/WEB-INF/lib/jato.jar

    Replace with:

    /usr/share/lib/jato/jato.tld %WEB_SRC_DIR%/WEB-INF/jato.tld
    /usr/share/lib/jato/jato.jar %WEB_SRC_DIR%/WEB-INF/lib/jato.jar

    In other words, replace %JATO_LIB_DIR% with /usr/share/lib/jato

  10. Restart Portal Server by restarting its web container.

    11. WebServer-base/https-instanceName/start

  11. Re-deploy the Portal Server web application to your web container.

    12. PortalServer-base/bin/deploy redeploy

    The redeploy command redeploys content from PortalServer-base/web-src to /var/PortalServer-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 deploy command, or such changes will be overwritten.

  12. Stop and restart the web container.

    13. While not required in all situations, restarting the web container ensures that Portal Server starts in a clean state.

Upgrade Procedure (Linux: Application Server)

The procedure documented below applies to Portal Server on the computer where the upgrade is taking place.

  1. Obtain the required patches, based on Table 17-7.

    2. Be sure to download the exact patch revisions shown in Table 17-7, except for the Portal Server fixes, for which a later patch might be available.

    Patches can be downloaded to /tmp from: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access

  2. Log in as root or become superuser.

    3. su -

  3. Make sure that Portal Server is no longer running in its Release 2 Application Server instance.

    4. AppServerConfig7-base/domains/domainName/instanceName/bin/stopserv

    In the above command, and in subsequent steps, the following conventions are used:

    • The default domainName is domain1
    • The default instanceName is server1
  4. If you have not already done so, upgrade all shared components, the web container, and Access Manager (or Access Manager SDK).

    5. See Upgrade Portal Server Dependencies.

  5. Make sure that the upgraded Access Manager is not running in its Release 4 Application Server instance.

    6. AppServer8-base/bin/asadmin stop-domain domainName

  6. Make sure the Access Manager configuration file,

    7. AccessManagerConfig-base/config/AMConfig.properties

    contains the following property values:

    com.iplanet.am.notification.url=
        http://    hostName:port/amserver/notificationservice
    com.sun.identity.webcontainer=IAS8.1
    com.iplanet.am.cookie.encode=true

    where hostName:port is the computer and port hosting the Access Manager instance.

  7. Apply the RPMs for Portal Server in Table 17-7.
    1. cd /tmp

      2. where /tmp is the directory to which you downloaded the patch in Step 1.

    2. Unzip the 118020 patch file, read the README file and run the following script:

      3. ./upgradeportalrpms

      The upgradeportalrpms script installs the RPMs and also ensures that the correct configurational changes occur as the result of the patch.

    3. Unzip the 119529 patch file, and run the ./update script from within the directory that was created when the patch was unzipped.
    4. Unzip the 118952 patch file, and run the ./update script from within the directory that was created when the patch was unzipped.
  8. Confirm that the patch upgrade was successful:

    9. rpm -qa | grep sun-portal
    rpm -qa | grep sun-mobileaccess

    The new version numbers of the RPMs should be returned.

  9. Edit the PortalServer-base/export/deploy.import file as follows:

    10. If the following is present:

    %JATO_LIB_DIR%/jato.tld %WEB_SRC_DIR%/WEB-INF/jato.tld
    %JATO_LIB_DIR%/jato.jar %WEB_SRC_DIR%/WEB-INF/lib/jato.jar

    Replace with:

    /usr/share/lib/jato/jato.tld %WEB_SRC_DIR%/WEB-INF/jato.tld
    /usr/share/lib/jato/jato.jar %WEB_SRC_DIR%/WEB-INF/lib/jato.jar

    In other words, replace %JATO_LIB_DIR% with /usr/share/lib/jato

  10. Follow Step 9 through Step 18 under Upgrade Procedure (Solaris: Application Server).

Verifying the Upgrade

The upgrade of Portal Server to Release 4 is verified by confirming that the upgrade patches have been properly applied. The steps for this verification were included in Upgrade Procedure (Solaris) and Upgrade Procedure (Linux).

In addition, you can use the following command:

See Table 17-3 for output values.

Beyond these tests of the patch upgrade you can verify that what previously worked still works and that bug fixes of interest have actually been fixed.

Post-Upgrade Tasks

There are no post-upgrade tasks beyond the steps described in Upgrade Procedure (Solaris: Application Server) and Upgrade Procedure (Linux: Web Server).

Rolling Back the Upgrade

The upgrade of Portal Server from Release 2 to Release 4 cannot be rolled back.

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. You perform the upgrade of each instance as described in Release 2 Portal Server Upgrade.



Previous      Contents      Index      Next     

Part No: 819-2331-13.   Copyright 2006 Sun Microsystems, Inc. All rights reserved.