Wednesday Aug 26, 2009

Automated 'wget' patch downloads: issue resolution

My colleague, Don O'Malley, asked me to post the following on resolving issues using 'wget' to automate patch downloads.  'wget' is a popular download method, and is used by patch automation tools such as 'pca'.

Summary: You can use versions 1.10.x and 1.11.x of 'wget' but not version 1.11.  Details of options to use are set out below.  See also Patch Download Automation using wget.

SunSolve recently migrated to using Akamai for patch and patch cluster downloads, to provide customers with a faster and more reliable experience.

Some customers have experienced issues accessing patches using 'wget'.  Here's information on the issues and how to resolve them:

1) You must use a version of 'wget' which supports 'https'.

Why?

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).
Which 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?
Run the command 'wget --version'

2) You must use the '-O' or '--output-document' switch in 'wget' to provide an output filename.

Why?

The Akamai URI identifying a patch is very long.  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

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).

3) If you are using 'wget' version 1.11.x you must use the '--auth-no-challenge' switch.

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'.)
Failure to include the '--auth-no-challenge' with 'wget' 1.11.x requests will result in the SunSolve Software License Agreement (SLA) being downloaded rather than the patch.
Example of the syntax for 'wget' 1.11.x users:
# /usr/sfw/bin/wget --auth-no-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
Note, 'wget' version 1.11 does not have the '--auth-no-challenge' switch and so is not compatible with patch downloads from SunSolve.

4) You must provide 'wget' with direction on how to handle security certificate information.  Otherwise, patch downloads via 'wget' will fail.

Why?

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 can you expect to see from a failing 'wget' request?
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.
Issue resolution:
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
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

5) You may need to add firewall rules to enable '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?
Contact your System Administrator.

6) 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.

Additionally, customers registered in the Members Support Center must make an initial 'wget' call (which will fail) in order to trigger the synchronization process after associating a new contract to their party.

Why?

The delay is due to synchronization issues between SunSolve and the back-end access entitlement system.  Work is ongoing to reduce this delay.
What error message can you expect to see until this synchronization is complete ?
HTTP request sent, awaiting response... 403 You are not entitled to retrieve this content.

7) Attempts to download a patch README file by providing "method=r" in the URI is now failing.

Why?

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
There's a bug in the current 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.  This will be fixed at a later date.
Workaround:
Use "method=tr" to download a patch README file.  Example 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
About

This blog is to inform customers about patching best practice, feature enhancements, and key issues. The views expressed on this blog are my own and do not necessarily reflect the views of Oracle. The Documents contained within this site may include statements about Oracle's product development plans. Many factors can materially affect these plans and the nature and timing of future product releases. Accordingly, this Information is provided to you solely for information only, is not a commitment to deliver any material code, or functionality, and SHOULD NOT BE RELIED UPON IN MAKING PURCHASING DECISIONS. The development, release, and timing of any features or functionality described remains at the sole discretion of Oracle. THIS INFORMATION MAY NOT BE INCORPORATED INTO ANY CONTRACTUAL AGREEMENT WITH ORACLE OR ITS SUBSIDIARIES OR AFFILIATES. ORACLE SPECIFICALLY DISCLAIMS ANY LIABILITY WITH RESPECT TO THIS INFORMATION. ~~~~~~~~~~~~ Gerry Haskins, Director, Software Lifecycle Engineer

Search

Categories
Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today