[pca] pca: Failed (unknown file type)

[Evan Bradley]

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