Cover V11, I04

Article

apr2002.tar

Upgrading to Solaris 8

Peter Baer Galvin

Solaris 8 is getting a little long in the tooth. It has been out and stable for more than a year. Most applications are certified and supported on it by the vendors. And yet many sites are still running Solaris 2.5.1, 2.6, and 2.7. There are many reasons to move, and many reasons not to upgrade. A major hurdle to performing the upgrade is the sheer complexity (and risk) of system upgrades. This month, the Solaris Companion explores the reasons to stay put and the reasons to upgrade, and provides detailed how-to-upgrade instructions.

Overview

Solaris 8 is inarguably the best Solaris release generally available. And yet many sites are not running it. Some have good reasons. Others have, well, less-good reasons. Should you decide to perform the upgrade, there are many, many aspects to consider. This month's Solaris Corner looks at the pros and cons of upgrading. A complete and detailed how-to guide completes this column.

Reasons to Live in the Past

Although Solaris 2.7 and below are not state of the art, they do work very well. If you have systems running those releases, and they are doing well, it is difficult to find the motivation to move forward. There is something to be said for the old adage, "if it ain't broke, don't fix it."

There is one major reason to not upgrade your systems: legacy applications. Many sites are limited to older operating system releases, or having to run and maintain a variety of releases because the applications are simply not supported on Solaris 8. Sometimes the source of the code no longer exists, so there will be no support. Sometimes the code is homegrown or home-modified, making the move to a new release of Solaris a systems and programming challenge.

At other times, corporate or department policy decreases upgrade enthusiasm. Some facilities require that one revision of the operating system be the standard. There, rather than facing individual upgrade tasks, administrators get to plan and execute upgrades of all the Sun machines in the environment.

Reasons to Get Back to the Future

With that said, there are many good reasons to move forward and upgrade to Solaris 8:

  • Solaris 8 is the latest current release.
  • It has the best performance of all Solaris releases.
  • It has the best support from third parties, especially for devices and their drivers.
  • It is arguably the most stable Solaris release.
  • It is arguably the most secure standard Solaris release.
  • Trusted Solaris 8 can be used to improve security over other Solaris releases, and is easier to install and use than other Trusted Solaris releases.
  • It is the most supported (by Sun) Solaris release. Other releases have support discontinued as they age.
  • Sun guarantees that customer-written applications that conform to the Solaris ABI are binary compatible with Solaris 8.
  • Solaris 8 is the only Sun operating system that runs on UltraSPARC III-based systems, such as the SunBlade 1000, 280R, 880R, and the SunFire servers.

If you are now convinced to move to Solaris 8, the only decision remaining is when to do so. Sun is working on a "liveupgrade" feature that is supposed to allow easy upgrading (and downgrading) between Solaris 2.6, 2.7, and 2.8. Live Upgrade has been gestating since before July 2000 (when a Sun blueprint about it was published). It is now in release 2.0. Unfortunately, I have yet to find anyone that has used it (successfully or otherwise). So you may want to try Live Upgrade in your QA lab, or wait for it to be more stable and feature-full, or go ahead and upgrade without it. Look for Live Upgrade to be discussed in a future Solaris Corner.

Solaris 8 Upgrade Implementation

Actually, there are two paths to take to Solaris 8. One is to perform an "upgrade" in which packages installed on the system are removed and replaced with Solaris 8 equivalents. The other is to save the system configuration and non-system files, perform a new Solaris 8 installation, and then restore the configuration and non-system files. In many ways, the fresh install is an easier path, but for complex systems, or ones where change control has not tracked configurations and files needing saving, upgrading is the only way to proceed.

Before the gory details are revealed, a word to the wise: Upgrading a production system is among the most complicated tasks a systems administrator can perform. If possible, test your upgrade methodology in a non-production environment. Also if you are a relatively inexperienced administrator, consider getting input from senior administrators, or having them work with you. A failed upgrade can be a nightmare to diagnose and recover from!

Here, then, are detailed steps for performing a manual upgrade to Solaris 8. Some of these steps may not be needed, depending on your requirements and system status. And some extra steps may be needed because every system and facility varies in implementation detail. I've tried to make the list as complete as possible, so many steps are available for consideration.

Planning

1. You may want to visit:

http://www.sun.com/bigadmin/content/misc/upgradeworksheet.html
which is a worksheet that can be used per machine being upgraded. It's a good place to record all of the configuration details that you may need to perform the upgrade (or recover from a failed upgrade).

2. Consider business requirements, limitations, and risks. Is there a limited window of time during which the system can be down? What are the risks of the system not being back up within that window, and how can they be minimized?

3. Determine the recoverability of the system. Are backups current? Have restores been tested recently? How long would it take to restore the system from backup tapes? Do not proceed without a valid set of up-to-date backups!

4. For each application running on the target server:

a. What is the version of the application?

b. Is the application certified/supported on Solaris 8?

