C H A P T E R  4

Upgrading to SSP 3.5

Before upgrading, review the SSP 3.5 requirements explained in Chapter 2 .


SSP Upgrade Process Title

The SSP upgrade process automatically updates SSP version 3.2. 3.3, or 3.4 to SSP 3.5. During the upgrade, SSP daemons are stopped if appropriate, existing SSP packages are removed, certain SSP files are archived, and the SSP 3.5 packages are added.

If you encounter problems with the upgrade to SSP 3.5, you can revert to a previous release of SSP. For instructions on switching back to a previous SSP release, see Chapter 6 .

Upgrading from SSP 3.2, 3.3, or 3.4 involves the following main tasks:

The following procedures describe the detailed steps for upgrading either a main or spare SSP from SSP 3.4 or from SSP 3.2 or SSP 3.3.


procedure icon  To Upgrade from SSP 3.4 to SSP 3.5



Note - If an error occurs during upgrade, use the pkgrm(1M) command to manually remove all the SSP 3.5 software packages that were installed and return to the beginning of this upgrade procedure. For details on removing packages, see Chapter 6.



1. If you have a dual SSP configuration, perform data synchronization and disable SSP failover as described in To Prepare for SSP 3.5 Upgrade or SSP Patch Installation .


Note - The data synchronization process backs up the main SSP configuration and restores it on the spare SSP.



2. On the main SSP, log in as superuser and change to the Tools directory:

ssp# cd base_directory/System_Service_Processor_3.5/Tools

where base_directory specifies one of the following:

3. If you have a spare SSP running SSP 3.4, stop the SSP daemons on the spare.

ssp# /etc/init.d/ssp stop

4. Back up the environment on the main SSP.

ssp# ./ssp_backup target_directory

A backup file named ssp_backup.cpio is created in target_directory . It is suggested that you rename this backup file so that you can identify the SSP release associated with this backup file.

5. Upgrade the SSP.

ssp# ./ssp_upgrade ../Product

During the upgrade, note the following:

6. Reboot the main SSP.

7. Upgrade the SSP software on the spare SSP by repeating Steps 2, 5, and 6 on the spare.

For Step 6, be sure to reboot the spare SSP.


procedure icon  To Upgrade from SSP 3.2 or SSP 3.3 to SSP 3.5



Note Note - If an error occurs during upgrade, use the pkgrm(1M) command to manually remove all the SSP 3.5 software packages that were installed and return to the beginning of this upgrade procedure. For details on removing packages, see Chapter 6.



1. On the main SSP, log in as superuser and change to the Tools directory:

ssp# cd base_directory/System_Service_Processor_3.5/Tools

where base_directory specifies one of the following:

2. Back up the environment on the main SSP.

ssp# ./ssp_backup target_directory

A backup file named ssp_backup.cpio is created in target_directory . It is suggested that you rename this backup file so that you can identify the SSP release associated with this backup file.

3. Upgrade the SSP.

ssp# ./ssp_upgrade ../Product

During the upgrade, note the following:

4. Restore the SSP backup file on the spare SSP.

ssp# /opt/SUNWssp/bin/ssp_restore backup_directory/ssp_backup.cpio

where the backup_directory is the directory in which the backup file resides. The SSP backup file is ssp_backup.cpio , unless you renamed the file as suggested in Step 4.



caution icon

Caution Caution - If you restore a backup file from SSP 3.2 or SSP 3.3, note that the $SSPVAR/data and $SSPVAR/ict directories are not restored, which prevents corruption of the hardware database. If a warning message tells you to run the autoconfig(1M) command, be sure to shut down your domains before running the autoconfig command. Otherwise, your running domains arbstop.



5. Reboot the main SSP.

6. Be sure that the floating host name is specified in the /etc/ssphostname file for each domain.

    a. From the main SSP, or from another workstation on the network, rlogin to the domain as superuser.

    b. Edit the /etc/ssphostname file to replace the host name of the main SSP with the host name of the floating IP address.

    c. Verify that the floating IP address and the floating host name are in the /etc/hosts file.

    d. Redirect console communication to the new floating IP address:

    # ps -ef | grep cvcd
    # kill -9 cvcd_pid
    # cvcd_path/cvcd

    where cvcd_path is /sbin under the Solaris 2.6 operating environment, and cvcd_path is /platform/SUNW,Ultra-Enterprise-10000/lib/ under the Solaris 7, 8, and 9 operating environments.

    e. For each domain, update the /etc/syslog.conf file to replace the host name of the former main SSP with the floating host name.

7. If you have other software that communicates with the main SSP, such as Sun Management Center, be sure to change the communication path (for that software) to the floating IP address.

8. Upgrade the SSP software on the spare SSP by repeating Steps 1, 3, and 5 on the spare.

For Step 5, be sure to reboot the spare SSP.