C H A P T E R 3 |
This chapter describes the requirements and procedures for upgrading from a previous version of SGD.
This section describes the things you must know and do before upgrading.
SGD version 4.4 includes a new web‐based administration tool, the SGD Administration Console, which replaces Object Manager, Array Manager, Configuration Wizard, and Session Manager. As a result, there are some significant changes to the SGD organizational hierarchy. The main changes are as follows:
Application objects are always created and maintained in a new organization object called o=applications.
Host objects are always created and maintained in a new organization object called o=appservers.
The previous administration tools allowed you to build complex relationships between objects. The allowed relationships have been simplified.
When you upgrade, your existing application and host objects (and their associated group and organizational unit objects) are moved to the new organizations. As far as possible, SGD attempts to preserve the relationships between the objects, but after the upgrade some users might find that some applications are no longer on their webtop.
Before you upgrade, it is a advisable to perform a test to see how the changes affect you. You can do this by upgrading a pre-production environment that mirrors the production environment. Alternatively, detach a secondary server from the array and upgrade it.
Upgrades to or upgrades from Early Access Program (EAP) software releases of SGD are not supported. EAP software releases must always be a fresh installation.
Upgrades to this version of SGD are only supported from the following versions:
If you want to upgrade from any other version of SGD, or from Tarantella Enterprise 3 version 3.3 or earlier, contact Sun Support.
If are sure you want to perform an unsupported upgrade, you must create an empty file /install‐dir/var/UPGRADE before installing the new version of the software. Your SGD installation might not be upgraded correctly.
When you upgrade on Solaris OS platforms, the pkgadd command performs several checks and asks you to confirm the changes before installing the package. You can create an administration file that instructs pkgadd to bypass these checks and install the package without user confirmation.
To avoid user interaction, the administration file must contain the following lines:
conflict=nocheck instance=unique
When you upgrade SGD, use the pkgadd -a adminfile command to specify the administration file.
If you do not specify an administration file when you upgrade, the SGD installation program creates one for you and gives you the option to quit the installation so that you can run the pkgadd command again with the -a adminfile option.
On Linux platforms, if you are upgrading from SGD version 4.2, you must manually remove all the optional SGD software packs before upgrading.
To list all installed SGD software packs:
# rpm -qa | grep -i tta |
The following are the optional SGD software packs:
Package | SGD Software Pack Name |
---|---|
ttasecure | Security Pack |
tta3270 | Mainframe Connectivity Pack |
tta5250 | AS/400 Connectivity Pack |
ttafandr | Andrew X fonts |
ttafhang | Hangul X fonts |
ttaficl | ICL X fonts |
ttaforie | Oriental X fonts |
ttafscot | SCO Term X fonts |
To remove all optional SGD software packs:
# rpm -e package ... |
When you upgrade, the following changes are applied to your existing configuration:
Your existing Enterprise Naming System (ENS) database is preserved and backed up.
The ENS database is the storage area for all the objects in your SGD organizational hierarchy.
The install-dir/var/ens directory is backed up to the install‐dir/var/ens.oldversion directory.
The backup is not changed. The existing ENS database might be changed if changes are needed to allow it work with the new version of SGD.
Note - Version 4.4 and Organizational Changes has details of some significant changes to ENS in this release. |
The SGD server configuration and the SGD global configuration are preserved but not backed up.
This configuration is stored in the install-dir/var/serverconfig directory.
This configuration is changed only if new properties files need to be added or new attributes need to be added to existing properties.
All the server resources files in the install-dir/var/serverresources directory are replaced.
These files are not normally edited as they control how SGD works.
Your SGD login scripts are preserved and backed up.
The install-dir/var/serverresources/expect directory is backed up to install‐dir/var/serverresources/expect.oldversion.
Your customized SGD files are backed up but they are not upgraded.
You can customize SGD by changing the files found in a standard installation, for example webtop themes, or by adding your own files, for example login scripts.
You have to upgrade these files manually.
When you install the new version of SGD, the installation program warns you if files exist that might need to be upgraded manually. See Upgrading a Customized SGD Installation for advice on how to upgrade these files.
How you upgrade SGD depends on whether you are upgrading an evaluation version or a fully licensed version of SGD, and on whether you are upgrading a single-server or multiple-server array. If you have customized SGD, you might have to upgrade your customized files manually.
If an SGD server does not have a license key installed, or belong to an array that is fully licensed, the SGD server is in evaluation mode. After 30 days the evaluation period expires and the SGD server is in expired evaluation mode.
Upgrade an SGD server in evaluation mode or expired evaluation mode by installing the next version of the software.
An SGD server that was in expired evaluation mode remains in expired evaluation mode after the upgrade. You cannot log in to an SGD server when it is in expired evaluation mode.
To license a server when it is in expired evaluation mode, you must either use the tarantella license add command to add a valid license key, or join the server to an array that is already fully licensed.
All SGD servers in a multiple-server array must run on the same version of the SGD software. This means that to upgrade an array, you must dismantle the array, upgrade each server independently, and then rebuild the array.
Make sure no webtop and emulator sessions are running in the array, including suspended sessions.
On the primary SGD server, detach the secondary SGD servers from the array:
# tarantella array detach --secondary server |
When a secondary SGD server is detached from an array, it loses its license keys and, temporarily, you might not be able to log in to SGD on this host.
Upgrade the primary SGD server by installing the new version of the software.
Upgrade the secondary SGD servers by installing the new version of the software.
On the primary SGD server, add the secondary SGD servers to the array:
# tarantella array join --secondary server |
When a secondary SGD server is added to an array, it gains any license keys installed on the primary SGD server.
When you upgrade, the SGD installation program preserves the customized files it finds, but it does not upgrade them. These files have to be manually upgraded. Two sets of files might need to be upgraded:
SGD Web Server files - Web application files and files used to configure the SGD Web Server.
SGD server files - Files used by the SGD server, such as login scripts, and files used for the classic webtop.
Two types of customized files might need attention after you have upgraded:
Customized files - Files found in a standard SGD installation that have been changed by an SGD Administrator.
Bespoke files - Files your organization created and added to an SGD installation.
When you upgrade, the SGD installation program backs up any customized SGD Web Server files it detects. Backed-up files and their locations are listed in the install‐dir/var/log/webservercustomized.list log file.
To upgrade the customized files, use utilities such as diff and patch to compare and merge the differences between the backed-up files and the files in the standard SGD installation.
The SGD installation program copies any bespoke SGD Web Server files it finds into the new installation. These files are not changed.
When you upgrade, the SGD installation program backs up the customized and bespoke SGD server files it detects and produces the following log files:
install-dir/var/log/upgraded.files - A summary of the changes.
install-dir/var/log/customized.list - A list of any files that an Administrator has edited or added.
install-dir/var/log/customizedchanged.list - A list of any files that an Administrator has edited that were changed by the upgrade.
install-dir/var/log/docrootjava.log -
A list of new or modified Java technology
files from the original installation.
Use these log files to identify the files that need to be manually upgraded.
Identify the changes made between SGD versions.
The customizedchanged.list log file lists the customized files that have to be manually upgraded. For each file listed in this log file, your system will have three versions of the file:
The old, customized version in one of the following directories:
The old, uncustomized version in the install-dir/etc/templates.oldversion directory.
The new, uncustomized version in the install-dir/etc/templates directory.
Use a utility such as diff to compare the old, uncustomized file with the new, uncustomized file. This highlights the changes made between SGD versions.
Apply the changes to the customized file.
Use a utility such as patch to apply the changes identified in Step 2 to the copy of your customized file.
Copy the upgraded customized file into the correct location in the new SGD installation.
Identify the changes made between SGD versions.
The docrootjava.log and customized.list log files list the bespoke files that might have to be manually upgraded.
The only way to upgrade bespoke files is to compare versions of the standard SGD files to identify changes that have taken place and then apply those changes to your bespoke files.
Use a utility such as diff to compare the old, uncustomized file with the new, uncustomized file. This highlights the changes made between SGD versions.
Apply the changes to the bespoke file.
Use a utility such as patch to apply the changes identified in Step 2 to the copy of your bespoke file.
Copy the upgraded bespoke file into the correct location in the new SGD installation.
This section describes how you upgrade the SGD Enhancement Module and the SGD Client.
|
Install the new version of the SGD Enhancement Module.
See How to Install the SGD Enhancement Module for Microsoft Windows.
|
When you upgrade the SGD Enhancement Module and you install the UNIX audio module, you might see a message that says the UNIX audio module is already running. This message displays because the SGD audio driver is currently in use and cannot be stopped. As the SGD audio driver has not changed in this release, this message can be safely ignored.
Install the new version of the Enhancement Module.
See How To Install the SGD Enhancement Module for UNIX or Linux Platforms.
See How to Log In to SGD.
Install the new version of the SGD Client.
See How to Install the SGD Client Manually on Solaris OS and Linux Platforms.
Copyright © 2008, Sun Microsystems, Inc. All rights reserved.