Stricter Solaris patch entitlement implementation roll-out commencing this week

I've updated this blog entry to avoid causing unnecessary confusion with the current patch entitlement policy now that Oracle has acquired Sun.  

The Solaris patch entitlement policy is available on

BTW: It's important to remember that hardware warranties only provide access to Firmware and hardware driver patches.   Hardware warranties do not cover software support or access to other Solaris patches.


Quoting the PCA mailing list: "The patchdiag.xref file currently only contains information about the most current revision of each patch. For pca to determine the set of missing security patch revisions, it would be necessary to have information about the last security revision of each patch as well. There are no plans for Sun to add this information to the patchdiag.xref"

This is very bad news for the Solaris users community. I understand times are tough, but if Solaris is to compete with the FOSS alternatives, Sun should seriously reconsider this move. It's not going to go down well with Solaris users and may make people reconsider choosing Solaris over alternatives.

Posted by Alasdair Lumsden on January 08, 2009 at 01:44 AM GMT #

I totally agree with Alasdair. It's a bad idea.

Posted by Remy Zandwijk on January 08, 2009 at 02:39 AM GMT #

All security fixes will continue to be available to customers without a support contract. That is not changing.

In the current phase of the Solaris patch entitlement implementation, all revisions of patches which contain security fixes remain free.

In the next phase, which will be rolled out later this quarter, only the specific patch revisions which introduce new security fixes will remain available to customers without a support contract. Subsequent revisions will not be available to customers without a support contract unless they too introduce a new security fix.

Since 'patchdiag.xref' only lists the latest revision of patches, 'pca' users who do not have a valid Sun support contract will need to download security patches while they are current (i.e. not yet superceded by a later entitled patch revision).

All patch revisions, including old revisions, will continue to be accessible on SunSolve.

Posted by Gerry Haskins on January 08, 2009 at 04:46 AM GMT #

I think the point of the previous comment writers is not that the patches won't be available, but that there will be no automated method to ensure a Solaris system is patched with all of the relevant security updates.

Many of us feel that the pca utility is the only "sane" way to manage patches. By not adding a field to the patchxref file that indicates the last version of the patch that did include a security fix, we lose the ability to generate a report of missing security patches on the machine. As a previous comment said, this makes keeping a Solaris box up to date with security patches much more cumbersome than competing Linux or Windows platforms. I don't have to read through archives of security bulletins to determine exactly which patches I need, I can just run one command or Windows Update and be sure I have all security patches. PCA gave equivalent functionality to the Solaris universe ('pca -d missings', for example, to just get missing security patches) but it sounds like this will no longer be a viable option.

Posted by Matthew Wilson on January 08, 2009 at 10:29 AM GMT #

I do not have any problem with the stricter policy: obviously Sun have to make money!

I do have a problem with the utterly shambolic implementation of patch access.

I have a Solaris subscription (paid for out of my own pocket, as I don't want to abuse access I have via customers). The current one (I've had several) started in September. SunSolve will not recognise it as a valid contract number. I have made at least 3 attempts to get this fixed: the first resulted in me getting a temporary number which expired on 31 December; the second in me getting the correct number, still expiring on 31 December, and the current attempt has resulted in me being told that subscriptions do NOT entitle me to download patches. I have now spent considerably more in my time trying to get it to work than the wretched subscription cost me.

This kind of Kafkaesque nightmare is driving people away from Sun, especially smaller customers who do not have the clout to just force Sun to fix things.

Posted by Tim Bradshaw on January 08, 2009 at 12:29 PM GMT #

Hi Tim!

The issues you are seeing with your contract are unrelated to the patch entitlement implementation.

I apologize on behalf of Sun for the issues you are encountering.

I will pass on your comments to the relevant SunSolve support folk and ask them to assist you.

Best Wishes,


Posted by Gerry Haskins on January 09, 2009 at 08:31 AM GMT #

I am aware of a number of sites that are currently Sun, at least to a degree, but are considering a move to or an expansion of their Linux capability. Sun's overall apparent open source strategy, transparency and an apparent desire to engage with a community away and solicit input (code and comment) while feeding back the same goes a long towards addressing the points that Linux offers.

However a frequent issue that crops up is the comment "Sun charges for patches on an open source OS". This has been a long running sore and seems to be one area where Sun is out of step with the overall strategy.

The proposed changes are only going to add more ammunition to the Linux proponents.

