On Fri, 17 Mar 2006 16:06:19 +0000, Jeff Wieland wrote:

> I just installed Patch Manager 2.0 on a few Solaris 8 boxes.
> It appears to run correctly on all but two of them. On those
> two machines, it lists nearly 500 patches that need to be
> installed -- they already are installed? Any idea what might
> be going on here?

I use pca, google for it. Never an issue with it for me.

Steve

In article Steve writes:
>On Fri, 17 Mar 2006 16:06:19 +0000, Jeff Wieland wrote:
>
>> I just installed Patch Manager 2.0 on a few Solaris 8 boxes.
>> It appears to run correctly on all but two of them. On those
>> two machines, it lists nearly 500 patches that need to be
>> installed -- they already are installed? Any idea what might
>> be going on here?
>
>I use pca, google for it. Never an issue with it for me.
>
>Steve

But will pca continue to work with the coming changes at Sun w.r.t patch
distribution?
--
Jeff Wieland

Jeff Wieland wrote:
> In article Steve writes:
>> On Fri, 17 Mar 2006 16:06:19 +0000, Jeff Wieland wrote:
>>
>>> I just installed Patch Manager 2.0 on a few Solaris 8 boxes.
>>> It appears to run correctly on all but two of them. On those
>>> two machines, it lists nearly 500 patches that need to be
>>> installed -- they already are installed? Any idea what might
>>> be going on here?
>> I use pca, google for it. Never an issue with it for me.
>>
>> Steve
>
> But will pca continue to work with the coming changes at Sun w.r.t patch
> distribution?
> --
> Jeff Wieland

Look for something wrong in /var/sadm/
Just had a similar case, patchdiag returned a very large list of needed
patches. Turned out there was a mail file in /var/sadm/pkg/ .
showrev -p returned weird results. Trussing showrev -p and looking at
opens, found a outbox file removed it. showrev -p and patchdiag are
back to normal.

Bill

In article Bill Goodridge writes:
>Jeff Wieland wrote:
>> In article Steve writes:
>>> On Fri, 17 Mar 2006 16:06:19 +0000, Jeff Wieland wrote:
>>>
>>>> I just installed Patch Manager 2.0 on a few Solaris 8 boxes.
>>>> It appears to run correctly on all but two of them. On those
>>>> two machines, it lists nearly 500 patches that need to be
>>>> installed -- they already are installed? Any idea what might
>>>> be going on here?
>>> I use pca, google for it. Never an issue with it for me.
>>>
>>> Steve
>>
>> But will pca continue to work with the coming changes at Sun w.r.t patch
>> distribution?
>> --
>> Jeff Wieland
>
>Look for something wrong in /var/sadm/
>Just had a similar case, patchdiag returned a very large list of needed
>patches. Turned out there was a mail file in /var/sadm/pkg/ .
>showrev -p returned weird results. Trussing showrev -p and looking at
>opens, found a outbox file removed it. showrev -p and patchdiag are
>back to normal.
>
>Bill

I did grab pca and run it. It does look pretty useful -- it found
a patch for GNOME 2 that smpatch didn't, the 64 bit libpng patch.
On one of the problem servers, it found a corrupt patch-related
file. Since this was for a piece of hardware I no longer use, I
removed the related packages. But, smpatch still doesn't work
correctly. I'm attempting to verify the contents of /var/sadm/,
but so far I haven't found anything wrong.

I could probably get by with pca, but smpatch should work, and it
bugs me that it doesn't. It indicates that something is amiss.
--
Jeff Wieland

In article ,
Jeff Wieland wrote:
>But will pca continue to work with the coming changes at Sun w.r.t patch
>distribution?

Should Sun yet again break the interface that pca and countless homegrown
tools use to fetch patchdiag.xref and the public and contract-only patches,
I would hope that the customer rabble would be waiting at Don Grantham
and company's doorstep with torches and pitch forks in hand.

John
groenveld@acm.org

In article groenvel@cse.psu.edu (John D Groenveld) writes:
>In article ,
>Jeff Wieland wrote:
>>But will pca continue to work with the coming changes at Sun w.r.t patch
>>distribution?
>
>Should Sun yet again break the interface that pca and countless homegrown
>tools use to fetch patchdiag.xref and the public and contract-only patches,
>I would hope that the customer rabble would be waiting at Don Grantham
>and company's doorstep with torches and pitch forks in hand.
>
>John
>groenveld@acm.org

I'm very impressed with pca. It works on every Solaris box I've tried
it on so far. It even found a security patch that smpatch (and PatchPro
Expert) missed. Plus it only needs perl (and wget) to run.

As far as speed goes, it takes about 10 seconds to run a check for new
patches on my 1.5 GHz SB1500. It takes about 45 seconds to run on my
old 170 MHz Ultra 1, which is decently fast on that machine.
--
Jeff Wieland

