Best Way to Update Software With IPS in Oracle Solaris 11

Introduction

The saying goes, “Nothing’s constant except change,” and perhaps no one knows this better than system administrators. Change is difficult to embrace when systems, applications, and users are functioning well, but there are usually external forces—new features, bug fixes, faster hardware, and so on—that make change a desirable undertaking.

Change can bring big improvements, which is exactly the case with Oracle Solaris. While there are certainly features to love in Oracle Solaris 10, Oracle Solaris 11 Express brings new innovations that offer key benefits for the organization, but require changes in how you perform certain administrative tasks. Here’s a quick summary of the task and technology differences:

This article—the first in a series—discusses how to perform software updates in Oracle Solaris 11 Express, focusing on best practices that minimize risk. To update or install packages in Oracle Solaris 11 Express, you can assume an authorized role (for example, by issuing a pfexec or su root command) instead of explicitly logging in as root. Command examples in this article presume a privileged user (see “User Accounts, Roles, and Rights Profiles” in Getting Started With Oracle Solaris 11 Express).

Updating Software in Oracle Solaris 11 Express

Quick, what’s the name of the SVR4 package in Oracle Solaris 10 that contains user components for Apache 2.0? It’s SUNWapch2u, which is hardly intuitive when you’re searching for the correct software package to add.

That’s one reason why Oracle engineers decided to construct an improved, easier-to-use software packaging model in Oracle Solaris 11 Express. Key design goals for this release included simplifying software installation and maintenance and making these processes more reliable and less prone to error. The new Image Packaging System (IPS) is the underlying foundation that streamlines software management.

IPS spans the full software lifecycle: installation, updates and bug fixes, major upgrades, and software removal. Software updates load entire, well-defined sets of packages to address feature upgrades and/or bug fixes. In earlier Solaris versions, patches updated a variety of components and libraries throughout the distribution, and you often didn’t know if one patch would interfere with another. In contrast, there is no patching in Oracle Solaris 11 Express, and there’s no patch analysis needed to predict how a specific patch will affect other software components. Oracle Solaris 11 Express packages are integration-tested before release, eliminating much of the risk associated with updating OS software.

Where Do I Get Updates?

The IPS interfaces first check for updates for currently installed packages before retrieving them via the network. By default, interfaces check repository catalogs in the following locations:

• The default installation repository at pkg.oracle.com/solaris/release.
• The support repository in My Oracle Support. This repository is restricted to users with Oracle Solaris 11 Express support contracts, and it contains packages with the latest bug fixes. For this reason, a support contract must be purchased for production deployments. For information on how to access packages from this repository, see the article Support Repositories Explained [ID 1021281.1] (login required).

Administrators can mirror repositories locally, optionally adding application software packages. (See How to Copy an Oracle Solaris 11 Express Software Package Repository (PDF) or Brian Leonard’s Local Repository Mirror blog entry for instructions on how to set up a local repository.)

How Do I Initiate a Software Update?

To search for and install updates, Oracle Solaris 11 Express offers both a command-line interface, pkg(1), and graphical user interfaces, the Package Manager and Update Manager.

The command pkg update updates currently installed packages, and the command /usr/lib/pm-launch packagemanager --update-all launches the Package Manager GUI to perform a full update. In both cases, a minimized OS environment stays that way—only previously installed and “sticky” packages are updated. (The “sticky” attribute refers to a specific publisher, meaning that a package previously installed from that publisher cannot be updated from a different publisher, preventing malicious package substitution.)

The following table lists a few common pkg commands and SVR4 equivalents.

Note that Oracle Solaris 11 Express includes “package/SVR4” tools, so you can still install applications distributed in SVR4 format. Here are some other helpful pkg commands:

• Look for packages in remote catalog that match the pattern:

# pkg search -r gcc

• List contents of a specified package using remote catalog:

# pkg contents -r gcc-3

• Preview an installation without actually doing it:

# pkg install -nv gcc-3

• Update and automatically accept license agreements, if any:

# pkg update --accept

How Do I Verify that a Package Has Been Installed or Updated Successfully?

Installing or updating a package with the -v (verbose) argument provides feedback about the operation’s success or failure. In addition, the pkg verify command validates packages installed in the current image:

  # pkg verify -v gcc-3 
  Verifying: PACKAGE STATUS
  pkg://solaris/developer/gcc-3 OK 

