[pca] pca: Failed (unknown file type)
Evan Bradley
ebradley03 at gmail.com
Tue Sep 23 19:31:49 CEST 2008
Martin,
Just a quick update...
I see now that pca did not recognize the --no-check-certificate option
because it is a wget parameter. I've specified 'check_certificate =
off' in the /etc/wgetrc file and it now appears as though the invalid
certificate no longer produces any warning/error messages...though I
don't know if it is still affecting the process in some way. The
output from that command has also changed, and follows below:
[397-root at machine_name-/path/to/pca] ./pca -i -V --user=<username>
--passwd=<password> --patchurl=https://getupdates1.sun.com
Option install: 1
Option patchdir: /current/working/directory/.
Option user: <username>
Option passwd: <password>
Option patchurl: https://getupdates1.sun.com/
Option debug: 1
ARGV: missing
Version: 20080911-01
Using /usr/sfw/bin/wget (1.10.2, 11002)
Prerequisites for threads not met, setting threads to 0
Never update
Expanded patch list: missing
xref now : Tue Sep 23 13:18:56 2008
xref current: Tue Sep 23 13:08:10 2008
xref age : 646
Local file /var/tmp/patchdiag.xref is up to date
Reading from /usr/bin/showrev -p 2>/dev/null
Using /var/tmp/patchdiag.xref from Sep/22/08
Bad patch installed: 119757-08
Bad patch installed: 120272-12
121133-02 required by 119254: already installed
.
<LONG list of patches omitted>
.
Host: machine_name (SunOS 5.10/Generic_120011-14/sparc/sun4u)
List: missing
Patch IR CR RSB Age Synopsis
------ -- - -- --- --- -------------------------------------------------------
119254 42 < 58 RS- 57 SunOS 5.10: Install and Patch Utilities Patch
Downloading 119254-58 (1/274)
Trying https://getupdates1.sun.com/
/usr/sfw/bin/wget "https://getupdates1.sun.com/119254-58.zip" -O
/current/working/directory/./119254-58.zip
--13:19:02-- https://getupdates1.sun.com/119254-58.zip
=> `/current/working/directory/./119254-58.zip'
Resolving getupdates1.sun.com... 198.232.168.136
Connecting to getupdates1.sun.com|198.232.168.136|:443... connected.
WARNING: Certificate verification error for getupdates1.sun.com: self
signed certificate in certificate chain
HTTP request sent, awaiting response... 401 Unauthorized
Authorization failed.
.
The command again goes on to try the .jar, tar.Z, and .tar file
extensions using the https protocol; and again, all with the same
result. It then switches to http but eventually times out and fails.
.
I think the most important part is how I'm now getting '401
Unauthorized' and 'Authorization failed' messages, but I don't know
how I can verify my Sun login info other than logging into
Sunsolve.com, which as you already know, works just fine.
Evan
On Tue, Sep 23, 2008 at 10:55 AM, Evan Bradley <ebradley03 at gmail.com> wrote:
>
> Martin,
>
> > Are there any proxies or gateways involved on your side?
>
> I don't think so. Here's the output of an 'smpatch get' command:
>
> [358-root at machine_name-/path/to/pca] smpatch get
> patchpro.backout.directory - ""
> patchpro.baseline.directory - /var/sadm/spool
> patchpro.download.directory - /var/sadm/spool
> patchpro.install.types
> standard:singleuser:rebootafter:reconfigafter:rebootimmediate:reconfigimmediate
> rebootafter:reconfigafter:standard
> patchpro.patch.source - https://getupdates1.sun.com/
> patchpro.patchset - current
> patchpro.proxy.host - ""
> patchpro.proxy.passwd **** ****
> patchpro.proxy.port - 8080
> patchpro.proxy.user - ""
>
> > Let's try one more thing - please run:
> >
> > /usr/sfw/bin/wget --http-user ... --http-passwd ... "http://sunsolve.sun.com/pdownload.do?target=119254-58&method=h" -O 119254-58.tmp
> >
> > (all on one line). If you don't end up with the correct patch file in 119254-58.tmp, please show us its contents.
>
> That worked...the file 119254-58.tmp was saved to my current
> directory, but a 'pca -i' still fails.
>
>
> I then tried the '--patchurl=https://getupdates1.sun.com/' option, as
> that is the URL specified in the 'smpatch get' output. The results
> are below:
>
> [369-root at machine_name-/path/to/pca] ./pca -i -V --user=<username>
> --passwd=<password> --patchurl=https://getupdates1.sun.com/
> Option install: 1
> Option patchdir: /path/to/pca/.
> Option user: <username>
> Option passwd: <password>
> Option patchurl: https://getupdates1.sun.com/
> Option debug: 1
> ARGV: missing
> Version: 20080911-01
> Using /usr/sfw/bin/wget (1.10.2, 11002)
> Prerequisites for threads not met, setting threads to 0
> Never update
> Expanded patch list: missing
> xref now : Tue Sep 23 10:43:12 2008
> xref current: Tue Sep 23 08:32:16 2008
> xref age : 7856
> Local file /var/tmp/patchdiag.xref is up to date
> Reading from /usr/bin/showrev -p 2>/dev/null
> Using /var/tmp/patchdiag.xref from Sep/22/08
> Bad patch installed: 119757-08
> Bad patch installed: 120272-12
> 121133-02 required by 119254: already installed
> .
> <LONG list of patches omitted>
> .
> Host: machine_name (SunOS 5.10/Generic_120011-14/sparc/sun4u)
> List: missing
>
> Patch IR CR RSB Age Synopsis
> ------ -- - -- --- --- -------------------------------------------------------
> 119254 42 < 58 RS- 57 SunOS 5.10: Install and Patch Utilities Patch
>
> Downloading 119254-58 (1/274)
> Trying https://getupdates1.sun.com/
> /usr/sfw/bin/wget "https://getupdates1.sun.com/119254-58.zip" -O
> /current/working/directory/./119254-58.zip
> --10:43:18-- https://getupdates1.sun.com/119254-58.zip
> => `/current/working/directory/./119254-58.zip'
> Resolving getupdates1.sun.com... 198.232.168.136
> Connecting to getupdates1.sun.com|198.232.168.136|:443... connected.
> ERROR: Certificate verification error for getupdates1.sun.com: self
> signed certificate in certificate chain
> To connect to getupdates1.sun.com insecurely, use `--no-check-certificate'.
> Unable to establish SSL connection.
>
> It then tries the above download sequence for 119254-58.jar, tar.Z,
> and .tar; all with the same result. After all the https:// attempts
> fail, it tries to access http://getupdates1.sun.com (non-secure) but
> times out and never completes. I then tried the above command with
> the '--no-check-certificate' option, but pca did not recognize it.
>
>
> > Trying pca on another machine (or even from another network) might be another option to verify that it is
> > actually sunsolve's fault. Otherwise, just wait and try again tomorrow.
>
> I see what you're saying about the cached connections, but smpatch
> works from this machine and from others, so I'm just wondering why
> that command is able to access the Sun cluster when pca is not,
> assuming they're both using the same URL/download destination.
>
>
>
> Evan
>
> On Tue, Sep 23, 2008 at 9:27 AM, Martin Paul <martin at par.univie.ac.at> wrote:
> >
> > Hi,
> >
> >> Reusing existing connection to sunsolve.sun.com:80.
> >> HTTP request sent, awaiting response... 200 No headers, assuming HTTP/0.9
> >> Length: unspecified
> >
> > Here's where things go wrong. The web server on sunsolve.sun.com obviously returns an unexptected reply (without any HTTP headers?).
> >
> > Are there any proxies or gateways involved on your side?
> >
> > Most probably, it's a bogus machine in Sun's sunsolve.sun.com web cluster. When you contact sunsolve, you are directed at one of the web servers behind the load balancer, and sometimes single machines act badly. The problem is that the frontend seems to cache connections, and in the next few hours you will always be connected to the same machine.
> >
> > Let's try one more thing - please run:
> >
> > /usr/sfw/bin/wget --http-user ... --http-passwd ... "http://sunsolve.sun.com/pdownload.do?target=119254-58&method=h" -O 119254-58.tmp
> >
> > (all on one line). If you don't end up with the correct patch file in 119254-58.tmp, please show us its contents.
> >
> > Trying pca on another machine (or even from another network) might be another option to verify that it's actually sunsolve's fault. Otherwise, just wait and try again tomorrow.
> >
> >> Thanks for the help, I really appreciate it. I too went through the
> >> '403 error' smpatch madness earlier this year, so if I can get pca
> >> working and replace smpatch I'll be very happy!
> >
> > I can only hope that the impression you get from pca will get better soon (even if it's not its fault) .. :)
> >
> > Martin.
> >
More information about the pca
mailing list