Patch Automation Tools

First of all, let me say that my personnel experience of Sun's patch automation tools is limited.  I work upstream from the SysNet and Services groups who produce most of Sun's patch automation tools, so I and my team mostly patch from first principles using the basic Solaris patch utilities, patchadd and patchrm.

My team does have some experience of working with some of the patch automation tools.  I've supplemented this with information from SysNet and Services folk.

Sun Connection 1.1.1 Satellite (a.k.a. UCE) and xVM Ops Center 1.0

The official Sun patching tool of choice is now xVM Ops Center, which contains an enhanced version of Sun Connection 1.1.1 Satellite Edition.

Sun acquired Aduva a couple of years ago.  Aduva has a track record of providing patch and update automation tools for multiple Operating Systems.

The next-generation Aduva-based tools are coming on stream. Sun Connection 1.1.1 Satellite is based on Aduva.  Note, "Satellite" has a completely different back end to the Sun Update Connection Hosted edition and Solaris Update Manager, which are based on PatchPro (see below).

I'm hearing good things about the Satellite.  I understand that its initial target market is customers with 50+ systems.

Sun Connection 1.1.1 Satellite Edition is based on Aduva Onstage and Update Connection Enterprise.   A central server (Satellite) at the customer site is used to analyze and update all attached client systems in a fully automated manner.  It builds upon a central Knowledge Database fed by Sun.  It covers the provisioning of patches, packages, config files and scripts.  It is available to customers who pay for it.

Sun Connection 1.1.1 Satellite provides a solution for customers primarily interested in patch and package provisioning.  There is a 10 minute demo introducing you to some of the key features of Sun Connection Satellite at, or alternatively there is a more detailed 32 minute demo at

Sun Connection Satellite is a component of the xVM Ops Center

xVM Ops Center is a merge of Sun Connection and N1SM.  Here's a BigAdmin article on Patching Solaris using Sun xVM Ops Center.  The monthly patch baselines referred to are the patch sets in the monthly EIS DVD release (see below).

For further information, please see the Sun Connection hub's Product Tour page on BigAdmin.


EIS stands for Enterprise Installation Standards and originated from Sun field personnel wanting to develop best practice installation standards for systems installed on customer sites.

EIS has proved extremely popular with Sun field personnel and approved partners.  It's widespread adoption was due to it successfully addressing a real need.  I view it's widespread adoption among field personnel and OEMs as proof positive of its efficacy.

The EIS patch baseline goes through QA testing prior to release.  The images installed by Sun's manufacturers on servers are also based upon the EIS patch baseline.  Additional testing by Sun's manufacturers plus feedback from the EIS user community raises confidence in the EIS patch baseline content further.  Since many system installations world-wide use the EIS methodology, any inherent problems will quickly appear and can be dealt with.  In the event of there being issues with the EIS patch baseline recommendations are communicated to the EIS community.

This same EIS set of patches which are considered by Sun Field Engineers as best practice to install on a new system, can also be used to patch existing systems to the same patch level.  The EIS set of patches is based on the Recommended Patch Cluster for the Solaris OS with additional patches included by the Field Engineers for additional products and to address irritating issues which do not meet the criteria for inclusion in the Recommended Patch Cluster.

The EIS patch baseline covers Solaris and other products such as SunCluster, SunVTS, SSP, SMS, QFS, SAM-FS, and includes patches which provide firmware updates.

EIS has traditionally only been available via Sun Services personnel but is now available direct to customers via Sun Connection Satellite.  This provides a good option to customers to patch to a defined and tested patch baseline.  See the Sun Connection blog for further information.


pca is a popular 3rd party tool developed by Martin Paul.  I've only ever heard positive feedback about pca.

pca is available from

To try out pca, just run this on any Solaris machine:

  $ wget
  $ chmod +x pca
  $ ./pca

pca is a good solution for customers interested in a simple, easy to use, patch automation tool.

smpatch, Update Manager, and Sun Connection Hosted Edition

smpatch is a command line tool and part of Solaris.   It allows customers to analyze and update Solaris with current patches.  For customers without a valid support contract,  only security and driver patches are available.  For customers with a valid support contract, all patches are available.