Posted by Tony Reeves on January 09, 2009 at 11:57 AM GMT #

Sometimes you have to ask yourself if Sun could do anything else retarded to shoot themselves in the foot and then they do something like this. Forcing people to pay for patches is only going to drive them to a platform which doesn't charge. As a hint : most patches mean SUN broke something. So this model says, yeah we know we broke it but if you want us to fix our mistakes you must cough up some cash. Maybe Sun should focus on making a patching subsystem that actually works instead of regularly locking up if you try to install more than 10 or so patches at a time. updatemanager is the biggest piece of garbage and smpatch isn't much better. If Sun can't even get the right then how are they going to do any better with the patches they are now charging to serve up. If it weren't for zones and ZFS...

Posted by McGee on January 11, 2009 at 06:52 PM GMT #

Does this mean that if you have:

Patch A (S) requires
Patch B (R+S) requires
Patch C (S) requires
Patch D (R)

That patch D is also retrievable without a contract?

eg for instance, the kernel jumbo patch (120011-14) (R+S) requires patch 120900-04 (notR/S). Currently 120900-04 is downloadable, but how do we know this from patchdiag.xref - there's no reference to it being a R or S patch at all.

I've seen dependencies that are 6-deep, and I hope that Sun has considered all the different combinations that could occur on a system. For instance, some patches are conditional, depending on which packages are also installed (Zones springs to mind).

Otherwise this is going to be a complete mess.

Posted by Chris Wells on January 12, 2009 at 12:44 PM GMT #

Hi Chris!

Yes, patches required by "free" patches will also be "free".

Also, if a patch in the chain is withdrawn from release due to an issue, it will be replaced by the next available revision of the patch (or a patch which accumulates that patch).

In all circumstances, the necessary dependencies to install "free" patches will also remain "free".

Best Wishes,


Posted by Gerry Haskins on January 13, 2009 at 04:02 AM GMT #

Many thanks!

The other question I have is:

If I, as a Sun spectrum customer, download non-S patches, and "slipstream" these into a flash archive (ie an existing flar which I unpack into a temp directory, and then use patchadd -R), is that flar then "encumbered" and not allowed to be deployed to build new systems that are not yet under support?

(This would be in the case where not all of our systems are covered under a Solaris Everywhere suport contract).

Does this mean that I would have to maintain two different flars - one which includes patches, and one which doesn't.

Similarly, What about automatic patching tools that you dump patches into, and those tools then search and apply patches to all the systems? Unless a patch is somehow signified as a non-distributable patch, I can't see how this could be differentiated.

Posted by Chris Wells on January 13, 2009 at 05:45 AM GMT #

Hi Chris!

A support contract is needed for each system on which you wish to apply "entitled" (i.e. not free) patches. Please see the Solaris Patch Entitlement Policy,

Best Wishes,


Posted by Gerry Haskins on January 13, 2009 at 08:29 AM GMT #

What about existing flars that aleady contain the "entitled" patches? Do we have to stop using those flars?

Posted by Chris Wells on January 13, 2009 at 04:22 PM GMT #

What about creating a flar of one system to deploy to another system (say a prod to dev copy) - If the first system is under support, but the dev system isn't are we banned from using a flar which does/could contain "encumbered" patches.

Posted by Chris Wells on January 13, 2009 at 06:41 PM GMT #

Hi Chris!

Yes. Every system to which you wish to apply entitled patches must have a support contract. So it is not permitted to apply a flar containing entitled patches to any system which is not covered by a support contract which covers Solaris.

Please note that all fixes will be made available in the next Solaris Update release, as all available patches are pre-applied into each Solaris Update release. You can apply the latest Solaris Update release to your dev system without a support contract.

But if you want your dev system to be an exact copy of your prod system, including entitled patches, then you'll need a support contract which covers Solaris for your dev system too.

You could potentially run with a SunSpectrum contract for your prod system for both hardware and software support coverage and just a Solaris Subscription (starting at $324 and purchasable on-line) for your dev system.

Please remember that this is not a change in policy. This policy has existed since March 2007. But it's a good discussion to clarify that policy.

Best Wishes,


Posted by Gerry Haskins on January 14, 2009 at 03:56 AM GMT #

Jesus, the moaning. If you don't want to pay, just use OpenSolaris, and don't pay. But if you want a commercially supported OS, use a commercially supported OS. This model is identical to Red Hat (who seem to have no problem building a business with far less contribution to the community than Sun).

