|
| |
| Sun Java Communications Suite 5 Upgrade Guide | |
Chapter 4
Upgrading Messaging ServerThis chapter describes how to upgrade previous versions of Messaging Server to Sun Java System Messaging Server 6.3.
The chapter provides an overview of upgrade considerations for the different supported upgrade paths on both the Solaris and Linux operating systems:
Overview of Messaging Server UpgradesThis section describes the following general aspects of Messaging Server that impact upgrade:
About Messaging Server 6.3
Messaging Server has two private interface changes that affect upgrade:
- Messaging Server 6.3 configuration data is no longer stored in a Directory Server instance called the configuration directory. This data is now stored as configuration variables in a local configuration file. Configuration information is no longer managed through the Administration Server and its administrative console interface.
- The Messenger Express Multiplexor (MEM) has been modified to eliminate its multiplexor function and to function only as a webmail server that accesses the Message Store. This webmail server interacts with the back-end Message Store using the IMAP protocol, which requires that new configuration parameters be set after upgrade. It is now called the Webmail Server.
Messaging Server Upgrade Roadmap
Table 4-1 shows the supported Messaging Server upgrade paths on both Solaris and Linux operating systems.
Table 4-1 Upgrade Paths to Sun Java System Messaging Server 6.3
Release
Messaging Server Version
General Approach
Re-configuration Required
Java Enterprise System 2005Q4 (6.2p3)
Sun Java System Messaging Server 6.2 2005Q4
Direct upgrade:
Performed by applying patches.Configuration data migrated to 6.3 configuration files and updated.
Java Enterprise System 2005Q1
(6.2)
Sun Java System Messaging Server 6.2 2005Q1
Direct upgrade:
Performed by applying patches.Configuration data migrated to 6.3 configuration files and updated.
Java Enterprise System 2004Q2
(6.1)
Sun Java System Messaging Server 6.1 2004Q2
Direct upgrade:
Performed by applying patches. Some additional manual steps on LinuxConfiguration data migrated to 6.3 configuration files and updated.
Java Enterprise System 2003Q4
(6.0) Solaris OS only
Sun ONE Messaging Server 6.0 (2003Q4)
Direct upgrade not certified:
Performed by applying patches.Configuration data migrated to 6.3 configuration files and updated.
Pre-dates Communications Suite releases
(5.2 and earlier)
Sun ONE Messaging Server 5.2
Direct upgrade not certified:
But you can upgrade to 6.3 using procedures in the Java Enterprise System 2005Q1 Upgrade and Migration Guide
(http://docs.sun.com/doc/819-0062).Configuration data migrated to 6.3 configuration files and updated.
Messaging Server Data
The following table shows the type of data that could be impacted by an upgrade of Messaging Server software.
Messaging Server Upgrade Strategy
Your strategy for upgrading Messaging Server depends on the many considerations discussed in Chapter 1, "Planning for Upgrades": upgrade path, dependencies between Communications Suite components, selective upgrade versus upgrade all, multi-instance deployments, and so forth.
This section is to particularize that general discussion to Messaging Server by presenting issues that might influence your Messaging Server upgrade plan.
Compatibility Issues
Messaging Server 6.3 does not introduce any changes in public interfaces. The logically distinct configurations of Messaging Server (Message Store, MTA, and MMP) have the same public interfaces, and are therefore backwardly compatible with 2005Q4, however the protocol between the Message Store and MEM (now known as Webmail Server) has changed in this release, impacting the upgrade procedure. See Post-Upgrade Tasks for Messaging Server Version 6.3.
Messaging Server Dependencies
Messaging Server dependencies on other Communications Suite components and on Java Enterprise System components can impact the procedure for upgrading and re-configuring Messaging Server software. Changes in Messaging Server interfaces or functions, for example, could require an upgraded version of components upon which Messaging Server depends. The need to upgrade such components depends upon the specific upgrade path.
Messaging Server has dependencies on the following Java Enterprise System components:
- Shared components. Messaging Server has dependencies on specific Communications Suite shared components (see Table 1-6).
- Directory Server. Message stores user data needed for Messaging in Directory Server. As a result, Messaging Server upgrades might require extensions of directory schema. Directory Server is no longer needed to store configuration data.
- Directory Preparation Tool. Messaging Server uses the Directory Preparation Tool to prepare Directory Server to support Messaging Server functions.
- Access Manager (optional). For software solutions that support single user sign-on for web-based services, Messaging Server can be configured to use Access Manager single sign-on capability.
- Message Queue (optional). Message Queue is used by Messaging Server for asynchronous notifications.
Deployment Architectures
In most deployment architectures involving Messaging Server, the logically distinct configurations of Messaging Server (Message Store, MTA, MMP, and MEM components) are deployed on different computers and often replicated for high availability and/or scalability.
These architectures can create upgrade challenges. In some cases the Messaging Server components need to be upgraded in a particular sequence, for example, because of changes in internal protocols. In many cases the upgrade needs to be performed as a rolling upgrade that does not interrupt service.
For documentation regarding some of these issues and how to resolve them, see Multiple Instance Upgrades.
Upgrading Messaging Server from Messaging Server 6.2p3 (Java Enterprise System 2005Q4)This section includes information about upgrading Messaging Server 6.2p3 (Java Enterprise System 2005Q4) to Messaging Server 6.3. The section covers the following topics:
Introduction
When upgrading Messaging Server 6.2p3 (Java Enterprise System 2005Q4) to Messaging Server 6.3, consider the following aspects of the upgrade process:
- General Upgrade Approach. The upgrade is performed by applying patches to the 2005Q4 version. Re-configuration is achieved by running two data configuration utilities and by importing configuration data into Directory Server.
- Upgrade Dependencies. While Messaging Server has dependencies on a number of Communications Suite shared components (see Table 1-6), Messaging Server requires that NSS/ NSPR be upgraded. Upgrade of J2SE is optional with respect to upgrade of Messaging Server.
In addition, Messaging Server is dependent upon Directory Server and optionally dependent on Access Manager, as described in Messaging Server Dependencies. These are soft upgrade dependencies; upgrade of these components is optional with respect to upgrade of Messaging Server.
However, Messaging Server has a hard upgrade dependency on Directory Preparation Tool; the Directory Preparation Tool is required to prepare Directory Server for messaging operations. See Chapter 3, "Directory Preparation Tool."
- Backward Compatibility. Messaging Server 6.3 is backwardly compatible with the 6.2p3 (Java Enterprise System 2005Q4) version.
- Upgrade Rollback. Rollback of the upgrade of Messaging Server to 6.2p3 (Java Enterprise System 2005Q4) is achieved by first removing the changes made to Directory Server, removing changes to local configuration files, and removing the patches applied during the upgrade.
- Platform Issues. The general approach for upgrading Messaging Server is the same on both Solaris and Linux operating systems, however the patching technologies are different. The upgrade process therefore includes platform-specific procedures.
Messaging Server 6.2p3 (Java Enterprise System 2005Q4) Upgrade
This section describes how to perform an upgrade of Messaging Server 6.2p3 (Java Enterprise System 2005Q4) to version 6.3 on both Solaris and Linux platforms. Where a topic depends on platform-specific procedures, the topic will indicate the operating system to which it applies. The section covers the following topics:
Pre-Upgrade Tasks
Before you upgrade Messaging Server you should perform the tasks described below.
Verify Current Version Information
You can verify the current version of Messaging Server by entering the following command:
Upgrade Messaging Server Dependencies
It is generally recommended that all Communications Suite components on a computer system (and in a computing environment) be upgraded to Communications Suite 5. However, Messaging Server has hard upgrade dependencies on a number of shared component and on Directory Preparation Tool. Upgrading of other Communications Suite 5 product components upon which Messaging Server depends is therefore optional.
However, if you choose to upgrade all Messaging Server dependencies, they should be upgraded in the following order, all before you upgrade Messaging Server. You can skip any that might already have been upgraded.
- Shared Components. If shared components have not yet been upgraded, you should do so by following the instructions in Chapter 2, "Upgrading Communications Suite Shared Components".
- Directory Server. Instructions for upgrading Directory Server are provided in the Java Enterprise System Upgrade Guide.
- Access Manager. Instructions for upgrading Access Manager are provided in the Java Enterprise System Upgrade Guide.
- Message Queue. Instructions for upgrading Message Queue are provided in the Java Enterprise System Upgrade Guide.
- Directory Preparation Tool. Instructions for upgrading Directory Preparation Tool are provided in the Chapter 3, "Directory Preparation Tool."
Back Up Messaging Server Data
The Messaging Server upgrade from 6.2p3 to 6.3 requires re-configuration of Messaging Server in a number of local configuration files and writing some data to Directory Server. The local changes can be rolled back, but it is a good idea to back up the Directory Server in case you want to roll back the upgrade at a future point.
Obtain Required Configuration Information and Passwords
Messaging Server upgrade requires knowing the following information:
Upgrading Messaging Server 6.2p3 (Solaris)
This section discusses considerations that impact the upgrade procedure for Messaging Server 6.2p3 followed by a description of the procedure itself.
Upgrade Considerations (Solaris)
The upgrade of Messaging Server software to Communications Suite 5 takes into account the following considerations:
- All logically distinct configurations of Messaging Server (Message Store, MTA, MMP, and Webmail Server (MEM) components) that correspond to the same installed Messaging Server image, should be upgraded together. All such components should be shut down before patches are applied to the installed image.
- Because of changes in protocol between the Message Store and Webmail Server (MEM) components, the Message Store should be upgraded and re-configured before upgrading the Webmail Server (MEM) component that interact with the Store. For more detailed information, see Multiple Front-end and Back-end Components and
- The Messaging Server upgrade patches for Solaris OS are shown in the following table. The core patch migrates configuration data from the Directory Server configuration directory to local configuration files.
Table 4-4 Patches1 to Upgrade Messaging Server 6.2p3 on Solaris
Description
SPARC
Solaris 9 & 10
X86
Solaris 9 & 10
Messaging Server core software with S/MIME
120228-17
120229-17
Messaging Server localization
117784 -17
117785 -17
1Patch revision numbers are the minimum required for upgrade to Communications Suite 5. If newer revisions become available, use the newer ones instead of those shown in the table.
Upgrade Procedure (Solaris)
The procedure documented below applies to all Messaging Server components that correspond to the same installed Messaging Server image on the computer where the upgrade is taking place.
- Obtain the required patches, based on Table 4-4.
Patches can be downloaded to /tmp from: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
- Log in as root or become superuser.
su -
- Stop all running Messaging Server components.
msg-svr-base/sbin/stop-msg
- If you have not already done so, upgrade shared components.
Upgrade Messaging Server Dependencies.
- Apply the appropriate Messaging Server core and, if needed, localization patches in Table 4-4, in that order.
patchadd patch_ID
- Confirm that the patch upgrades were successful:
showrev -p | grep patch_ID
The output should return the versions of patch IDs applied in Step 5.
- Migrate configuration data from existing configuration files and the Directory Server configuration directory to 6.3 configuration files.
- Create configuration files corresponding to the core and, if needed, localization patches.
cd msg-svr-base/sbin
./patch-config msg-svr-base/install/patch/patch_IDThis command backs up existing configuration files. Then it merges configuration parameter values in these files with 6.3 template configuration files to create new 6.3 configuration files. In addition, configuration that was previously stored in the Directory Server configuration directory is migrated to the new 6.3 configuration files. You should examine these new files for possible conflicts, as described in the Special Installation Instructions section of the core patch readme file.
This command also generates the following ldif file (LDAP directory import files):
msg-svr-base/lib/patch/ugdir_diff.ldif
- Install the 6.3 configuration files corresponding to the core and, if needed, localization patches, making them the active configuration.
./install-newconfig -f msg-svr-base/install/patch/patch_ID
This command installs the new 6.3 configuration files in their correct locations. The -f flag avoids having to confirm the operation for each file.
- Import the new configuration data generated in Step a into the Directory Server instance being used by Messaging Server.
Change to the Directory Server instance and import the ldif file using the ldapmodify command:
cd msg-svr-base/lib
./ldapmodify -D bind_dn -w password -c -h hostName -p port
-e patch/ugdir_diff.rej -f patch/ugdir_diff.ldif
Note
If the ldapmodify command fails on the Solaris platform, first set the library path appropriately for your shell to:
LD_LIBRARY_PATH=msg-svr-base/lib
- If the IMAP proxy username and password are different from the username and password of the store the webmail server is accessing via IMAP, you need to set LD_LIBRARY_PATH as follows.
LD_LIBRARY_PATH= msg-svr-base/sbin/configutil -o
local.service.proxy.admin -v admin_IDLD_LIBRARY_PATH= msg-svr-base/sbin/configutil -o
local.service.proxy.adminpass -v passwordThe default value of local.service.proxy.admin is admin. The default value of local.service.proxy.adminpass is the password you entered at configure time.
- Increase the number of file descriptors by setting ulimit as follows:
ulimit -n <number of file descriptors>
For example:
ulimit -n 100000
Configure ulimit with a value no less than 12851.
- Restart the Messaging Server components that were stopped in Step 3.
msg-svr-base/sbin/stop-msg
msg-svr-base/sbin/start-msg
Upgrading Messaging Server 6.2p3 (Linux)
This section discusses considerations that impact the upgrade procedure for Messaging Server followed by a description of the procedure itself.
Upgrade Considerations (Linux)
The upgrade of Messaging Server software on the Linux platform takes into account the same considerations as on the Solaris platform (see Upgrade Considerations (Solaris)), except that the Linux upgrade patches differ from the Solaris patches.
The Messaging Server upgrade patches for Linux OS are shown in the following table:
Table 4-5 Patches1 to Upgrade Messaging Server on Linux
Description
Patch ID and RPM names
Messaging Server core software with S/MIME
120230-17
Messaging Server localization
117786-17
1Patch revision numbers are the minimum required for upgrade to Communications Suite 5. If newer revisions become available, use the newer ones instead of those shown in the table.
Upgrade Procedure (Linux)
The procedure documented below applies to all Messaging Server components that correspond to the same installed Messaging Server image on the computer where the upgrade is taking place.
Caution
An upgrade from Messaging Server 6.2p3 to Messaging Serevr 6.3 on Linux cannot be rolled back.
- Obtain the required patches using the patch numbers and RPM names from Table 4-5. Use this information to obtain the version numbers for the RPM.
Patches can be downloaded to /tmp from: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
- Log in as root or become superuser.
su -
- Stop all running Messaging Server components.
msg-svr-base/sbin/stop-msg
- If you have not already done so, upgrade shared components.
Upgrade Messaging Server Dependencies.
- Apply the RPMs for Messaging Server core and, if needed, localization patches in Table 4-5, in that order.
For example:
rpm -Fvh sun-messaging-server-6.3-13.9.i386.rpm
- Confirm that the patch upgrades were successful:
rpm -q sun-messaging-server
The new version number of the RPM should be returned.
- Migrate configuration data from existing configuration files and the Directory Server configuration directory to 6.3 configuration files.
- Create configuration files corresponding to the core and, if needed, localization patches.
cd msg-svr-base/sbin
./patch-config msg-svr-base/install/patch/patch_IDThis command backs up existing configuration files. Then it merges configuration parameter values in these files with 6.3 template configuration files to create new configuration files. In addition, configuration previously stored in the Directory Server configuration directory is migrated to the new 6.3 configuration files. You should examine these new files for possible conflicts, as described in the Special Installation Instructions section of the patch 12030 README file.
This command also generates the following ldif files (LDAP directory import files):
msg-svr-base/lib/patch/ugdir_diff.ldif
- Install the 6.3 configuration files corresponding to the core and, if needed, localization patches, making them the active configuration.
./install-newconfig msg-svr-base/install/patch/patch_ID
This command installs the new configuration files in their correct locations.
- Import the new configuration data generated in Step a into the Directory Server instance being used by Messaging Server.
Change to the Directory Server instance and import the ldif file using the ldapmodify command:
cd msg-svr-base/lib
./ldapmodify -D bind_dn -w password -c -h hostName -p port
-e patch/ugdir_diff.rej -f patch/ugdir_diff.ldif
Note
If the ldapmodify command fails on the Linux platform, first set the library path appropriately for your shell to:
LD_LIBRARY_PATH=msg-svr-base/lib
- Change the number of file descriptors by setting ulimit as follows:
ulimit -n <number of file descriptors>
For example:
ulimit -n 100000
- Restart the Messaging Server components that were stopped in Step 3.
msg-svr-base/sbin/start-msg
Verifying the Messaging Server Upgrade to Version 6.3
You can verify the upgrade of Messaging Server to version 6.3 by entering the following command:
msg-svr-base/sbin/imsimta version
You can also check the banner displayed when starting up Messaging Server components.
See Table 4-3 for output values.
Post-Upgrade Tasks for Messaging Server Version 6.3
If you used MEM (Messenger Express Multiplexor) in previous releases, the new Webmail Server now interacts with the Message Store using the IMAP protocol.
Caution
If you are using Communications Express, the Webmail Server, and back-end Message Stores, the following deployment scenarios are supported:
The following upgrade scenario is not supported:
When upgrading from Version 6.2 Patch 3 (2005Q4), you must upgrade Message back-end Store(s) first and make sure that IMAP is enabled before upgrading and re-configuring Webmail Server that accesses the Message Store. In addition, you must make sure that the Webmail Server and Communications Express are upgraded together and are of the same version.
In other words, you must perform the following steps:
- After upgrading the Message Store, enable the IMAP protocol.
Perform the following configutil command:
msg-svr-base/sbin/configutil -o service.imap.enable -v yes
- After upgrading MEM to Webmail Server, configure it to access the Message Store.
You need to specify the IMAP admin user and password. Webmail Server can be configured to interact with more than one Message Store by setting respective configutil variables, each specifying a target host name, as indicated below. If there is only one Message Store, omit the .hostname.
msg-svr-base/sbin/configutil
-o service.http.allowadminproxy.hostname -v yesmsg-svr-base/sbin/configutil
-o local.service.http.proxy.admin.hostname
-v webmailProxyAdmin user IDmsg-svr-base/sbin/configutil
-o local.service.http.proxy.adminpass.hostname
-v webmailProxyAdmin password- After all components have been upgraded for a Message Store, you can disable and shut down the mshttpd process, as follows:
msg-svr-base/sbin/configutil -o service.http.enable -v no
msg-svr-base/sbin/stop-msg httpIn a single-host environment, you can't shut down mshttpd, otherwise Webmail Server will also be shut down.
However, in a distributed environment where you had MEM on front ends and mshttpd on the back-end prior to upgrade, you will now need to shut down mshttpd on the back-end server (co-located with the store) after upgrade and reconfiguration.
- After all components have been migrated to 6.3, the Directory Server configuration directory server is no longer accessed. It can be decommissioned.
Rolling Back the Upgrade (Solaris)
This section describes considerations that impact the upgrade rollback procedure for Messaging Server followed by the procedure itself.
Rollback Considerations (Solaris)
The procedure for rolling back the upgrade to a previous version of Messaging Server is for the most part the reverse of the procedure for upgrading the newest version. The re-configurations are rolled back and the patches are removed.
Rollback Procedure (Solaris)
- Log in as root or become superuser.
su -
- Stop all running Messaging Server components.
msg-svr-base/sbin/stop-msg
- Roll back the changes made to the Directory Server user/group directory being used by Messaging Server.
Replace the directory with the pre-upgrade directory that you backed up before beginning the upgrade procedure (see Back Up Messaging Server Data).
- Roll back the re-configuration performed in Step 7.
cd msg-svr-base/sbin
./uninstall-newconfig -f msg-svr-base/install/patch/patch_ID- Remove the core and, if applied, localization patches in Table 4-4.
patchrm patch_ID
- Restart the Messaging Server components that were stopped in Step 2.
msg-svr-base/sbin/start-msg
Multiple Instance Upgrades
In most deployment architectures involving Messaging Server, the logically distinct configurations of Messaging Server (Message Store, MTA, MMP, and Webmail Server) are deployed on different computers and often replicated for high availability and/or scalability.
For example, you might have MTA or MMP components running on multiple computers with a load balancer to distribute the load. You might also have the Message Store component running in a Sun Cluster environment to provide high availability.
Multiple Front-end and Back-end Components
In deployment architectures in which various Messaging Server subcomponents (Message Store, MTA, MMP, Webmail Server) are deployed on different computers, it is generally best to upgrade components beginning in the back-end tier (Message Store) and working toward the front-end tier (MTA, MMP, and Webmail Server).
This approach is particularly important when upgrading MEM components to the Webmail Server because the protocol to access Message Store has changed. In this case Message Store needs to be upgraded and the IMAP protocol enabled (see Post-Upgrade Tasks for Messaging Server Version 6.3) before upgrading to Webmail Server.
If both a Message Store and Webmail Server are configured for the same computer, be sure to upgrade any remote Message Stores accessed by the Webmail Server before upgrading Messaging Server on the local computer.
You perform the upgrade of each instance as described in Messaging Server 6.2p3 (Java Enterprise System 2005Q4) Upgrade.
In the case of load-balanced instances of Messaging Server, you can perform a rolling upgrade in which you upgrade the Messaging Server instances sequentially without interrupting service. You upgrade each instance of Messaging Server while the others remain running.
High Availability Clusters
In the case of Message Store running in a cluster environment, the active Messaging Server instance nodes and the failover nodes share the same configuration and user data, located on a shared file system. Generally speaking, the Messaging Server image is also installed on the shared file system. Depending on your cluster configuration you can minimize upgrade downtime by performing a rolling patch upgrade, as described below.
This approach is possible because the 6.3 binaries are compatible with the 6.2p3 configuration files and other data. However it is important to note that once you have started using 6.3 with a configuration, you should avoid reverting back to the 6.2p3 binaries. The reason is that some 6.3 generated data (e.g. queue files) might not be compatible with 6.2p3.
Asymmetric HA
The basic asymmetric or “hot standby” high availability model consists of two clustered host machines or “nodes.” A logical IP address and associated host name are designated to both nodes.
In this model, only one node is active at any given time; the backup or hot standby node remains idle most of the time. A single shared disk array between both nodes is configured and is mastered by the active or “primary” node. The message store partitions and Message Transfer Agent (MTA) queues reside on this shared file system.
N+1 Cluster
The N + 1 or “N over 1” model operates in a multi-node asymmetrical configuration. N logical host names and N shared disk arrays are required. A single backup node is reserved as a hot standby for all the other nodes. The backup node is capable of concurrently running Messaging Server from the N nodes.
The shared file system is also accessed by a failover node, shown in Figure 4-1 as NodeX. When any of the N nodes fail, The failover node, which had been standing by, becomes active, running the binaries of the failed node using the corresponding configuration and data in the shared file system. (The expectation is that only one node would fail at any given time.)
The key concept in upgrading Messaging Server in this cluster is to sequentially upgrade the N active nodes by failing over the node being upgraded to NodeX, while patching and re-configuring (running the patch-config script) Messaging Server for that node.
For example, consider the upgrade of Messaging Server on Node1. Messaging Server services on Node1 are failed over to NodeX while patching and re-configuration take place. In other words MS-X binaries use the MS-1 config and MS-1 data wile the MS-1 binaries are patched and re-configured. When this part of the upgrade is complete, the Messaging Server services are failed back over to Node1. At that point, the Messaging Server services are shut down briefly while the install-newconfig script is run, after which the services are restarted.
The procedure is repeated for each node in the cluster.
The steps for Node1, for example, are as follows.
- Make sure the MS-X binaries are at the same patch level as Node1.
- On NodeX, set up the MS-X binaries to use the MS-1 config/MS-1 data, using the useconfig utility.
- On Node1, stop the MS-1 services being run by MS-1 binaries.
- On NodeX, start up the MS-1 services using the MS-X binaries.
(Step 2 through Step 4 amount to a manual failover of MS-1 binaries to MS-X binaries.)
- On Node 1, patch the MS-1 binaries and run the patch-config script.
- On NodeX, stop the MS-1 services being run by MS-X binaries.
- Run install-newconfig on MS-1.
- Bring the MS-1 services back up.
Repeat the above steps for Node2 through NodeN of the cluster. Finally, apply the patch to MS-X on NodeX, so it is at the same patch level as all the other nodes.
Note that MS services are truly down only when install-newconfig is run. The other times that MS services are brought down are only for the brief period of a manual failover.
Figure 4-1 Messaging Server N+1 Cluster
Symmetric HA
The basic symmetric or “dual services” high availability model consists of two hosting machines, each with its own logical IP address. Each logical node is associated with one physical node, and each physical node controls one disk array with two storage volumes. One volume is used for its local message store partitions and MTA queues, and the other is a mirror image of its partner’s message store partitions and MTA queues.
In the symmetric high availability mode (Figure 4-2), both nodes are active concurrently, and each node serves as a backup node for the other. Under normal conditions, each node runs only one instance of the messaging server.
Figure 4-2 Messaging Server Symmetric Cluster
In the case of symmetric high availability, The MS service being upgraded must be shut down for the duration of the patching and re-configuration. That is, MS-1 binaries need to be stopped during patching and cannot therefore be failed over to Node2.
Upgrading Messaging Server from Messaging Server 6.2 (Java Enterprise System 2005Q1)The procedure for upgrading 2005Q1 Messaging Server 6.2 (Java Enterprise System 2005Q1) to 6.3 is the same as that for upgrading Messaging Server 6.2p3 (Java Enterprise System 2005Q4) to Messaging Server 6.3.
To upgrade Messaging Server 6.2 (Java Enterprise System 2005Q1) to Messaging Server 6.3, use the instructions in Upgrading Messaging Server from Messaging Server 6.2p3 (Java Enterprise System 2005Q4), except substitute 6.2 (Java Enterprise System 2005Q1) wherever 6.2p3 (Java Enterprise System 2005Q4) is referenced.
Upgrading Messaging Server from Messaging Server 6.1 (Java Enterprise System 2004Q2)The procedure for upgrading Messaging Server 6.1 (Java Enterprise System 2004Q2) to 6.3 is the same as that for upgrading Messaging Server 6.2p3 (Java Enterprise System 2005Q4) to Messaging Server 6.3, with a couple of exceptions, noted below.
Upgrade Messaging Server Dependencies
As compared to the upgrade from Messaging Server 6.2p3 (Java Enterprise System 2005Q4), the Messaging Server 6.1 (Java Enterprise System 2004Q2) to Messaging Server 6.3 pre-upgrade tasks should include the upgrading to 6.3 of all shared components (see Table 1-6) and all locally-resident product components upon which Messaging Server depends:
- Shared Components. Instructions for upgrading Communications Suite shared components to 6.3 are provided in Chapter 2, "Upgrading Communications Suite Shared Components".
- Directory Server. Directory Server rarely resides on the same computer as Messaging Server, however, instructions for upgrading Directory Server are provided in the Java Enterprise System Upgrade Guide.
- Access Manager (optional). Instructions for upgrading Access Manager are provided in the Java Enterprise System Upgrade Guide.
- Directory Preparation Tool. Directory Preparation Tool rarely resides on the same computer as Messaging Server, however, instructions for upgrading Directory Preparation Tool and running it against Directory Server are provided in the Chapter 3, "Directory Preparation Tool".
Messaging Server 6.1 (Java Enterprise System 2004Q2) Upgrade
The procedure for upgrading Messaging Server 6.1 (Java Enterprise System 2004Q2) to Messaging Server 6.3 depends on operating system platform.
Upgrading Messaging Server 6.1(Solaris)
To upgrade Messaging Server 6.1 (Java Enterprise System 2004Q2) to Messaging Server 6.3, use the instructions in Upgrading Messaging Server 6.2p3 (Solaris), except substitute Messaging Server 6.1 (Java Enterprise System 2004Q2) wherever Messaging Server 6.2p3 (Java Enterprise System 2005Q4) is referenced.
Upgrading Messaging Server 6.1 (Linux)
The procedure documented below applies to all Messaging Server components that correspond to the same installed Messaging Server image on the computer where the upgrade is taking place.
- Log in as root or become superuser.
su -
- Stop all running Messaging Server components.
msg-svr-base/sbin/stop-msg
- If you have not already done so, synchronize shared components to 6.3.
See Upgrade Messaging Server Dependencies.
- Uninstall the 6.1 RPM packages.
rpm -e --noscripts sun-messaging-lib-6.1-9 \
sun-messaging-store-6.1-9 \
sun-messaging-install-6.1-9 \
sun-messaging-core-6.1-9 \
sun-messaging-mmp-6.1-9 \
sun-messaging-sieveui-6.1-9 \
sun-messaging-webmail-6.1-9 \
sun-messaging-core-en-6.1-9 \
sun-messaging-mta-6.1-9- Install the RPMs for Messaging Server core and, if needed, localization patches in Table 4-5.
rpm -i sun-messaging-server-6.1-12.38.i386.rpm
- Confirm that the patch upgrades were successful:
rpm -q sun-messaging-server
The version number of the newly installed RPM should be returned.
- Save off your old 6.1 configuration.
The configuration files are located at: msg-svr-base/config
- Run the Messaging Server configuration program.
cd msg-svr-base/sbin
./configure- Perform a manual merge of the 6.1 configuration values with the new 6.3 configuration entries.
- Restart the Messaging Server components that were stopped in Step 2.
msg-svr-base/sbin/start-msg
For further details, for example to change the HTTP port using the configutil command, see the Special Installation Instructions section of the patch 120230-08 readme file.
Verifying the Upgrade from Version 6.1
You can verify the upgrade from 6.1 to 6.3 in the same way as you can verify the upgrade from 6.2 to 6.3. See Verifying the Messaging Server Upgrade to Version 6.3.
Post-Upgrade Tasks for Upgrade from Version 6.1 to 6.3
The post-upgrade tasks in upgrading from 6.1 to 6.3 are the same as in upgrading from 6.2 to 6.3. See Post-Upgrade Tasks for Messaging Server Version 6.3.
