Communications Suite InformationUpgrading to Calendar Server 6.3 with Convergence
This section describes how to upgrade Calendar Server to use Sun Convergence. The version required is Calendar Server 6.3 with the latest patches installed. Upgrading consists of choosing an upgrade strategy, then upgrading each of the individual servers using that strategy. The procedure for upgrading individual servers depends on the version of Calendar Server you are currently running.
To upgrade the Calendar Server from Communications Suite Release 5 to Release 6, you use the commpkg upgrade command. Both versions are 6.3, but commpkg upgrade installs the required patches. To upgrade from 6.2, see To Upgrade From Calendar Server 6.2 . To upgrade from a version earlier then 6.2, refer to the Chapter 5, Upgrading Calendar Server of the Sun Java Communications Suite 5 Upgrade Guide to upgrade to 6.3, then return here for instructions on how to apply the appropriate patches.
This chapter consists of the following sections:
Calendar Server Upgrade Strategies
There are two possible Calendar Server upgrade strategies: the parallel system upgrade or the in-place upgrade.
In an in-place upgrade, the existing software is upgraded to the new version in the same location.
In a parallel system upgrade, the existing software remains operating while the new version is installed in another location. A parallel system upgrade is useful for deployments consisting of multiple servers in a distributed network. The servers interoperate by using adjacent builds (in adjacent directories) so that the network can be upgraded in phases.
Each strategy has its advantages and disadvantages:
- In a parallel system upgrade, users have access to the calendar (though, readonly) throughout the upgrade process. During an in-place upgrade, some downtime is incurred.
- A parallel system upgrade limits the impact on global and distributed services during the upgrades.
- In a parallel system upgrade, a smaller staff is required to administer the upgrades on many distributed machines. Conversely, this approach limits the extended downtime a small staff needs to upgrade many machines together.
- If the upgrade is not successful, parallel system upgrades offer an easier roll-back procedure. Parallel system upgrades reduce the risk of attempting to change all installations at once before being able to verify that the solution is workable. In-place upgrades have a more complex roll-back procedure.
- Parallel system upgrades require additional hardware. In-place upgrades do not require additional hardware.
 | Upgrade Strategy for Calendar Server Deployments Using the DWP Protocol For Calendar Server deployments that use the Database Wire Protocol (DWP) protocol, you are strongly urged to consider a parallel system upgrade. Here's why: DWP design constraints require all nodes in a distributed deployment to be upgraded at the same time. With its versionless state, the DWP protocol presumes (requires) the front-end and back-end servers to be the same build/version. For example, suppose an organization running Calendar Server with DWP has back-end servers in Europe, Asia, and the Americas and front-end servers in a multitude of countries. To perform an in-place upgrade, this deployment would need to shut down the entire Calendar Server network. A parallel system upgrade would enable the existing Calendar Servers to continue running while the network is upgraded in phases. |