c. If so, is it the version that is currently running?

i. If so, proceed with analysis of the next application.

ii. If not, determine the cost, effort, and risk associated with upgrading the application. Can the application be upgraded on the current operating system? If so, that would limit the disk of upgrading to Solaris 8 and then upgrading the application.

d. Create a test plan for each application, such that its functionality can be determined after the upgrade completes but before the system is handed over to the users.

5. Read the release notes and other up-to-date documentation (e.g., sunsolve.sun.com) about the Solaris release to be installed. Make sure all installation criteria are met and that no open issues are pertinent to your system.

Create the Upgrade Plan

1. Check the firmware levels of all systems components (e.g., with prtdiag). If any are out of date, add that firmware upgrade to the plan. It is a good idea to save all firmware that gets installed on your systems. Having the currently installed firmware as well as the newly released firmware allows for restoration to the current system state.

2. Prepare a back-out strategy to allow resumption of operation of the system should the result of the upgrade not be desirable. The plan could involve restoring from tape, for example. A better method is to have enough spare disk space to create a bootable copy of the current system disk. If the upgrade goes badly, a boot from the alternate copy may be just the ticket home. (See for example the Solaris Corner about "Manual Mirroring" at http://www.samag.com/documents/sam0107j). As mentioned above, be sure to test any back-out method.

3. Is the root disk mirrored with disksuite? If so, add undoing and redoing the disksuite mirroring to the plan.

4. Is the root disk "encapsulated" by Veritas Volume Manager? If so, add execution of the Veritas pre- and post-upgrade scripts to the plan. (See the Veritas VM documentation if upgrading this kind of system.)

5. Have the currently installed Solaris on CD available in case it is needed.

6. Plan the upgrade itself, based on the test upgrade performed above. This actually tends to be the easiest step, due to all of the work done in the other steps. The steps likely include:

a. Insert Solaris 8 release CDROM.

b. Halt the system, and boot from the CDROM.

c. Answer the asked questions based on questionnaire information.

d. Reboot from upgraded operating system disk.

e. Check the EEPROM "boot-from" variable to assure that it is correct.

7. If any applications are going to be upgraded after the Solaris 8 upgrade, have their CDs ready, along with the implementation and back-out plan.

8. For all applications, have their test plans ready.

9. Execute and save the results of system status commands so that they can be re-executed after the upgrade and compared for problem detection:

cat /var/adm/messages
prtdiag -V
ps -elf
df -k
iostat -x 5
vmstat 5
ls -lR /dev
ls -lR /devices
10. Copy important files to a disk that will be unaffected by the upgrade. Make manual copies of the files: /etc/system, /etc/passwd, /etc/group, /etc/shadow, /etc/vfstab.

11. Create a project plan timeline for implementation steps, downtime, back-out plans, testing, and so on.

Implement the Plan

After the extensive planning that was performed above, the actual upgrade is a step-wise implementation of that plan. It should go smoothly, and the result should be a system up and running with Solaris 8, with the disk mirrored if it had been before, and with all applications certified to run and be supported.

The major steps are:

1. Implement the testing plan.

2. Implement the backup plan.

3. Implement the upgrade plan.

4. Implement the testing plan.

If the tests failed after the upgrade, or some snag prevented the upgrade from completing, then the implementation of the back-out steps should have gotten you back to your original system configuration.

Post Implementation

After the implementation is completed, it is wise to run the set of system status commands again and compare them to the previous results, to capture system state and look for problems. Especially check /etc/system to ensure that the values set there match those previously there (keep in mind that the newer release might add new variables to require the disabling of old ones).

Finally, perform a full backup of the upgraded system, and set it aside, so you have a canonical copy of the system state post-upgrade. Also, be sure to document what you did, and the state of the system, for emergency use or for the entertainment of your fellow systems administrators.

Conclusions

I hope this information will prove useful as you decide what to upgrade, when to upgrade it, and how to upgrade it. Also, Sun is providing quite a lot of support for Solaris 8 adopters. Check out http://www.sun.com/software/solaris/programs/adoption/index.html for blueprints, certified applications, a solutions catalog, and a lot more.

Acknowledgements

Thanks to the system architects and system engineers at Corporate Technologies (http://www.cptech.com) for input to this column and testing of the methods described here.

Peter Baer Galvin (http://www.petergalvin.org) is the Chief Technologist for Corporate Technologies (www.cptech.com), a premier systems integrator and VAR. Before that, Peter was the systems manager for Brown University's Computer Science Department. He has written articles for Byte and other magazines, and previously wrote Pete's Wicked World, the security column, and Pete's Super Systems, the systems management column for Unix Insider (http://www.unixinsider.com). Peter is coauthor of the Operating Systems Concepts and Applied Operating Systems Concepts textbooks. As a consultant and trainer, Peter has taught tutorials and given talks on security and systems administration worldwide.