Problem downloading patches.
For several weeks now we have been experiencing a number of different problems downloading patches.
1. On a Solaris 8 sparc server:
The following patches were not downloaded:
117350-39Unexpected error while accessing the requested patch.
108940-74Unexpected error while accessing the requested patch.
This problem can be overcome by retrying the download (sometimes many times) or sometimes waiting 'till the next day before trying again. KIt is not restricted to just Solaris 8. I've seen it on 9 & 10 also and sometimes there are dozens of missing patches
2. On a Solaris 10 sparc server:
123332-01 cannot be validated.
122376-01 cannot be validated.
121010-02 cannot be validated.
123132-01 cannot be validated.
119090-20 cannot be validated.
123358-01 cannot be validated.
121620-02 cannot be validated.
119213-09 cannot be validated.
118666-06 cannot be validated.
3. On a Solaris 9 sparc server:
# smpatch analyze
Cannot connect to retrieve patchdb: Server returned HTTP response code: 500 for URL: http://mypatchserver:3816/solaris/
After waiting an hour and having changed nothing it later worked. This is the most common and annoying problem.
We have around 90 servers we need to patch on a cyclical basis so we have several people doing several servers per week. These problems sometimes cause us to miss the allocated maintenance windows for the servers so it is important for us that PatchManager/UpdateManager works when we need it.
INSJohn
[1594 byte] By [
INSJohn] at [2007-11-26 9:00:28]
# 1
Please post the output of "smpatch get" from each of the 3 mentioned servers.
# 2
Thanks for the reply.
smpatch get from a Solaris 8 server:
# smpatch get
patchpro.backout.directory-""
patchpro.download.directory-/var/sadm/spool
patchpro.install.types -rebootafter:reconfigafter:standard
patchpro.patch.sourcehttp://mypatchserver:3816/solaris/https://updateserver.sun.com/solaris/
patchpro.patchset-patchdb
patchpro.proxy.host -""
patchpro.proxy.passwd********
patchpro.proxy.port -8080
patchpro.proxy.user -""
patchpro.sun.passwd ********
patchpro.sun.user-""
From a Solaris 9 server:
# smpatch get
patchpro.backout.directory-""
patchpro.download.directory-/var/sadm/spool
patchpro.install.types -rebootafter:reconfigafter:standard
patchpro.patch.sourcehttp://mypatchserver:3816/solaris/https://updateserver.sun.com/solaris/
patchpro.patchset-patchdb
patchpro.proxy.host -""
patchpro.proxy.passwd********
patchpro.proxy.port -8080
patchpro.proxy.user -""
patchpro.sun.passwd ********
patchpro.sun.user-""
From a Solaris 10 server:
# smpatch get
patchpro.backout.directory-""
patchpro.download.directory-/var/sadm/spool
patchpro.install.types -rebootafter:reconfigafter:standard
patchpro.patch.sourcehttp://mypatchserver:3816/solaris/https://getupdates.sun.com/solaris/
patchpro.patchset-current
patchpro.proxy.host "" ""
patchpro.proxy.passwd********
patchpro.proxy.port "" 8080
patchpro.proxy.user "" ""
And on mypatchserver (Sol 10 update proxy server):
# patchsvr setup -l
Patch source URL: https://getupdates.sun.com/solaris/
Cache Location: /var/sadm/spool/patchsvr
Web proxy host name: myproxy
Web proxy port number: 3128
Web proxy user:
Note that PatchManager/UpdateManager on these servers works most of the time.
# 3
I have this same problem. It seems to be when there is a alot of patches to download. I clear it by rebooting and starting over till it downloads all patches...
It seems to "hang" more frequently on the system with the least amount of memory.
$ smpatch get
patchpro.backout.directory-""
patchpro.download.directory-/var/sadm/spool
patchpro.install.types -rebootafter:reconfigafter:standard
patchpro.patch.source-https://getupdates1.sun.com/solaris/
patchpro.patchset-current
patchpro.proxy.host """"
patchpro.proxy.passwd********
patchpro.proxy.port ""8080
patchpro.proxy.user """"
# 4
INSJohn, I can deduce from you smpatch get output that you do not have the latest Sun UC patches on your Solaris 10 systems, so the first thing to do would be to apply the ltatest patches. Check to see whether you have the following patches and apply any that are missing:
121453-02 - SunOS 5.10: Sun Update Connection Client Foundation
121118-06 - SunOS 5.10: Sun Update Connection Client, System Edition 1.0.4
120335-04 - SunOS 5.10: Sun Update Connection Client Localization
121081-05 - SunOS 5.10: Connected Customer Agents 1.1.0
121563-02 - SunOS 5.10: Sun Update Connection Registration, version 1.0.3
122231-01 - SunOS 5.10: Sun Connection agents, transport certificate update
119788-02 - SunOS 5.10: Sun Update Connection Proxy, System Edition 1.0
This command can be used:
$ showrev -p | egrep -e '121453|121118|120335|121081|121563|122231|119788'
Obviously the 119788-02 patch is only relevant for the Sun UC proxy system.
CHANSL0R, are you sure your problem is the same? INSJohn didn't say he needs to reboot the system, plus you don't appear to be using a Sun UC proxy.
# 5
Thanks for the info.
Now, on my Sol 10 clients I get the following response to smpatch analyze:
Error: Unable to download entitlement information using the update server proxy.
Response code was 500
This response is new.
Is this because of the lack of those patches?
# 6
Hi INSJohn.Does smpatch analyze work on the Update proxy host?
# 7
hello,
Well yes, it's now working on all the Solaris 10 clients where it failed with the above message yesterday - including on the Update Proxy host (this machine uses itself as the proxy).
This demonstrates the problems we are seeing. It appears to be so often unavailable for a variety of reasons and we get a variety of error messages.
I note that patch 122231-01 is a certificate update. If I'm missing this patch in my proxy how is smpatch update working at all?
# 8
Dear John,
Regarding the certificates patch it is likely the previous certificates which you were using on the proxy were not yet out of date.
Would you be kind enough to tell us the order in which you added the patches, I mean to which machines first, followed by the order in which you attempted the re-try of the analysis - again which machines first.
Additionally , are you aware of any work being carried out on your network proxy recently?
Thank-you for your time.
# 9
We have updated the patches on several clients - Sol 8, 9 & 10 - since last updating the the proxy. ie. the proxy is now behind the level of many of our other severs.
As far as the order of analysis, I can't say because we have been trying to update many machines - sometimes it works and sometimes it doesn't. However the patch proxy so far is not one of the machines we have updated so as far as its level of patching is concerned it has been stable. This is part of our problem - we see varying results to smpatch analyze/download without having changed anything at our end.
As far as work on our proxy is concerned - no - there has been nothing except I have sometimes stopped & restarted the proxy server (patchsvr stop & patchsvr start) in an attempt to get things working again when we see the "response code was 500 " message on a client.
BTW. I have just tried an analyze on a Sol 8 and a Sol 9 client. Both failed with "Response code was 500". I retried them both within 5 minutes and both now worked. It is currently a very low activity and low network traffic period on our network.
Thanks for your help.
# 11
I have now updated the proxy with all the latest patches and I still see the problem of "Response code was 500" from several Solaris 8 & 9 clients. Solaris 10 is currently working OK. ie. So it's not a problem of patch level on the proxy.
# 12
This issue is going to need more indepth investigation so we recommend you log a support case via the Online Support Center, or by calling your local Sun Solution Center.
The support team will then gather from you logs from the proxy server (which can be collected using command below) and will probably need some snoop output as well.
$ cd /var/patchsvr ; tar cf - logs | gzip - > /tmp/tomcat_logs-`hostname`.tar.gz
Please make reference to this forum thread when you submit the case.
# 13
OK, thank you for your help.
# 14
I submitted a case re this problem and the response I received was to try a different patch source. viz:
https://patchpro.sun.com/servlet/com.sun.patchpro.server.PatchProServerServlet/
I now know of four sources of patches:
https://updateserver.sun.com/solaris
https://patchpro.sun.com/servlet/com.sun.patchpro.server.PatchProServerServlet/
https://getupdates.sun.com/solaris
https://getupdates1.sun.com/solaris
Does anyone know if these are actually different servers or just different names for the same beast? The Sun engineer didn't know. I haven't yet seen whether one works any better than another.
Also, a request to Sun.. If they are actually different servers, how about being able to configure more than one of them in the Update proxy and clients? ie. a primary and a backup etc.
# 15
The different servers were used for the different patching products and therefore aimed primarily at different Solaris versions.
All Solaris 10 hosts (including the SunUC proxy) should be using the getupdates.sun.com or getupdates1.sun.com as their patch source.Any lower versions of Solaris that connect through the Sol 10 SunUC proxy will be able to pull patches through the SunUC proxy for their Solaris version.
Only directly connecting Solaris 8 and 9 hosts should be using the https://updateserver.sun.com/solaris as their patch source. There may have been a short outage on this URL yesterday during some planned maintenance but there should have been no major impact.
