lps stopped working
Recently our local patch server stop working correctly.
It could have been after we upgraded to 1.0.8
Anyway what its doing is it starts downloading patches to /var/sadm/spool/patchsrv/Patches as a .jar.tmp file as normal.
But after downloading it instead of renaming it to a .jar file, it deletes it.
Then of course the client gets a error
WARNING: The installer cannot find the patch.
I don't see any relevant messages in /var/adm/messages or /var/log/syslog
# 1
Dear Robert
Please let us know which patches are installed on your system pertaining to Update Connection and some system details using the following commands;
Version information of Sun Update Connection software packages
* SPARC:
# showrev -p | egrep -e '121453|121118|120335|121081|121563|122231|119788'
* X86:
# showrev -p | egrep -e '121454|121119|120336|121082|121564|122232|119789'
# cat /etc/release
Thank-you.
# 2
Its a fully up to date sparc box.
bondi# uname -a
SunOS bondi 5.10 Generic_118833-24 sun4u sparc SUNW,Sun-Fire-V240
bondi# showrev -p | egrep -e '121453|121118|120335|121081|121563|122231|119788'
Patch: 121453-02 Obsoletes: 120776-03, 121086-02, 119107-07 Requires: 119574-02, 119254-06 Incompatibles: Packages: SUNWcsu, SUNWcsr, SUNWccccrr, SUNWccccr, SUNWccfw, SUNWccsign, SUNWcsmauth, SUNWdc, SUNWbreg, SUNWcctpx, SUNWccinv, SUNWppror, SUNWpprou, SUNWupdatemgru, SUNWupdatemgrr, SUNWswupcl, SUNWccccfg, SUNWccfwctrl, SUNWppro-plugin-sunos-base
Patch: 121081-03 Obsoletes: Requires: 121453-02 Incompatibles: Packages: SUNWccccrr, SUNWccccr, SUNWccfw, SUNWccsign, SUNWcctpx, SUNWccinv, SUNWccccfg, SUNWccfwctrl
Patch: 121081-04 Obsoletes: Requires: 121453-02 Incompatibles: Packages: SUNWccccrr, SUNWccccr, SUNWccfw, SUNWccsign, SUNWcctpx, SUNWccinv, SUNWccccfg, SUNWccfwctrl
Patch: 121081-05 Obsoletes: Requires: 121453-02 Incompatibles: Packages: SUNWccccrr, SUNWccccr, SUNWccfw, SUNWccsign, SUNWcctpx, SUNWccinv, SUNWccccfg, SUNWccfwctrl
Patch: 121081-02 Obsoletes: Requires: 121453-02 Incompatibles: Packages: SUNWccccr, SUNWccfw, SUNWcctpx, SUNWccccfg
Patch: 121563-02 Obsoletes: Requires: 121453-02 Incompatibles: Packages: SUNWbreg
Patch: 122231-01 Obsoletes: Requires: 121453-02 Incompatibles: Packages: SUNWcctpx
Patch: 121118-03 Obsoletes: Requires: 121453-02 Incompatibles: Packages: SUNWppror, SUNWpprou, SUNWupdatemgru, SUNWppro-plugin-sunos-base
Patch: 119788-02 Obsoletes: Requires: 119107-02 Incompatibles: Packages: SUNWppror, SUNWpprou
Patch: 121118-05 Obsoletes: Requires: 121453-02 Incompatibles: Packages: SUNWppror, SUNWpprou, SUNWupdatemgru, SUNWupdatemgrr, SUNWppro-plugin-sunos-base
Patch: 121118-06 Obsoletes: Requires: 121453-02 Incompatibles: Packages: SUNWppror, SUNWpprou, SUNWupdatemgru, SUNWupdatemgrr, SUNWppro-plugin-sunos-base
Patch: 121118-08 Obsoletes: Requires: 121453-02 Incompatibles: Packages: SUNWppror, SUNWpprou, SUNWupdatemgru, SUNWupdatemgrr, SUNWppro-plugin-sunos-base
Patch: 120335-04 Obsoletes: Requires: 121453-01 Incompatibles: Packages: SUNWpprou
bondi# cat /etc/release
Solaris 10 1/06 s10s_u1wos_19a SPARC
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 07 December 2005
# 3
On the patch server, could you see if there are any errors in the last of the: /var/patchsvr/logs/catalina_log*files?
# 4
Nothing that looks like an error to me.
This is a representative sample
2006-10-03 17:25:04 HttpProcessor[3816][2]parseConnection: address=/150.203.2.89, port=3816
2006-10-03 17:25:04 HttpProcessor[3816][2] Normalized: '/solaris/' to '/solaris/'
2006-10-03 17:25:04 HttpProcessor[3816][2] Request is 'POST' for '/solaris/' with protocol 'HTTP/1.1'
2006-10-03 17:25:04 HttpProcessor[3816][2] Header authorization = Basic XzAtNTAyMzkwMjY1OnVuNmg2dDdvcWNHaGZ3NGE3YjR1L1RMdE9BUlRGT0V0bFJRd3lqLzB6UFpzNGR XRjQ4VFl0RHgrd3gxKzdmZ3FrY2xqM0RQMkx0MGdwSS9welY4eFJHV0c2SFVZSnJEZlg4ejVKWEFDS21 1ZTBJOFBka21ha2pXanVEd2F4UFBKcHFQVTdsZDByUUdsMFQvaURpMVl6TnIvblA5UEo5MnJsK0xXa2F ZNGg3Yz0=
2006-10-03 17:25:04 HttpProcessor[3816][2] Header user-agent = Java/1.5.0_07
2006-10-03 17:25:04 HttpProcessor[3816][2] Header host = bondi.anu.edu.au:3816
2006-10-03 17:25:04 HttpProcessor[3816][2] Header accept = text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
2006-10-03 17:25:04 HttpProcessor[3816][2] Header connection = keep-alive
2006-10-03 17:25:04 HttpProcessor[3816][2] Header content-type = application/x-www-form-urlencoded
2006-10-03 17:25:04 HttpProcessor[3816][2] Header content-length = 194
# 5
http://sunsolve.sun.com/search/document.do?assetkey=1-26-102639-1Can you review the link above and update as required....this may be causeing the problems you are experiencing.
# 6
I think I have similar problem.
All patches presented as available fail to download.
The root cause seems to be this
2006-10-03 10:54:54 Tue Oct 03 10:54:54 PDT 2006(ERROR) => com.sun.patchpro.server.ServerPatchServiceProvider@608760 <=Failed to validate th
e digital signature(s). for: /var/sadm/spool/patchsvr/Patches/119060-17.jar.tmp: The specific Jar file is not signed by a known digital cert
ificate. 119060-17/README.119060-17 CN=Enterprise Services Patch Management, O=Sun Microsystems Inc
seen in /var/patchsrv/localhost_log.2006-10-03.txt
# 7
it does look like I do have this issue.
wondering how that happened, other environments configured identically did not end up in this state.
However, the note is not very helpful in instructions how to
recover. It seems to assume reader is already experienced in
managing the java keystore. I have not yet had any need to do
that so could appreciate a pointer.
The note also states that 121119-06 should have corrected
the problem. I have that patch installed, but still have the problem.
# 8
further reading of note and docs tells us how to import the certificate
in case you manually use patchadd. I did that. But that doesnt
solve the problem with updatemgr failing to verify the signatures.
That was supposed to be fixed in 121119-06. I had no problem
with that patch. But shortly after applying 121119-08 the problem
started to happen (presumably after Sun started using the new
signing certificate)
So we still need a way to patch ourself out of this state.
# 9
I am also having the same issue on my lps server. Both before and after applying 121118-08
...
Update 119903-02 will not be downloaded since it already exists in the download directory.
Update 119059-18 will not be downloaded since it already exists in the download directory.
The following patches were not downloaded:
119252-13: 119252-13Unexpected error while accessing the requested patch.
123494-02: 123494-02Unexpected error while accessing the requested patch.
122761-01: 122761-01Unexpected error while accessing the requested patch.
119280-07: 119280-07Unexpected error while accessing the requested patch.
#
These patches showed as .tmp files in the LPS dir, then were deleted. The logs appear to show they had invalid sigs.
Here's a grep of the log for the first one: 119252-13
2006-10-03 15:33:17 Tue Oct 03 15:33:17 PDT 2006(DEBUG) => com.sun.patchpro.server.ServerPatchServiceProvider@59fb21 <=Adding 119252-13 to the POST list...
2006-10-03 15:33:17 Tue Oct 03 15:33:17 PDT 2006(DEBUG) => com.sun.patchpro.server.ServerPatchServiceProvider@59fb21 <=Post String: action=patchDownload&version=2.1&patchId=119252-13
2006-10-03 15:33:18 Tue Oct 03 15:33:18 PDT 2006(DEBUG) => com.sun.patchpro.server.ServerPatchServiceProvider@59fb21 <=Patches returned: 119252-13.jar&250841
2006-10-03 15:33:18 Tue Oct 03 15:33:18 PDT 2006(DEBUG) => com.sun.patchpro.server.ServerPatchServiceProvider@59fb21 <=PatchID: /jumpstart/patches/patchsvr/Patches/119252-13.jarSize: 250841
2006-10-03 15:33:18 Tue Oct 03 15:33:18 PDT 2006(DEBUG) => com.sun.patchpro.server.ServerPatchServiceProvider@59fb21 <=The patch returned by server is PatchID: /jumpstart/patches/patchsvr/Patches/119252-13.jarSize: 250841
2006-10-03 15:33:18 Tue Oct 03 15:33:18 PDT 2006(DEBUG) => com.sun.patchpro.server.ServerPatchServiceProvider@59fb21 <=/jumpstart/patches/patchsvr/Patches/119252-13.jar.tmp
2006-10-03 15:33:18 Tue Oct 03 15:33:18 PDT 2006(DEBUG) => com.sun.patchpro.server.ServerPatchServiceProvider@59fb21 <=Created /jumpstart/patches/patchsvr/Patches/119252-13.jar.tmp
2006-10-03 15:33:20 Tue Oct 03 15:33:20 PDT 2006(ERROR) => com.sun.patchpro.security.SignatureValidationUtil@1f01a29 <=SignatureValidationUtil.validateJarFile(): The specific Jar file is not signed by a known digital certificate. 119252-13/.diPatch CN=Enterprise Services Patch Management, O=Sun Microsystems Inc
2006-10-03 15:33:21 Tue Oct 03 15:33:20 PDT 2006(ERROR) => com.sun.patchpro.server.ServerPatchServiceProvider@59fb21 <=com.sun.patchpro.security.NotSignedByKnownCertificateException: The specific Jar file is not signed by a known digital certificate. 119252-13/.diPatch CN=Enterprise Services Patch Management, O=Sun Microsystems Inc
2006-10-03 15:33:21 Tue Oct 03 15:33:21 PDT 2006(ERROR) => com.sun.patchpro.server.ServerPatchServiceProvider@59fb21 <=Failed to validate the digital signature(s). for: /jumpstart/patches/patchsvr/Patches/119252-13.jar.tmp: The specific Jar file is not signed by a known digital certificate. 119252-13/.diPatch CN=Enterprise Services Patch Management, O=Sun Microsystems Inc
2006-10-03 15:33:21 Tue Oct 03 15:33:21 PDT 2006(DEBUG) => com.sun.patchpro.server.ServerPatchServiceProvider@59fb21 <=Added patch 119252-13 to the list. ErrString: Failed to validate the digital signature(s).
2006-10-03 15:33:21 Tue Oct 03 15:33:21 PDT 2006(DEBUG) => com.sun.patchpro.server.PatchProServerServlet@ed662d <=rejects: 119252-13&1
2006-10-03 15:33:21 Tue Oct 03 15:33:21 PDT 2006(DEBUG) => com.sun.patchpro.server.ServerPatchServiceProvider@59fb21 <=Adding 119252-13 to the POST list...
2006-10-03 15:33:21 Tue Oct 03 15:33:21 PDT 2006(DEBUG) => com.sun.patchpro.server.ServerPatchServiceProvider@59fb21 <=Post String: action=patchDownload&version=2.1&patchId=119252-13
2006-10-03 15:33:22 Tue Oct 03 15:33:22 PDT 2006(DEBUG) => com.sun.patchpro.server.ServerPatchServiceProvider@59fb21 <=Patches returned: 119252-13.jar&250841
2006-10-03 15:33:22 Tue Oct 03 15:33:22 PDT 2006(DEBUG) => com.sun.patchpro.server.ServerPatchServiceProvider@59fb21 <=PatchID: /jumpstart/patches/patchsvr/Patches/119252-13.jarSize: 250841
2006-10-03 15:33:22 Tue Oct 03 15:33:22 PDT 2006(DEBUG) => com.sun.patchpro.server.ServerPatchServiceProvider@59fb21 <=The patch returned by server is PatchID: /jumpstart/patches/patchsvr/Patches/119252-13.jarSize: 250841
2006-10-03 15:33:22 Tue Oct 03 15:33:22 PDT 2006(DEBUG) => com.sun.patchpro.server.ServerPatchServiceProvider@59fb21 <=/jumpstart/patches/patchsvr/Patches/119252-13.jar.tmp
2006-10-03 15:33:22 Tue Oct 03 15:33:22 PDT 2006(DEBUG) => com.sun.patchpro.server.ServerPatchServiceProvider@59fb21 <=Created /jumpstart/patches/patchsvr/Patches/119252-13.jar.tmp
2006-10-03 15:33:24 Tue Oct 03 15:33:24 PDT 2006(ERROR) => com.sun.patchpro.security.SignatureValidationUtil@1f01a29 <=SignatureValidationUtil.validateJarFile(): The specific Jar file is not signed by a known digital certificate. 119252-13/.diPatch CN=Enterprise Services Patch Management, O=Sun Microsystems Inc
2006-10-03 15:33:24 Tue Oct 03 15:33:24 PDT 2006(ERROR) => com.sun.patchpro.server.ServerPatchServiceProvider@59fb21 <=com.sun.patchpro.security.NotSignedByKnownCertificateException: The specific Jar file is not signed by a known digital certificate. 119252-13/.diPatch CN=Enterprise Services Patch Management, O=Sun Microsystems Inc
2006-10-03 15:33:24 Tue Oct 03 15:33:24 PDT 2006(ERROR) => com.sun.patchpro.server.ServerPatchServiceProvider@59fb21 <=Failed to validate the digital signature(s). for: /jumpstart/patches/patchsvr/Patches/119252-13.jar.tmp: The specific Jar file is not signed by a known digital certificate. 119252-13/.diPatch CN=Enterprise Services Patch Management, O=Sun Microsystems Inc
2006-10-03 15:33:24 Tue Oct 03 15:33:24 PDT 2006(DEBUG) => com.sun.patchpro.server.ServerPatchServiceProvider@59fb21 <=Added patch 119252-13 to the list. ErrString: Failed to validate the digital signature(s).
2006-10-03 15:33:24 Tue Oct 03 15:33:24 PDT 2006(DEBUG) => com.sun.patchpro.server.ServerPatchServiceProvider@59fb21 <=Requested patch file name: /jumpstart/patches/patchsvr/Patches/119252-13.jar
ljcqs152:
# 10
definately related to LPS, I unset the source so it wouldn't go through LPS and smpatch downloaded the patches fine. Obviously this down't help me for all my other hosts though.
patchpro.patch.sourcehttp://localhost:3816/solaris/ https://getupdates1.sun.com/
patchpro.patch.source-https://getupdates1.sun.com/
...
Update 119903-02 will not be downloaded since it already exists in the download directory.
Update 119059-18 will not be downloaded since it already exists in the download directory.
119252-13 has been validated.
123494-02 has been validated.
122761-01 has been validated.
119280-07 has been validated.
#
# 11
I don't believe I am experiencing the problem iin http://sunsolve.sun.com/search/document.do?assetkey=1-26-102639-1
Firstly I do have patch 121118-06 both on the LPS and the host that is being updated.
And secondly I am not seeing any errors about patches failing to validate.
In fact I'm not seeing any error messages at all. Except for "couldnt find the patch".
# 12
My mistake, Ive now spotted the validate errors in /var/patchsvr/logs/localhost_log.date.txt
And as the previous poster pointed out, the infodoc provides a method of getting manual patchadd to work.
Or we can stop using our lps and get smpatch on each host to grab the patches directly.
But we still need a method of getting the lps to work...
I tried backing out 121118-08, but it didnt help
# 13
On the machine that is the patch proxy.
smpatch update direct to sun works. So obviously has the correct certs installed.
But smpatch update to the lps on the local machine doesnt. It complains about certs.
So I am guessing that smpatch and the lps use different certificate stores.
And the patch 121118 update the smpatch certs but not the lps certs....
# 14
I'd have to agree with Robert.
It would be nice if Sun would work this a bit, I've already got admins annoyed because smpatch isn't working due to LPS being broke.
Sure I could open a case, but where's the fun in that. I'll give forums through today then open a case.
JB
# 15
The problem is that Sun has switched over to use a new signing certificate, but LPS is still looking at the old certificate.We are currently working on a formally released fix for this problem.
In the meantime, there is a simple workaround which you can implement on the LPS server:
1. Make sure that you have installed the SWUP 1.0.8 Client update on the LPS. That would be update 121118-08 (SPARC) or 121119-08 (x86).
2. Edit /var/patchsvr/solaris/WEB-INF/web.xml using your favorite text editor by changing the "patchsvr.security.patch.signingcert" parameter value from "patchsigning" to "patchsigning:patchsigning2".That should end up looking like:
<init-param>
<param-name>patchsvr.security.patch.signingcert</param-name>
<param-value>patchsigning:patchsigning2</param-value>
</init-param>
3. Restart the LPS by running:
# patchsvr stop
# patchsvr start
as root.
Following those steps should remedy your problems. Clients not using LPS will not encounter this problem as it was resolved as part of the 1.0.8 update.
I'll follow this thread for a few days to make sure that you haven't had any other issues. I apologize for the inconvenience.
# 16
Thanks. That seems to fix it.
# 17
Thanks.
That's fixed the validation issue and the patches are retained once downloaded on the lps.
However there seems to be a problem in that the clients don't wait for the downloads to complete and report "WARNING: The installer cannot find the patch."
This happens whether using smpatch update or updatemanager.
# 18
I noticed the same actually.Wasnt sure what were happening, but after a reboot andtrying again, updatemanager did install the patches.Thought it was the reboot that did it.
# 19
I saw the same thing as well, I thought it was just confused about the patches that had failed on preceeding runs.I waited till all downloaded on the lps completed. Then the updates worked.I guess we won't know if its an ongoing problem until another patch comes down the
# 20
My guess is that it was reporting those errors based on the previously cached results/analysis from the lps. These should clear by themselves (or of course following a reboot or manual clearing of the cache)
# 21
worked for me too. All smpatch commands (no updatemanager or updateconnection tried)
Here's some other notes for those that care:
on lps clients where I didn't clear the cache dir I got errors on downloads and re-ran download without issues. Generally I clear everything out of /var/sadm/spool on LPS clients before doing work (except on the LPS server where the cache dir needs to remain cause that's were the registration is). This might be overkill but I rarely have issues with smpatch and when I do it's due to a valid bug like this one.
on lps clients where I cleared the cache dir first, there were no errors on analyze or download.
It should be noted that Sol9/Sol10 won't recreate a cache dir on first analyze, Sol8 does. Annoying, but no big deal unless you are scripting the work and need to allow for that.
Solaris 10 clients didn't seem to care that 121118-08 wasn't installed, the analyze shows all needed patches including this one.
Solaris 9 clients required the wbem patch 112945-43 to be installed before analyze would show all needed patches.
Solaris 8 requires the PatchPro patch 124270-01 before showing other needed patches.
# 22
I re-tested this when a few new patches showed up.
Never downloaded before. Then, updatemanager says they
are available, I select them for update and wait. Then, after
a few minutes I get the result popup stating they ALL failed.
Then I exit updatemanager, I see that local patch server
is still busy downloading something, waiting for that to finish,
then starting updatemanager again and then I can install
those patches. So there seems to be a synhronization problem
between updatemanager and local patch server. Didnt try
smpatch directly.
# 23
Did you try clearing the cache first?
# 24
I'm still getting the same problem on solaris 10. Solaris 9 seems ok.And yes, I cleaned the cache first.
# 25
Dear Robert,
If I am understanding your setup correctly your Sun Update Connection proxy (previously called an LPS) , which is running Solaris 10 , is working ok for your Solaris 9 clients however not for your Solaris 10 clients?
May I ask if you applied that patch and the workaround to the Update Connection proxy _and_ any Solaris 10 clients?
Additionally , is the Update Connection proxy downloading patches ok for itself or is it failing for both itself and its S10 clients?
Regards,
Moderator
# 26
Well, I'm getting inconsistent results.
I ran a update through the SUC proxy.
And it seemed to work ok.
And since then I have been seeing less problems. So maybe patching the SUC proxy fixed something. But it was pretty close to up to date. And none of the patches installed looked particularly relevant.
But I also installed packages SUNWsam SUNWsamr SUNWcacaort and SUNWscn* to the SUC proxy. So I could install patch 124171-01. I don't know if its connected to the whole SUC system.
This stuff is hard to debug as its timing dependent.
You run an update and it fails, but the SUC proxy starts downloading the patch in the background anyway. And next time you try to update something the patch has downloaded so now it works.
Ive been trying to develop a repeatable testcase.
I start with a completely patched client.
I patchrm a test patch on the client.
Stop the proxy. Delete that patch from the SUC proxy.
Start the proxy again.
Then do a smpatch update which gets just that patch.
But I'm having trouble reproducing the bug on demand.
Maybe it only fails for larger number of patches. Or maybe something got fixed.
I tried with and without the update to /var/patchsvr/solaris/WEB-INF/web.xml on the client.
I had assumed that that change was only relevant on the SUC proxy.
But so far it doesnt seem to making a difference.
# 27
Has anyone has found the fix for this yet? The work around seems to be working, but what does it do really? There does still seem to be a syncronation problem.
# 28
To clarify - the workaround is for the certs issue, the issue with the patches not being provided by the SunUC proxy but still being downloaded is a seperate issue.
To date we've been unable to replicate the download issue. The SUNWcacaort and SUNWscn* packages are most likely required by the SunUC proxy and i'm surprised that there were not issues with the clients too if these packages are not installed. Can anyone else having problems confirm that these packages are installed?
# 29
Hmm, as far as I am aware, those packages are not installed by default on Solaris 10 prior to 6/6.So if their needed by the SUC system, you have a dependency problem...
# 30
Sorry I did mean on 6/06 releases and not on previous ones
# 31
I can confirm this is still happening.My proxy is 01/06 but I tried adding the extra package from 6/06.
# 32
Robert,When you previously cleared the cache can you confirm exactly what you cleared?
# 33
I tend to docd /var/sadm/spoolrm -rf 1*rm cache/*rm cache/*/*This is on the client machine, not the proxy.
# 34
Adding the other cert into the xml file has given me back the pre 1.0.8 smpatch severs but I still get a response code 400 from any that are 1.0.8.
The cataline_log.2006-10-17.txt contains only
2006-10-17 21:01:29 Tue Oct 17 21:01:29 EST 2006(INFO) => com.sun.patchpro.server.PatchProServerServlet@ba5bdb <=Protocol version: 2.0
2006-10-17 21:01:29 Tue Oct 17 21:01:29 EST 2006(ERROR) => com.sun.patchpro.server.PatchProServerServlet@ba5bdb <=Invalid request: Either the "action" parameter was not specified or multiple "action" parameters were detected.
2006-10-17 21:01:29 Tue Oct 17 21:01:29 EST 2006(INFO) => com.sun.patchpro.server.PatchProServerServlet@ba5bdb <=Protocol version: 2.0
2006-10-17 21:01:29 Tue Oct 17 21:01:29 EST 2006(ERROR) => com.sun.patchpro.server.PatchProServerServlet@ba5bdb <=Invalid request: Either the "action" parameter was not specified or multiple "action" parameters were detected.
for any of the failed requests, everything else looks normal. Changing the 1.0.8 smpatch client to go direct rather than using the proxy works like a charm.
# 35
Hello Robert,Please can you run the following command on the system which you have cleared the cache on:ls -l /var/sadm/spool/Regards,Moderator
# 36
talwood# ls -l
total 10
1 drwxr-xr-x5 root 1024 Oct 18 12:41 ./
1 drwxr-xr-x 13 root 512 Oct 16 12:26 ../
1 drwxr-xr-x4 root 512 Oct 18 12:41 cache/
2 -rw-r--r--1 root 1895 Oct 16 12:13 disallowed_patch_list_report
4 drwxr-xr-x2 root 3584 Oct 16 12:11 patchproSequester/
1 drwxr-xr-x4 root 512 Mar 8 2006 patchsvr/
# 37
Hello Robert,
You have stated that you have cleared out the cache one of your systems which was not the SunUC proxy.
However the "ls -l /var/sadm/spool/" output which you have provided appears to be from a SunUC proxy:
1 drwxr-xr-x 4 root 512 Mar 8 2006 patchsvr/
Please can you run the folllowing command on one of the SunUC client systems which is exhibiting this behaviour:
rm -rf /var/sadm/spool/cache/*
And then run and smpatch analyze again.
Regards,
# 38
Well, all of the systems have SunUC proxy installed, it comes by default.
But in this case I'm not using the proxy off that machine.
I can't do this unless some more patches are available to be installed.
But luckily a new batch came out today.
However clearing the cache didnt make any difference.
BTW, smpatch analyze works just fine.
Its smpatch update which shows the problem...
