What is Sun's answer about PCA patch manager free tool ?
Hi all,
this post aims on echoing customers'feedback.
from customers'experience it seems that smpatch from patch manager tool is suffering of a lack of reliability.
One of them moved to a new freeware called PCA-Patch Check Advanced
http://www.par.univie.ac.at/solaris/pca/
From PCA Web Site we can read:
Sun has offered various tools in the past to analyze Sun/Solaris systems for patches which are installed or missing, e.g. PatchDiag, PatchCheck, PatchPro, smpatch (see the Sun Patch Portal for details). Some of them are not actively maintained, some are huge and opaque, some don't run on older Solaris releases or stripped-down machines. None of them really made me happy. Based on PatchCheck source I implemented PCA, which gets rid of the disadvantages of Sun's own tools.
I would like to know what is Sun's position and could it be possible to integrate such a tool ?
Thanks.
Malek.
[957 byte] By [
MaLeK] at [2007-11-26 6:05:41]
# 1
- Sun is always interested in customer feedback, and is interested in the concerns expressed here.
- Sun is working to reduce the number of patching tools and to actively maintain and improve those that remain.
- We do understand that opaque is bad, but one of Sun's goals is to provide complex analysis beyond matching patches with installed packages. This analysis and its support processes will necessarily be somewhat opaque.
- Sun's general policy is to focus enhancement on newer releases of Solaris. This approach keeps our development costs under control and aids our goals increase customer adoption of the latest Solaris release.
- We are interested in the concerns surrounding stripped-down systems, and are considering a "light" version of our tools that would support minimal systems. However at this time there are no plans to release a light version.
Regards,
Forum Moderator
# 2
To begin - I'm the author of PCA, so of course I'm biased. I'm patching Sun systems since 10+ years. The development of PCA started as a modified version of patchdiag a long time ago. I probably wouldn't have invested much time into my own tool if smpatch would have appeared earlier. Last year I even thought about switching to smpatch - but after all the hassles of restricting access to Solaris patches, being forced to register systems, and all the problems and functionality changes to smpatch every few weeks I decided that I'd better put my time into PCA instead of wading through smpatch's java errors. Commenting on the points you made in your posting:
Sun is reducing the number of patching tools - that's a good idea. In fact there should be just one Sun-supported tool for all patch needs. But of course this should run on all supported Sun systems for which patches are still produced. If Sun offers stripped-down installation clusters for the OS, the patch tool must run on those, too. Is it Sun's recommendation to not patch a system with "Core System Support" at all ?
I still don't understand why the process of patch analysis is opaque. If it can be implemented, it can be documented. In fact smpatch doesn't even do the basic matching of patches to packages correctly, or why would "smpatch analyze" show 120445-01 as missing on my Blade 1000 ? I've often compared "smpatch analyze" output with pca's output, and manually checked the differences, and at the end it usually turned out to be smpatch which was wrong. Just try for yourself :)
As far as the argument to cut down costs by focussing on the newest Solaris releases is concerned - the software packaging system and patch tools haven't changed in at least a decade, the last big step being the transition from installpatch to patchadd in Solaris 2.6. So there's no technical reason why a patch tool shouldn't work on older releases (look at pca). Not all customers can upgrade to Solaris 10 at will at any time, the real world is a little more complicated.
Patching must be easy. A user dealing with a broken patch tool will just stop running it (and smpatch just seems to break too often). This leads to a lot of unpatched systems, which is bad for the customer and Sun.
mp.
# 3
>- Sun is always interested in customer feedback, and is interested in
> the concerns expressed here.
I'd also very muck like Sun to be interested in fixing the customers problems, which has not been done in my cases. No solution or explanation has been given to my many cases opened on smpatch, and this, even though in some cases, patches were made (months later): I was never told about them. Which makes me wonder about the point of having paid support contracts in the first place.
But since UM was developed by interns, it's no wonder there's trouble maintaining it (how do I know? I've been an intern doing Java development, and I made the exact same beginner's mistakes, not knowing to handle exceptions, leaving debug output on stdout, being unable to make proper localisation).
It's obviously not the work of experienced Java programmers. Hard to trust it...
> - We do understand that opaque is bad, but one of Sun's goals is to
> provide complex analysis beyond matching patches with installed
> packages. This analysis and its support processes will necessarily
> be somewhat opaque.
What analysis are you talking about? smpatch is not even able to tell me that security fixes are available for NSS, which has been part of Solaris for years. PCA does.
And what about Studio? Why can't smpatch tell me there are patches for that, too? And why aren't free patches, that are neither recommended nor security (such as the man patches) shown by smpatch when running without a contract?
>- We are interested in the concerns surrounding stripped-dow
> systems, and are considering a "light" version of our tools that would
> support minimal systems. However at this time there are no plans to
> release a light version.
And what about systems without a network?
And what about not forcing me to read and agreeing to a, abusive license agreement, which can't even be printed, nor shown full screen (5 lines at a time!)?
And, please, can you explain me why I should agree to respect Reuters so-called intellectual property? What does it have to do to with keeping my systems up to date reliably and easily? Is it a competition between Sun and Microsoft to put the most ludicrous licenses on line?
Anyway, I'm sure Solaris 11 will introduce some new bloated offspring of the PatchProManagerUpdateConnection family, so I'm not holding my breath. Rather than repeat this experience again and again, I'll stick with PCA.
Laurent