updatemanager is a GUI wrapper around smpatch and is also part of Solaris.  It can be used to see what patches/updates are available and to easily select the patches, which the customer wants to install. Again, for customers without a valid support contract,  only security and driver patches are available.  For customers with a valid support contract,  all patches are available.

Sun Connection - Hosted Edition is the internet portal version of  updatemanager.  The customer can register all their servers and  can schedule and review the installation of patches from a central portal.  This is only available to customers who pay for it.

The above tools rely on the "PatchPro" analysis engine to recommend patches to customers.

PatchPro utilizes what are called "Realizations".  These are listed in the patchinfo file in the top directory of a patch.  This allows the patch developer to associate a patch with one or more "Realization Detectors", which determines whether or not it is appropriate to apply a patch to a particular customer environment.  For example, a Realization Detector might only recommend a particular patch if the target system utilizes a particular piece of hardware or software, or if a particular service is enabled.  This provides fine-grained control on patch recommendations.

The vast majority of Realizations simply associate a patch to packages installed on the target system, in the same way patchadd determines whether or not to apply a patch.  That is, if the package name, package version, and platform architecture in the pkginfo file(s) in the patch match at least one package name, package version, and platform architecture on the target system, the patch can be applied, else not.

Errors in writing Realization Detectors cause patch automation tools which utilize the PatchPro analysis engine to occasionally recommend inappropriate patches.  This has impacted the reliability of PatchPro based tools.

Work is underway to write a generic realization detector to match patches to packages.  This will save patch creators from writing their own realization detectors for the common case, simplifying the process and reducing error opportunity.  Patch creators will still be able to write specific Realization Detectors where necessary.

See Instructions for Getting Started with Sun Connection's Update Manager and Sun Hosted solutions and Patch Manager 2.0 FAQs for further information.


TLP stands for Traffic Light Patching, and is another tool which was developed by Sun Service folk for Sun Service folk to address the need for Patch Automation.

TLP is not directly available to customers.  It's used by Sun Service personnel to determine the appropriate patches to be installed on a customer's system, including things like firmware patches.

TLP has a modular design.   It utilizes the concept of a "baseline" of patches chosen by the user, from the Recommended Patch Set, to the EIS patch set, to a user defined set of patches.  TLP allows a number of different patch analysis engines to be used to determine which patches from the "baseline" to apply to a particular target system.

TLP is popular with customers who use it, as it's reliable and works well. 

