Stricter Solaris patch entitlement implementation roll-out commencing this week
This blog entry expands on a previous blog entry regarding Solaris patch entitlement.
The Solaris patch entitlement policy is available on http://sunsolve.sun.com/search/document.do?assetkey=1-61-203648-1. "Entitlement" refers to patches which require you to have a valid support contract to access them.
Solaris changed its business model a few years ago from selling Solaris and providing patches for free to a model of giving away the Solaris releases for free and charging for patches.
The Solaris patch entitlement policy applies to all Solaris Operating System patches. It does not necessarily apply to middleware or application layer product patches which may be installed on top of Solaris, such as SunStudio, Java, etc.
The Solaris patch entitlement policy is that the following Solaris OS patches will remain available irrespective of whether or not you have a valid support contract:
- the specific patch revisions which introduce all new security fixes
- the specific patch revisions which introduce certain hardware support
- all revisions of Solaris patch utility, smpatch, and Update Manager patches to ensure correct patch application
- the specific pre-requisite patch revisions for Live Upgrade
- the specific pre-requisite patch revisions for certain Sun software application products
- all revisions of patches which patch products which are both bundled as part of Solaris and also released as separate products which don't enforce patch entitlement
- a small number of other specific patch revisons at the discretion of Sun
- any patch revision explicitly required by any of the above patches
Other Solaris OS patches require that you have a valid support contract to access them.
All fixes will all be available for free in the next Solaris 10 Update release, so if you are not willing to pay for a support contract, you can still get the fixes by installing or upgrading to the next Solaris 10 Update release. You'll just need to wait for it to be released.
The key point is that if you may need timely access to a patch which fixes a critical non-security issue, then you need to have a valid support contract for each system you may wish to patch. You also need to have a valid support contract in order to get telephone support or fixes coded for any issues which are unique to your environment.
So it's highly advisable for you to have a valid support contract in place for each production system.
If you are a home user for example, and don't want to go to the expense of buying a support contract, using OpenSolaris or waiting for the next Solaris 10 Update release are valid options.
This policy is not changing.
What is changing is the implementation of patch entitlement to ensure it matches the policy. Currently, circa 60% of Solaris OS patches are available without a support contract, including most of the key patches. Under the new entitlement implementation, 18% of Solaris OS patches will remain available without a support contract. The rest will require a valid support contract to access.
Any of the following support contracts will provide you with access to all Solaris OS patches and patch clusters: a Solaris subscription, a Software Support Contract, a Sun System Service Plan for Solaris, a Sun Spectrum Storage Plan, or a Sun Spectrum Enterprise Service Plan. Since the names of the support contracts change from time-to-time, this list may change.
If you are running Solaris on Sun Hardware, I suggest you consider purchasing a SunSpectrum System Plan. This will cover both your HW and OS with one simple support contract.
If you are running Solaris on non-Sun hardware, you should consider a Solaris Subscription Support Plan, which is available on-line from just $324 per year.
Remember, you need a support contract for each system you wish to patch, so if you need more of a site-wide support plan, Solaris Everywhere is a good choice.
BTW: It's important to remember that hardware warranties do not cover software support or access to Solaris patches.
The new implementation will roll out in phases, starting this week.
You should check that you have valid support contracts in place for each system you may need to patch. Please do not wait until you need a patch to put the support contract in place. There is a latency of several days between subscribing for a support contract and patch access being granted. Support for your production Operating System really isn't something you should play "chicken" with.
The new Solaris OS patch entitlement implementation roll-out should be completely transparent if you have a valid support contract for each system you wish to patch.
A PodCast talking about the above and the Solaris 8 Vintage program which commences April 1, 2009 is available here
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 09:44 AM GMT #
I totally agree with Alasdair. It's a bad idea.
Posted by Remy Zandwijk on January 08, 2009 at 10: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 12:46 PM 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 06:29 PM 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 08: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,
Gerry.
Posted by Gerry Haskins on January 09, 2009 at 04:31 PM 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 07:57 PM 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 12, 2009 at 02:52 AM 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 08: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,
Gerry.
Posted by Gerry Haskins on January 13, 2009 at 12:02 PM 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 01:45 PM 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, http://sunsolve.sun.com/search/document.do?assetkey=1-9-89212-1
Best Wishes,
Gerry.
Posted by Gerry Haskins on January 13, 2009 at 04:29 PM 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 14, 2009 at 12:22 AM 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 14, 2009 at 02:41 AM 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,
Gerry.
Posted by Gerry Haskins on January 14, 2009 at 11: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 16, 2009 at 01:34 AM 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 02:25 PM 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 03:45 PM 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 04:42 PM 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 05:51 PM 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-- http://sunsolve.sun.com/CDW/119254-63.zip;jsessionid=stuff => `/l/var/pca/patch/119254-63.tmp'
Reusing existing connection to sunsolve.sun.com:80.
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 03:05 PM 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,
Gerry.
Posted by Gerry Haskins on January 21, 2009 at 06:00 PM 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 08:36 AM GMT #
Folks,
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,
claudia
Posted by Claudia Hildebrandt on February 06, 2009 at 10: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 02, 2009 at 07:53 AM 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 05, 2009 at 05:29 AM 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'.
Thanks,
Michael
Posted by Michael Newcomb on March 09, 2009 at 05:40 PM 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,
Gerry.
Posted by Gerry Haskins on March 10, 2009 at 01:10 PM 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,
Gerry.
Posted by Gerry Haskins on March 10, 2009 at 03:35 PM 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 03:55 PM 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 11: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,
Gerry.
Posted by Gerry Haskins on March 13, 2009 at 02:13 PM 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 03:48 PM GMT #
Hi Steven!
The official Solaris patch entitlement policy, http://sunsolve.sun.com/search/document.do?assetkey=1-61-203648-1, 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, http://sunsolve.sun.com/search/document.do?assetkey=1-61-203648-1. 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,
Gerry.
Posted by Gerry Haskins on March 16, 2009 at 05:22 PM 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 25, 2009 at 01:52 AM 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 08: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 10:36 PM IST #
Do Sun provide a support contract which covers an individual or account rather than a specific host id? I work for a Sun CDP in the UK and even I am going around in circles trying to get a clear understanding on this. I have spent several days to no avail. No-one at Sun appears to understand what I feel is a very straightforward situation.
I am running a number of Solaris 10 test environments inside VirtualBox. The environments contain various configurations of the Sun Ray software. The OpenSolaris OS architecture is not suitable here.
The problem I have is that a VirtualBox machine has a specific but random host id only as long as it exists. I might use such a machine for a day and then blow it away to start again with a new configuration. I need to ensure that each machine is fully patched because in some cases there is instability (genunix panics) which may be fixed with non-security patches.
However Sun refuse to budge from the host id model and cannot advise on the correct way to cover my situation. Each machine only exists for a short time and is then replaced by a new machine. But it's still me needing patches for an instance of Solaris. I need some kind of developer plan or something for CDPs. The environment I have built is used to demonstrate Sun's VDI capability to Sun partners and end-users, so I would expect Sun to want to help me get it working.
I have been given a couple of names of people to speak to and will follow this up, but in my frustration trying to get this working I stumbled across this blog and thought it worth asking here.
So in summary - do Sun have a sensible support option available to me or not? By sensible I mean that I am not expected to pay a fortune for a 'site wide' contract just because it's the only thing Sun can think of to use with virtualised environments.
Can I also add my voice to those who think that patching is stupidly complex as it stands and that it needs to be simplifed in all respects. Personally I mean everything from the commercial model to the actual patching process and tools.
The opinions expressed in this post are explicitly my own.
Regards,
Chris
Posted by Chris on June 11, 2009 at 11:07 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,
Gerry.
Posted by Gerry Haskins on June 19, 2009 at 04:10 PM 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 10:22 PM IST #