Parallel System Upgrade Procedures
In a parallel system upgrade, you do the following:
- Create a separate new Calendar Server environment. Refer to the Sun Java Communications Suite 5 Deployment Planning Guide for details.
- Set the existing Calendar server to a read-only mode and inform users that calendar entries cannot be created or modified until the migration is complete.
Set caldb.berkeleydb.readonly to yes in ics.conf and restart the services.
- Migrate the configuration and calendar data to the new environment. (See the version-specific section.)
- Switch over to the new system and verify that everything works.
End users, or any applications that depend on this server, will need to connect to this box instead of the old box.
- Inform users that calendar entries can be created or modified and the migration is complete.
- Shut down the legacy servers.
- If the switchover does not work, switch back to the legacy servers.
In-place Upgrade Procedures
In an in-place upgrade, you do the following:
- Back up your calendar database.
See csbackup
- Perform the upgrade procedures as described in the following sections.
- Verify that the new system works.
For example, check that users can log in and create events and to-do's.
- If the new system does not work, remove the upgrade patches and then restore the data.
Restore the database save in step 1. See csrestore
Note You cannot remove the upgrade patches and restore the data in Linux by using an in-place upgrade.
The rest of this section describes how to upgrade your individual Calendar Servers by using these two strategies.
Upgrading Individual Calendar Servers
Whether you are doing an in-place or parallel upgrade, the process for upgrading individual servers is the same. How those individual Servers are upgraded to use Sun Convergence depends on whether you are using the version 6.3 or an earlier version of Calendar Server. To upgrade from a version earlier then 6.2, refer to the Chapter 5, Upgrading Calendar Server of the Sun Java Communications Suite 5 Upgrade Guide to upgrade to 6.3, then return here for instructions on how to apply the appropriate patches. To upgrade from 6.3 or 6.2 you'll need to install the latest patches listed in Release Notes . Detailed instructions are provided in later sections.
The localization patches and packages are no longer required separately, as localization resources are bundled with core packages. Before applying this patch, remove the old l10n packages if installed. For example:
pkgrm -n SUNWics-l10n
or
pkgrm -n SUNWfrics SUNWdeics SUNWesics SUNWjaics SUNWkoics SUNWzhics SUNWtwics
for Linux:
rpm -e sun-calendar-core-l10n
or
rpm -e sun-calendar-core-fr
rpm -e sun-calendar-core-de
rpm -e sun-calendar-core-es
rpm -e sun-calendar-core-ja
rpm -e sun-calendar-core-ko
rpm -e sun-calendar-core-zh
rpm -e sun-calendar-core-zh_TW
Other Calendar Server Upgrade Notes:
- At some sites, Calendar Server 6.3 might not start after patching. If this problem occurs, follow the procedure described in the Known Issues section of Calendar Server 6.3 Release Notes .
- Calendar Server should be shut down when patches are being applied to the installed image.
- In architectures in which different Calendar Server subcomponents reside on different computers, for example, Calendar Server back-end store on one computer and Calendar Server front-end processes (such as cshttpd) on another, the upgrade must be performed on all such computers.
- The Calendar Server upgrade applies to multiple Calendar Server subcomponents on one computer using the same installed image.
- Data created in the Solaris x86 version of Calendar Server 6.3 patch 121658-19 or earlier is corrupted when you upgrade to patch 121658-20 or later. This issue occurs on Solaris x86 platforms only (CR 6642958). With patch 121658-20 and later, Calendar Server uses the new Berkeley Database library, which is incompatible with the database created by earlier versions. In order to use the database created by patch 121658-19 (or prior) with this patch, you must update the database. See Release Notes for details on how to update the database and further details.
- Calendar Server 6.3 requires the software dependencies listed in the Release Notes . For a list of all Communications Suite requirements, see the Requirements for Communications Suite 6.
If you want to upgrade Calendar Server 6.3 so that it can be used by Sun Convergence, you can simply run the commpkg upgrade command
To Upgrade From Calendar Server 6.3
Note that Communications Suite 5 and 6 both use Calendar Server 6.3, but Communications Suite 6 has the required patches that work with Sun Convergence.
To Upgrade From Calendar Server 6.2 on Solaris
To upgrade Calendar Server 6.2 to Convergence-enabled Calendar Server 6.3, use the following directions:
- Obtain the required patch. See Release Notes .
You can download patches to /tmp from: http://sunsolve.sun.com.
- Log in to the machine where you are upgrading Calendar Server (as superuser or root).
> su -
- Stop Calendar Server if it is running.
cal-svr-base/cal/sbin/stop-cal
- If you have not already done so, upgrade shared components to Communications Suite 6.
See Communications Suite Requirements.
- Apply the Calendar Server core patch (see Release Notes ).
patchadd <patch_ID>
- Confirm that the patch upgrades were successful:
showrev -p | grep ics
The output should return the versions of patch IDs applied in Step 5.
- Reconfigure Calendar Server.
cd cal-svr-base/sbin
./csconfigurator.sh -noconsole -nodisplay -novalidate
The -noconsole -nodisplay -novalidate arguments pick up the existing Calendar Server 6.x configuration values and perform the necessary reconfiguration for the upgraded software.
If the Calendar Server 6.x installation had been configured in nonhosted domain (legacy) mode, the configurator gives the choice either to stay in that mode or switch to hosted domain mode, the default for this version of Calendar Server. Switching to hosted domain mode is not reversible.
The csconfigurator command is documented in the Calendar Server Administration Guide .
- Move Calendar Server data files to a temporary location.
mkdir /var/cal-svr-base/old_csdb
mv /var/cal-svr-base/csdb/* /var/cal-svr-base/old_csdb
The old_csdb directory is a temporary location.
- Change permissions on the temporary location.
chown -R icsuser:icsgroup /var/cal-svr-base/oldcsdb
- Migrate the Calendar Server 6.2 (Java Enterprise System 2005Q4) data using the csmigrate migration tool.
cd cal-svr-base/cal/sbin
./csmigrate -l max /var/cal-svr-base/old_csddb /var/cal-svr-base/csdb
The general syntax for csmigrate is as follows:
csmigrate [-q] [-d] [-l min|max] [-b backup_dir] source_dbdir target_dbdir
Command options and operands are documented in the following table.
TABLE 1. csmigrate Command Options and Operands
Option/Operand Description -q Specifies quiet mode, no print statements -d Specifies dry run mode, no new db written -l min or max Specifies log level. csmigrate creates the following log files:
cal-svr-base/logs/csmigrate.log
cal-svr-base/logs/csmigrateError.log-b backup_dir Specifies directory to which to back up the source database. The program works on the backed-up copy to prevent any damage to the source database. The default location is source_dbdir/backup. source_dbdir Directory where pre-migration database files are located. target_dbdir Directory where pos-tmigration files will be written
If you choose an arbitrary target_dbdir rather than /var/cal-svr-base/csdb, then you have to change the value of the caldb.berkeleydb.homedir.path property in the Calendar Server configuration file to point to that location.
Note: If the csmigrate command fails on the Solaris 10 platform, set the library path to null when running the command:
LD_LIBRARY_PATH= ./csmigrate ... - Restart the Calendar Server that was stopped in the earlier step.
cal-svr-base/cal/sbin/start-cal
To Upgrade From Calendar Server 6.2 on Linux
The following procedure applies to Calendar Server on the computer where the upgrade is taking place.
- Obtain the required patches by using the patch numbers and RPM names from Release Notes . Use this information to obtain the version numbers for the RPM.
Patches can be downloaded to /tmp from: http://sunsolve.sun.com
- Log in as root or become superuser.
su -
- Stop Calendar Server if it is running.
cal-svr-base/sbin/stop-cal
- If you have not already done so, synchronize all shared components to Release 6.
See Upgrade Calendar Server Dependencies. - Remove the 6.2 calendar-api package
rpm -e sun-calendar-api-6.2-10.28
Note: The version number on the package name might be different, depending on the version of calendar patch installed. Confirm the package name to be deleted by using rpm -qa | grep sun-calendar - Apply the core and calendar-api in the following order. (The following *rpm files are an example. Use the *rpm files that came with the patch download.)
rpm -Fvh sun-calendar-core-6.3-7.03.i386.rpm
rpm -i sun-calendar-api-6.3-7.03.i386.rpm
- Confirm that the patch upgrades were successful:
rpm -qa | grep sun-calendar
The new version numbers of the RPMs in Step 5 should be returned.
- Reconfigure Calendar Server.
cd cal-svr-base/sbin
./csconfigurator.sh
If the Calendar Server 6.2 or earlier Calendar Server installation had been configured in non-hosted domain (legacy) mode, the configurator offers the choice of either staying in that mode or switching to hosted domain mode, which is the default for Calendar Server 6.3 with the latest patches. Switching to hosted domain mode is not reversible.
The csconfigurator command is documented in the Calendar Server Administration Guide .
- Move Calendar Server data files to a temporary location.
mkdir /var/cal-svr-base/oldcsdb
mv /var/cal-svr-base/csdb/* /var/cal-svr-base/oldcsdb
where oldcsdb is a temporary location.
- Change permissions on the temporary location.
chown -R icsuser:icsgroup /var/cal-svr-base/oldcsdb - Migrate the Calendar Server 6.2 or earlier data by using the csmigrate migration tool.
cd cal-svr-base/sbin
./csmigrate -l max /var/cal-svr-base/old_csddb /var/cal-svr-base/csdb
The general syntax for csmigrate is as follows:
csmigrate [-q] [-d] [-l min|max] [-b backup_dir] source_dbdir target_dbdir
Command options and operands are documented in Table 1, shown previously.
- Restart the Calendar Server that was stopped in Step 3.
cal-svr-base/sbin/start-cal
Verifying the Upgrade
You can verify the upgrade of Calendar Server by running the following commands:
Solaris: cal-svr-base/cal/sbin/csversion
Linux: cal-svr-base/sbin/csversion
See the Release Notes for the appropriate version values.
Upgrading Calendar Server With HA
Calendar Server instances running in a cluster environment must share the same configuration. Ensure that the config directory is mounted on the node that you are upgrading. Apply Calendar Server upgrade patches to each of the instances as described previously. No reconfiguration is required.
Calendar Server Backoff
To roll back to the previous version of Calendar Server, install a fresh copy of the old version of Calendar Server and perform a csrestore on the database you backed up prior to starting the upgrade.