TLP was End-Of-Lifed (EOL'd) in September of 2006 and reached End-Of-Service-Life (EOSL) in December 2007.  However, a number of customers have been given extensions on TLP support for transition purposes. 

Sun Services Patch Recommendations 

Most European countries provide a service where customers can submit Explorer logs and the local Sun office provides back a patch bundle.  These services may use SRAS and TLP in the background.

Please contact your local Sun Services office for further details.

I believe the plan will be to consolidate these services into a consistent official worldwide service.


Defintly, PCA is a winner.

Posted by Sergiusz Pawłowicz on January 25, 2008 at 07:20 AM GMT #

After checking most Sun native command line utilities for patching, I've been happily using pca ( ) for the last three years or so.

It's slim, fast, more accurate than anything I've come across so far, with a 60 seconds learning curve, and presents its output in a format that is both complete and easy to read.

The most useful utility for Solaris (IMHO).


Posted by Loris Serena on January 25, 2008 at 07:31 AM GMT #

pca is definitly the best patch tool for Solaris that I have seen in the last years. It is a pity that Sun does not recognize the power pca brings to Solaris customers. With pca there is no need for any other patch tool. I would really hope that Sun cared about pca and did not change their interface every few weeks without mentioning.

Posted by Christopher Odenbach on January 25, 2008 at 07:40 AM GMT #

PCA is definitely the best tool for Solaris patch management. I am using it from the very early versions and it never disappointed me. Thanks to Martin for his great job!

Posted by Leon Koll on January 25, 2008 at 07:59 AM GMT #


Posted by Matthew Slowe on January 25, 2008 at 08:05 AM GMT #

Like many others, the best tool I've seen out there is PCA which is truly sad. That's not to denigrate Martin's work (which has been amazing) but more is a criticism of Sun itself. They have whole teams dedicated to this stuff and with internal access to the folks who write, package and test the patches they haven't been able to make something as well as a single individual who is outside their company.

Sun's solutions in this area have missed the mark, sometimes so badly that NOT patching was much preferred to patching with their tools. After seeing the long list of requirements for installing some of their many, many attempts at solving this problem, we gave up. We would just download the recommended and security bundle, add a few patches we knew we needed and install that on all our systems. We knew we were missing things, but we got about the 99% mark and that was good enough.

Once we discovered PCA, we were able to use it to build a custom bundle for each machine, then merge those into a single one so that were were more or less consistent across our environment.

I've heard talk (esp. at LISA07) that Sun is working on a whole new method of packaging patches and all I can say is it's about time. I hope that it provides robust methods for determining patch dependencies and provide faster patch install times.

Posted by Mike Myers on January 25, 2008 at 08:23 AM GMT #

"...They have whole teams dedicated to this stuff and with internal access to the folks who write, package and test the patches they haven't been able to make something as well as a single individual who is outside their company..."
Add to this a bunch of millions $$ that Sun paid for Aduva - an absolutely useless deal...

Mike is right, it's really, really sad.
My impression is that Sun is demonstratively ignoring the existence and effectiveness of PCA tool. That's bad.

Posted by Leon Koll on January 25, 2008 at 08:50 AM GMT #

Until Sun gets an equivalent to "apt-get update ; apt-get upgrade" like Debian, the PCA tool from Martin is the best game in town.

I particularly like that PCA can dump the list of needed patches in an HTML-friendly format so you can use it for system monitoring via Hobbit Server or the like.

Very nice tool, does the job, it is extensible, command line, scriptable, etc. Cant say enough about it. Written in the true non-bloatware style of the UNIXes of yore.

Posted by Matt Weatherford on January 25, 2008 at 09:03 AM GMT #

PCA rulez, the one-file-perl-script is doing the job much better than all other complicate packages.

Posted by Oren Amir on January 25, 2008 at 11:26 AM GMT #

We've tried many patch methods in our change-control-bound corporate environment -- dim sum, the Recommended bundle, Update Connection, UC Enterprise (Aduva -- the worst of all), Altiris, &c.

Nothing even comes close to what we get from Martin Paul's Patch Check Advanced. It's easily the best tool for managing Solaris patching. Give it a try, and see for yourself.

One modestly-sized Perl script does it all -- the caching proxy, the analysis, download, application, and reporting. It's all we need for our enterprise. The documentation is also quite good -- see Martin's website for more.

Posted by Craig S. Bell on January 25, 2008 at 11:27 AM GMT #

I have to agree with the other comments. Frequently, pca is the only way we can patch our Solaris 10 machines. Very very often, smpatch simply crashes and gives us screens of java stack traces.

Posted by Derek Morr on January 26, 2008 at 07:43 AM GMT #

I am a total fan of pca. It saved me hours and hours of work and got me rid of many hours of fighting with a dead smpatch system.

Posted by Michal Bielicki on January 26, 2008 at 03:24 PM GMT #

PCA rocks. Sun should just start distributing it...

Posted by Paul B. Henson on January 27, 2008 at 05:08 PM GMT #

I have been using Sun equipment for about 20 years and was an employee for 12yrs.

Sun's patching tools have been really dreadful for several years. There is way too much complexity with far too many processes and interfaces.

It is rare that things work smoothly in this area, normally requiring lots of manual intervention. Inexplicable problems occur literally every few days on my SPARC and Sun X86 (V60) servers.

I have just discovered PCA and it is truly a breath of fresh air. Simple, easy to use and actually seems to WORK. Having just batted yet again for a couple of hours today with more new SunConnection issues, I am certainly going to dump all the Sun stuff and stick with pca/patchadd/patchrm.

I am puzzled why Sun continues to put layers upon layers of "stuff" that is fragile and complicated when third parties can come up with a Perl script that does 95% of what most administrators actually need.


Posted by Dave Kerr on January 27, 2008 at 11:05 PM GMT #


I'll totally agree. I've been using PCA for about 2 years and still be totaly hooked.
@Martin if you read this
Please keep up the good work!!



Posted by Alex Hofmann on January 27, 2008 at 11:28 PM GMT #

I'm always amazed at how easy it is to run up2date on my Redhat Linux server compared to the patching tools I've used on Sun. How can a company with so many resources and so much history in the field have such poor patching tools?

I run pca on my Sun boxes now and it works spectacularly. Even if Sun comes out with a new patching tool, I probably won't even try it until I hear months of good comments about it.

Posted by C Becker on January 28, 2008 at 08:04 AM GMT #

Patching multiple sun machines is never fun, but PCA has made the job much more tolerable. Kudos to Martin for simplifying the task.

Posted by Judy Gaukel on January 28, 2008 at 10:31 AM GMT #

pca is simply brilliant, especially when it comes to patching systems that do not have internet access.

The ability to run it against the 'uname,pkginfo and showrev' files of another machine to build patchsets is pure magic.

It is like a fine wine. it seems to improve with age. :-) .

