Sun Update Connection Proxy - not getting patches?
I've deployed SUCP and it has full access to the Internet. If I point any clients at the proxy server and run 'smpatch analyze', it returns "No patches required.". If I point the client directly at sunupdates1.sun.com, it returns a list of patches. This can be seen below:
root@seashell# smpatch set patchpro.patch.source=http://localhost:3816/solaris/
root@seashell# smpatch get patchpro.patch.source
http://localhost:3816/solaris/
root@seashell# smpatch analyze
No patches required.
root@seashell# smpatch set patchpro.patch.source=https://getupdates1.sun.com/
root@seashell# smpatch get patchpro.patch.source
https://getupdates1.sun.com/
root@seashell# smpatch analyze
120199-07 SunOS 5.10: sysidtool patch
119252-15 SunOS 5.10: System Administration Applications Patch
119315-07 SunOS 5.10: Solaris Management Applications Patch
...
...
This may be a case of my expectations of what SUCP should do being wrong. I would expect any client that needed a patch would tell the proxy server, which would download the patch from Sun, and pass back to the client. It appears that SUCP becomes a definitive source of patches for the client - so if the patch isn't on SUCP, the client doesn't get it. I've followed the steps as per the admin guide (http://docs.sun.com/source/835-0615/index.html) but it seems like there's a step missing. Should I be getting a patch catalogue that clients can reference?
(btw the document appears to be wrong, as it talks about downloading "updateConnection-proxy-sparc.zip" yet a search on Sun shows this document is the only reference to that file)
Any advice? Have I missed an obvious step in getting SUCP running?
Iain
# 1
The document is a little out of date with regards to the smpatch settings.
The current list of patches for Solaris 10 hosts are:
# 11978[8|9]-07: Sun Update Connection Proxy 1.0.9
# 12033[5|6]-04: Sun Update Connection Client Localization
# 12108[1|2]-06: Connected Customer Agents 1.1.0
# 12111[8|9]-11: Sun Update Connection System Client 1.0.8
# 12145[3|4]-02: Sun Update Connection Client Foundation
# 12156[3|4]-02: Sun Update Connection Registration, version 1.0.3 - NOT required for Sol10u1 and higher hosts...only initial Sol 10 release needs this (pre-cacao)
# 12223[1|2]-01: Sun Connection agents, transport certificate update
# 12300[5|6]-05: Basic Registration Update
# 124463-02: cacao 2.0 patch 02 (Sparc only - no x86 version)
# 12461[4|5]-01: sconadm proxy: UnknownHostException
Note that the numbers in square brackets refer to the [sparc|x86] version of the patch.
Assuming the latest SunUC proxy patch is installed and assuming the Patch Manager or SunUC toolset is also up to date) -
-
sol10sunucproxy # patchsvr setup -l
Patch source URL: https://getupdates1.sun.com/
Cache location: /var/sadm/spool/patchsvr
Web proxy host name: <your web proxy>
Web proxy port number: <your web proxy port>
sol10sunucproxy # smpatch get
...
patchpro.patch.source - http://sol10sunucproxy:3816/
patchpro.patchset - current
...
--
sol10client # smpatch get
...
patchpro.patch.source - http://sol10sunucproxy:3816/
patchpro.patchset - current
...
--
sol8or9client # smpatch get
...
patchpro.patch.source - http://sol10sunucproxy:3816/solaris/
patchpro.patchset - patchdb1
...
--
Please note these settings are applicable as of March 7th 2007, but may change with newer patches.
# 2
Thanks for the notes above, this works like a charm now.Do you know how SUCP will work if two hosts request the same patch at the same time?Iain
# 3
The SunUC proxy is basically just an HTTP server, so concurrent requests for the same file (or patch in this case) are not a problem.
# 4
With the right config, I often had intermitent problems without clear reasons , mainly getting following errors on clients
# correct MemoryPatchDBBuilder error
# read time out
I now scheduled following command every minute on my proxy ,and it seems to have fixed my issues.
zero size files in that dir seems to be the culprit, No rocket science here, I would be very glad if SUN could explain ....
find /var/sadm/spool/patchsvr -type f -size 0 -exec rm {} \;
# 5
Backline are investigating both the toolset and the server infrastructure about this on-going fault.-- Modski
# 6
I have following exactly the same procedure for setting up a proxy for downloading patches but i'm getting the following errors. Note that the machine i'm using can retrieve patches using smpatch and is a registered machine.
on the proxy server:
/usr/lib/cc-ccr/bin/ccr -g cns.patchsvr.patchsource
19-Mar-2007 13:05:23 com.sun.swup.updateserver.handler.CachingProxyHandler isCached
INFO: Cache Entry for key : /database/current.zip is null!
/usr/lib/cc-ccr/bin/ccr -g cns.patchsvr.patchsource
/usr/lib/cc-ccr/bin/ccr -g cns.httpproxy.ipaddr
/usr/lib/cc-ccr/bin/ccr -g cns.patchsvr.patchsource
19-Mar-2007 13:05:24 com.sun.swup.updateserver.net.ConnectionFactory getConnection
INFO: Connecting to https://getupdates1.sun.com/
/usr/lib/cc-ccr/bin/ccr -g cns.assetid
19-Mar-2007 13:05:26 com.sun.swup.updateserver.handler.CachingProxyHandler handleRequest
SEVERE: Bad Request
java.io.IOException: Bad Request
at com.sun.swup.updateserver.handler.CachingProxyHandler.getInputStream(CachingPro xyHandler.java:492)
at com.sun.swup.updateserver.handler.CachingProxyHandler.handleRequest(CachingProx yHandler.java:92)
at com.sun.swup.updateserver.UpdateServlet.proc
at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1125)
at java.lang.Thread.run(Thread.java:595)
19-Mar-2007 13:05:28 com.sun.swup.updateserver.handler.CachingProxyHandler handleRequest
SEVERE: Bad Request
java.io.IOException: Bad Request
at com.sun.swup.updateserver.handler.CachingProxyHandler.getInputStream(CachingPro xyHandler.java:492)
at com.sun.swup.updateserver.handler.CachingProxyHand
on the client:
bash-3.00# smpatch download -L
Failure: Cannot connect to retrieve detectors.jar: Bad Request
Have i done something wrong or am'i missing something ?
Thierry.
# 7
I had something similar to this in the past, and it seemed to be resolved by deleting the existing 'detectors.jar' in /var/sadm/spool/patchsvr. Also, it might be worth a check to see if the file is 0 bytes or not, as it could be that particular problem you're suffering from.
Cheers,
Iain
# 8
/var/sadm/spool/patchsvr is empty. It does not seem to get populated even when running a client via this LPS.Thierry.
# 9
What is the 'Cache location: ' from:# patchsvr setup -l?
