Hi!
In the past 2 weeks SunSolve has migrated to using Akamai for patch and
cluster downloads, to provide customers with a faster and more reliable
patch & cluster download experience.
Unfortunately, there seem to be some issues accessing patches using wget
since SunSolve's patch download mechanism has changed over to using
Akamai's download service.
These issues have been detailed in document
http://sunsolve.sun.com/search/document.do?assetkey=1-9-240066-1.
This post gives a little further information on some of the issues
introduced in that document.
So, looking at some of the issues:
1) HTTPS support is now required in the version of wget you are using to
download patches.
Why?
This is because SunSolve's new patch download service is accessed by
redirecting requests to https://getupdates2.sun.com, which subsequently
redirects to https://a248.e.akamai.net (Akamai).
What versions of wget support https?
- Wget version 1.10.x or later has https support.
How can I check which version of wget I am using?
- Use the command 'wget --version'
2) Some additional firewall rules may need to be added for wget to work
with SunSolve's new download service.
Why?
- As the new download service is accessed by redirecting from
http//:sunsolve.sun.com to https://getupdates2.sun.com initially and
subsequently to https://a248.e.akamai.net, some customers may need to
update their firewall rules to pass traffic from getupdates2.sun.com &
a248.e.akamai.net in addition to sunsolve.sun.com.
How can I verify this?
- You will need to contact your System Administrator to confirm.
3) When attempting to download a patch via wget you must now use the
'-O' or '--output-document' switch in wget to provide an output filename.
Why?
- Since moving to using Akamai the URI identifying a patch has become a
LOT longer. By default wget will name the downloaded file the same as
the URI.
- As the filename is too long an error is thrown and the download will fail.
Example of the correct syntax:
# /usr/sfw/bin/wget ---http-user="xxxxxxxx" --http-passwd="xxxxxxx"
--no-check-certificate
"http://sunsolve.sun.com/pdownload.do?target=119255-01&method=h"; -O
/tmp/119255-01.zip
What error message would you see if you hit this issue:
- Here is an example of some the output for a failing wget request:
140778-01.zip?AuthParam=1251205908_479a27379ab5595128ae9170de4228c9&TUrl=L0QdUQV8Z4i0fdED3QTP3SJDWA8FMyaJsHfIWf4X29kTWQpKEzIbwqFuyRPZ&TicketId=3q3wk1CPNxhU&GroupName=SWUP&BHost=sdlc2h.sun.com&FilePath=%2Fpatches%2Fpatchroot%2Fall_unsigned%2F140778-01.zip&File=140778-01.zip:
File name too long
Cannot write to `140778-01.zip?
AuthParam=1251205908_479a27379ab5595128ae9170de4228c9&TUrl=L0QdUQV8Z4i0fdED3QTP3SJDWA8FMyaJsHfIWf4X29kTWQpKEzIbwqFuyRPZ&TicketId=3q3wk1CPNxhU&GroupName=SWUP&BHost=sdlc2h.sun.com&FilePath=%2Fpatches%2Fpatchroot%2Fall_unsigned%2F140778-01.zip&File=140778-01.zip'
(Error 0).
4) After associating a new contract to a SunSolve account there is a
delay of up to 48 hours before wget downloads will work for patches that
the new contract should provide access to.
Why?
- The delay is due to synchronization issues between SunSolve and the
entitlement system used by Akamai.
- There is work ongoing to reduce this delay.
What error message could you expect to see until this synchronization is
compete?
- Typically you will see the following error message:
HTTP request sent, awaiting response... 403 You are not entitled to
retrieve this content.
- Note: For customers registered in the Members Support Center, after
associating a new contract to their party an initial wget request (which
will fail) is required to trigger the synchronization process.
5) If you are using wget version 1.11.x you must also use the
'--no-auth-challenge' switch in wget.
Why?
- This is related to the manner in which wget 1.11.x sends SunSolve a
users Sun Online Account (SOA) information in this version of wget (i.e.
via '--http-user' & '--http-passwd'.)
- Note wget version 1.11 does not have the '--no-auth-challenge' switch
and so is not compatible with patch downloads from SunSolve.
- Failure to include the '--no-auth-challenge' with wget 1.11.x requests
will result in the SunSolve SLA being downloaded rather than the patch.
Example of the syntax for wget 1.11.x users:
# /usr/sfw/bin/wget --no-auth-challenge --http-user="xxxxxxxx"
--http-passwd="xxxxxxx" --no-check-certificate
"http://sunsolve.sun.com/pdownload.do?target=119255-01&method=h"; -O
/tmp/119255-01.zip
6) If you do not provide wget with any direction as to how they should
handle security certificate information, patch downloads via wget will fail.
Why?
- This is happening because both domains, getupdates2.sun.com &
a248.e.akamai.net, are signed by trusted Certificate Authorities.
(Verisign for Sun's and GTE Cybertrust for the case of Akamai.) Without
a pointer to these certificates being provided to wget, download
attempts will fail.
Which certs are required?
- CN=GTE CyberTrust Global Root
- CN=VeriSign Class 3 Secure Server CA - G2
What kind of error message could you expect to see from a failing wget
request?
- The error message you will see will be:
ERROR: Certificate verification error for getupdates2.sun.com: self
signed certificate in certificate chain
To connect to getupdates2.sun.com insecurely, use `--no-check-certificate'.
Unable to establish SSL connection.
How is this issue resolved?
- If you wish to ignore this failure you can use the
'--no-check-certificate' switch in wget.
Example of the syntax:
# /usr/sfw/bin/wget --http-user="xxxxxxxx" --http-passwd="xxxxxxx"
--no-check-certificate
"http://sunsolve.sun.com/pdownload.do?target=119255-01&method=h"; -O
/tmp/119255-01.zip
- On the other hand if you wish to check against the certificates, you
can use the '--ca-certificate' switch to point to a file containing the
certificates.
- http://sunsolve.sun.com/search/document.do?assetkey=1-9-240066-1 has
an attachment called cacerts.pem, which is a concatenation of the two
certificates.
- If you save this file locally (eg to /tmp/cacerts.pem), you can use a
syntax similar to:
# /usr/sfw/bin/wget --ca-certificate=/tmp/cacerts.pem
--http-user="xxxxxxxx" --http-passwd="xxxxxxx"
"http://sunsolve.sun.com/pdownload.pl?target=142284&method=h"; -O
/tmp/140778-01.zip
7) Attempts to download a patch README file by providing "method=r" in
the URI is now failing.
What is the problem exactly?
- Prior to the latest SunSolve release it was possible to download a
patch's README file only via wget, using a syntax similar to :
# /usr/sfw/bin/wget --no-check-certificate --http-user="xxxxxxxx"
--http-passwd="xxxxxxxx"
"http://sunsolve.sun.com/pdownload.do?target=142284-01&method=r"; -O
/tmp/142284-01.README
- As of the latest SunSolve release this no longer works and attempts to
download a patch README using this URI will result in a file of 0 Bytes
being created.
Why?
- This is due to an oversight in the migration to the new download service.
- The SunSolve Engineers are working to fix this issue.
Workaround
- Until this bug is fixed it tis possible to use "method=tr" to download
a patch README file. eg. command syntax:
# /usr/sfw/bin/wget --no-check-certificate --http-user="xxxxxxxx"
--http-passwd="xxxxxxxx"
"http://sunsolve.sun.com/pdownload.do?target=142284-01&method=tr"; -O
/tmp/142284-01.README
If you come across any other issues using wget, please feel free to let
me know.
Don O'Malley
Software Patch Services
Sun Microsystems (Ireland)
