Solaris 11 Customer Maintenance Lifecycle

Hi Folks,

Welcome to my new blog which is all about the Customer Maintenance Lifecycle for Image Packaging System (IPS) based Solaris releases, such as Solaris 11.

It'll include policies, best practices, clarifications, and lots of other stuff which I hope you'll find useful as you get up to speed with Solaris 11 and IPS.  

Let's start with an updated version of my Solaris 11 Customer Maintenance Lifecycle presentation which I originally gave at Oracle Open World 2011 and at the 2011 Deutsche Oracle Anwendergruppe (DOAG - German Oracle Users Group) conference in N├╝rnberg.

Some of you may be familiar with my Patch Corner blog, , which fulfilled a similar purpose for System V [five] Release 4 (SVR4) based Solaris releases, such as Solaris 10 and below.

Since maintaining a Solaris 11 system is quite different to maintaining a Solaris 10 system, I thought it prudent to start this 2nd parallel blog for Solaris 11.

Actually, I have an ulterior motive for starting this separate blog. 

Since IPS is a single tier packaging architecture, it doesn't have any patches, only package updates. 

I've therefore banned the word "patch" in Solaris 11 and introduced a swear box to which my colleagues must contribute a quarter [$0.25] every time they use the word "patch" in a public forum.  From their Oracle Open World presentations, John Fowler owes 50 cents, Liane Preza owes $1.25, and Bart Smaalders owes 75 cents. 

Since I'm stinging my colleagues in what could be a lucrative enterprise, I couldn't very well discuss IPS best practices on a blog called "Patch Corner" with a URI of  I simply couldn't afford all those contributions to the "patch" swear box. :)

Feel free to let me know what topics you'd like covered - just post a comment in the comment box on the blog.

Best Wishes,



A quick look at IPS gives the impression that it would be simple enough to check pkg updates on a daily basis. But you must know how organizations are, especially those that are familiar with old patching strategies. I've been tasked with developing a "patch" strategy for solaris 11. So it would be great to hear from you on what you think would be a reasonable update strategy for those of us in entrenched bureaucracies. Perhaps keeping in mind that we have "test", "development", and "production" environments.

Posted by guest on February 22, 2012 at 08:41 AM PST #


Regarding checking pkg updates on a daily basis, you may wish to keep a local repository and review the changes. From my colleague, Albert White:

"Please see Copying and Creating Oracle Solaris 11 Package Repositories ( ) covers the main points about how to create your local repo.

Checking daily can be accomplished easily enough. Basically:
0. Once you have you local repo, take a zfs(1M) clone of it and set that clone up as your production repo. So now you have one staging and one production repo.
1. Check if there is an update from Oracle against your staging repo by running with pkgrecv(1)
2. If there is an update, take a zfs snapshot your staging repo, then update the staging repo. If you encounter an error you can rollback to the zfs snapshot.
3. Perform whatever testing is needed on this staging repo.
4. Promote the staging repo to be the production repo.

Using zfs and pkgrecv allows you to easily manage all this and tailor it to specific needs. This is how we manage repos internally."

Regarding a patching strategy, please see the presentation in this blog entry.

Basically, the recommendation is to align with the quarterly CPU (Critical Patch Updates) schedule. We don't expect customers to deploy every CPU, but we recommend deploying ideally every 2nd one or however frequently you can manage it as the CPUs contain critical security (and other) fixes. This is similar to how the Recommended Patch Cluster would be applied to Solaris 10 and earlier systems. So the packaging system has changed, but the maintenance strategy remains similar.

The candidate CPU should be tested in your environment prior to deployment to ensure all your apps work. Ideally, this should include load/stress testing.

SRUs/CPUs primarily deliver bug fixes, so there shouldn't be any issues. If your apps only use published public interfaces, then we guarantee binary compatibility across not only SRUs/CPUs, but also Update releases and even major releases of Solaris.

Indeed, you can run Solaris 8 apps on a Solaris 11 system without issue so long as they use non-deprecated Public interfaces. BTW: We give a minimum of 1 year's notice of any old interfaces which we intend to deprecate.

So the only issues you should see in pre-deployment testing is if your apps (including 3rd party apps) are being naughty and using private interfaces which they are not supposed to be using. For example, a number of 3rd part multipathing products broke with Solaris 10 Update 10 because they were using a private interface which changed to fix a race condition in that Update release. But even such issues are normally when crossing an Update release boundary, rather than in a bug fix CPU/SRU release.

I hope this helps.

Best Wishes,


Posted by Gerry on February 23, 2012 at 03:23 AM PST #

Does IPS support parallel patching of zones ( similar to Solaris10 parallel patching feature of Zones)

Posted by martin francis k on March 27, 2012 at 12:05 AM PDT #

Hi Martin,

Apologies for my delay in responding - I hadn't seen your comment.

Parallel patching of Zones is not currently supported in the Solaris 11 11/11 release. But it is being worked upon.

Disclaimer on forwarding looking statements apply.

Best Wishes,


Posted by Gerry Haskins on June 21, 2012 at 09:57 AM PDT #

Hi Martin,

As you may know by now, parallel updating of Zones is now available in Solaris 11.1.

Best Wishes,


Posted by guest on April 15, 2013 at 02:56 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed

This blog is to inform customers about Solaris 11 maintenance best practice, feature enhancements, and key issues. The views expressed on this blog are my own and do not necessarily reflect the views of Oracle. The Documents contained within this site may include statements about Oracle's product development plans. Many factors can materially affect these plans and the nature and timing of future product releases. Accordingly, this Information is provided to you solely for information only, is not a commitment to deliver any material code, or functionality, and SHOULD NOT BE RELIED UPON IN MAKING PURCHASING DECISIONS. The development, release, and timing of any features or functionality described remains at the sole discretion of Oracle. THIS INFORMATION MAY NOT BE INCORPORATED INTO ANY CONTRACTUAL AGREEMENT WITH ORACLE OR ITS SUBSIDIARIES OR AFFILIATES. ORACLE SPECIFICALLY DISCLAIMS ANY LIABILITY WITH RESPECT TO THIS INFORMATION. Gerry Haskins, Director, Software Lifecycle Engineering


« October 2016