Posted by Ashley Krelle on January 28, 2008 at 06:23 PM GMT #

I have been recently involved in a patch management policy and implementation for more than 300 servers, and PCA ( seems to me like the best patch management option out there. It is even better than all the tools I have also worked with on other operating systems. Definitely, if SUN wants to accomplish something practical, they'll need to follow on PCA steps.

Posted by Andres A. Flores on January 29, 2008 at 05:01 AM GMT #

I also recommend PCA over anything else. It is so easy to manage and Martin Paul is quick to respond to any issues that could arise. Sun should consider paying Martin a good amount of money and make PCA their default for patch updates.

Posted by David Coronel on January 29, 2008 at 06:35 AM GMT #

PCA has simplified the patching process for Solaris servers! Thanks for the awesome tool, Martin.

Posted by Albert Lee on January 29, 2008 at 02:39 PM GMT #

I find it hard to believe that there are people that consider even consider Sun' patching tool to be a real alternative to pca. To me it is a no-brainer - pca is _the_ winner.

Posted by Cyril Plisko on January 30, 2008 at 06:18 AM GMT #

smpatch is called smpatch because it is so \*painful\* to use.

Even after you navigate through the tens of packages it requires to be installed, you then have to get the thing working. It's inherently optimistic: apparently there are no security updates available - again! It lies. There are security updates - I can see them on Sunsolve, and I can see them with pca.

pca is infinitely better. It does everything a patch manager should do:
\* Self-contained
\* Shows me updates of a given category (all updates, security updates, recommended updates)
\* Downloads them
\* Installs them

"Self contained" is \*important\*. If I have a minimal server, I shouldn't have to install fifteen packages just to get security updates.

This blog says:
"pca is a good solution for customers interested in a simple, easy to use, patch automation tool."
Forget that: pca \*works\*. Shame on you Sun!

Posted by Simon B on January 30, 2008 at 06:46 AM GMT #

I stumbled on this site while trying to find out what \*exactly\* Sun has done to sabotage pca (once more). All I know so far is that the download url for patchdiag.xref no longer works. Worse: not even the download url shown in the status bar of my browser works with wget; it would seem that Sunsolve now requires that session cookie they give you upon "acceptance of the terms and conditions" in order to download patchdiag.xref or something... :(((

Which means that Sun has just broken the one and only functional and reliable patch atomatization tool we have - pca. Thank you Sun! >_<

While I understand that there are tons of "political" reasons why Sun cannot /officially/ support the use of pca I would like \*you\* to understand \*this\* \*one\* \*thing\*:

Whatever Sun's marketing nutballs may be stating to the contrary in their regular SWOT-analyses: SOLARIS' CURRENT PATCH MANAGEMENT FACILITIES DON'T QUALIFY AS A "WEAKNESS" OF SOLARIS BUT RATHER AS A DOWNRIGHT \*THREAT\*!!!

Wrt to patch management Solaris has put me through sysadmin horror stories unparalled by any other operating system I ever laid my hands on, including WinDoS and Irix before version 6.5. And even where Solaris patching tools do work as advertised they usually display all those "qualities" I loathe in Linsux-based OSes: quick and dirty ad-hoc designs that don't stand the test of real-world usage and are replaced in a roughly yearly cycle by the newest and hottest (and - needless to say - backward-incompatible) "ultimate solution" \*eg\*

I hear that remedy is being developed (or at least being designed; sry, I misplaced the url) but a solution that matches Sun's usual quality standards wrt to design and implementation (think ZFS) will take years to design, develop and deploy.


Sun, please don't force me to get a Netapp or EMC next time I need a new file server. Thank you.

Posted by Stefan J on February 01, 2008 at 05:05 AM GMT #

Thank you all for your comments on patch automation tools.

The overwhelming vote of confidence in Martin Paul's 'pca' tool is clear. Sun owes a big debt of gratitude to Martin - thank you Martin!

As I've mentioned, I work upstream of the SysNet and Services organization. I don't have control over the availability of patchdiag.xref or Sun's tools or policies in this area.

I have been passing your comments on to the relevant Marketing and Services folk and I will continue to do what I can to ensure that the right decisions are taken to support customers.

Your feedback does help.

Please be aware that there are a number of infrastructure changes being rolled out behind the scenes at the moment. I'm pinging the relevant folks to try to ensure that the changes do not adversely affect the customer experience.

Posted by Gerry Haskins on February 01, 2008 at 09:52 AM GMT #

PCA is definitely the hands-down winner. As an admin in large (440+) server telecom environments, it's the only tool that has consistently worked.

Frankly, Sun's tools just suck. They're slow, unreliable and unfeasible to use.

Now, is Sun would only, please for the love of Pete, STOP messing around with Sunsolve so that PCA doesn't have to have so many revs to keep up. I mean for crying out loud, why does Sunsolve have to be fiddled with so much, it's ludicrous! Every freaking few months, when I try to update my jumpstart patches, I have to wait until Sunsolve gets fixed yet again when they break it so PCA has problems working.

I swear, it's about as brain-dead as Sun's decision to axe the x86 version of Solaris was. Come on, Sun, wake up and get with the program!

Posted by Allen Eastwood on February 04, 2008 at 03:53 PM GMT #

Gerry, thank you for listening and responding. I look forward to using the new SSMSC, and I will give it a thorough test, as soon as it becomes available. See for more.

A postscript to my earlier comments:

Indeed, an important part of what makes "pca" so useful is the fact that Martin is quick to test and release a new version, every time that SunSolve changes the (seemingly arbitrary) patch download policies.

Even if you have an active SOA, try browsing SunSolve, and search for a patch revision that hasn't been released yet. This is often an issue, but today, SunSolve replied with this topper:

"This feature is no more supported, however you can use OneSearch alternatively"

No, really -- a bit amusing, but please note that I received a prompt and polite response from the SunSolve team, regarding a fix.

Posted by Craig S. Bell on February 04, 2008 at 04:38 PM GMT #

pca is by far the simplest and most elegant solution.

I just wish that SUN would stop breaking its patchdiag.xref download, and many other "enhancements" that interfere with pca.

I just hope that SUN never, never puts their hands on pca. Otherwise, a great tool will be lost.

Thank you Martin.

Posted by Ricardo Fitipaldi on February 06, 2008 at 08:46 AM GMT #

After several years struggling to get Sun tools like smpatch and patchpro to work and wondering what I was doing wrong, I happened upon pca - and it worked first time and every time without a fuss. It really is the best Solaris patching tool around.

Posted by Richard Mayebo on February 06, 2008 at 06:23 PM GMT #

We've used them most of the patching tools over the years, including some home-grown shell scripts. PCA is wonderful -- it gets the job done, it works on hosts behind firewalls with essentially no "outside" connectivity, and it works well on older, slower machines as well. On my SB15090 it takes about 15 seconds to check patches, and about a minute on my old Ultra 1/170E (with 2,429 patches installed currently).

Posted by Jeff Wieland on February 06, 2008 at 07:36 PM GMT #

I'm curious to know if PCA is able to manage with conditional patches on Solaris 10 such as 122660-10 needed by 120011-14 only if zones are installed...

Posted by Etienne B on February 07, 2008 at 03:58 AM GMT #

The fact that 120011-14 (indirectly) requires 122660-10 is a very special case. It's described on

While pca \*could\* resolve this situation by recommending and installing 122660-10, I decided against it. 122660-10 is marked as OBSOLETE; I don't want to make pca override Sun's decision in that case. It should have been fixed by a new revision of 120011 or 125547 instead, but that never happened.

Posted by Martin Paul on February 07, 2008 at 04:33 AM GMT #

God bless pca.

Unfortunately it is too late for Solaris here. Problems patching a large number of servers mean that we have decided to switch to Redhat where up2date is making things much easier.

Posted by Jeremy Bates on February 22, 2008 at 04:40 AM GMT #

I too struggled with Sun's patching tools, especially Sun Update Connection (SUC -a well chosen acronym for this product) until somebody on the MailScanner mailing list recommended pca. Thank you, Martin! It has saved me hours of frustration!. Before pca, I constantly had open support calls into Sun on SUC, some dragging on for months, never with any resolution. The whole lot of the SUC team in the UK should be fired.

Like Jeremy Bates' comments, it is too late for Solaris here too. The continuing patch issue problems before pca means that we too have decided to move our servers to Redhat.

Posted by Jeff Earickson on February 28, 2008 at 07:03 AM GMT #

I find pca to be a superior Solaris patching tool.

Posted by Alex Maidak on February 28, 2008 at 08:01 AM GMT #

pca is a life saver, Sun better keep patchdiag.xref alive and well!

Not only it is the best thing out there, sadly so as many have pointed out, but IT WILL BE THE BEST THING OUT THERE FOR YEARS TO COME. If history is any indication, then the odds of Sun actually understanding what we need and delivering it are slim. Instead, SSMSC will probably be another unreliable monster.

Posted by Christophe Kalt on February 28, 2008 at 08:36 AM GMT #

We use PCA to patch our Sun systems, and have found it to be simple to use and most reliable. We gave up on using other solutions simply because of the lack of reliability, usability, and/or dependency problems. We actually ran some servers unpatched for a while before we found PCA! It definitely gets my vote.

Posted by John Horne on February 28, 2008 at 01:26 PM GMT #

Autonomic Software has release a version of ANSA for SUN Solaris which includes a single agent for patching, asset management and configuration management.

Posted by Darren Nicholson on February 28, 2008 at 03:13 PM GMT #

I find PCA faster and more reliable for patching my solaris 10 system on my ultra 24 workstation. (smpatch and the update GUI
are no replacement).

Posted by Mario Medjeral on March 04, 2008 at 01:52 AM GMT #

pca is the best!

Posted by ak on March 05, 2008 at 01:07 PM GMT #

God save the pca ! ;-)

Posted by przemol on March 06, 2008 at 12:12 AM GMT #

PCA is only patching solution which works as expected in any cases, including error cases. You can even propose new functionality to it.
It is fast and simple.

Posted by Pietari Hyvarinen on March 10, 2008 at 12:16 AM GMT #

Sun needs to add PCA to Solaris and get rid of smpatch. It's totally unreliable.

Posted by JC on April 23, 2008 at 10:17 AM IST #

Sun again broke the patchdiag.xref file today that it doesn't work with pca any more :-( I wish someone at Sun would test changes for compatibility with pca. Most of our customers rely on PCA instead of the Sun tools, so these kinds of bugs \*do\* fall back to Sun.

Posted by Dago on May 06, 2008 at 07:22 AM IST #

The problem with the broken patchdiag.xref file, which suddenly included HTML tags, is fixed in the current official release of pca (20080507-01).

Posted by Martin Paul on May 07, 2008 at 02:03 AM IST #

It simply great tool , installs many patches within shortime.This tools helping us on saving downtime for production servers for patching on regular basis.

Simply Great!
Simply Great!

Posted by Gangadhar on May 14, 2008 at 08:45 AM IST #

I am a new user of pca and so far am very impressed with the ease of use. I am totally amazed at the speed that comments/changes are incorporated to improve functionality.

Posted by Kevin Bliss on May 16, 2008 at 10:03 AM IST #

I just found, that Sun has noticed the existence of pca, which is great:-)
BigAdmin Newsletter: May 2008
Topic: Patch Management Best Practices
Enda O'Connor, April 2008

pca is a wonderful tool.
many thanks,

Posted by Thomas Bleek on May 26, 2008 at 05:06 AM IST #

I'm not sure what is going wrong here:
Solaris 9 Sparc with two BEs (LU)
I have patched (with pca) the inactive BE with lumount BE
pca -R /.alt.... -i ....
everything went fine, but the file /reconfigure was created in the ACTIVE BE, not in the inactive, patched BE.

Did I miss something with pca and Live Upgrade???

I this is the wrong place to ask, please give me a hint.

Posted by Thomas Bleek on May 26, 2008 at 05:11 AM IST #

Hi Thomas,

please subscribe to the pca users mailing list at to state questions about PCA.

Best regards

-- Dago

Posted by Dagobert Michelsen on May 26, 2008 at 05:26 AM IST #

Thanks Thomas!

FYI, Martin Paul has fixed the 'pca' issue you refer to in the current development release. Thanks Martin for the rapid response!

Best Wishes,


Posted by Gerry Haskins on May 26, 2008 at 07:47 AM IST #

One of the best Sun utility I've used for patch management.

Posted by Efren Villa on September 19, 2008 at 07:54 PM IST #

PCA is the only reasonable way to patch Solaris.

Posted by Eric Ziegenhorn on October 10, 2008 at 04:19 PM IST #

PCA is the best :-) patch management tool for at least three reasons:

#1 - It's simple and free (no registration and bla bla bla...)

#2 - If you see the code to improve!

#3 - Run fast with more computational resource and easy to automate.

I plan to sponsor on my blog and translated into Italian.


Posted by Michele Vecchiato on January 15, 2009 at 04:20 PM GMT #

never use any other patch management tool except pca.

Posted by chrislo on January 25, 2009 at 08:54 AM GMT #

PCA is the only way to up to date my Solaris servers.

With very early release - I use only PCA. Other patching tools from Sun is too bogus for daily/weekly updates.

Moreover, with PCA I've never ever goes my systems to unstable state. Single-mode kernel updates (in most cases) installed in multi-user correctly.

Posted by Yuri on February 10, 2009 at 10:14 AM GMT #

I had the dubious honor of inheriting ~50 Solaris machines from a sysadmin who didn't patch at all. For, in some cases, more than three years. My first act upon receiving them was to try to find a way to add, at bare minimum, the necessary security patches.

Our RHEL machines are connected to an RHN Satellite, which provides real-time reports on patch levels and allows you to administer a patch to multiple machines, machine groups, or even your entire organization at once. If a new critical security update is released, you can \*immediately\* see which machines are affected.

While PCA does not do these things, I have managed to use it to emulate much of that functionality with nightly scans of patch status. I can parse that output to determine which machines are affected by certain issues. Nightly emails are then sent to affected Sysadmins and/or users.

The design decisions behind PCA, and the ability to do a system scan with the output of three commands installed on every solaris box (uname, showrev, pkginfo) are what made this possible. Bloated and buggy "patch management" software from Sun would never have allowed that functionality to be added.

As a side note, PCA, similar to RHN Satellite, will download and cache patches (I cache them on an NFS share), so machines not able to contact SunSolve can be easily patched.

As a final note, directed at the Sun employees working on such matters, consider the following. In many ways, I see patch management in Solaris as paralleling SVM. Solaris Volume Manager is a piece of crap. It is so bad that most admins seem to prefer a VM that isn't even provided by Sun. SVM's command-line UI is almost unusable, and the design decisions behind it are reminiscent of the late 1970s. Then, zfs came along and took over the problem from \*another angle entirely\*. Now you have a zpool and don't need to deal with svm at all. Similarly, patch management on Solaris is stuck in the 1970s. Sun should stop thinking of the issue as \*patch\* management, and should instead think of it as \*package\* management. Instead of having a base package + patches, you should have an integrated system where "patches" are simply updates to the base package. Reference RPM, dpkg, conary, etc. From that base, the problem becomes manageable, as you only need to ensure that your packages are the same version as the current, a trivial exercise.

Posted by jon on February 17, 2009 at 01:15 PM GMT #

Hi Jon!

I agree that Martin Paul and friends have done a great job in making 'pca' an excellent and flexible tool.

Regarding your last point about "Sun should stop thinking of the issue as patch management, and should instead think of it as package management", this is exactly what is happening.

Please see the Image Packaging System (IPS) implementation in OpenSolaris. This will replace the 2-tier package and patch layers in current Solaris versions with a single packaging layer in future versions. Since IPS is being developed as part of OpenSolaris, there are opportunities for people like you to get involved in the design and development effort. See references to Image Packaging System (IPS) in my previous blog postings.

Best Wishes,


Posted by Gerry Haskins on February 18, 2009 at 03:16 AM GMT #

I wasn't aware that IPS existed, it is good to know that Sun is thinking about the problem, and I like the way they're approaching it now. I did clone the hg repo, but haven't had a chance to look at it yet.

Reading, it looks like the IPS project is still fairly new, even to OpenSolaris. Do you have any idea when a supported Solaris release will occur which contains it? Whether that is the ever-mythical Solaris 11, or an update to Solaris 10... we simply can't run production services on a community-supported operating system, especially not one not certified by any ISVs.

Posted by jon on February 18, 2009 at 04:26 PM GMT #

Hi Jon!

Firstly, let me state that I am not an OpenSolaris expert, but here's my current understanding...

There's no published date yet as to when a fully supported "Solaris" release using IPS will appear. It won't be a Solaris 10 Update - to change the packaging architecture mid-stream in Solaris 10 would be too disruptive - so think of it more as "Solaris 11" although that may not be the actual name.

The first couple of OpenSolaris releases were primarily designed for use by Developers who want to contribute to OpenSolaris. Over the next couple of releases, expect to see the target audience being expanded to ISVs and production customers. You can buy support for the current OpenSolaris releases, so it is already supported. Support Repository Updates will be made available for each release (monthly I believe) to provide bug fixes for the current release.

There's a lot of ongoing work on IPS, so each successive OpenSolaris release will showcase new IPS functionality. The starting point was basic functionality needed for developers and ISVs. The focus is now moving towards the features that many production customers would desire.

Posted by Gery Haskins on February 19, 2009 at 02:14 AM GMT #

A few years back (Jan 2006), I tried the official tools "smpatch" and "Sun Update Connection Proxy", after much frustration I gave up and switched to pca.

This one simple tool (pca) rocks.

Posted by Alberto on March 21, 2009 at 04:03 AM GMT #

Request for enhancement.

We are using PCA using a control script we created.
Our control script runs under the userid of pca and has a UID of 1390.
We then use sudo to execute PCA with the user pca/1390.

However in the pca code there is a line that checks your id and asks if it
is '0'. If not pca exits and says you must be root. However since we are running as sudo we are effectively root, but do not have roots UID.

So we have to modify PCA from

if ($o{install} && ($< != 0) && !$o{pretend}) {

to this
if ($o{install} && ($< != 1390) && !$o{pretend}) {

So that means we cannot have PCA update itself cause when it does we need to go back in and change the code again.

The RFE is: have a command line option called --uid <a valid uid> that we can
use that will check if you are uid of 0 OR if you are UID of <a valid uid>


Posted by Just Me on October 15, 2009 at 08:02 AM IST #

Hi "Just Me"!

'pca' is a free, community based tool, and doesn't belong to Sun. See

I'll pass your request on to Martin Paul, 'pca' author and all-round good guy, and ask him to post a response here.

Best Wishes,


Posted by Gerry Haskins on October 15, 2009 at 08:26 AM IST #

@Just Me:

That's a good point. With sudo and RBAC it's not a safe assumption that UID==0 is a requirement to install patches with "patchadd".

As a solution for your problem I've added a new option "--norootchk", which simply skips the UID check when --install (or --safe) is used. If you really want to check for a specific UID, this is better done in your wrapper script.

The new option is already available in the current development version of pca, which you can get from:

Thanks for the feedback,


Posted by Martin Paul on October 16, 2009 at 01:32 AM IST #

Please forgive the tear stains on this post. I can't help it. PCA just makes me SO happy. THANK YOU. Martin, may happiness pursue you more vigorously than Blackboard pursues competitors.

Posted by Doug Simmons on April 01, 2010 at 02:20 PM IST #

I got hooked on to PCA few years ago and have been using it to patch hundreds of servers without issue. I have simply loved it and have no words to express my gratitude for such a simple, no-hassle, easy to use application. It addresses all my concerns. Having used it for so many years for free I think the least that I owe to Martin is this note.

Posted by Pankaj Govil on November 21, 2011 at 07:32 AM GMT #

Post a Comment:
  • HTML Syntax: NOT allowed

This blog is to inform customers about patching 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 Engineer


« July 2016