On 2006-03-19 15:33:57 +0000, Jeff Wieland said:

> In article groenvel@cse.psu.edu
> (John D Groenveld) writes:
>> In article ,
>> Jeff Wieland wrote:
>>> But will pca continue to work with the coming changes at Sun w.r.t patch
>>> distribution?
>>
>> Should Sun yet again break the interface that pca and countless homegrown
>> tools use to fetch patchdiag.xref and the public and contract-only patches,
>> I would hope that the customer rabble would be waiting at Don Grantham
>> and company's doorstep with torches and pitch forks in hand.
>>
>> John
>> groenveld@acm.org
>
> I'm very impressed with pca. It works on every Solaris box I've tried
> it on so far. It even found a security patch that smpatch (and
> PatchPro Expert) missed. Plus it only needs perl (and wget) to run.
>
> As far as speed goes, it takes about 10 seconds to run a check for new
> patches on my 1.5 GHz SB1500. It takes about 45 seconds to run on my
> old 170 MHz Ultra 1, which is decently fast on that machine.

Glad to help Jeff, I know from experience that Sun have broken most
patching automation, pca seems to do it mostly right....

Steve

In comp.sys.sun.admin Jeff Wieland wrote:
>
> But will pca continue to work with the coming changes at Sun w.r.t patch
> distribution?

As of now, no further changes to patch distribution have been announced.
In 2005, it was a real mess. The download URLs for automatic patch down-
loads changed, and no stable interface was ever published or documented,
esp. to access the restricted Solaris 10 patches (which was the real
big change, completed 2005/11/29).

I've been following those announcements closely, and adapted pca accordingly,
so that there always was a working version available at any time (of course
limited by the restriction imposed on patch downloads by Sun). I don't see
a reason why this would change in the future. At the end, the good thing
is that you can use pca now, and maybe switch to smpatch/SUC again later,
or you can use them in parallel, as it uses Sun's own CLI tool (patchadd)
to install patches, just like smpatch.

Sun could restrict patch downloads to their own tool at any time, but
there is no official announcement to do so in the near future.

mp.
--
Systems Administrator | Institute of Scientific Computing | Univ. of Vienna

In comp.sys.sun.admin Jeff Wieland wrote:
> removed the related packages. But, smpatch still doesn't work
> correctly. I'm attempting to verify the contents of /var/sadm/,
> but so far I haven't found anything wrong.
>
> I could probably get by with pca, but smpatch should work, and it
> bugs me that it doesn't. It indicates that something is amiss.

Unlike pca, smpatch mostly hides what it does. truss shows that it
uses "patchadd -p" to get a list of installed patches, so maybe that's
where the problem lies. Compare the output of:

showrev -p | cut -d' ' -f2 | sort
patchadd -p | cut -d' ' -f2 | sort

for differences, they should show the same list of all installed patches.
If not, it's just patchadd which has to be debugged.

mp.
--
Systems Administrator | Institute of Scientific Computing | Univ. of Vienna

In article <441eae7d$0$11868$3b214f66@usenet.univie.ac.at> Martin Paul writes:
>In comp.sys.sun.admin Jeff Wieland wrote:
>> removed the related packages. But, smpatch still doesn't work
>> correctly. I'm attempting to verify the contents of /var/sadm/,
>> but so far I haven't found anything wrong.
>>
>> I could probably get by with pca, but smpatch should work, and it
>> bugs me that it doesn't. It indicates that something is amiss.
>
>Unlike pca, smpatch mostly hides what it does. truss shows that it
>uses "patchadd -p" to get a list of installed patches, so maybe that's
>where the problem lies. Compare the output of:
>
> showrev -p | cut -d' ' -f2 | sort
> patchadd -p | cut -d' ' -f2 | sort
>
>for differences, they should show the same list of all installed patches.
>If not, it's just patchadd which has to be debugged.
>
>mp.
>--
>Systems Administrator | Institute of Scientific Computing | Univ. of Vienna

The results from these are identical. One of the three problem boxes
I might just end up reloading, but the other two I really can't for
now -- and I shouldn't have to anyway -- this isn't Microsoft Windows
after all :-).

I'll probably use pca and smpatch in parallel where I can, and pca where
smpatch won't work. Currently I'd say that pca is by far the better tool.
Thanks for your great work!
--
Jeff Wieland

In comp.unix.solaris Jeff Wieland wrote:
>>I use pca, google for it. Never an issue with it for me.
> But will pca continue to work with the coming changes at Sun w.r.t patch
> distribution?

I hope it does. I depend on PCA a lot. smpatch has not been dependable or
as accurate IMO.

Can anyone from Sun chime in on this? How about hiring the guy who wrote
it?

Throw a bone to the open source community why won't you ;-)?

I agree with the other posters, Sun should have a working patch solution
and they don't. The Linux guys never have these problems with yum.

-Sanjay