Posted by Marian Dannaher on January 15, 2009 at 05:34 PM GMT #

Actually Marian, it's not moaning. Sun wants to encourage uptake of Solaris but this highly discourages it, therefore it is a stupid move. You mention Redhat.

When Redhat had an open policy they were far more popular than they are today. They were once the number one Linux vendor but when they implemented this exact same type of policy their popularity fell almost immediately. The number one title passed to Fedora then passed off to Ubuntu. Ubuntu is number one and where is Redhat?

Opensolaris as it currently stands doesn't have a reliable or updated patching system in place as far as I can tell (I haven't seen a patch yet) which means unless I want to use Live Upgrade every 6 months this is not a viable mechanism either. So, it seems it is time to remove the Solaris from the servers and replace it with an OS that is patched without a $300 bare min investment per machine per year. In small environments it just isn't worth it.

Ubuntu and Linux are already eating away at Sun's margins by taking over the small servers and this guarantees that Sun will never be on the small servers again.

Posted by McGee on January 16, 2009 at 06:25 AM GMT #

As an added thought Marian :
Sun can copy the Redhat model all they want even though it has failed Redhat in many ways, BUT : Redhat can at least claim value add as many of the software packages they ship are community provided. Sun on the other hand is primarily providing Sun packages which means Sun broke it to begin with.
Redhat can get away with "Pay us to maintain and support these community packages."
Sun will not be able to get away with "Pay us to maintain and support the software we broke to begin with."

Posted by McGee on January 16, 2009 at 07:45 AM GMT #

Let me repeat again that all bug fixes will be available for free in the next Solaris Update release (and also in OpenSolaris).

What customers are paying for with a support contract is faster access to fixes and feature enhancements released in entitled patches prior to the next Solaris Update release as well as the other benefits a support contract brings (telephone support, access to extended knowledge articles, issue resolution, etc.).

May I make the point that if we did as some seem to be suggesting and gave away software for free which has been developed at very considerable cost \*and\* gave away support for free which also costs money to produce, that would not constitute a sustainable business model. I think it's in customers' interest that the business model be sustainable.

If you're a production customer, you really need to have a support contract in place.

If you're a home user, then if you are not prepared to pay for support, you can wait for the next Solaris Update release or look at using OpenSolaris.

Posted by Gerry Haskins on January 16, 2009 at 08:42 AM GMT #

Then might I point out that your model is backwards. Sometimes it's all about perception. Why would someone pay for support on a "free" product.
When you give it away for free then the perception from the customers view is already set.
Neither Redhat,nor Microsoft, nor Apple give the base OS away for free.
Perhaps you should be charging for the base OS, then providing the patches at no cost.

I might also point out that it is the home user these days that promotes the use of your OS through software development. They are that community that Redhat has and Sun wants to build. The home user of "Solaris" is the one that goes in to work in the data center and may(probably does) make recommendations on what should be used in said data-center. They are the ones that go into that meeting and state quite emphatically "What we need is a large rack full of Redhat or Solaris servers." Discount those users at your own peril.

You should also consider the folly of asserting the Redhat business model will work for Sun. Redhat is in the business of repackaging existing software provided by a large community into a usable product which people expect to pay support for in an enterprise environment. Sun is in the business of selling a stack from hardware to software which is more akin to the Apple model than Redhat.

Posted by McGee on January 16, 2009 at 09:51 AM GMT #

Without going into politics, something HAS changed, even for contract customers.

We got fed up with all the different and equally horrible patching mechanisms provided by Sun a long time ago - ever since the Recommended clusters stopped being useful. We've now been using those clusters as a base level and patching with pca afterwards and are _extremely_ happy with it. Unfortunately, pca has started to fail now and again:

--16:52:02--;jsessionid=stuff => `/l/var/pca/patch/119254-63.tmp'
Reusing existing connection to
HTTP request sent, awaiting response... 500 Internal Server Error
16:52:22 ERROR 500: Internal Server Error.

Very annoying. Sometimes it just works, sometimes we're fed 500's. We need this to work 24/7...

Posted by Janne Korkkula on January 19, 2009 at 07:05 AM GMT #

Hi Janne!

I've been discussing this with Martin Paul (author of 'pca') and we don't believe this error has anything to do with the recent changes to the Solaris patch entitlement implementation.

Martin says this is a known sporadic issue, which he believes may be related to an outage of one of the SunSolve load balancing servers which serves the download requests.

Since customers get effectively bound to one of these servers for a period of time, if the server has an issue, then the customer may experience repeated failures until the server is fixed or the binding to that server expires. At least that's the current theory.

I'm following up with the relevant SunSolve folk to see if they can get to the bottom of the issue and resolve it. Thanks for bringing it to my attention.

Best Wishes,


Posted by Gerry Haskins on January 21, 2009 at 10:00 AM GMT #

It would be very nice to have information about all patch releases (including old, but downloadable without contract security patches) in the patchdiag.xref. Otherwise PCA can't find out about all missing security patches. If Sun hasn't the resources for this: the community has if Sun would allow redistribution of modified patchdiag.xref files.

Best regards

-- Dago

Posted by Dagobert Michelsen on January 28, 2009 at 12:36 AM GMT #


earlier you had to pay for Solaris and patches were free, now Solaris is for free and you have to pay for the patches.
you also have to pay for patches and hot fixes with Red Hat, as far as I know. Only when you update your OS the patches are included and therefor "free". That is the same with Solaris. Run an update, and hopefully you use Live Upgrade, and you get the latest patches for "free".

I've never heard from a garage that fixes your car for free and give their cars away for free. If you heard of one, please let me know. I'm really curious how the garage pays their bills ;o))))

Solaris is constructed and designed by well-trained, excellent engineers and they deerve to get money for it. Period.
And it is stabil. Be realistic, running a cluster on Linux, and meintaining sensitive data - which OS are you going to choose???? And in the end, take the support costs and compare the quality -

think about it,

Posted by Claudia Hildebrandt on February 06, 2009 at 02:37 AM GMT #

Personally I have moved to AIX.
I got fed up with Solaris patching either being difficult or just not working a long time ago and have moved to something that works properly - well the patching side anyway.
Patching on Solaris has always been a bit of a hit and miss. Why can Sun just not get the process to work properly? Look at how Microsoft does it. It just works - (well most of the time) but with Sun it's just flaky and time consuming. It's only patching and should not be difficult.

Posted by Stuart Budd on March 01, 2009 at 11:53 PM GMT #

We have a paid contract (for 5 years now) with Sun and this is very frustrating. Getting support with Sun because of contract entitlement issues has been frustrating for the past 5 years. The entitlement policy needs to be done away with for a far more simpler model.

Tonight we needed a critical patch but we could not get to it because of either a glitch with Sunsolve or a configuration glitch with our contract. We have had issues with our contract for the entire 5 years we have been with Sun.

This is never the case with IBM or Veritas. With these 2 companies, we just give them our customer number, and they take care of us.

With Sun, just getting the case OPENED, always because of entitlement issues, has always been a royal pain. We have wasted hours in down system states because of contract wrangling. We are constantly being asked for proof of our entitlement and it gets really old especially when we need help.

This entitlement policy is not customer-centric. It is revenue-centric. Sun needs to earn a commission. Fine. At least make it as painless as possible.

As far as Red Hat, their patch model is even more annoying. They are not the right model to follow.

Sorry guys but this type of support is not the way to go, and as a loyal customer for 5 years it makes me really frustrated just to even attempt basic support anymore.

Posted by Lightway on March 04, 2009 at 09:29 PM GMT #

We just ran a security scan and the scanning software flagged our system as missing '116227-01'.

This patch is no where to be found except as a roll up in '109889-07'. This patch requires a valid support contract.

So, the claim "the specific patch revisions which introduce all new security fixes", is not true.

Please release '109889-07' or re-release '116227-01'.


Posted by Michael Newcomb on March 09, 2009 at 10:40 AM GMT #

Hi Michael!

Can you please provide the CR number of what you believe is the security fix in these patches ?

What security scanning software were you using ?

BTW: 109889-07 was released December 2003, so these are very old patches.

Best Wishes,


Posted by Gerry Haskins on March 10, 2009 at 06:10 AM GMT #

Hi Michael!

I've looked up every single CR included in these patches and not one of them is flagged as a security fix. I've also checked that these patches are not referenced in any Sun Alert.

So I don't believe these patches address a recognized security issue.

Unless you can provide further information which shows these patches address a security issue, their availability will remain restricted to customers with a support contract which covers Solaris.

Best Wishes,


Posted by Gerry Haskins on March 10, 2009 at 08:35 AM GMT #

Hi Lightway!

Apologies for my delay in responding to your comment.

I hear what you are saying. I can only apologize on behalf of Sun for the problems you have experienced.

The problems you allude to are much wider than patch entitlement.

There is a lot of change going on in the backend at the moment as the contract and support infrastructure migrates to IBIS, and this is undoubtedly causing ongoing transition pains.

Contract management is owned by Sales and Services and I have very limited influence in this area, but I am continuing to work with the relevant groups to try to ensure the smooth operation of patch entitlement and iron out any issues arising.

Posted by Gerry Haskins on March 10, 2009 at 08:55 AM GMT #

I could make a comfortable living just going to sites and writing and implementing patching policies and scripts. As a long time Solaris user soemtimes I just went spare trying to patch systems. The patching model is a POS and everybody knows it, every single Sun patching piece of software might as well report to /dev/null, that is why savvy sysadmins use PCA, which uses patchdiag.xref. Now Sun says we are going to intentionally break the one tool that works, first class, I won't even mention the times Sun has broken patchdiag.xref un-intentionaly. Gerry, who did you annoy to be given this mess to sort out? And as far as Sunsolve access goes don't get me started once I had some issue and I had to wait 48 hours for the Clowns in some sub-continental place to come into the office, this 48 hour waiting time was on the front page of some deeply nested sunsolve page. Whoever does some of these things should be forced to patch a Sol 10 FCS system using Sun tools as a reminder why not to break patchdiag.xref.

core dumped....

Posted by PCA-User on March 13, 2009 at 04:36 AM GMT #

Hi PCA-User!

First, let me state that I have no intention of breaking 'pca'. I keep in contact with Martin Paul, co-ordinate changes with him, and work to with him to resolve any issues arising.

Secondly, regarding who did I annoy to be given this mess to sort out. I volunteered. I understand it's a key customer dissatisfier. There's lots of things in the way we present the patching experience to customers which is sub-optimal. That really, really irritates me.

I want to improve it. I don't own SunSolve, or how contracts are managed in IBIS, or Sun's patch automation tools, but I am working with those teams, especially the SunSolve team, to improve how patches are displayed to customers and the accuracy and quality of patch related documentation.

We're currently working on improving the contents, installability, and presentation of the Patch Clusters.

My team and I are also continuing to work extremely closely with Solaris Sustaining on targeted improvements to the patch utilities, such as the forthcoming Zones Parallel Patching enhancement.

And I'm looking to leverage the patch metadata my team has available in-house to provide better search and self-help tools for customers.

I'm also using the Big Admin Patching Center and this blog to try to bridge the knowledge gap on best practices and potential issues with customers.

I'm convinced the customer patching experience can be significantly improved and that's what I'm working to achieve.

And we're starting work on what I call "Pre-flight checks" to aid Sys Admins in ensuring a system is in a state ready to be patched - e.g. enough space, no left over lock files, no IDRs which need to be removed, etc., etc.

There are limitations as to what can be achieved with the current architecture and implementation, which is why Solaris is moving to the Image Packaging System (IPS) packaging format as can be currently previewed in OpenSolaris. This is the longer term strategic solution.

But I, my team, the Solaris Sustaining organization, and others are committed to improving the customer patching experience in the current releases of Solaris too. Incremental steps, which taken together can make a real difference.

And I'm happy to partner with Martin Paul and friends on 'pca' related matters.

Best Wishes,


Posted by Gerry Haskins on March 13, 2009 at 07:13 AM GMT #

we are looking at a third party support vendor, in an attempt to thwart this I pointed out this item and that 18% of patches will be all we can get if we cancel sun and go with the third party, there ( 3rd party vendor ) response is that this is just a blog.

Is there a URL form sun that shows this percentage, I guess I would like to be able to present something official on this which shows the percentage numbers of private versus public patches?

Posted by Steven Ward on March 16, 2009 at 08:48 AM GMT #

Hi Steven!

The official Solaris patch entitlement policy,, has been updated to provide more details on what is and is not available without a support contract from Sun.

This doesn't mention the percentage of Solaris patches available to customer without a support contract from Sun as it can vary a little over time, but I can tell you that in Phase 1 of the implementation, it currently equates to 28% of Solaris 10 patches remaining available to users without a support contract, and that is due to fall to 19% after we introduce some further changes.
I get a daily report from the entitlement database, so these figures are absolutely accurate.

I would point out that rogue Third Party Support vendors who abuse Sun's IP rights in this area are liable to legal prosecution as are end users.

You are welcome to work with Sun authorized partners or deal with Sun directly. But producing patches, etc., is not cheap and Sun will not tolerate abuse of its entitlement policies.

While this is a blog, I am the Director for Software Patch Services, and I am responsible for the Solaris Engineering side of the patch entitlement implementation. So what's stated here is reasonably official and I strive to be as accurate as possible. It was I who updated the official Solaris Patch Policy document, in conjunction with Marketing and Legal.

If you or your third party support vendor would like to discuss this further, please contact me directly and we can set up a meeting.

Best Wishes,


Posted by Gerry Haskins on March 16, 2009 at 10:22 AM GMT #

@ Gerry Haskins...

Not even Microsoft charged to fix defects in Windows... And they are the king of monetization.

Moot point I supposed as I'm sure Oracle will try and milk Solaris for what its worth.

One has to wonder if this aggressive "screw over the hackers" mentality with Solaris and charging for bug fixes contributed to the unceremonious end for SUNW/JAVA that we saw just recently.

Posted by Mick Russom on April 24, 2009 at 06:52 PM IST #

To understand how broken the customer support and entitlement process is, one should look at a company like ours. We purchase both sun hardware as well as the solaris_x86 system for various machines. At one point several years ago, we had well over 1000 machines running Solaris. The support and patching problem became a nightmare with sun. One such nightmare for us was when congress mandated a change in timezone information. Because we operate a huge number of cell phones, this became a major issue for us. Getting help from sun even in the form of finding us our entitlement number for hundreds of machines (we spent >6 digits on maintenance in the last few years) took a significant amount of time. Even today, we can't get an agreement on our contracts or support... At this point we only use the machine serial number to try and get in the system. In fact, many of our SAs just walk into our lab for serial numbers even though it has nothing to do with the machine being repaired. Others just use serial numbers from past companies that appeared to have gotten their entitlements semi-figured out. Personally I do not condone this behaviour at all and we have gone to great and expensive lengths to straighten it out.

What HAS happened is that our operations group finally was fed up with Sun back with the timezone issue. Since then we have had several MAJOR internal projects to migrate off of sun onto linux or other alternatives. At this stage, the only thing left with Solaris is sun hardware and we've stopped purchasing most of the sun hardware with the exception of database machines for just this reason.

If you follow what happened over the last three years, Sun lost a \*significant\* about of revenue from us because of both policies and mismanagement of their internal processes for managing entitlement. I can't point to any one situation other than a level of frustration that has built up over the years that has allowed senior operations management to take on the cost of migrating away from sun.

As a systems architect, this has made my job and my groups jobs significantly harder as we went from a mostly homogeneous environment to a hetrogeneous setup. As the sun OS fades out of our implementations, its moving more towards a homogeneous environment albeit with CentOS rather than Solaris.

Why am I venting on here today? Because I've wasted most of my day today already trying to get access to the patch system because no one remembers our username/password for access and the runaround with entitlement and customer service has finally exposed me personally to the issues many of my people have been complaining about for years. After wasting several hours of time and still getting nowhere, I've finally called another company and had them download what I needed and mail it to me. I still don't have our accounts and quite frankly don't even care anymore. If nothing else, at least that section of the maintenance budget is going down. Since we already spend multi-millions for Oracle support contracts, maybe the acquisition will help us get better sun support in the future. Until then, I'm not holding my breath.

Posted by Marcos Della on May 04, 2009 at 01:02 PM IST #

Marcos' situation describes our situation nearly word for word. Red Hat has the same patching issues, so I can see why he would want to go with CentOS. The whole patching and entitlement process is completely counterproductive and revenue destroying.

I can attest to the hours spent just trying to GET support because of tracking down the right magic number. Though it is funny to get better service through the high end server queue.

I also thought Solaris was supposed to be open source now, so why hold patches hostage? Customers want to use the Sun software yet Sun seems to want to place barriers to prevent them from doing it. Nickel and diming customers isn't the way to go.

Posted by Lightway on May 04, 2009 at 03:36 PM IST #

Hi Chris!

You raise an interesting issue and I've taken some time to consult with Services Marketing on this.

Here are their collated responses:

Solaris Subscriptions are tied to the h/w serial number of the system. They cannot use Solaris and patch on any other system than the one that was purchased for Solaris support unless you have something like a 4walls or Solaris everywhere support contract.

Although Chris sort of disparages a "site-wide" plan for what he is managing on VirtualBox, I would not be surprised that our cleanest offering for this person would be Solaris Everywhere. Now the rules on Solaris Everywhere are that he cover all Solaris instances in his site - not just the transient ones he's concerned about within his VirtualBox.

If he has a 100 other Solaris instances he does not "care" about elsewhere in development - we would want to cover these too, although there is some flexibility in how those would be priced.

A Solaris service plan (single system version) covers just one binary instance of the Solaris OS, per the service listing. And from an entitlement standpoint (related issue) a serial number is normally required for that instance. But for the case of transient binary instances, our answer thus far has been to use common sense approach and flexibility provided by Solaris Everywhere - which does not "care" about serial numbers and can price based on an average number of instances in existence at any point in time.

Chris, feel free to follow up with me off-line if you'd like me to put you in touch with the right folks to discuss this further.

Best Wishes,


Posted by Gerry Haskins on June 19, 2009 at 09:10 AM IST #

Does it matter if the Solaris instance is for personal use or if it's internet facing?

Posted by Sander on July 20, 2009 at 03:22 PM IST #

Ok. I still dont get it.

Sun say they give away Solaris 10 for free, including security patches.

But then they only send out information about the last patch, which might not be an security patch. And this means you can not use the only working patching tool available, pca.

So basicly, for free you can not run a secure system.

If this is so, what is the point of giving away Solaris 10 for free at all? Why even mention it, if its useless?

Or have I missed something? Have Sun realized that this "only last patch in patchdiag.xref issue" is conflicting with the statement that "Solaris 10 for free"? Or is it all just a missunderstanding? It really cant be this stupid?

Is the "last patch" in patchdiag.xref the last security patch, for free users? Or might the last patch be shadowed out by a later non security patch, for free users?

Posted by henriko on December 09, 2009 at 11:49 AM GMT #

I still think that charging for patches is really stupid. Think, Linux, (Ubuntu LTS,CentOS), FreeBSD, OpenBSD, NetBSD heck, even Windows doesn't charge for patches.

This model is really obsolete erecting a toll booth in front of security and reliability (don't even try to insinuate that the "S" and "R" patch lables are meaningful.

Also, PCA is the only working patch tool for solaris and patchdiag.xref only has useful information for entitled accounts.

I've still got the original Solaris 1 / 4.1.4 install media, I've been doing this a long time, and this patch access mess has always been a mess and it still is and its pissing the the face of Solaris lovers and they don't even do MUs anymore.


Posted by Mick Russom on December 15, 2009 at 09:07 AM GMT #

Hi Mick!

MUs are available. They are now called "Solaris Update Patch Bundles" and are available to customers with a support contract from

Best Wishes,


Posted by Gerry Haskins on December 15, 2009 at 12:50 PM GMT #

Hi Henriko!

Let me try to clarify a number of points:

1. Currently, all revisions of security patches are currently free, so if a security fix is introduced in rev-03 of a patch and rev-05 of the patch is currently the latest, then rev-05 will also be free in the current phase of the stricter patch access entitlement implementation.

2. You correctly state that the metadata file which 'pca' leverages only contains the latest revision of a patch. But since in the current phase of the stricter patch access entitlement implementation, all subsequence revisions of security fixes are still free, then you can still use 'pca' to patch all security issues.

3. In a future phase of the stricter patch access entitlement implementation, only the specific patch revision which introduced the security fix will remain free. While this will impact 'pca' for customers without a support contract, such users can still use the PatchFinder tool, to locate and download all security fixes.

Best Wishes,


Posted by Gerry Haskins on December 16, 2009 at 05:28 PM GMT #

I am presently editing the CIS Solaris 10 Benchmark, probably for the last time because of Sun's suicidal patch policy. I have no intention of paying for a support contract for systems that I use for research to produce content that indirectly benefits Sun. Going to OpenSolaris is not a feasible option since I need to document how patches get applied, which means testing the process. I think Sun will also find vendors dropping Solaris support for their products in droves. Sad to watch Sun's continuing downward spiral.

Posted by Carole Fennelly on February 03, 2010 at 07:04 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