|
| |
| Sun Java Enterprise System 2005Q1 Upgrade and Migration Guide | |
Chapter 3
Upgrading from Previous Java Enterprise System VersionsThis chapter provides the procedures to upgrade component products from previous Java Enterprise System versions for the Solaris operating system to the Sun Java™ Enterprise System (Java ES) software 2005Q1 release for the Solaris operating system. For procedures to upgrade from releases earlier than those contained in Java Enterprise System 2003Q4, see Upgrading Components from Versions Predating Java Enterprise System.
This chapter contains the following sections
Upgrading Access ManagerThis section includes the following information about upgrading to Sun Java™ System Access Manager 6 2005Q1 from previous versions of Access Manager:
Access Manager Upgrade Roadmap
Table 3-1 shows how to upgrade previous versions of Access Manger.
Table 3-1 Access Manager 6 2005Q1 Upgrade Roadmap
Previous Version
How to Upgrade to Access Manager 6 2005Q1
Sun Java System Identity Server 2004Q2 (6.2)
Follow the steps in Upgrading Identity Server 2004Q2 (6.2) in this guide.
Sun Java System Identity Server 2004Q2 (6.2) SP1
Back out SP1 and then follow the steps in Upgrading Identity Server 2004Q2 (6.2) in this guide.
Sun ONE Identity Server (6.1)
Follow the steps in Upgrading Identity Server 6.1 in this guide.
Sun ONE Identity Server 6.0 or 6.0 SP 1
or
iPlanet Directory Server Access Management Edition (DSAME) 5.1
Upgrade to Identity Server 2003Q4 (6.1), by following the process in the Sun ONE Identity Server 6.1 Migration Guide:
http://docs.sun.com/doc/816-6771-10
After you upgrade to Identity Server 2003Q4 (6.1), follow the steps in Upgrading Identity Server 6.1 in this guide.
Before You Begin the Access Manager Upgrade
Before you upgrade Access Manager, perform these preliminary steps:
Obtaining the Java Enterprise System 2005Q1 Installation Software
Obtain the Sun Java Enterprise System (Java ES) 2005Q1 installation software. You can download the software from the Sun Download Center at:
http://www.sun.com/software/download/
Or, request a media kit containing the software on CDs or a DVD from your Sun sales representative.
For more information about obtaining the Java ES installation software, see the Sun Java Enterprise System 2005Q1 Installation Guide.
Obtaining All Required Patches
If you plan to upgrade to Access Manager 6 2005Q1, you need the following patches:
- Solaris™ OS, SPARC� Platform Edition: 118217, 118218, 117585, 117112, 118151
- Solaris OS, x86 Platform Edition: 118217, 118218, 117584, 117585, 118152
Note
118217, 118218 and 117585 are common patches that apply to both the SPARC and x86 platforms. Apply patches 118217 and 118218 first, before you apply 117585.
- Linux OS: 117588 (patch that contains the required Linux RPM packages)
- Shared components: See Upgrading Shared Components
- To obtain the required patches, download them from the SunSolve site: http://sunsolve.sun.com/
Obtaining the Required Information and Passwords
To upgrade Access Manager, you must provide specific information, including administrator names and passwords. For example, you must know the Access Manager administrator and password and Directory Manager name and password for the Directory Server that Access Manager is using.
Backing Up Your Directory Server Data
The upgrade process uses scripts that modify the Directory Server schema (DIT). Therefore, before you upgrade, back up your Directory Server data using the Directory Server Console or a command-line utility such as db2bak.
For more information about backing up Directory Server, see the Sun Java System Directory Server Administration Guide (http://docs.sun.com/doc/817-7613).
Backing Up Any Web Container Customized Files
Before you upgrade, back up any web container customized files related to previous versions of Access Manager, including:
Upgrading the Shared Components
Patches to upgrade the shared components are not required to upgrade Access Manager, but they are required when you upgrade other Java ES components such as the Access Manager web containers (see Upgrading Shared Components).
Upgrading the Web Container Software
If you are upgrading both the web container (Web Server or Application Server) and Access Manager, upgrade the web container first, or the Access Manager amconfig script will configure and redeploy Access Manager to the existing (old) web container. Access Manager 6 2005Q1 supports these web containers:
For information about upgrading the web container, refer to the respective web container documentation:
- Sun Java System Web Server 6.1 2005Q1 SP4: (see Upgrading Web Server)
- Sun Java System Application Server 8.1 2005Q: (see Upgrading Application Server)
Also, if you saved any customized files under Backing Up Any Web Container Customized Files, redo the customizations after you upgrade the web container.
Use a Non-SSL Port for Directory Server
When you upgrade Access Manager, the upgrade process does not finish successfully if you specify the Directory Server SSL port (for example, the default value of 636) when you run the pre61to62upgrade, Upgrade61DitTo62, or amupgrade script.
Therefore, when you run these scripts, specify a non-SSL port such as the 389 default value.
Upgrading the Directory Server LDAP directory schema
If the Directory Server was configured with comm_dssetup.pl as part of Java Enterprise System 2004Q2 for Messaging Server, Calendar Server or commcli then please complete the section Upgrading Sun Java System Directory Server LDAP directory schema before upgrading Access Manager.
If you already have already completed the upgrade of the Sun Java System Directory Server LDAP directory schema as part of another product upgrade, you do not need to repeat this step again.
Upgrading Directory Server (Optional)
Upgrading Directory Server is optional. To upgrade from Identity Server 2004Q2 to Access Manager 6 2005Q1, you can be running either of these versions:
For more information about upgrading Directory Server, refer to Upgrading Directory Server.
Upgrading Identity Server 2004Q2 (6.2)
In this scenario, you want to upgrade Identity Server 2004Q2 (6.2) or Identity Server 2004Q2 (6.2) SP1 to Access Manager 6 2005Q1 (6.3).
To Upgrade Identity Server 2004Q2 to Access Manager 6 2005Q1
- Log in as or become superuser (root).
- Make sure you have performed the steps listed under Before You Begin the Access Manager Upgrade.
- If you have installed Identity Server 2004Q2 SP1, you must first back out SP1 before you apply the upgrade patches.
To determine the release you are running use the amserver version command on either a Solaris or Linux system. On Solaris systems, you can also use the showrev command with the -p option to display patch information. For example:
# showrev -p | grep SUNWam
- On the Solaris 8 or 9 SPARC and x86 platforms, remove the SUNWamjwsdp Solaris package. On Linux systems, remove the sun-identity-jwsdp RPM package. For example, on a Solaris system:
# pkgrm SUNWamjwsdp
These packages contain Access Manager 2004Q2 (6.2) components such as JAXP and JAXB for the Java Web Services Developer Pack (JWSDP). Access Manager 2005Q1 (6.3) uses the Java ES shared component packages and RPMs for the JWSDP products instead of bundling its own.
- Apply the Access Manager upgrade patches or RPMs, depending on your platform (see Table 3-2). If you have a multi-server configuration, apply the respective patches or RPMs to each server running an instance of Access Manager.
- Solaris™ OS, SPARC� Platform Edition: 118217, 118218, 117585, 117112, 118151
- Solaris OS, x86 Platform Edition: 118217, 118218, 117585, 117584, 118152
- Linux OS: 117588 (patch that contains the required Linux RPMs)
To upgrade:a. Unzip the 117588 patch file.
b. Read the README file.
c. Run the installpatch script, which adds the RPMs.
- Re-apply the customized JSPs for the Access Manager console and authentication user interface (UI) that you saved under Backing Up Any Web Container Customized Files. Then, copy the customized JSP files to the correct directories. For example, on Solaris systems:
- Console: AccessManager-Base/SUNWam/web-src/applications/console
- Authentication UI: AccessManager-Base/SUNWam/web-src/services/config/auth/default or AccessManager-Base/SUNWam/web-src/services/config/auth/default_lcl (where lcl is a locale indicator like ja)
For more information, see the Sun Java System Access Manager Developer's Guide (http://docs.sun.com/doc/817-7649).
- Configure Access Manager for your specific web container by running the amconfig script.
Note
Before you run amconfig, make sure that you have upgraded the Access Manager web container, as described in Upgrading the Web Container Software.
Before you run amconfig, Directory Server and the appropriate web container must be running.
Before you run amconfig, set the configuration variables in the configuration script input file, which is based on the amsamplesilent template file:
- Set DEPLOY_LEVEL=21 and DIRECTORY_MODE=4.
- The default JDK version for Sun Java Enterprise System 2005Q1 release is 1.5, so make sure you set the JAVA_HOME variable in the configuration script input file to the correct directory.
- Make sure to set the AM_ENC_PWD variable to the same value you specified when you ran the Java ES installer (which is also the value of the am.encryption.pwd parameter in the AMConfig.properties file.
- For other values in the configuration script input file, provide the same values that were used for the Identity Server 6.1 configuration that you are upgrading (unless you have changed specific items such as your web container or passwords).
The amconfig script and the amsamplesilent file are installed in the following directories:
- Solaris systems: AccessManager-base/SUNWam/bin
- Linux systems: AccessManager-base/identity/bin
The default AccessManager-base installation directory is /opt on Solaris systems and /opt/sun on Linux systems.
For example, to run amconfig on a Solaris system with Access Manager installed in the base installation directory:
# cd /opt/SUNWam/bin
# ./amconfig -s config-filewhere config-file is the configuration script input file.
For information about the amconfig script and the amsamplesilent file, see the Sun Java System Access Manager Administration Guide (http://docs.sun.com/doc/817-7647).
- Upgrade the Access Manager schema (DIT) to Access Manager 6 2005Q1 by running the amupgrade script, which is installed in the following directory:
- Solaris systems: AccessManager-base/SUNWam/upgrade/scripts
- Linux systems: AccessManager-base/identity/upgrade/scripts
The default AccessManager-base installation directory is /opt on Solaris systems and /opt/sun on Linux systems.
Before you run amupgrade, you will need to know the following information:
- Fully-qualified host name and non-SSL port number of the Directory Server that Access Manager is using
- Directory Manager name (default: cn=Directory Manager) and password for the Directory Server
- Access Manager administrator (default: amadmin) and password
Run the amupgrade script. For example, on Solaris systems:
# cd opt/SUNWam/upgrade/scripts
# ./amupgradeIf the upgrade is successful, the script displays “Upgrade completed.”
- The amupgrade script writes status information to the following log file:
/var/sadm/install/logs/Sun_Java_System_Identity_Server_upgrade_dit_log. mmddhhmm
Check this log file for information about the upgrade.
- Restart the Access Manager web container for the upgrade changes to take effect.
- If you are using the Security Assertion Markup Language (SAML) service, you must add and enable the SAML authentication module using the Access Manager console. For the steps involved, refer to the Sun Java System Access Manager Administration Guide (http://docs.sun.com/doc/817-7647).
Upgrading Identity Server 6.1
In this scenario, you want to upgrade Identity Server 2003Q4 (6.1) to Access Manager 6 2005Q1.
To Upgrade Identity Server 6.1 to Access Manager 6 2005Q1
- Log in as or become superuser (root).
- Make sure you have performed any required steps listed under Before You Begin the Access Manager Upgrade.
- To run the pre-upgrade script in the next step, Directory Server must be running. To verify that Directory Server is running:
# ps -ef | grep slapd
If Directory Server is not running, start it. For example:
# cd /var/opt/mps/serverroot/slapd-instance-name
# ./start-slapd- Run the Identity Server 2004Q2 pre-upgrade script (pre61to62upgrade) to perform these functions:
- Backs up Identity Server 2003Q4 by running the am2bak script
- Removes the Identity Server 2003Q4 packages (but not the Directory Server or web container packages) and then updates the /var/sadm/install/productregistry file to reflect that the packages have been removed
- Writes the Sun_Java_System_Identity_Server_upgrade_log.timestamp log file to the /var/sadm/install/logs directory
The pre61to62upgrade script is part of the Java ES installation software and is available in the following directory:
JavaES_base/Solaris_sparc/Product/identity_srv/Tools
The JavaES_base is the directory where you uncompressed the archive. For example:
# cd JavaES2005Q1/Solaris_sparc/Product/identity_srv/Tools
# ./pre61to62upgrade- When you are prompted by the script, enter the following information:
- Directory Server fully qualified host name. For example: ds.example.com
- Directory Server non-SSL port number. Default is 389.
- Distinguished name (DN) and password of the top-level Identity Server administrator. For example: uid=amAdmin,ou=People,dc=example,dc=com
- Directory where the script should back up the Identity Server 6.1 files. For example: /opt/is_backup
- Certificate directory of the web container. For example: /opt/SUNWwbsvr/alias
- Install Access Manager 6 2005Q1 by running the Java ES 2005Q1 installer. On the Configuration Type panel, choose the Configure Later option.
The Java ES installer then installs the component packages but does not configure the components. For information about the Java ES installer, refer to the Sun Java Enterprise System 2005Q1 Installation Guide (http://docs.sun.com/doc/819-0056).
- Configure Access Manager for your specific web container by running the amconfig script.
Note
Before you run amconfig, make sure that you have upgraded the Access Manager web container, as described in Upgrading the Web Container Software.
- Set DEPLOY_LEVEL=21 and DIRECTORY_MODE=4.
- The default JDK version for Sun Java Enterprise System 2005Q1 release is 1.5, so make sure you set the JAVA_HOME variable in the configuration script input file to the correct directory.
- Make sure to set the AM_ENC_PWD variable to the same value you specified when you ran the Java ES installer (which is also the value of the am.encryption.pwd parameter in the AMConfig.properties file.
- For other values in the configuration script input file, provide the same values that were used for the Identity Server 6.1 configuration that you are upgrading (unless you have changed specific items such as your web container or passwords).
The amconfig script and the amsamplesilent file are installed in the following directories:
- Solaris systems: AccessManager-base/SUNWam/bin
- Linux systems: AccessManager-base/identity/bin
The default AccessManager-base installation directory is /opt on Solaris systems and /opt/sun on Linux systems.
For information about the amconfig script and the amsamplesilent file, see the Sun Java System Access Manager Administration Guide (http://docs.sun.com/doc/817-7647).
- To run the post-upgrade script in the next step, Directory Server must be running. To verify that Directory Server is running:
# ps -ef | grep slapd
If Directory Server is not running, start it. For example:
# cd /var/opt/mps/serverroot/slapd-instance-name
# ./start-slapd- Run the Identity Server 2004Q2 post-upgrade script (Upgrade61DitTo62) to upgrade the Directory Server schema (DIT) to Identity Server 2004Q2.
This script is available in the following directories:
- Solaris systems: AccessManager-base/SUNWam/migration/61to62/scripts
- Linux systems: AccessManager-base/identity/migration/61to62/scripts
The default AccessManager-base installation directory is /opt on Solaris systems and /opt/sun on Linux systems.
For example, to run the script on Solaris systems:
# cd opt/SUNWam/migration/61to62/scripts
# ./Upgrade61DitTo62- When you are prompted by the Upgrade61DitTo62 script, provide the following information:
- Directory Server fully qualified host name. For example: ds.example.com
- Directory Server non-SSL port number. Default is 389.
- Distinguished name (DN) and password of the Directory Manager
- Distinguished name (DN) and password of the top-level Identity Server administrator. For example: uid=amAdmin,ou=People,dc=example,dc=com
- When you are prompted by the Upgrade61DitTo62 script, restart Directory Server. The script pauses for you to perform the restart.
- After the Upgrade61DitTo62 script finishes, restart both Directory Server and the web container for the schema changes to take effect.
- Upgrade the Access Manager schema (DIT) to Access Manager 6 2005Q1 by running the amupgrade script, which is installed in the following directory:
- Solaris systems: AccessManager-base/SUNWam/upgrade/scripts
- Linux systems: AccessManager-base/identity/upgrade/scripts
The default AccessManager-base installation directory is /opt on Solaris systems and /opt/sun on Linux systems.
Before you run amupgrade, you will need to know the following information:
- Fully-qualified host name and non-SSL port number of the Directory Server that Access Manager is using
- Directory Manager name (default: cn=Directory Manager) and password for the Directory Server
- Access Manager administrator (default: amadmin) and password
Run the amupgrade script. For example, on Solaris systems:
# cd /opt/SUNWam/upgrade/scripts
# ./amupgradeIf the upgrade is successful, the script displays “Upgrade completed.”
- The amupgrade script writes status information to the following log file:
/var/sadm/install/logs/Sun_Java_System_Identity_Server_upgrade_dit_log. mmddhhmm
Check this log file for information about the upgrade.
- If you are using the Security Assertion Markup Language (SAML) service, you must add and enable the SAML authentication module using the Access Manager console. For the steps involved, refer to the Sun Java System Access Manager Administration Guide (http://docs.sun.com/doc/817-7647).
You have now upgraded to Access Manager 6 2005Q1.
Upgrading an Access Manager SDK Installation
This section describes how to upgrade an SDK only installation to the Access Manager 6 2005Q1 SDK, including:
To Upgrade an Identity Server 2003Q4 (6.1) SDK Only Installation
- Log in as or become superuser (root).
- Make sure you have saved the Identity Server 6.1 AMConfig.properties and serverconfig.xml configuration files.
- Uninstall the Identity Server 6.1 SDK by following the instructions in the Sun Java Enterprise System 2003Q4 Installation Guide (http://docs.sun.com/doc/816-6874).
- Install the Access Manager 6 2005Q1 SDK by following the instructions in the Sun Java Enterprise System 2005Q1 Installation Guide (http://docs.sun.com/doc/819-0056).
You can also install the Identity Server 2004Q2 SDK and then apply the patches described in To Upgrade an Identity Server 2004Q2 (6.2) SDK Only Installation.
- Incorporate the configuration changes you saved in Step 2 into the new Access Manager 6 2005Q1 configuration files.
To Upgrade an Identity Server 2004Q2 (6.2) SDK Only Installation
- Make sure you have saved the Identity Server 2004Q2 AMConfig.properties and serverconfig.xml configuration files.
- Apply the following Access Manager upgrade patches on the server where the SDK is installed, depending on your platform:
- Solaris™ OS, SPARC� Platform Edition: 118217, 118218, 117585,117112, 118151
- Solaris OS, x86 Platform Edition: 118217, 118218, 117584, 117585, 118152
- Linux OS: 117588 (patch that contains the required Linux RPMs)
To upgrade:a. Unzip the 117588 patch file.
b. Read the README file.
c. Run the installpatch script, which adds the RPMs.
- Configure the Access Manager SDK for your specific deployment by running the amconfig script. Before you run amconfig, set the configuration variables in the configuration script input file, which is based on the amsamplesilent template file. Set DEPLOY_LEVEL as follows:
- DEPLOY_LEVEL=3 to upgrade the SDK only
- DEPLOY_LEVEL=4 to upgrade the SDK and configure the web container
For other values in the configuration script input file, provide the same values that were used for the Identity Server 6.1 SDK configuration that you are upgrading (unless you have changed specific items such as your web container or passwords).
The default JDK version for Sun Java Enterprise System 2005Q1 release is 1.5, so make sure you set the JAVA_HOME variable in the configuration script input file to the correct directory.
The amconfig script and the amsamplesilent file are installed in the following directories:
- Solaris systems: AccessManager-base/SUNWam/bin
- Linux systems: AccessManager-base/identity/bin
The default AccessManager-base installation directory is /opt on Solaris systems and /opt/sun on Linux systems.
For information about the amconfig script and the amsamplesilent file, see the Sun Java System Access Manager Administration Guide (http://docs.sun.com/doc/817-7647).
- Incorporate the configuration changes you saved in Step 1 into the new Access Manager 6 2005Q1 configuration files.
- If you are using the Security Assertion Markup Language (SAML) service, you must add and enable the SAML authentication module using the Access Manager console. For the steps involved, refer to the Sun Java System Access Manager Administration Guide (http://docs.sun.com/doc/817-7647).
Upgrading Multiple Instances
This section describes how to upgrade multiple Identity Server instances running on different host systems that share the same Directory Server.
The upgrade process supports multiple instances of Identity Server installed on different host systems. Upgrading multiple instances of Identity Server installed on the same host system is not supported in the current release. If you have multiple instances on the same host, after you upgrade the main instance, you must then recreate the additional instances.
To Upgrade an Instance
- Log in as or become superuser (root).
- Stop all Identity Server instances that access Directory Server. For example, on a Solaris system that uses the default installation directory:
# cd /opt/SUNWam/bin
# ./amserver stopStopping all instances prevents Identity Server from making changes to the Directory Server while you are performing the upgrade.
- Start the Identity Server instance you want to upgrade.
- Upgrade the Identity Server instance you started in Step 3, following the process shown in the Access Manager Upgrade Roadmap.
During the upgrade of the first instance, the post-upgrade scripts upgrade the Directory Server to include the Access Manager 6 2005Q1 schema elements. During subsequent upgrades of other instances, however, the scripts detect that Directory Server has already been upgraded and do not try to upgrade it again.
- Restart the instance you just upgraded.
- Repeat Step 3 through Step 5 for each Identity Server instance on a different host that you want to upgrade.
- If there are any Identity Server 2004Q2 instances you did not upgrade, restart those instances. For information about the co-existence of Identity Server 2004Q2 and Access Manager 6 2005Q1, see Access Manager Coexistence.
Verifying the Upgrade
After you finish the upgrade process, verify that the upgrade was successful as follows:
- Log in to the Access Manager 6 2005Q1 console as amadmin using the following URL:
http://host-name.domain-name:port/amconsole
where host-name.domain-name:port is the fully qualified host name and port number of the web container you are using.
Verify that new services under the “Service Configuration” tab are available.
- Review the status of the upgrade by checking the following log files in the /var/sadm/install/logs directory:
pre61to62upgrade script:
Sun_Java_System_Identity_Server_upgrade_log.timestamp
Sun Java Enterprise System installer:
–Java_Shared_Component_Install.timestamp
–Java_Enterprise_System_install.Atimestamp
–Java_Enterprise_System_install.Btimestamp
–Java_Enterprise_System_Summary_Report_install.timestamp
Upgrade61DitTo62 script:
Sun_Java_System_Identity_Server_upgrade_dit_log.timestamp
amupgrade script:
Sun_Java_System_Identity_Server_upgrade_dit_log.timestamp
Access Manager Coexistence
The coexistence of Access Manager 6 2005Q1 and Identity Server 2004Q2 is a transitional phase during an Access Manager upgrade. These two versions can coexist and run concurrently against the same shared Directory Server, with these considerations:
- Access Manager 6 2005Q1 and Identity Server 2004Q2 must be installed on different servers.
- When you install Access Manager 6 2005Q1 using the Java ES installer, specify the Configure Later option, since you are using existing Directory Server. After installation, run the amconfig script to configure Access Manager and to deploy the web applications. In the amconfig configuration script input file (amsamplesilent), set DEPLOY_LEVEL=1 and DIRECTORY_MODE=4.
- If you have not upgraded Directory Server to include the Access Manager 6 2005Q1 schema elements, you can use either Access Manager 6 2005Q1 or Identity Server 2004Q2 to access the directory.
- After you have upgraded Directory Server to include the Access Manager 6 2005Q1 schema elements, you must use Access Manager 6 2005Q1 to access new the new Access Manager features, including new services, attributes in existing services, and policy plug-ins. Identity Server 2004Q2, including the console, will not function correctly with the Manager 6 2005Q1 schema.
Upgrading Administration Server, Directory Server, and Directory Proxy ServerThis section describes how to upgrade and backout Administration Server, Directory Server, and Directory Proxy Server for Sun Java Enterprise System 2005Q1. This section describes upgrade and backout for the following versions of Administration Server, Directory Server, and Directory Proxy Server:
For information about how to upgrade from or backout to versions of Administration Server, Directory Server, and Directory Proxy Server prior to these versions, see the Administration Server Migration Information, Directory Server Migration Information, and Directory Proxy Server Migration Information.
This section describes the following topics:
Planning to Upgrade Administration Server, Directory Server, and Directory Proxy Server
Before you upgrade Administration Server, Directory Server, or Directory Proxy Server, take note of the following points:
- Directory Server and Directory Proxy Server belong to a group of products that share the same Administration Server. You must patch these products at the same time.
- When you upgrade Directory Server on Solaris, some but not all instance-specific scripts under ServerRoot/slapd-serverID/ might be backed up under ServerRoot/slapd-serverID/upgrade/bak_patch2/, and then regenerated to reflect changes made during the upgrade. When you back out Directory Server, the back-up scripts are restored.
- You cannot upgrade Administration Server, Directory Server, or Directory Proxy Server by applying patches unless these products are installed on a Solaris system with SUNW* packages or on a Linux system with RPM packages.
- When you apply patches, you upgrade the SSL certificate database. If you subsequently decide to back out the patches and you have changed the content of the certificate database, you must manually replay the changes after backing out the patches. Consider performing a backup before you back out the patches.
- Directory Server, Directory Proxy Server, Messaging Server, Calendar Server and the associated Administration Server must run as the same user and group. That is, they must run with the same UID and GID.
- Rolling upgrade for Administration Server and Directory Server as a Sun Cluster data services is not supported.
Upgrading Administration Server, Directory Server, and Directory Proxy Server on Solaris
This section describes how to upgrade and backout Administration Server, Directory Server, and Directory Proxy Server on Solaris.
The procedures in this section use the commands directoryserver(1m) and mpsadmserver(1m). For more information about these commands, see the Directory Server Man Page Reference and the Administration Server Man Page Reference.
Table 3-3 lists the patches required for the upgrade. Patches can be downloaded from http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access.
To Upgrade Administration Server, Directory Server, and Directory Proxy Server on Solaris
This procedure includes steps for Calendar Server, and Messaging Server. If you are not using a component product, ignore the steps related to that product.
- Obtain the required patch numbers from Table 3-3.
- Stop the console if it is running.
- Stop all servers, in this order:
- Apply the shared component patch cluster. For information, see Upgrading Shared Components.
- Apply the Administration Server component patch.
- Apply the patch and the locale patch by using the patchadd(1m) command.
- Ensure that the configuration directory server is running.
- Synchronize the upgraded settings with the configuration directory server:
# /usr/sbin/mpsadmserver sync-cds
- If the configuration directory server is local, stop the configuration directory server.
- Apply the Directory Server component patch.
- If you are running Directory Server standalone, without Administration Server:
- Upgrade the partial Administration Server that was installed during the initial Directory Server installation. To do this, follow the instructions above for applying the Administration Server component patch.
- Change directory to the serverroot directory
# cd /var/opt/mps/serverroot
- Make a configuration directory:
# mkdir -p admin-serv/config
- Create an adm.config file:
# vi admin-serv/config/adm.conf
- Add the following text
isie: cn=Administration Server, cn=Server Group, cn=hostname, ou=administration_domain, o=NetscapeRoot
All on one line where hostname is a FQDN for the host Directory Server is running on. administration_domain is typically the host domain name.
- If the Directory Server is running, stop it now.
- Apply the patch by using the patchadd(1m) command.
Reset the default Directory Server:
# /usr/sbin/directoryserver -d 5.2
- Ensure that the configuration directory server is running.
- Synchronize the upgraded settings with the configuration directory server:
# /usr/sbin/directoryserver -u 5.2 sync-cds
- If the configuration directory server is local, stop the configuration directory server.
- Apply the Directory Proxy Server component patch.
- Ensure that the configuration directory server is running. This step is essential for automatic synchronization with the settings stored in the configuration directory server.
- Apply the patch by using the patchadd(1m) command.
- If the configuration directory server is local, stop the configuration directory server.
- Apply the Messaging Server component patch. For information, see Upgrading Messaging Server.
- Apply the Calendar Server component patch. For information, see Upgrading Calendar Server
- Restart the servers in this order:
To Back Out Administration Server, Directory Server, and Directory Proxy Server on Solaris
This procedure includes steps for Calendar Server, and Messaging Server. If you are not using a component product, ignore the steps related to that product.
- Stop the console if it is running.
- Stop all servers, in this order:
- Backout the Calendar Server component patch. For information, see Upgrading Calendar Server.
- Backout the Messaging Server component patch. For information, see Upgrading Messaging Server.
- Backout the Directory Proxy Server component patch.
- Ensure that the configuration directory server is running. This step is essential for automatic synchronization with the settings stored in the configuration directory server.
- Backout the patch by using the patchrm(1m) command.
- If the configuration directory server is local, stop the configuration directory server.
- Backout the Directory Server component patch.
- To backout to Directory Server 5.2 2003Q4
- Ensure that the configuration directory server is running.
- Synchronize the downgraded settings with the configuration directory server:
# /usr/sbin/directoryserver -u 5.2 sync-cds 5.2
- If the configuration directory server is local, stop the configuration directory server.
- Remove the patch by using the patchrm(1m) command
- If you are running Directory Server standalone, without Administration Server, you must back out the partial Administration Server that was upgraded. To do this, follow the instructions below for backing out the Administration Server.
- To backout to Directory Server 5.2 2004Q2
- Remove the patch by using the patchrm(1m) command
- Ensure that the configuration directory server is running.
- Synchronize the downgraded settings with the configuration directory server:
# /usr/sbin/directoryserver -u 5.2 sync-cds
- If the configuration directory server is local, stop the configuration directory server.
- If you are running Directory Server standalone, without Administration Server, you must back out the partial Administration Server that was upgraded. To do this, follow the instructions below for backing out the Administration Server.
- Backout the Administration Server component patch.
- To backout to Administration Server 5.2 2003Q4
- Ensure that the configuration directory server is running.
- Return to the pre-patch settings stored in the configuration directory server:
# /usr/sbin/mpsadmserver sync-cds 5.2
- If the configuration directory server is local, stop the configuration directory server.
- Remove the patch by using the patchrm(1m) command.
- To backout to Administration Server 5.2 2004Q2
- Remove the patch by using the patchrm(1m) command
- Ensure that the configuration directory server is running.
- Synchronize the downgraded settings with the configuration directory server:
# /opt/sun/sbin/mpsadmserver sync-cds
- If the configuration directory server is local, stop the configuration directory server.
- Backout the shared component patch cluster. For information, see Upgrading Shared Components.
- Restart the servers in this order:
Upgrading Administration Server, Directory Server, and Directory Proxy Server on Linux
This section describes how to upgrade Administration Server, Directory Server, and Directory Proxy Server on Linux.
The procedures in this section use the commands directoryserver(1m) and mpsadmserver(1m). For more information about these commands, see the Directory Server Man Page Reference and the Administration Server Man Page Reference.
If you are planning to upgrade from Linux RH AS 2.1 to Linux RH AS 3, you must upgrade the Sun Java Enterprise System component products before you upgrade Linux.
Caution
Only upgrade from version 5.2 2004Q2 to version 5.2 2005Q1 on Linux if you are sure you will not want to back out later. It is not possible to back out from version 5.2 2005Q1 on Linux.
Table 3-4 lists the patches and RPM packages required to upgrade Administration Server, Directory Server, and Directory Proxy Server on Linux. Patches can be downloaded from
http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access.
To Upgrade Administration Server, Directory Server, and Directory Proxy Server on Linux
This procedure includes steps for Directory Proxy Server, Calendar Server, and Messaging Server. If you are not using a component product, ignore the steps related to that product.
- Stop the console if it is running.
- Stop all servers, in this order:
- Obtain the required patches using the patch numbers and RPM names from Table 3-4. Use this information to obtain the version numbers for the RPM. In this procedure <oldversion> signifies the RPM for the previous version of Directory Server, Directory Proxy Server, and Administration Server 5.2 2004Q2.
- Apply the shared component patch cluster for Linux. For information, see Upgrading Shared Components.
- Apply each of the RPMs for the Administration Server component.
- Apply the RPM for the Administration Server product.
- Apply the RPM as follows:
# rpm -Fvh sun-admin-server-5.2-13.i386.rpm
If your Administration Server was configured previously, the following error will be returned:
error: execution of %preun scriptlet from sun-admin-server-5.2-<oldversion> failed, exit status 1
If this is the case, remove the old version of the RPM using the --noscripts option, as follows:
# rpm -e --noscripts sun-admin-server-5.2-<oldversion>
- If your Administration Server was configured previously, ensure that the configuration directory server is running, and then synchronize the upgraded settings with the configuration directory server, by using the command:
# /opt/sun/sbin/mpsadmserver sync-cds
- If the configuration directory server is local, stop the configuration directory server.
- Confirm that the upgrade was successful:
# rpm -q sun-admin-server
The new version number of the RPM should be returned.
- Apply the RPM for the Administration Server console:
# rpm -Fvh sun-server-console-5.2-13.i386.rpm
- Install the RPM for the Administration Server man pages:
# rpm -ivh sun-admin-server-man-5.2-3.i386.rpm
- Apply each of the RPM for the Directory Server component.
- If you are running Directory Server standalone, without Administration Server, you must upgrade the partial Administration Server that was installed during the initial Directory Server installation.
To do this, apply the Administration Server RPM:
# rpm -Fvh sun-admin-server-5.2-13.i386.rpm
- Apply the RPM for the Directory Server product.
- Apply the RPM as follows:
# rpm -Fvh sun-directory-server-5.2-19.i386.rpm
If your Directory Server was configured previously, the following error will be returned:
error: execution of %preun scriptlet from sun-directory-server-5.2-<oldversion> failed, exit status 1
If this is the case, remove the old version of the RPM using the --noscripts option, as follows:
# rpm -e --noscripts sun-directory-server-5.2-<oldversion>
- If your Directory Server was configured previously, ensure that the configuration directory server is running, and then synchronize the upgraded settings with the configuration directory server, by using the command:
# /opt/sun/sbin/directoryserver sync-cds
- If the configuration directory server is local, stop the configuration directory server.
- Confirm that the upgrade was successful:
# rpm -q sun-directory-server
The new version number of the RPM should be returned.
- Install the RPM for the Directory Server man pages:
# rpm -ivh sun-directory-server-man-5.2-3.i386.rpm
- Apply the RPM for the Directory Proxy Server component.
- Ensure that the configuration directory server is running.
- Apply the RPM:
# rpm -Fvh sun-directory-proxy-server-5.2-9.i386.rpm
The upgraded settings are automatically synchronized with the configuration directory server.
- If the configuration directory server is local, stop the configuration directory server.
- Apply the RPMs for the Messaging Server component. For information, see Upgrading Messaging Server.
- Apply the RPMs for the Calendar Server component. For information, seeUpgrading Calendar Server.
- Restart the servers in this order:
- If you wish to upgrade from Linux RH AS 2.1 to Linux RH AS 3, do so now. For information, see the Linux documentation.
Upgrading Directory Server as a Data Service in a Cluster
This section describes how to upgrade and backout Directory Server as a data service in a cluster. Consider the following points before you upgrade or backout Directory Server as a Sun Cluster data service:
- Stop the Directory Server for the duration of the upgrade or backout operation. Earlier versions of Directory Server 5.2 binaries cannot run on an upgraded Directory Server instance.
- Backup data before performing an upgrade or backout operation.
- Run all nodes of the cluster on the same version and release of Directory Server and the associated Administration Server.
- Patch all nodes of the cluster in sequence, not in parallel.
- If you are running the cluster in failover mode, consider upgrading from HAStorage to HAStoragePlus.
To Upgrade Directory Server as a Data Service in a Cluster
- Stop each Directory Server instance and its associated Administration Server by using the following commands:
# serverroot/stop-admin
# serverroot/slapd-instancename/stop-slapd- Make the current cluster node the active node:
# scswitch -z -g ldap-group -h this-node-name
- Upgrade the current node as described in To Upgrade Administration Server, Directory Server, and Directory Proxy Server on Solaris.
- Make another cluster node the active node:
# scswitch -z -g ldap-group -h another-node-name
To Backout Directory Server as a Data Service in a Cluster
- Stop each Directory Server instance and its associated Administration Server by using the following commands:
# serverroot/stop-admin
# serverroot/slapd-instancename/stop-slapd- Make the current cluster node the active node:
# scswitch -z -g ldap-group -h this-node-name
- Backout the current node as described in To Back Out Administration Server, Directory Server, and Directory Proxy Server on Solaris.
- Make another cluster node the active node:
# scswitch -z -g ldap-group -h another-node-name
Upgrading Application ServerIt is possible that your version of Application Server was installed as part of Java Enterprise System, or included with a Solaris operating system bundle.
This section contains:
Upgrading from Versions Bundled with Solaris
The Java Enterprise System installer allows an automatic upgrade of versions of Application Server installed bundled with Solaris.
Use the Java Enterprise System installer and follow the instructions in the Java Enterprise System 2005Q1 Installation Guide to upgrade to Application Server 8.1.
Upgrading from All Other Versions
Use these procedures to upgrade Application Server 7.0 UR to Application Server 8. 1 EE.
- Log in as or become superuser (root).
- Stop all Application Server and related processes.
- Upgrade the dependent old version of Sun Java System Message Queue to the latest Sun Java System Message Queue 3 2005Q1. For more detail refer to the Upgrading Message Queue.
- If necessary, upgrade the dependent old version of Java Enterprise System 2003Q4 version Web Server. For more detail refer to Upgrading Web Server. (This is an optional step for when the LoadBalance Plugin is going to be installed.)
- Back up both Admin and Domain server instance of Application Server 7.0 UR config directory.
- Use the Java Enterprise System installer to install Sun Java System Application Server Enterprise Edition 8.1 2005Q1 with the Configure Later option. For more information, refer to the Sun Java Enterprise System 200Q1 Installation Guide (http://docs.sun.com/doc/819-0056).
- Identify both target and source installation directories, for example:
- Know your admin username, password, and master password.
- Launch the asupgrade tool located under the Application Server directory, for example:
/<appserver_install_dir>/asupgrade - upgrade wizard mode.
/<appserver_install_dir>/asupgrade -c - upgrade console mode.
- The upgrade wizard or upgrade console will guide you through the upgrade steps.
For more information about the Application Server upgrade utility, refer to Chapter 3 of the Application Server Enterprise Edition 8.1 Upgrade and Migration Guide 2005Q1 (http://docs.sun.com/doc/819-0222).
Upgrading a Cluster: How Is It Done?
The Application Server’s Upgrade utility captures cluster details from the clinstance.conf, the cluster configuration file. If more than one cluster has been defined for the Application Server 7.x, multiple .conf files may exist prior to the upgrade. The configuration files could have any name, but all would have the .conf file extension. If clusters will be included in an upgrade, consider the following points when you are defining clinstance.conf files.
Instance names in the clinstance.conf file must be unique. For example, in Application Server 7.x, machine A could have server1 and server2 participating in a cluster. Machine B could also have a server1 participating in the same cluster. Typically, the clinstance.conf file would include the server1 and server2 of machine A and server1 of machine B. Application Server 8.1 requires instance names in a cluster to be unique. Therefore, prior to the upgrade, in the clinstance.conf file you would need to rename server1 of machine B to a unique name, such as server3 or server1of machine B. You do not, however, need to rename the server1 instance itself in machine B; you only need to rename the server in the clinstance.conf file. The expectation is that instances participating in the cluster are homogeneous, in the sense that they would have same kind of resources, and same applications deployed in them.
When the upgrade process runs, the instance marked as the master instance will be picked up for transferring the configuration. If there is no instance marked as the master instance, one of the instances will be picked up in a random manner and used for transferring the configuration.
A cluster is created in the DAS, along with instances defined in the clinstance.conf file. All these instances participating in this cluster share the same configuration named <cluster_name>-config, where the cluster_name is cluster_0 for the first cluster, cluster_1 for the next cluster, and so forth. Each instance in the cluster has HTTP and IIOP ports set in their system properties. The HTTP port is the port defined in the clinstance.conf file as the instance port. IIOP ports are selected from the iiop-cluster configuration in the server.xml file.
Server instances that participate in the cluster and that run on a machine other than the machine on which the DAS is running, are created with a node-agent named <host-name>-<domain-name>, where the host-name is the name given in the clisntance.conf file for that particular instance and the domain-name is the name to which this cluster belongs.
After the upgrade process has been completed on the DAS, install Application Server 8.1 on the other machines where clustered instances need to run.
- Copy the node-agent directory from DAS machine to client machine under install-dir/nodeagents/. For instance, if your DAS is installed on HostA and client machine name is HostB, the upgrade process would have created a node agent named "HostB-<domain_name>" as the node-agent for HostB. Hence copy HostB-<domain_name> from HostA<AS81_install_dir>/nodeagents/HostB-<domain_name> directory to HostB <AS81_install_dir>/nodeagents. After copying, delete the copied node agent directory under HostA.
- Edit nodeagent.properties file on client machine HostB under agent/config directory. Set agent.client.host to the client machine name. In this case it should be HostB.
- Edit das.properties file on client machine HostB under agent/config directory. Make sure agent.das.isSecure=false in das.properties file. It should be set to false if by default Application Server 7.x Administration Server was running on non secure port. If Application Server 7.x Administration Server was running on secure port, then it should be set to true.
- Start domain and start node agents on both DAS machine as well as client machines. This in turn will run the clustered instance.
Correcting Potential PE and EE Upgrade Problems
This section addresses the following issues that could occur during an upgrade to Application Server 8.1:
Migrating Additional HTTP Listeners Defined on the Source Server to the Target PE Server
If additional HTTP listeners have been defined in the PE source server, those listeners need to be added to the PE target server after the upgrade:
Migrating Additional HTTP and IIOP Listeners Defined on the Source Server to the Target EE Server
If additional HTTP listeners or IIOP listeners have been defined in the source server, the IIOP ports must be manually updated for the target EE servers before any clustered instances are started. For example, if MyHttpListener was defined as an additional HTTP listener in server1, which is part of the cluster, because server instances are symmetrical in a cluster, the other instances in the cluster will also have the same HTTP listener. In the target configuration named <cluster_name>-config, this listener must be added with its port set to a system property {myHttpListener_HTTP_LISTENER_PORT}. In the target server, each server instance in this cluster that uses this configuration would have system property named myHttpListener_HTTP_LISTENER_PORT. The value of this property for all server instances would be set to the port value in the source server, server1. These system properties for these server instances must be manually updated with non-conflicting port numbers before the server is started.
If additional HTTP listeners have been defined in the source server, those listeners need to be added to the target server after the upgrade:
Eliminating Port Conflict Problems
After upgrading the source server to AS 8.1 EE, start the domain. Start the node agent that, by default, starts the server instances. Start the Admin Console and verify that these servers are started. If any of the servers are not running, in the <install_dir>/nodeagents/<node-agent-name>/<server_name>/logs/server.log file, check for failures that are caused by port conflicts. If there any failures due to port conflicts, use the Admin Console and modify the port numbers so there are no more conflicts, then stop and restart the node agent and servers.
If an AS 7.1 EE source server with no clusters is being upgraded to AS 8.1 EE (only standalone instances are being upgraded), and if server1 in the AS 7.1 source server has an IIOP port number of 3700, this conflicts with the IIOP port that is defined for the AS 8.1server-config. If these conditions exist, start the Admin Console after the upgrade and change the IIOP port for the server-config’s IIOP listener to a non conflicting port number. If an AS 7.x SE source server is being upgraded to AS 8.1 EE, the upgrade process should automatically update the IIOP port for the <server-config>.
Eliminating Problems Encountered When A Single Domain has Multiple Certificate Database Passwords
If the upgrade includes certificates, provide the passwords for the source PKCS12 file and the target JKS keyfile for each domain that contains certificates to be migrated. Since Application Server 7 uses a different certificate store format (NSS) than Application Server 8 PE (JSSE), the migration keys and certificates are converted to the new format. Only one certificate database password per domain is supported. If multiple certificate database passwords are used in a single domain, make all of the passwords the same before starting the upgrade. Then reset the passwords after the upgrade has been completed.
Upgrading Calendar ServerThis section describes how to upgrade from Sun Java System Calender Server to the 2005Q1 release. Upgrading Calendar Server involves upgrading other Java Enterprise System components and applying the appropriate patches. This section includes:
Upgrading Non-Cluster Deployments
Use the upgrade procedures relevant to your situation:
- Upgrading from earlier Java Enterprise System versions (see Upgrading from Earlier Calendar Server Versions).
- Upgrading from Pre Java Enterprise System Calendar Server versions (see Calendar Server Migration Information).
Upgrading from Earlier Calendar Server Versions
- Upgrade Shared Components.
Before you upgrade the Calendar Server core software to the 6 2005Q1, you must obtain upgrade patches for the shared components shown in Table 3-5
- Apply the Dependent Patch Using the patchadd command.
Before you apply the Calendar Server core patch, you must install the appropriate dependent patch shown in Table 3-6.
- To upgrade to the Calendar Server 6 2005Q1 release, apply the appropriate core software patch shown in Table 3-7 using the patchadd command.
- Install and run the Directory Server Setup Perl script, see Upgrading Sun Java System Directory Server LDAP directory schema.
- Configure Calendar Server 6 2005Q1.
Run the Calendar Server configuration program (csconfigurator.sh).
For instructions, see “Chapter 3: Configuring Calendar Server,” in the Sun Java System Calendar Server 6 2004Q2 Administration Guide (http://docs.sun.com/doc/817-5697)
To Upgrade Cluster Deployments
- Stop the cluster services:
cal_svr_base/cal/sbin/stop-cal
- To find Cluster nodes containing Calendar Server enter the following:
# pkginfo | grep -i sunwics5
- Follow the procedure in Upgrading Non-Cluster Deployments on each node where the Calendar Server is installed.
To Upgrade Delegated Administrator
Calendar Server requires that you use Delegated Administrator to provision users, groups, domains, and resources.See Upgrading to Delegated Administrator.
To Remove Calendar Server Patches
If you decide to remove the Java Enterprise System 2005Q1 patches, perform the following steps:
- Stop the Calendar Server:
cal_svr_base/cal/sbin/stop-cal
- Backup the calendar database. The default database directory is:
/var/opt/SUNWics5/csdb
- Remove the appropriate Calendar Server Patches added in Step 3.
Upgrading Communications ExpressThis section describes how to upgrade from Sun Java System Communications Express 6 2004Q2 to the 2005Q1 release. Upgrading Communications Express involves upgrading other Java Enterprise System components and applying the appropriate patches. It includes:
Note
To upgrade from Messaging Server 6 2003Q4 to the latest release you must first upgrade to Messaging Server 6 2004Q2. You must upgrade all component products located on the same system to the 2004Q2 level at the same time.
For more details refer to Chapter 8 of the Sun Java Enterprise System 2004Q2 Installation Guide (http://docs.sun.com/doc/817-5760).
Upgrading from Communications Express 6 2004Q2
If you want to use S/MIME for Communications Express Mail, you must follow the steps described in this section.
To configure S/MIME, after you install and configure Communications Express 6 2005Q1, you also must perform the tasks described in the following section:
To run Communications Express, you must have an instance of Messaging Server installed on the same machine as the Communications Express software.
Prior to upgrading Communications Express, you must upgrade the following:
- Shared components
- JDK and web container (Webserver or Application Server)
- Messaging Server
- Calendar Server
- Directory Server and Schema
- Apply the Communications Express upgrade patch.
To upgrade to the Communications Express 6 2005Q1 release, apply the patch shown in Table 3-8.
- Install the appropriate patch.
- On Solaris
- On Linux:
- Run the following command to install the patch.
rpm -F <directory-under-which-patch-tarball-was-untarred>/ <uwc-patch.rpm>
- Run the following command to ensure that the patch is installed successfully. Ensure that the rpm name is present in the command output.
rpm -qa |grep uwc
An example of the rpm name is sun-uwc-6.1.7.x
Configuring Communications Express
To apply the patch files and patch configuration to Communications Express, you need to run the patch-config and install-newconfig script.
- Running the patch-config script maintains a backup of the existing files and merges the .properties file under the existing deployment with the new.properties file data that is bundled with the patch.
The new patch files and the backup files are created under <uwc-basedir>/SUNWuwc/install/patch/<patchID>/save
where, <patchID> is the number of the patch that is configured.
The save directory is created during patch configuration. The save directory has the same directory structure layout as the <uwc-basedir> directory and maintains the backed up files.
For each file included in the Communications Express patch, the script prepares two files under <uwc-basedir>/SUNWuwc/install/patch/<patchID>/save.
For example, if the two files are <web.xml> and <web.xml>.new are created under save/WEB-INF
Where,
<web.xml> represents the file backed up from previous Communications Express deployment.
<web.xml>.new represents the new file installed from Sun Java System Communications Express 6 2005Q1. This file is copies to the deploy location when you run the install-newconfig program.
- Running the install-newconfig script copies the Sun Java System Communications Express 6 2005Q1 files to the deployed location.
The install-newconfig script copies all the .new files prepared by patch-config script into the Communications Express deployment and removes certain shared component jar files from the existing Communications Express deployment.
The following jar files are removed from the deployed location:
am_logging.jar, am_sdk.jar, am_services.jar, jaxp-api.jar, jss3.jar, sax.jar,xtype.jar,xmlutil.jar
- Run patch-config script.
The patch-config script prepares the patch files to be installed. It takes a backup of the existing customization and merges the new configuration changes. Note, this step will not update the existing configuration.
On Solaris:
/opt/SUNWuwc/sbin/patch-config -d /var/opt/SUNWuwc /opt/SUNWuwc /install/patch/<patchID>
Where, -d is the directory in which Communications Express is deployed.
On Linux:
/opt/sun/uwc/sbin/patch-config -d /var/opt/sun/uwc /opt/sun/uwc /install/patch/<patchID>
- Run the following command to copy the patch files prepared by the patch-config script into the deployed location. This step will update the existing configuration. After performing this step successfully, the existing deployment is upgraded to Java Enterprise System 2005Q1.
On Solaris:
/opt/SUNWuwc/sbin/install-newconfig /opt/SUNWuwc/install/patch /<patchID>
Where, /opt is the package base directory of the Communications Express (uwc-basedir).
On Linux:
/opt/sun/uwc/sbin/install-newconfig /opt/sun/uwc/install/patch /<patchID>
Where, /opt/sun/uwc represents the rpm install directory of the Communications Express (uwc-basedir).
- Update the Address Book schema.
To update the Address Book schema you need to
- Upgrade to Messaging Server JES3 Patch.
- Install and run the Directory Server Setup Perl script, see Upgrading Sun Java System Directory Server LDAP directory schema.
- Remove the JSP class cache maintained in the web container for this application.
For example in a default install of web server on a Solaris system this would reside in:
/opt/SUNWwbsvr/<virtual-instance>/ClassCache/<virtual-instance>/uwc
- Restart the Web Container Instance on which the Communications Express application is deployed for the changes to take effect.
Backing out the Communications Express 6 2005Q1 configuration
To back out Sun Java System Communications Express 6 2005Q1
- Run <uwc-basedir>/SUNWuwc/sbin/backout-newconfig
Where, <uwc-basedir> represents the package base directory of Communication Express. For example, to backout the patch 118540-xx configuration from Communications Express deployment,
- On Solaris
Run opt/SUNWuwc/sbin/backout-newconfig /opt/SUNWuwc/install /patch/118540-xx
- On Linux
/opt/sun/uwc/sbin/backout-newconfig /opt/sun/uwc/install/patch /118540-xx
The backout-newconfig script reverts the Communications Express deployment to the state it was before the last patch configuration was applied.
The script maintains backup of any customization and modifications performed after the last patch configuration in the directory <uwc-basedir>/install/patch/118540-xx/save with an extension .backup.
- Run the following command to backout the patch installation.
patchrm <patch ID>
For example, patchrm 118540-xx
- Remove the JSP class cache maintained in the web container for this application.
- Restart the web container instance on which the Communications Express application is deployed for the changes to take effect.
Installing Shared Components to Support S/MIME
In the Communications Services 6 2005Q1 release, certain shared components must be installed to support S/MIME for Communications Express Mail.
Before you configure S/MIME for Communications Express Mail, follow the steps described in this section.
- Upgrade Messaging Server (see Upgrading Messaging Server).
- Install these packages by using the pkgadd command. For example:
pkgadd -d /working_directory SUNWjaf
pkgadd -d /working_directory SUNWjmail
When you run the pkgadd command, the following files are copied to the /usr/share/lib directory:
- Before you apply the core software patch to upgrade Messaging Server, verify that the activation.jar and mail.jar files were copied to the /usr/share/lib directory.
- Configure S/MIME for Communications Express Mail
For information about configuring S/MIME for Communications Express Mail, see the Messaging Server 6 2005Q1 Administration Guide (http://docs.sun.com/doc/817-0105).
Upgrading Directory ServerAdministration Server, Directory Server, and Directory Proxy Server belong to a group of products that share the same Administration Server. You must patch these products at the same time.
For information about how to upgrade and backout Directory Server, see Upgrading Administration Server, Directory Server, and Directory Proxy Server.
Upgrading Directory Proxy ServerAdministration Server, Directory Server, and Directory Proxy Server belong to a group of products that share the same Administration Server. You must patch these products at the same time.
For information about how to upgrade and backout Directory Proxy Server, see Upgrading Administration Server, Directory Server, and Directory Proxy Server.
Upgrading Instant MessagingYou can install this release of Java Enterprise System directly on top of your existing installation. However, you should make a backup of your current installation before you proceed.
You can upgrade Java Enterprise System from a previous version of the software as described in Table 3-9.
In order to upgrade from a previous release of Instant Messaging not listed in Table 3-9, you need to first upgrade to one of the supported releases.
You will need to:
The upgrade utility uses your existing configuration details. However, if you want to change the configuration from your previous installation, you can run the configure utility after you have finished upgrading. See the Sun Java System Instant Messaging Administration Guide for instructions.
To Upgrade Instant Messaging From a Previous Release
- Back up the database and any existing resource and configuration files you have customized. This includes files in the DB, installation, and resource directories. The installation directory also contains the configuration files. Default locations for these directories are as follows:
Solaris
DB directory: /var/opt/SUNWiim/default/db
Installation directory: /opt/SUNWiim
Resource directory: /opt/SUNWiim/html
Linux
DB directory: /var/opt/sun/im/db
Installation directory: /opt/sun/im
Resource directory: /opt/sun/im/html
- Check to see if the system already has the Sun Java System Instant Messaging and Presence APIs package (SUNWiimdv) or RPM (sun-im-dev) installed. For Solaris this is done as follows:
# pkginfo SUNWiimdv
You will get the following message if the package is not installed:
ERROR: information for "SUNWiimdv" was not found
If SUNWiimdv is installed, remove it. For Solaris this is done as follows:
# pkgrm SUNWiimdv
Once the package/RPM is removed, install the newer version from the shared components area of the CD, for example on Solaris:
# cd /cdrom/cdrom0/Solaris_<arch>/Product/shared_components/Packages
# pkgadd -d . SUNWiimdvOr on Linux:
rpm -e sun-im-dev
rpm -i /mnt/cdrom/Linux_x86/Product/shared_components/Packages/sun-im-dev*rpm- Run the upgrade utility.
Solaris:
# cd /cdrom/cdrom0/Solaris_arch/Product/instant_messaging/Tools
# ./upgradeThe above example finds the command on the product CD. to execute the command from your download location:
# cd /unzipped location/Solaris_arch/Product/instant_messaging/Tools
# ./upgradeLinux:
# cd /dev/cdrom/Linux_x86/Product/instant_messaging/Tools/
# ./upgrade
During upgrade, the utility:
- Creates a temporary directory where it stores working files. This directory is deleted upon successful upgrade of Instant Messaging.
- Creates an administrative file based on the existing Instant Messaging configuration that the utility uses to configure the upgraded installation.
- Merges parameter values if a conflict arises between the old configuration and the new defaults. The utility uses merge files which it stores in the temporary directory for the duration of the upgrade to resolve conflicts.
- Shuts down the previous version of the Instant Messaging server.
- Installs new packages and patches existing packages.
- Installs any shared component packages used by Instant Messaging and other Java Enterprise System servers if they are not already present.
- If the previous IIM_DOCROOT parameter was set to something other than the default, links from the new resource files location to the old location to preserve the same availability.
- Restarts all services.
- Deletes the temporary directory and its contents.
- (Optional) Change configuration as necessary. See Sun Java System Instant Messaging Administration Guide for more information.
The upgrade utility creates a log file that shows the progression of the upgrade process in the following location:
/var/sadm/install/logs/Instant_Messaging_Upgrade.<timestamp>
Where <timestamp> is in the format yyyymmddhhss.
Upgrading Message QueueUse the following instructions to upgrade and (if necessary) migrate Message Queue from earlier versions.
For the purposes of this section, upgrade means installing the Message Queue 3 2005Q1 (3.6) product; migrate means moving existing data from a Message Queue installation to a Message Queue 3 2005Q1 installation.
These instructions contain the following sections:
Upgrade and Migration Overview
Sun Java Enterprise System 2005Q1 contains scripts that allow you to upgrade and migrate your previous versions of Message Queue shipped with Java Enterprise System. These scripts can also upgrade and migrate versions of Message Queue that were installed as a standalone product.
Table 3-10 shows the Message Queue product versions that support upgrade and migration with Java Enterprise System. You can upgrade some of these versions using the Java Enterprise System installer. Other versions require you to use the scripts provided with Java Enterprise System to manually migrate and upgrade your version of Message Queue.
It is possible that your version of Message Queue was installed as a standalone version, or included with a Solaris operating system bundle. The supported versions of Message Queue standalone and those bundled with Solaris are also listed in Table 3-10.
The process of migration and upgrade of Message Queue may include one or more of the following steps.
- Verify Message Queue version and edition information
It may be necessary to verify version and edition information before you upgrade. You may also want to verify the existence of Message Queue 3 2005Q1 (3.6), Enterprise Edition after the upgrade process.- Migrate existing Message Queue data
Depending on your platform, you may have to run a script to migrate existing broker instance data.- Upgrade to Message Queue 3 2005Q1 (3.6), Enterprise Edition
Depending on your platform, You may need to run a script to upgrade Message Queue on both Solaris and Linux platforms.- Uninstall Message Queue
If you want to uninstall Message Queue after an upgrade, you must manually uninstall program files.Choosing Your Upgrade Path
Your upgrade and migration path depends upon your operating system.
Table 3-11 shows the upgrade and migration path you should follow based on your operating system and currently installed Message Queue software edition.
Table 3-11 Upgrade and Migration path for Message Queue 3 2005Q1 (3.6)
Operating System
Installed Message Queue Edition
Upgrade and Migration Path
Solaris SPARC
Solaris x86Bundled Message Queue,
Platform EditionThe Java Enterprise System installer allows an automatic upgrade of all versions of Message Queue, Platform Edition installed bundled with Solaris.
Use the Java Enterprise System installer and follow the instructions in the Java Enterprise System Installation Guide to upgrade to Message Queue 3 2005Q1 (3.6), Enterprise Edition.
There are no migration issues involved. All broker instance data will be preserved.
Solaris SPARC Solaris x86
Unbundled Message Queue, Platform Edition
For Message Queue, Platform Edition versions installed independently from Solaris the Java Enterprise System installer may produce error messages. In this case, follow the procedures in Upgrading Message Queue on Solaris. There you use the mqupgrade script in the following locations where you unzipped the Java Enterprise System distribution.
On Solaris SPARC:
Solaris_sparc/Product/message_queue/ToolsOn Solaris x86:
Solaris_x86/Product/message_queue/ToolsThere are no migration issues involved. All broker instance data will be preserved.
Solaris SPARC
Solaris x86Message Queue, Enterprise Edition
The Java Enterprise System installer does not allow an upgrade of any version of Message Queue, Enterprise Edition installed on Solaris.
To upgrade to Message Queue 3 2005Q1 (3.6), Enterprise Edition, follow the procedures in Upgrading Message Queue on Solaris.
Linux (RPM - Based)
Message Queue, Platform Edition
Message Queue, Enterprise Edition
If you are upgrading from Message Queue 3 2005Q1 (3.6), Platform Edition to 3 2005Q1 (3.6), Enterprise Edition and you want to migrate your data, there are no migration issues and you should not run the mqmigrate script.
On Linux, Message Queue 3 2005Q1 (3.6) installs in locations different from previous Message Queue versions. If you want to migrate existing broker instance data, you must run an mqmigrate script that copies this data to the new install locations prior to upgrading Message Queue.
To migrate and upgrade to Message Queue 3 2005Q1 (3.6), Enterprise Edition follow the procedures in Upgrading and Migrating on Linux. There you will:
The mqmigrate and mqupgrade scripts are in the following location where you unzipped the Java Enterprise System distribution: Linux_x86/Product/message_queue/Tools
Note: If you do not want to preserve existing broker information, use only the mqupgrade script.
Linux (tar Based)
Message Queue, Platform Edition
Message Queue, Enterprise Edition
You should search for the RPM-based installation of a previous version of Message Queue, see Verifying RPM-Installed Versions of Message Queue.
If no RPM-based installation is found, search for the tar-based installation of a previous version of Message Queue.
Run the mqmigrate script (if desired), to migrate the data to the new location.
Do not use mqupgrade.
Instead, uninstall the tar-based installation of Message Queue, see Finding and Removing a Message Queue Tar-Based Installation.
Install Message Queue 3 2005Q1 (3.6) Enterprise Edition using the Java Enterprise System Installer.
Upgrading Message Queue on Solaris
This section contains procedures for upgrading Message Queue to the Java Enterprise System 2005Q1 version on Solaris. It contains the following sections:
Verifying Version Information
You may want to determine the edition and version information of Message Queue installed on your system before and after upgrade.
To Verify the Product Edition of Message Queue Installed on Your System
- Enter the following command:
pkginfo | grep SUNWiq
If a list of package files containing SUNWiq appear, you have Message Queue installed on your system.
Additionally, if the package file SUNWiqlen is listed, Enterprise Edition is installed on your system.
If Message Queue packages are installed on your system, you can also verify the product version of Message Queue.
To Verify the Product Version of Message Queue Installed on Your System
- Enter the following command:
pkgparam -v SUNWiqr SUNW_PRODVERS
The product version is the value of SUNW_PRODVERS. Table 3-12 shows the SUNW_PRODVERS value returned for each release.
Upgrading Message Queue
To Upgrade to Message Queue 3 2005Q1 (3.6), Enterprise Edition
- Stop any running Message Queue client applications.
- Stop any running brokers. You will be prompted for the admin user name and password.
imqcmd shutdown bkr [-b hostName:port]
- If you want to delete dynamic data, the Message Queue flat-file user repository, and the Message Queue access control file associated with each broker instance, remove this data using the following command.
imqbrokerd -name instanceName -remove instance
Note
Before upgrading from Message Queue 3.0.1 back up the accesscontrol.properties and passwd files. After running the mqupgrade script restore these files to preserve user account data. For the location of these files, refer to Table 5-4.
- Login as Root.
su root
- From the location where you unzipped the Java Enterprise System distribution, change directories to the Tools directory.
- Run the mqupgrade script.
./mqupgrade
The mqupgrade script lists installed shared component files.
- If you want to update shared components, enter y (yes).
If you do not want to update shared components, enter n (no).
Note
If you have already updated shared components using the Sun Java Enterprise System installer, you should enter n (no) and proceed to Message Queue component installation.
The mqupgrade script lists installed Message Queue components.
- If you want to update Message Queue packages, enter y (yes).
If you do not want to update Message Queue components, enter n (no). The mqupgrade script will exit without installing Message Queue components.
The mqupgrade script detects and lists installed locale files.
- If you want to update locale files, enter y (yes). If you do not want to update locale files, enter n (no).
The mqupgrade script sends output to a log file in the following location:
/var/sadm/install/logs/Message_Queue_upgrade_'date'.log
Uninstalling Message Queue
If you have upgraded Message Queue using the mqupgrade script, you cannot use the Java Enterprise System uninstall program to uninstall Message Queue. Instead, you must manually uninstall Message Queue components using the following procedure.
To Uninstall Message Queue on Solaris
- Stop any running Message Queue client applications.
- Stop any running brokers. You will be prompted for the admin user name and password.
imqcmd shutdown bkr [-b hostName:port]
- If you want to delete dynamic data, the Message Queue flat-file user repository, and the Message Queue access control file associated with each broker instance, remove this data using the following command.
imqbrokerd -name instanceName -remove instance
- Become Root
su root
- Retrieve the list of installed Message Queue packages with the following command:
pkginfo | grep -i "message queue"
- Remove the Message Queue packages, using the following command:
pkgrm packageName
where packageName is any of the Message Queue packages. To remove multiple packages, separate the package names by a space.
Because other products might be using Message Queue packages, be careful about removing them. The pkgrm command will warn you of any dependencies on a package before removing it.
When prompted, confirm your removal request by typing y (yes).
- Type “q” to quit.
- Exit the root shell.
Upgrading and Migrating on Linux
This section contains procedures for upgrading any earlier version of Message Queue to the Java Enterprise System 2005Q1 version on Linux. It contains the following sections:
Depending on the version, Message Queue might have been installed using tar files or the Red Hat Package Manager (RPM). To check for installed versions, therefore, you need to check for both. It is recommended that you check first for RPM installations and then for tar file installations.
You may want to determine the edition and version information of Message Queue installed on your system before and after upgrade.
Verifying RPM-Installed Versions of Message Queue
To Verify the Version and Edition of Message Queue Installed on Your System
If found, the version numbers of any RPM’s are imbedded in the RPM name. If none are found, proceed to Finding and Removing a Message Queue Tar-Based Installation.
Table 3-13 shows the version number that corresponds with RPM names for each Message Queue release.
For older versions of Message Queue, if the imq-ent package license file is listed, you have Enterprise Edition installed on your system.
For Message Queue 3 2005Q1 (3.6), if the sun-mq-ent package license file is listed, you have Enterprise Edition installed on your system.
Finding and Removing a Message Queue Tar-Based Installation
If you have a tar-based Message Queue installation, your upgrade procedure is a bit different from an RPM-based installation. Message Queue releases 3.0.1 and 3.0.1 SP1 were released as both tar-based and RPM-based distributions.
To Find and Remove Earlier Tar-Based Installed Message Queue
- See if the default Message Queue installation directory (/opt/imq/bin) exists on your system.
If found, proceed to Step 2.
If not found, Message Queue might have been installed in a non-default location. If you cannot remember the installation directory, search for the Message Queue imqbrokerd executable and note its root install directory. Proceed to Step 2.
- If you find an earlier Message Queue installation in the default location (/opt/imq/bin), remove it as follows:
- If you wish to preserve existing broker instance data, run the mqmigrate utility, as described in Migrating Message Queue Data.
The mqmigrate utility moves existing broker instance data (broker configuration files and persistent data) and security-related files, to new Message Queue 3 2005Q1 (3.6) locations.
- Remove the /opt/imq/ directory and all its contents.
rm -rf /opt/imq
- Install Message Queue 3 2005Q1 (3.6) for Linux using the Java Enterprise System installer.
Migrating Message Queue Data
On Linux, Message Queue installs in locations different from previous Message Queue versions. If you want to migrate existing broker instance data, you must run an mqmigrate script that copies this data to the new install locations prior to upgrading Message Queue.
The mqmigrate script is in the following location:
baseJESdistDir/Linux_x86/Product/message_queue/Tools
where baseJESdistDir is the location where you unzipped the Java Enterprise System distribution files.
The mqmigrate script includes a -basedir option that allows you to migrate data that has been installed in a non-default location. This option only applies to users who have installed Message Queue 3.0.x data in a non-default location. Message Queue 3.5 did not allow you to install Message Queue in a non-default location.
The mqmigrate script, which must be run as root, uses the following syntax:
mqmigrate [-basedir baseDir]
Table 3-14 shows default data locations for Message Queue installations. The mqmigrate script assumes these locations. Message Queue 3.0.x allowed you to install in a non-default location (noted in brackets). If Message Queue is installed in a non-default location, you must use the -basedir option described in Table 3-15 to point the utility to that location.
Table 3-15 describes the mqmigrate script -basedir option. This option is only required when migrating Message Queue 3.0.x data that has been installed in a non-default directory.
To Migrate Broker Instance Data from Message Queue Installed in a Default Location to New var and opt Directories
To Migrate Broker Instance Data from Message Queue 3.0.1 Installed in the Non-Default Directory /my_mq, to New var and opt Directories
Upgrading Message Queue
After migrating broker instance data, you can use the mqupgrade script to upgrade to Message Queue 3 2005Q1 (3.6), Enterprise Edition.
To Upgrade to Message Queue 3 2005Q1 (3.6), Enterprise Edition
- Stop any running Message Queue client applications.
- Stop any running brokers. You will be prompted for the admin user name and password.
imqcmd shutdown bkr [-b hostName:port]
- Login as Root.
su root
- From the location where you unzipped the Java Enterprise System distribution, change directories to the directory that contains the mqupgrade script.
cd Linux_x86/Product/message_queue/Tools
- Run the mqupgrade script.
./mqupgrade
The mqupgrade script lists shared components.
- If you want to upgrade shared components, enter y (yes).
If you do not want to upgrade shared components, enter n (no).
Note
If you have already updated shared components using the Sun Java Enterprise System installer, you should enter n (no) and proceed to Message Queue component installation.
The mqupgrade script lists installed Message Queue components.
- If you want to upgrade Message Queue components, enter y (yes).
If you do not want to upgrade Message Queue components, enter n (no) The mqupgrade script will exit without installing Message Queue components.
The mqupgrade script sends output to a log file in the following location:
/var/sadm/install/logs/Message_Queue_upgrade_'date'.log
Installing the sun-mq-compat Package
If your client applications contain scripts that depend on the location of Message Queue 3.5 installed files, you will need to install the sun-mq-compat package, which contains symlinks from Message Queue 3.5 file locations to Message Queue 3 2005Q1 (3.6) file locations
The sun-mq-compat package is in the following location where you unzipped the Java Enterprise System distribution.
Linux_x86/Product/message_queue/Packages
To Install the sun-mq-compat Package
Uninstalling Message Queue
If you have upgraded Message Queue using the mqupgrade script, you cannot use the Java Enterprise System uninstall program to uninstall Message Queue. Instead, you must manually uninstall Message Queue components using the following procedure.
To Uninstall Message Queue on Linux
- Stop any running Message Queue client applications.
- Stop any running brokers. You will be prompted for the admin user name and password.
imqcmd shutdown bkr [-b hostName:port]
- Unless you want to retain dynamic data, the Message Queue flat file user repository, and the Message Queue access control file associated with each broker instance, remove this data using the following command.
imqbrokerd -name instanceName -remove instance
- Become Root
su root
- Retrieve the list of installed Message Queue packages with the following command:
rpm -qa | grep sun-mq
- Remove the Message Queue packages, using the following command:
rpm -e --nodeps RPMName
where RPMName is any of the Message Queue packages. To remove multiple packages, separate the package names by a space.
Upgrading Messaging ServerThis section contains procedures for upgrading to Messaging Server 6 2005Q1 from previous Java Enterprise System versions. It contains the following topics:
Upgrading Non-Cluster Deployments
Use the upgrade procedures relevant to your situation:
- Upgrading from Messaging Server 6 2003Q4 (see Upgrading from Messaging Server 6 2003Q4).
- Upgrading from Messaging Server 6 2004Q2 (see Upgrading from Messaging Server 6 2004Q2).
- Upgrading from Pre Java Enterprise System Messaging Server versions (see Messaging Server Migration Information).
Upgrading from Messaging Server 6 2003Q4
To upgrade from Messaging Server 6 2003Q4 to the latest release you must first upgrade to Messaging Server 6 2004Q2.
Note
You must upgrade all component products located on the same system to the 2004Q2 level at the same time.
For more details refer to Chapter 8 of the Sun Java Enterprise System 2004Q2 Installation Guide (http://docs.sun.com/doc/817-5760).
- Check the /etc/hosts file entry
Ensure that you have the following entry in /etc/hosts file on your Solaris system:
<ip-of system> <FQHN> <hostname>
For Example, 129.158.230.64 example.com example
- Install or Upgrade to Messaging Server 6 2004Q2 (6.1)
Before you can upgrade to Messaging Server 6 2005Q1 (6.2), you must have installed Messaging Server 6 2004Q2 (6.1).
- If you already have installed Messaging Server 6 2004Q2 (version 6.1), you can proceed to Upgrading from Messaging Server 6 2004Q2.
(If you are installing Delegated Administrator, be sure you have installed the components listed in Requirements for Delegated Administrator, below.)
- If you are installing Messaging Server for the first time, you can use the Java Enterprise Installer to perform the installation.
For instructions on installing Messaging Server 6 2004Q2 (6.1), see the Sun Java Enterprise System 2004Q2 Installation Guide (http://docs.sun.com/doc/817-5760).
Note
You do not have to configure Messaging Server at this step. You will configure Messaging Server in Configuring Messaging Server 6 2005Q1.
Requirements for Delegated Administrator
If you intend to install Delegated Administrator, you must use the Java Enterprise System 2004Q2 Installer to install the following components:
The commadmin utility is installed as a component of Access Manager.
Note
In the Communications Services 6 2005Q1 release, the User Management Utility (commadmin) has been renamed. It is now the Delegated Administrator Utility.
For installation instructions, see the Sun Java Enterprise System 2004Q2 Installation Guide
(http://docs.sun.com/doc/817-5760).To use Delegated Administrator, your LDAP Directory must be Schema 2.
- Proceed to Upgrading from Messaging Server 6 2004Q2.
Upgrading from Messaging Server 6 2004Q2
This section contains procedures for upgrading to Messaging Server 6 2005Q1 from Messaging Server 6 2004Q2 (6.1).
- Upgrade the required shared components.
Before you upgrade the Messaging Server core software to the 6 2005Q1, you must obtain upgrade patches for the shared components shown in Table 3-16. See Upgrading Shared Components.
The above patches are for Solaris systems. For Linux RPM equivalents see Applying Linux Shared Component RPMs.
- Apply the Messaging Server Upgrade Patch
Before you apply the Messaging Server core patch, you must install the ICU patch (114677), the LDAP-C-SDK (116837) and NSPR/NSS/JSS patch (117724).
To upgrade to the Messaging Server 6 2005Q1 release, apply the appropriate software patch shown in Table 3-17.
To apply the Messaging Server core patch, follow these steps:
- Log in as or become superuser (root).
- Read the README file, which contains instructions and last-minute information about the patch.
- Apply the appropriate Messaging Server patch for your platform using the patchadd command.
After applying the patch, you may need to upgrade your configuration files. You can continue to run Messaging Server with the old configuration files until you are ready to install the new configuration files. For details, see Configuring Messaging Server 6 2005Q1.
To apply the Directory Server Setup Perl script (comm_dssetup.pl) patches, follow the steps shown below. You must perform this step on the machine where the Directory Server is installed:
- cd to your working directory.
- Install the Directory Server Setup Perl script patches, 118242 and 118245, by using the patchadd command. You must install both patches.
- Install and run the Directory Server Setup Perl script, see Upgrading Sun Java System Directory Server LDAP directory schema.
Configuring Messaging Server 6 2005Q1
There are two ways to configure Messaging Server 6 2005Q1. Choose the method that fits your situation:
- If you installed Messaging Server 6 2004Q2 (6.1) for the first time in Upgrading from Messaging Server 6 2003Q4—-if you have not yet configured Messaging Server—you can run the standard Messaging Server configuration program (configure).
For instructions, see “Chapter 1: Post-install Tasks and Layout,” in the Sun Java System Messaging Server 6 2004Q2 Administration Guide (http://docs.sun.com/doc/817-6266).
- If you already installed and configured Messaging Server 6 2004Q2 (6.1) before you began this upgrade procedure, you can patch your configuration for Messaging Server 6 2005Q1 by running the patch-config and install-newconfig scripts. For more information, see the Special Installation Instructions section in the README file of patch 118207, 118208, or 118209, depending on your platform.
Apply changes to the Directory Server using ldif files. The ldif files are located under <msg_svr_base>/lib/patch. See the comments in the ldif files for instructions. Note that there is no utility to help backout the changes made.
Upgrading Cluster Deployments
If you have two or more instances of Messaging Server in a clustered environment, use a rolling upgrade strategy, one server at a time, to keep most of the cluster available. First you upgrade one Messaging Server on one machine. The Messaging Server upgrade includes upgrading the mboxlist database to a higher version (for that Messaging Server on that machine).
To install in cluster environments:
- Install Messaging Server 6 2005Q1 on the standby node.
- Configure it to use the configuration data of primary node.
- Failover to the standby node.
- Remove the primary node from the cluster.
- Upgrade the primary node using patchadd (see Upgrading Non-Cluster Deployments.)
- Put the primary node back into the cluster.
- Failover the configuration and data from the standby node back to the primary node.
- Run patch-config to generate new candidate upgraded configuration files.
- Examine the new candidate upgraded configuration files manually.
- Schedule downtime for the primary node configuration and data.
During downtime:
- Stop the services for the primary node.
- Install the new confide files, e.g. you can use the install-unconfined command.
- Run the commands.
msg_svr_base/sbin/imsimta chbuild
msg_svr_base/sbin/imsimta clbuild -image_file=IMTA_COMMAND_DATA IMTA_BIN:pmdf.cld
msg_svr_base/sbin/imsimta cnbuild
- Restart the services.
Removing Messaging Server Patches
- Stop the Messaging Server with the stop-msg command.
- Disable the watcher daemon by running the configutil command, as follows:
configutil -o local.watcher.enable -v no
- Remove the message store database environment files by using the stored -r command.
If this command fails to remove the files, use the stored -R command. This action forces the removal of the files.
- Enable the watcher daemon as follows:
configutil -o local.watcher.enable -v yes
- Remove the log files under the mboxlist directory. For example:
rm -f /var/opt/SUNWmsgsr/store/mboxlist/log.*
- Remove the Messaging Server 6 2004Q2 patches by running the patchrm patch id command.
- Manually restore the backed-up configuration files as required. Pre-upgrade configuration files are stored under:
msg_svr_base/install/patch/patchnumber/save
patchnumber is the Messaging Server core patch.
- Run the imsimta cnbuild command, as follows:
msg_svr_base/sbin/imsimta cnbuild
- Start Messaging Server with the start-msg command, as follows:
msg_svr_base/sbin/start-msg
Upgrading to Delegated AdministratorThe Communications Services 6 2005Q1 Delegated Administrator is a tool for provisioning Messaging Server and Calendar Server users, groups, domains, and resources in an LDAP Schema 2 directory. Delegated Administrator consists of a console and a utility (commadmin). In Java Enterprise System 2004Q2, the Delegated Administrator utility was called User Management Utility.
This section describes how to upgrade from earlier versions of Delegated Administrator. Note that previous versions consisted only of the utility. The upgrade process described here upgrades the Delegated Administrator utility and installs the Delegated Administrator console.
Installing Delegated Administrator
The procedure to install Delegated Administrator 2005Q1 is as follows.
- Configure Messaging Server for Delegated Administrator, see Upgrading Sun Java System Directory Server LDAP directory schema.
- Using the patchadd(1M) command, install the latest patch for the Delegated Administrator utility (which is installed in the Access Manager machine by default.) This patch, shown in Table 3-18, is available on SunSolve.
- Run the configuration program for Delegated Administrator. (Among other configuration tasks, the program configures Delegated Administrator to work with your Web container.)
For further information, see the Chapter 3 Configuring Delegated Administrator Sun Java System Communications Services 6 2005Q1 Delegated Administration Guide. http://docs.sun.com/doc/819-0114
Upgrading Mobile AccessThis section contains procedures for upgrading from Mobile Access 6.2 or Sun Java System Portal Server Mobile Access 6 2004Q2 to the Sun Java System Portal Server Mobile Access 6 2005Q1. It contains the following topics:
Upgrading from 2003Q4 to 2005Q1
Mobile Access 6.2 shipped as a point product was intended to augment Java Enterprise System 2003Q4 installations of Identity Server and Portal Server. Mobile Access functionality is now a standard feature of Java Enterprise System 2004Q2 and 2005Q2. Mobile enablement of Identity Server and Portal Server is now standard.
If you are upgrading from Mobile Access 6.2 you must first upgrade to Sun Java System Portal Server Mobile Access 6 2004Q2 following the instructions found in Chapter 8 of the Java Enterprise System 2004Q2 Installation Guide. http://docs.sun.com/app/docs/doc/817-5760;
You are now ready to proceed to Upgrading from 2004Q2 to 2005Q1.
Upgrading from 2004Q2 to 2005Q1
Sun Java System Portal Server Mobile Access is upgraded with Portal Server. Follow the procedures in Upgrading Portal Server. Mobile access specific patches are listed in Table 3-19.
The above patches are intended for a Solaris SPARC and Solaris x86 systems. Table 3-20 list the Access Manager Linux upgrade RPMS.
.
Upgrading Portal ServerThis section contains procedures for upgrading from Sun ONE Portal Server 6.2 or Sun Java System Portal Server 6 2004Q2 to Sun Java System Portal Server 6 2005Q1. It contains the following topics:
Note
If you are upgrading from Sun ONE Portal Server 6.2 you must first upgrade to Portal Server 6 2004Q2 following the instructions found in Chapter 8 of the Java Enterprise System 2004Q2 Installation Guide. http://docs.sun.com/app/docs/doc/817-5760
Accessing Patches and RPMs
Upgrading Portal Server on Solaris is done using patches. Download the patches listed in Table 3-21 from SunSolve (patch revision should be the same as listed in the table or newer).
Upgrading Portal Server on Linux is done using RPMs. Access the patch listed in Table 3-22 from SunSolve and the RPMs from the product distribution CD.
Backing up Web Container Customized Files
Before you upgrade, back up any web container customized files related to Portal Server 6.2, including:
- Customized console JSP pages
- Customized authentication JSP pages
- JAR files for customized modules
- Customized sample Portal Server desktop
Caution
If you have made extensive customizations to Portal Server 6.2 files, you should contact Sun technical support or professional services for assistance.
It is recommend that you make a list of your customizations so you can redo them after you upgrade and then verify that they work correctly. The following directories should be backed up:
Upgrading the Sun Web Container Software
The Java Enterprise System 2005Q1 release requires that the Identity Server instance be run on Sun’s Web Server or Application Server (such as Web Server 6.1 SP2 or Application Server 7.0 Update 3) on the same system. If you are using an older version, you must upgrade the web container software before you can upgrade to Java Enterprise System 2005Q1 release.
For information about upgrading Sun’s Web Server or Application Server software, refer to the respective web container documentation:
- For Web Server 6.1 SP2 see:
http://docs.sun.com/coll/S1_websvr61_en
- For Application Server 7.0 Update 3, see:
Also, if you saved any customization files under Backing Up Any Web Container Customized Files, you will need to redo the customizations after you upgrade the web container.
Upgrading Access Manager
Portal Server upgrade has a dependency on Access Manager. Prior to upgrading Portal Server, upgrade all systems running Access Manager to the Java Enterprise System 2005Q1 version.
Refer to theUpgrading Access Manager for more a more detailed description of the Access Manager upgrade.
Using Web Server 6 2004Q2 as a Web Container
If you are using Sun Java System Web Server as a web container, you must run the install the Identity Server administration console patch.
- Install Access Manager 2005Q1.
Refer to theUpgrading Access Manager for more a more detailed description of the Access Manager upgrade.
- If necessary, run the following command to install the Access Manager administration console patch:
> patchadd 117769-01
Backing up the Administration Console Help Files
The Portal Server help files that are used with the Access Manager administration console must be backed up before the Identity Server 6.1 software is upgraded and restored after the Access Manager 2005Q1 software is installed.
- Copy the contents of the online help directory to a temporary directory, such as:
cp -r /installation-directory/SUNWam/public_html/online_help/docs_en_US/ps /tmp
- Run the Access Manager pre-upgrade script.
Refer to theUpgrading Access Manager for more a more detailed description of the Access Manager upgrade.
- Install Access Manager 2005Q1.
Refer to theUpgrading Access Manager for more a more detailed description of the Access Manager upgrade.
- Copy the contents of the temporary directory to the online help directory, such as:
cp -r /tmp/ps /installation-directory/SUNWam/public_html/online_help/docs_en_US/ps
Enabling Client Detection
In order to enable client detection, change the Access Manager Client Detection global attributes as follows:
- Access the Access Manager 2005Q1 console using the following URL:
http://host-name.domain-name:port/amconsole
where host-name.domain-name:port is the fully qualified host name and port of the web container you are using.
- When the Access Manager login page appears, log in as amadmin.
- On the console, click the Service Configuration tab.
The console displays the Service Configuration options in the navigation frame.
- In the navigation frame under Service Configuration, click Client Detection.
- For Client Detection, set the following items in the data frame:
- Click Save.
Verifying the Upgrade
If you customized your Identity Server 6.1 installation, you must manually redo the customizations in your new Access Manager 2005Q1 installation.
Here are several ways to verify that the upgrade was successful:
- Access the Access Manager 2005Q1 console using the following URL:
http://host-name.domain-name:port/amconsole
where host-name.domain-name:port is the fully qualified host name and port of the web container you are using.
When the Access Manager login page appears, log in as amadmin. Click the “Service Configuration” tab. If the new Access Manager 2005Q1 services such as “Discovery Service” and “Liberty and Personal Profile Service” are available, the upgrade of Access Manager on the specific web container should be successful.
- Review the status of the upgrade by checking the following log files in the /var/sadm/install/logs directory:
Upgrading Portal Server
These procedures upgrade Sun Java System Portal Server 6 2004Q2 to Sun Java System Portal Server 6 2005Q1. If you are upgrading from Sun ONE Portal Server 6.2 you must first upgrade to Portal Server 6 2004Q2 following the instructions found in Chapter 8 of the Java Enterprise System 2004Q2 Installation Guide. http://docs.sun.com/app/docs/doc/817-5760
- Log in as root.
- Download Portal Server patches described in Table 3-21 from the SunSolve site.
- Ensure that the J2EE web container is up and running.
- Ensure that the Directory Server is up and running.
- Ensure that the Access Manager used by Portal Server is upgraded to Java Enterprise System 2005Q1. If Access Manager is installed remotely, also ensure that Access Manager SDK is upgraded to Java Enterprise System 2005Q1 on all Portal Server nodes.
- Ensure that the JWSDP shared components JAXP, JAX-RPC, JAXR, SAAJ, JAXB are updated on both Portal Server and Gateway nodes. (SeeUpgrading Shared Components.)
- Ensure that the JSS, NSS, and NSPR shared components are updated on both Portal Server and Gateway nodes. (SeeUpgrading Shared Components.)
- To upgrade on Solaris perform the following:
- On nodes where Portal Server or Gateway is installed, run the following commands to install the patches:
> patchadd 118195-07
> patchadd 118128-13
> patchadd 118219-12
> patchadd 118950-01- On nodes where Access Manager is installed, run the following commands to install the patches:
> patchadd 118217-11
> patchadd 118218-11The above patches are intended for a Solaris SPARC system (refer to Table 3-21 for patch information for a Solaris x86 system).
- To upgrade on Linux perform the following:
- Use “rpm -Fvh” command (option -F to update existing rpm, -vh for verbose mode) to other rpms that are listed in Table 3-22. For example:
# cd <rpm location>
# rpm -Fvh sun-identity-mobileaccess-6.2-25.i386.rpm"Refer to Table 3-22 for the RPM listing.
- Unzip the 118020 patch file.
- Read the README file.
- Run the upgradeportalrpms script, that is found in the unzipped directory, which adds the RPMs.
- Unzip the 119515 patch file and follow the instructions in its README file to install the patch.
- Unzip the 119516 patch file and follow the instructions in its README file to install the patch.
- Unzip the 118952 patch file and follow the instructions in its README file to install the patch.
- Run the following commands to upgrade the Portal Server (with /opt/SUNWps as the default installation directory):
> cd /opt/SUNWps/lib
> ./upgradePS04Q205Q1
> ./upgradeSRA-04Q4-05Q1The upgradeSRA script is needed if Secure Remote Access is installed. These scripts will prompt you for passwords.
Caution
Once the upgradePS or upgradeSRA scripts are run, any Portal Server patches that were applied cannot be backed out.
- Redeploy Portal Server:
> cd /opt/SUNWps/bin
> ./deploy redeploy- Restart the web container.
- Logon to AMCONSOLE as user amadmin to configure Proxylet and Netlet services.
- Remove Proxylet and Netlet services.
Under the Identity Management tab, select the Services option. This lists all the registered services on the left panel. From SRA Configuration, select the Proxylet and Netlet check boxes. Scroll to the top on the left panel and click the Remove button. This will remove the Proxylet and Netlet service from the ORG level.
To Verify this step manually, you may check your LDAP directory (under your organization) to make sure that the services (srapProxylet, srapNetlet) are really removed.
- Add the services again.
Under Identity Management tab, select the Services option. Click the Add button under Services. This displays all the available services on the right panel. Choose proxylet and Netlet service check box and click OK. The newly added services will appear under SRA Configuration on your left panel.
- Click the newly added services and build the template file. Click the Save button.
Add /portal/netlet/jnlpclient.jar and /portal/netlet/netletjsse.jar to non-Authenticated list of URLs under the gateway service. *
- Click the Service Configuration tab.
- Click the Gateway link under SRA Configuration. This lists all the available gateway profiles.
- Choose the appropriate profile by clicking on the link.
- Click the Security tab.
- Add /portal/netlet/jnlpclient.jar in the edit field under Non-authenticated URLs and click the Add button.
- Add /portal/netlet/netletjsse.jar in the edit field under Non-authenticated URLs and click the Add button.
- Click the Save button at the bottom of the page.
- Restart your gateway server.
Upgrading Delegated Administrator
Calendar Server requires that you use the Delegated Administrator (formerly commadmin) to provision users, groups, domains, and resources.
If Delegated Administrator has not been installed or upgraded see Upgrading to Delegated Administrator.
Upgrading Sun ClusterThis section provides an upgrade overview of Sun Cluster 3.1 9/04 from the version that shipped with Java Enterprise System 2004Q2. This section contains:
Note
For complete upgrade instructions, see the Chapter 5 “Upgrading Sun Cluster Software,” of the Sun Cluster Software Installation Guide for Solaris OS at http://docs.sun.com/doc/817-6543.
To manually install Sun Web Console use the Sun Java Enterprise System 2005 Q1 2 of 2 CD-ROM instead of the Sun Cluster 3.1 9/04 CD-ROM.
To run the Sun Web Console setup command, change directory to /cdrom/cdrom0/Solaris_arch/Product/sunwebconsole/ where arch is sparc or x86, to get to the setup command.
Upgrade Requirements and Restrictions
Observe the following requirements and restrictions when you upgrade to Sun Cluster 3.1 9/04 software:
You must upgrade all software to a version that is supported by Sun Cluster 3.1 9/04 software. For example, if a data service is supported on Sun Cluster 3.0 software but is not supported on Sun Cluster 3.1 9/04 software, you must upgrade that data service to the version of that data service that is supported on Sun Cluster 3.1 9/04 software. If the related application of that data service is not supported on Sun Cluster 3.1 9/04 software, you must also upgrade that application to a supported release.
The scinstall upgrade utility only upgrades those data services that are provided with Sun Cluster 3.1 9/04 software. You must manually upgrade any custom or third-party data services.
Sun Cluster 3.1 9/04 software supports:
Sun Cluster 3.1 9/04 software does not support:
Upgrading Shared Components
You must upgrade the appropriate shared component packages that most Sun Cluster configurations will already have installed. Upgrade shared components on each node of the cluster in this order:
The detailed steps for each of these upgrades follow.
To Upgrade Shared Components For Apache Tomcat
- Determine whether Apache Tomcat package is installed.
# pkginfo SUNWtcatu
- If the Apache Tomcat package is installed on the node, determine whether the applicable required patch for the platform is also installed.
# showrev -p | grep SUNWtcatu
The required patch and its minimum level for each platform are as follows:
- If the SUNWtcatu package is installed but the required patch is not installed, remove the package.
# pkgrm SUNWtcatu
To Upgrade Shared Components For Explorer
To Upgrade Shared Components For JDMK
- Determine whether JDMK packages are already installed.
# pkginfo SUNWjdmk-runtime SUNWjdmk-runtime-jmx
application SUNWjdmk-runtime Java DMK 5.1 Runtime Library
application SUNWjdmk-runtime-jmx Java DMK 5.1 JMX libraries- If the JDMK packages already exist on the cluster node, remove them.
# pkgrm SUNWjdmk-runtime SUNWjdmk-runtime-jmx
- Insert the Sun Java System 1 of 2 CD-ROM.
- Change to the Solaris_arch/Product/shared_components/Packages/ directory, where arch is sparc or x86.
- Install the JDMK packages.
# pkgadd -d . SUNWjdmk*
To Upgrade Shared Components for Sun Java Web Console
To Upgrade Shared Components For Common Agent Container
Before starting the upgrade, upgrade the common agent container packages. You can perform this task while the cluster is still in production.
- Determine whether the common agent container packages are already installed.
# pkginfo SUNWcacao SUNWcacaocfg
application SUNWcacao Cacao Component
application SUNWcacaocfg Cacao configuration files- If the common agent container packages already exist, stop the security file agent for the common agent container on each cluster node.
# /opt/SUNWcacao/bin/cacaoadm stop
- Remove the existing common agent container packages from each cluster node.
# pkgrm SUNWcacao SUNWcacaocfg
- Insert the Sun Java System 1 of 2 CD-ROM.
- Change to the Solaris_arch/Product/shared_components/Packages/ directory, where arch is sparc or x86.
- Install the common agent container packages.
# pkgadd -d . SUNWcacaocfg SUNWcacao
Proceed with Sun Cluster software upgrade. After all cluster nodes are upgraded and rebooted into the cluster, distribute the upgraded security files for common agent container to all nodes. This task ensures that security files for the common agent container are identical on all cluster nodes and that the copied files retain the correct file permissions.
- On each node, stop the Sun Java Web Console agent.
# /usr/sbin/smcwebserver stop
- On each node, stop the security file agent.
# /opt/SUNWcacao/bin/cacaoadm stop
- On one node, change to the /etc/opt/SUNWcacao/ directory.
phys-schost-1# cd /etc/opt/SUNWcacao/
- Create a tar file of the /etc/opt/SUNWcacao/security/ directory.
phys-schost-1# tar cf /tmp/SECURITY.tar security
- Copy the /tmp/SECURITY.tar file to each of the other cluster nodes.
- On each node to which you copied the /tmp/SECURITY.tar file, extract the security files.
Any security files that already exist in the /etc/opt/SUNWcacao/ directory are overwritten.
phys-schost-2# cd /etc/opt/SUNWcacao/
phys-schost-2# tar xf /tmp/SECURITY.tar
- Delete the /tmp/SECURITY.tar file from each node in the cluster.
You must delete each copy of the tar file to avoid security risks.
phys-schost-1# rm /tmp/SECURITY.tar
phys-schost-2# rm /tmp/SECURITY.tar
- On each node, start the security file agent.
phys-schost-1# /opt/SUNWcacao/bin/cacaoadm start
phys-schost-2# /opt/SUNWcacao/bin/cacaoadm start
- On each node, start the Sun Java Web Console agent.
phys-schost-1# /usr/sbin/smcwebserver start
phys-schost-2# /usr/sbin/smcwebserver start
Choosing a Sun Cluster Upgrade Method
Choose one of the following methods to upgrade your cluster software.
Nonrolling Upgrade
In a nonrolling upgrade, you shut down the cluster before you upgrade the cluster nodes. You return the cluster to production after all nodes are fully upgraded. You must use the nonrolling-upgrade method if one or more of the following conditions apply:
Rolling Upgrade
In a rolling upgrade, you upgrade one node of the cluster at a time. The cluster remains in production with services running on the other nodes. You can use the rolling-upgrade method only if all of the following conditions apply:
If your cluster configuration meets the requirements to perform a rolling upgrade, you can still choose to perform a nonrolling upgrade instead.
For overview information about planning your Sun Cluster configuration, see Chapter 1, “Planning the Sun Cluster Configuration” of the Sun Cluster Software Installation Guide for Solaris OS at http://docs.sun.com/doc/817-6543.
Upgrading Web ServerThis section contains procedures for upgrading to Web Server SP4 from the previous Java Enterprise System 2003Q4 version. It contains the following topics:
For further Web Server information, refer to the following documentation:
To Upgrade Web Server
- Login as superuser (root).
- Stop all running instances of Web Server and the Administration Server by entering:
web_svr_base/https-instancename/stop
web_svr_base/https-admserv/stopThe default location for web_svr_base is:
Solaris /opt/SUNWwbsvr
Linux /opt/sun/webserver
- If not already done, upgrade the shared components listed in Table 3-23.
For Solaris see Applying Solaris Shared Component Patch Clusters.
For Linux see Applying Linux Shared Component RPMs.
- If not already done upgrade J2SE (See Upgrading J2SE Packages.).
- Apply the following patches using patchadd(1M).
- Restart Web Server.
To Remove Web Server Patches
If you decide to remove the Web Server patches, perform the following steps:
- Stop all running instances of the Web Server.
- Become root:
su root
When prompted, type your root password.
- Remove the appropriate Web Server patches added in To Upgrade Web Server using patchrm(1M).
- Restart the Web Server instances.