What’s “Best Practice” for Updating Packages in Oracle Solaris 11 Express?

In Oracle Solaris 10, Live Upgrade acts as an administrative safety net that allows you to roll back to a previously saved OS environment in case something goes wrong. Similarly, Oracle Solaris 11 Express takes advantage of the underlying ZFS file system with its built-in snapshot capabilities that enable Boot Environment (BE) cloning.

Best practice in Oracle Solaris 11 Express:
Always generate a new BE prior to a software change.

Creating a BE preserves the current software state, allowing you to revert to it if there’s a problem after an update. In some cases, as in a full update, IPS automatically creates a new BE; in other cases you must explicitly create one.
Consider this example. Suppose you’ve downloaded the Oracle Solaris 11 Express text-install image, burned a DVD, and installed it on an x86 machine. Afterwards, you want to run the GNOME desktop manager (gdm) since your system is really a desktop, not a headless server.

The following commands create a new inactive BE called SLIM, mount SLIM, and install the slim_install package group (containing gdm) to the inactive, mounted BE.

	
  # beadm create SLIM
  # beadm mount SLIM/tmp/a
  # pkg -R /tmp/a install slim_install

The next command removes the group dependency on slim_install so that packages from the group can be treated individually:

# pkg -R /tmp/a uninstall slim_install

The following commands update the boot archive and GRUB and then unmount the SLIM BE (now that the installation is complete):

  # bootadm update-archive -R /tmp/a
  # beadm unmount SLIM

The next step is to activate the new BE for boot by setting SLIM as the default BE in menu.lst. The beadm list command shows BE status. In the following output, the BE solaris is now running (N) and SLIM will be the active BE after the next reboot (R):

  # beadm activate SLIM
  # beadm list 
   BE Active Mountpoint Space Policy Created
   -- ------ ---------- ----- ------ -------
   SLIM R - 4.57G static 2011-02-17 15:06 
   solaris N / 2.89M static 2011-02-10 09:47

Finally, a reboot launches the SLIM BE, and then after reboot, you can enable the GNOME desktop management (gdm) service:

 # reboot
  # svcadm enable gdm; exit

The same basic process can be used for almost any software update or package installation: Create a BE, mount it, modify the mounted image, activate it, and then reboot.

What If I Need to Revert to a Previous BE?

To roll back, activate the earlier BE and then reboot. For example, the following commands set solaris as the active BE upon reboot and then list the BEs:

  # beadm activate solaris
  # beadm list
   BE Active Mountpoint Space Policy Created
   -- ------ ---------- ----- ------ -------
   SLIM N - 4.57G static 2011-02-17 15:06
   solaris R / 2.89M static 2011-02-10 09:47
  # reboot

BEs are essentially ZFS snapshots. Since snapshots can share disk space, an inactive, cloned BE does not initially consume any additional space in the ZFS pool. As data within the active or mounted BE changes, it begins to consume space as data references become unique.

How Do Software Updates Impact Zones?

Currently, zones are not automatically updated when you update the BE that is the global zone. Instead, you must manually update non-global zones after rebooting to keep them in sync with the global zone. (A future article may discuss this; in the meantime, check the System Administration Guide: Oracle Solaris Zones, Oracle Solaris 10 Containers, and Resource Management.)

Final Thoughts

Periodic OS updates are a great idea, since they deliver the latest package fixes and OS features that maximize stability and security. One thought is to schedule operating system software updates coincident with the Oracle Critical Patch Updates that are released each quarter.

Oracle Enterprise Manager Ops Center doesn’t yet support Oracle Solaris 11 Express, but when it does, it will be an effective tool for managing operating systems, firmware, virtual machines, storage, and network fabrics—all from within a single, integrated console.

In summary, Oracle Solaris 11 Express uses the underlying functionality of ZFS to create a safe method of software updates. Just as Live Upgrade enabled safe upgrades in Oracle Solaris 10, BEs in Oracle Solaris 11 Express allow you to revert to a previous software state.

It bears repeating: Best practice is to always create a new BE before making software changes.

Revision 1.0, 04/28/2011