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.
|