Re: [pca] Date issue

[Martin Paul]

Hi,

wow - I just returned from vacation and saw that there is long thread on the 
PCA mailing list! This hasn’t happened for years :)

While I don’t plan to put time in the development of PCA anymore, this sounded 
interesting enough to take a short look. Turns out that it took 22 years for 
this Y2K issue to show up.

A little background: 

SUN decided to use 2-digit years in the patch release date column in 
patchdiag.xref, which was a bad idea. Plus, there are a handful of patches with 
an empty release date field. That’s why I used a standard date (Jan/01/71) in 
PCA to fill in the missing data, which is used to calculate the age of the 
patch.

PCA uses perl’s timelocal() function, which has an interesting way to deal with 
2-digit years. From the man page:

"Years in the range 0..99 are interpreted as shorthand for years in the rolling 
``current century,'' defined as 50 years on either side of the current year. 
Thus, today, in 1999, 0 would refer to 2000, and 45 to 2045, but 55 would refer 
to 1955. Twenty years from now, 55 would instead refer to 2055. This is messy, 
but matches the way people currently think about two digit dates. Whenever 
possible, use an absolute four digit year instead.“

So for a long time, 71 was interpreted as 1971. But in 2022, 2071 is actually 
closer to now than 1971, so suddenly timelocal() switches from 1971 to 2071.

Thanks to Marcel, who already figured this out and provided a workaround. As 
the fix is simple enough, I decided to push a new version of PCA. I’m using 
Jan/01/00 as the default date now, which should give us enough time until the 
last installation of Solaris 10 is gone… ;)

Martin.


> Am 16.08.2022 um 17:47 schrieb Ken Harford :
> 
> Hi All,
> 
> This already may have been addressed but I am new here
> 
> When running  "pca -l all” on Solaris 10 I get the following error:
> 
> Using /var/tmp/patchdiag.xref from Aug/15/22
> Cannot handle date (0, 0, 0, 01, 0, 2071) at ./pca line 2511
> 
> Has anybody else run into this? And if so is there a workaround?
> 
> Thanks
> Ken

[pca] New release: 20220902-01

[Martin Paul]

A new release of PCA has just been published. Here's a list of new features and 
changes:

 * Fix Y2K issue

Update:
 pca --update now

Download:
 http://www.par.univie.ac.at/solaris/pca/installation.html 


MD5: 8c0466d2e9b36be98785596df40825c9

Re: [pca] Download host name changed

[Martin Paul]

I have now published a new release of PCA, changing getupdates.oracle.com 
 to updates.oracle.com 
. Without an Oracle support account I cannot do 
much testing anymore, but I can download patchdiag.xref successfully, and 
others reported that patch downloads work from updates.oracle.com 
 as well.

Hope this helps the few of you who still use PCA.

Best,
Martin.

> Am 10.12.2021 um 16:59 schrieb Jeff Wieland :
> 
> The hostname for downloading patchdiag.xref appears to have changed
> from getupdates.oracle.com to updates.oracle.com.
> 
> Of course you can fix this by adding the following to your .pca file:
> 
> ohost=updates.oracle.com
> 
> --
> Jeff Wieland, UNIX Systems Administrator
> Purdue University IT Infrastructure Services UNIX Platforms
> 
> 

[pca] New release: 20220111-01

[Martin Paul]

A new release of PCA has just been published. Here's a list of new features and 
changes:

* Replace getupdates.oracle.com with updates.oracle.com 


Update:
 pca --update now

Download:
 http://www.par.univie.ac.at/solaris/pca/installation.html 


MD5: 40f8a76709092f79460e0ca9f082c6aa

Re: [pca] Download host name changed

[Martin Paul]

Hi Jeff (and everybody still reading this),

it’s been a long time since messages popped up on this mailing list :)

I took a look, and it seems as if getupdates.oracle.com 
 still exists, but the SSL certificate is 
invalid for that hostname:

/usr/bin/wget --progress=dot:binary --ca-certificate=./pca -O 
/var/tmp/patchdiag.xref "https://getupdates.oracle.com/reports/patchdiag.xref";
--2021-12-14 10:44:10--  https://getupdates.oracle.com/reports/patchdiag.xref
Resolving getupdates.oracle.com (getupdates.oracle.com)... 104.96.155.106, 
2a02:26f0:ea:48d::4425, 2a02:26f0:ea:486::4425
Connecting to getupdates.oracle.com 
(getupdates.oracle.com)|104.96.155.106|:443... connected.
ERROR: no certificate subject alternative name matches
requested host name 'getupdates.oracle.com'.
To connect to getupdates.oracle.com insecurely, use `--no-check-certificate’.

I looked at the certificate details of https://getupdates.oracle.com 
 in the browser, and it seems as if the 
certificate is for peo-eas-esps-prod.oracle.com 
 and has a lot of alternative names (e.g. 
updates.oracle.com ), but getupdates.oracle.com 
 is missing in this list, and the certificate is 
therefore not valid for that hostname.

Unfortunately Don O’Malley doesn’t seem to work for Oracle anymore, but back in 
2018 he told me about two other guys working for the patch team. I contacted 
them, let’s see if they can get the certficate fixed so PCA would work out of 
the box again.

Until then, everybody still using PCA can use Jeff’s workaround.

Best,
Martin.


> Am 10.12.2021 um 16:59 schrieb Jeff Wieland :
> 
> The hostname for downloading patchdiag.xref appears to have changed
> from getupdates.oracle.com to updates.oracle.com.
> 
> Of course you can fix this by adding the following to your .pca file:
> 
> ohost=updates.oracle.com
> 
> --
> Jeff Wieland, UNIX Systems Administrator
> Purdue University IT Infrastructure Services UNIX Platforms
> 
> 

Re: [pca] New release: 20190715-02

[Martin Paul]

Am 15.07.2019 um 16:05 schrieb Dennis Clarke:

On 7/15/19 3:24 AM, Martin Paul wrote:
A new release of PCA has just been published. Here's a list of new 
features and changes:


wow.

It has been a while.


Indeed :) I had not planned to ever release a new version of PCA, but 
Oracle turning off TLS1_0 on their servers broke all downloads, and 
there was a very simple fix for that. Plus, I was a little bored at that 
moment and was curious whether my notes on how to publish a new release 
were good enough. They were, but I do not plan to do that again.


Best regards,
Martin.

[pca] New release: 20190715-02

[Martin Paul]

A new release of PCA has just been published. Here's a list of new 
features and changes:


 * Fix version info
 * Remove --secure-protocol=TLSv1 setting for downloads from Oracle server

Update:
  pca --update now

Download:
  http://www.par.univie.ac.at/solaris/pca/installation.html

MD5: 8afbde1e30aae35cbb6ae519d93a5ac9

Re: [pca] patch downloads broken

[Martin Paul]

Am 03.05.2018 um 13:50 schrieb BABAULT.Daniel:

Hello,

Some patches are OK (Oracle Studio, Java), others not …


Seems as if Oracle Premier Support allows patch downloads for Solaris 10 
patches before Feb 1st 2018 and unbundled products (Java, Studio, etc.).


For Solaris 10 patches *after* Feb 1st 2018, you need Extended Support.

Martin.

[pca] Solaris 10 gone into extended support

[Martin Paul]

Dear PCA users,

I have been informed that Solaris 10 has gone into extended support on 
February 1st 2018. This means that you will not be able to download 
(new) patches for Solaris 10 anymore with your standard Oracle Premier 
Support.


The blog article at 
https://blogs.oracle.com/solaris/oracle-solaris-10-support-explained 
tells you which options you have:


1) Continue your Oracle Premier Support for Systems or Oracle Premier 
Support for Software subscription and migrate to Oracle Solaris 11 free 
of charge.


2) Transition to Oracle Solaris 10 Extended Support and be entitled to 
continue to receive updates as you already have been.


3) Transition to Oracle Solaris 10 Sustaining Support. You will be 
entitled to patches that were available as of January 31, 2018. So, even 
if your systems aren't quite up to date, you will be able to update them 
to those fixes in the future.


4) Discontinue Oracle Solaris 10 Support.


Best regards,
Martin.


Am 03.05.2018 um 09:35 schrieb Martin Paul:
I've had two independent reports about patch downloads failing with 
"ERROR 403: Forbidden" since last week. It seems as if Oracle has 
changed or broken something in their hands-off patch download service.

[pca] patch downloads broken

[Martin Paul]

Dear PCA users,

I've had two independent reports about patch downloads failing with 
"ERROR 403: Forbidden" since last week. It seems as if Oracle has 
changed or broken something in their hands-off patch download service.


The only thing I can do is to contact Don O'Malley from Oracle, who has 
helped with such issues in the past. He's out of of office until May 
14th, though, so don't expect any quick solution soon.


Martin.

Re: [pca] Using PCA for obtaining other-than S10 patches

[Martin Paul]

Hi,

Am 05.05.2017 um 18:23 schrieb noskcaJ leahciM:
https://updates.oracle.com/Orion/PatchDetails/process_form?patch_num=25791246 


has S11.3 SRU 19.5 available as "Patchset 25791246" but PCA
baulks at the patch id.  Is there a way to get PCA's anger-
management preserving command-line interface to that
instrument of frustration otherwise known as MOS?


PCA can handle those classic 123456-78-style patch IDs only. Even if I 
still had a MOS-account I wouldn't be keen on messing with yet another 
style of patch downloads nowadays.


With some good luck you might not need PCA at all. Maybe it's enough to 
feed the download URL to wget, probably extended with http-user and 
http-passwd options. Or you look at PCA's debug output for a sample wget 
command and just replace the URL.


So, sorry, no chance that I would add support for those patchsets to PCA 
anytime.


Best,
Martin.

Re: [pca] Proxy/relay question

[Martin Paul]

It's been such a long time, even I have to read the docs to look up the 
configuration :)


It should work by setting xrefurl and patchurl in the secondary PCA 
proxy's pca-proxy.conf to point at the primary PCA proxy, like this:


 # Get everything from the proxy
 patchurl=http://www.networkA.org:/patches/pca-proxy.cgi
 xrefurl=http://www.networkA.org:/patches/pca-proxy.cgi

(actual URLs, ports and paths of course depend on your setup - basically 
the same setup you use on the clients in networkA).


Clients in networkB will access the proxy in networkB, which contacts 
the PCA proxy in networkA, which gets the patches from Oracle.


hth,
Martin.

Am 13.03.2017 um 10:19 schrieb Tim Hosfelt:

That's exactly what I want to do, but not sure how to do it.

On Mon, Mar 13, 2017 at 4:39 AM, Martin Paul mailto:martin.p...@univie.ac.at>> wrote:

Am 10.03.2017 um 18:36 schrieb Tim Hosfelt:

In my environment I have networks separated by firewalls.  In network A
I have
successfully set up a PCA Patch server via proxy and all hosts on
network A can
update via PCA.  In network B I have no access to a proxy server, but my
network
team did open port  through the firewall for a single host - is
there a way
to set up the single host on network B to relay requests to the PCA
Patch server
in network A?


Not sure if I understand your firewall setup correctly, but one solution
might be to build a cascade of PCA proxy servers. You'd configure the one in
network B to access the one in network A.

    hth,
    Martin.





--
Martin Paul
System Administrator

Universität Wien
Fakultät für Informatik
Scientific Computing
Währinger Straße 29/6.45, A-1090 Wien

T +43-1-4277-78409
M +43-664-60277-78409
F +43-1-4277-8-78409
martin.p...@univie.ac.at
http://informatik.univie.ac.at | http://informatik.univie.ac.at/martin.paul

Re: [pca] Proxy/relay question

[Martin Paul]

Am 10.03.2017 um 18:36 schrieb Tim Hosfelt:

In my environment I have networks separated by firewalls.  In network A I have
successfully set up a PCA Patch server via proxy and all hosts on network A can
update via PCA.  In network B I have no access to a proxy server, but my network
team did open port  through the firewall for a single host - is there a way
to set up the single host on network B to relay requests to the PCA Patch server
in network A?


Not sure if I understand your firewall setup correctly, but one solution 
might be to build a cascade of PCA proxy servers. You'd configure the 
one in network B to access the one in network A.


hth,
Martin.

Re: [pca] Issue with wget version 1.18 (Solaris 10 patch# 125215-07) :: ERROR "Unable to establish SSL connection"

[Martin Paul]

Am 17.02.2017 um 11:11 schrieb Michele Vecchiato:

Thanks Martin,
 i don't understand why with wget 1.18 the SSL Handshake failed and with
1.16 work fine...
When try to connect with the wget 1.18 client version, the apache 2 (httpd)
process core...


Now that's weird indeed. Must be some bug in apache which gets triggered 
by a change in wget 1.18.


If not done yet, I'd try to update the apache with the latest patch (if 
you're using the one that comes with Solaris) or with the most recent 
version available otherwise. If you don't want to hassle with reporting 
the bug to Oracle, the apache maintainers and/or the wget authors, I'd 
take the easy way out and just stick to wget 1.16, I guess.


Martin.

Re: [pca] Issue with wget version 1.18 (Solaris 10 patch# 125215-07) :: ERROR "Unable to establish SSL connection"

[Martin Paul]

Hi,


   i have a problem with wget ver.1.18 (125215-07). No problem with a previous
revision, wget 1.16 (125215-06). My PCA proxy (pdpcasrv1) have a Self  Signed
Certificate (https).


Just to be sure, I tried wget 1.18 with Oracle's patch download server - 
this still works fine.


To find out why wget 1.18 doesn't like to talk HTTPS to your local PCA 
proxy, I guess you'll need to collect wget debug information (put 
--debug in PCA's "wgetopt"-option or in a wgetrc or the like, or try 
wget outside of PCA) or check the log files of your PCA proxy web server.


Martin.

Re: [pca] PCA Proxy Setup

[Martin Paul]

Hi,

Am 05.10.2016 um 19:01 schrieb Timothy Hosfelt:

Small issue – my clients are communicating with the proxy cache server, but the
cache server is behind a firewall and I’m unable to successfully make an
outgoing call through the proxy as the authentication fails.  Running PCA from
the command line with .wgetrc setup with username and password works fine, but I
don’t see where I can set these option in the pca-proxy.conf file.


There are two options:

Put the proxy settings into the global /etc/wgetrc file. Maybe the best 
idea, as they will then be used for every usage of wget, system-wide.


Use PCA's "wgetopt" option in pca-proxy.conf. Something like this might 
work:


  wgetopt="--proxy-user=user --proxy-password=passwd"

Hope that helps,

Martin.

Re: [pca] Unable to download patches anymore in sparc Solaris 10 platform

[Martin Paul]

Joe,

Do you use PCA regularly and did it work before? When was the last time 
it worked?


Is your support contract active?

Please re-run the same command with --debug and show us the output.

Martin.

Re: [pca] Critical Patch List and its details.

[Martin Paul]

Hi,


I am doing one patching project in which I need all the critical patch list and 
its severity or detail that why we need to update the patch or impact if we 
don't update. Do you have any such kind of CMDB which will hekp me to prepare a 
patch list for each server?


PCA won't help you with this, as the information source it uses 
(patchdiag.xref) doesn't contain such detailed information. Maybe the 
Critical Patch Updates provide what you need:


  http://www.oracle.com/technetwork/topics/security/alerts-086861.html

ISTR that it refers patches to CVEs in some document.

What PCA can do is show you the list of those patches from the 
Recommended Patchset which are not installed on a specific system:


  pca --minimal --list missingr

Best,
Martin.

Re: [pca] Patch file not downloaded with "cipher or hash unavailable"

[Martin Paul]

Am 03.05.2015 um 11:53 schrieb Frank Langelage:

Connecting to aru-akam-secure.oracle.com|184.31.84.14|:443... connected.
OpenSSL: error:140D308A:SSL routines:TLS1_SETUP_KEY_BLOCK:cipher or hash
unavailable
Unable to establish SSL connection.


Strange. Did patch downloads work on that system before? Did you update 
wget or pca or install patches recently?


The error seems to suggest that certain ciphers are missing from the SSL 
library. If that's true, and nothing has changed on your system, it 
would mean that something must have changed on the server. Could other 
PCA users please test patch downloads and see if they get the same error?


Martin.

Re: [pca] pca broken for sparc architecture

[Martin Paul]

Am 16.04.2015 um 10:39 schrieb Borut:

Thank you Martin, wget in /usr/local/bin was a problem. The same wget was
used by pca 2 month ago without troubles...


I just saw that this error has come up twice on the PCA mailing list in 
the past, but it's still unclear what causes the problems. One time it 
helped to set the default router correctly (weird), another time it was 
a precompiled binary from sunfreeware which was missing some dependencies.


I've given up trying to understand all the oddities with wget and 
Oracle's servers. Let's just be happy that it works again :)


Martin.

Re: [pca] pca broken for sparc architecture

[Martin Paul]

Am 16.04.2015 um 09:27 schrieb Borut:

Found /usr/sfw/bin/wget (1.12, 11200, https)
Found /usr/local/bin/wget (1.15, 11500, https)
Using /usr/local/bin/wget
...
/usr/local/bin/wget --progress=dot:binary
--ca-certificate=/usr/local/bin/pca --secure-protocol=TLSv1 -O
/var/tmp/./151908-01.zip
"https://getupdates.oracle.com/all_unsigned/151908-01.zip";
--2015-04-16 09:22:13--
https://getupdates.oracle.com/all_unsigned/151908-01.zip
idn_decode failed (9): 'System iconv failed'
Resolving getupdates.oracle.com... 141.146.44.51
idn_decode failed (9): 'System iconv failed'
Connecting to getupdates.oracle.com|141.146.44.51|:443... connected.
Unable to establish SSL connection.



Seems to be a problem with your local version of wget 
(/usr/local/bin/wget), see those "idn_decode" errors.


Try to temporarily move wget away from /usr/local/bin or use --wget 
/usr/sfw/bin/wget with PCA. I'm pretty sure downloads will work then.


Try wget on the command line with some other http and https URLs. If all 
https URLs fail, try to re-compile or re-install it, depending on 
whether you installed from source or a binary package.


Martin.

Re: [pca] pca broken for sparc architecture

[Martin Paul]

Am 16.04.2015 um 08:42 schrieb Borut:

I downloaded the latest patchdiag.xref from https://support.oracle.com, but
pca couldn't find sparc patches:


Obviously you downloaded 151909 on x86 with the same user/password (?) 
and the same copy of PCA (?) without problems. Can you try to download 
151908 on that machine, too, and see if that works? Maybe it's some 
network problem.


If the problems persist, please send the output of "pca -V --user=xxx 
--passwd=xxx -d 151908-01" on the sparc machine.


Martin.

Re: [pca] pca broken for sparc architecture

[Martin Paul]

Hi,


The last version of pca script is working fine only for i86pc/i386,
but is broken for sparc architecture:


I tested here, but can't reproduce the problem. Works fine on sparc for me.


# pca -l --wgetopt="--no-check-certificate --secure-protocol=TLSv1"
Using /var/tmp/patchdiag.xref from Dec/14/14
Host: star (SunOS 5.10/Generic_150400-21/sparc/sun4u)


The patchdiag.xref is pretty old, maybe it's corrupt. Try with the most 
recent one.


And BTW, with the current version of PCA you don't need --wgetopt anymore.

Martin.

Re: [pca] Problem to download news patches

[Martin Paul]

Hi Olvier,


During this last night, my script has correctly works without problem of "Unknown 
Error". So I think also that's a problem with authentication on the Oarcle site.


Ok, that sounds fine.


But I have this other message :

Looking for 800184-03 (1267/1267)

...

--
Download Summary: 1267 total, 0 successful, 1203 skipped, 64 failed


All of the 64 failed patches are marked with "NOT FOUND IN CROSS 
REFERENCE FILE!" in PCA's output. Usually, if a patch is not in 
patchdiag.xref, you can't download it from Oracle.


Did you by chance try to download patches with "pca -d all"? Most 
probably you want "missing" instead of "all", because "all" also 
includes already installed patches. There are pre-installed patches in 
Solaris 10 update releases which are never published by Oracle, so you 
can't (and don't need to) download them.


hth,
Martin.

Re: [pca] Problem to download news patches

[Martin Paul]

Hi Olivier,

I looked at the logfiles you provided, and it's indeed a strange 
behaviour. As far as I can see you made 3 attempts (the first 2 failed, 
the 3rd worked):


pca --wget=/usr/sfw/bin/wget --wgetopt="--no-check-certificate" -d -V 
150400-22

pca  -d -V 150400-22
pca --debug -d 150400-22

Actually all commands do the same. -V/--debug is the same for PCA, and 
while the wget/wgetopt options are not necessary, they result in the 
same wget command being used by PCA.


The only difference is that you ran the third command half an hour later 
than the other two. Right now, I can only imagine that it was a 
temporary problem on the Oracle authentication server.


Maybe you can retry today (with the 3rd command above). If it fails 
again, feel free to send me the output again.


Best,
Martin.


Am 27.03.2015 um 15:50 schrieb Studer Olivier:

Hi Martin,

It's very strange. With your command I can download the patch.

You can see in my debug file (pca_debug_olivier.txt) the problem. But with your 
debug command it's works (pca_debug_olivier.txt).

But I have try as follow without success:

root@hefrjet01@/root/scripts # pca --wgetopt="--no-check-certificate" -d 
150400-22
Using /www/pca/patchdiag.xref from Mar/26/15
Host: hefrjet01 (SunOS 5.10/Generic_150400-20/sparc/sun4u)
List: 150400-22 (1/0)

Patch  IR   CR RSB Age Synopsis
-- -- - -- --- --- ---
150400 20 < 22 RS-  13 SunOS 5.10: Kernel Patch

Looking for 150400-22 (1/1)
Trying Oracle
Trying https://getupdates.oracle.com/ (1/3)
Failed (unknown file type)
Failed (Unknown Error)
Trying https://getupdates.oracle.com/ (2/3)
Failed (unknown file type)
Failed (Unknown Error)
Trying https://getupdates.oracle.com/ (3/3)
Failed (unknown file type)
Failed (Unknown Error)
Failed (patch not found)
--
Download Summary: 1 total, 0 successful, 0 skipped, 1 failed
root@hefrjet01@/root/scripts #

Regards
/Olivier


-Original Message-
From: pca [mailto:pca-boun...@lists.univie.ac.at] On Behalf Of Martin Paul
Sent: vendredi 27 mars 2015 15:22
To: PCA (Patch Check Advanced) Discussion
Subject: Re: [pca] Problem to download news patches

Hi,


With the new PCA tool, I'm not able to download the Kernel Patch and
all new patches


Did it work before? When was the last time you used successfully?

I assume you have checked validity of your MOS account and support contract. Can you 
re-run PCA with "pca --debug -d 150400-22" and post the complete output here?

Martin.

Re: [pca] Problem to download news patches

[Martin Paul]

Hi,


With the new PCA tool, I'm not able to download the Kernel Patch and all new 
patches


Did it work before? When was the last time you used successfully?

I assume you have checked validity of your MOS account and support 
contract. Can you re-run PCA with "pca --debug -d 150400-22" and post 
the complete output here?


Martin.

[pca] New release: 20150327-01

[Martin Paul]

A new release of PCA has just been published. Here's a list of new 
features and changes:


 * Add new CA certs
 * Must use --no-check-certificate for Oracle server with wget <= 1.12
 * Verify file type on patch downloads from Oracle server

Update:
  pca --update now

Download:
  http://www.par.univie.ac.at/solaris/pca/installation.html

MD5: 2745e21d035aa068ae23a530a9378dff

Re: [pca] Patch download fails

[Martin Paul]

I don't think that Oracle will (soon) fix the problem on their side, so 
I pushed out a new stable version of PCA with the previously mentioned 
changes.


If you are using /usr/sfw/bin/wget from stock Solaris, SSL certs will 
not be verified as of now. Depending on how paranoid you are, install 
and use a local version of wget > 1.12 to avoid this.


Martin.

Re: [pca] Patch download fails

[Martin Paul]

I'm now in contact with Don O'Malley from Oracle and sent him details 
about the issue. I will delay the publishing of a new stable version of 
PCA until I know if and what Oracle will do about it.


Until then, feel free to use the development version of PCA and report 
any problems you should have with that.


Martin.

Re: [pca] Patch download fails

[Martin Paul]

Am 24.03.2015 um 14:52 schrieb Glen Gunselman:

I do not remember whether the listserv allows attachments but I ran the current 
dev pca on x86 Solaris 10 (so I used 151616) - the output is attached.


Thanks Glen!

So the development version of PCA works on a Solaris 10 with the stock 
wget command again. It doesn't verify all certificates anymore, but this 
can't be fixed without the help of Oracle. Paranoid users should install 
and use a local version of wget > 1.12, which would be more secure.


I'll wait till tomorrow, but if I don't get any reports of the 
development version of PCA *not* working on somebodies system, I'll push 
out a new stable version.


Martin.

Re: [pca] Patch download fails

[Martin Paul]

Am 24.03.2015 um 11:31 schrieb Chuck Floyd:

The wget version is 1.12 with patch 125215-05 on Solaris 10 SPARC.  No joy.


Thanks for taking a look. I kind of expected that :-/

So Oracle should either change the certificate or provide an updated 
version of wget. The first option would be better, as everything would 
immediately work again on all systems. The second option would require 
an install of a new wget patch on all systems to make it work again. We 
probably will see neither of these solutions.


Martin.

Re: [pca] Patch download fails

[Martin Paul]

Thanks Jan for the detailed analysis, that makes perfect sense!

I have made two changes to the development version of PCA:

  http://www.par.univie.ac.at/solaris/pca/develop/pca

  - Add the GeoTrust CA cert
  - Use --no-check-certificate with wget versions <= 1.12

The bug with recognizing alternative names in certs seems to be fixed in 
wget 1.13.1 onwards.


For wget versions <= 1.12 I have no choice but turning off certificate 
checks. That's ugly, but if Oracle doesn't change the certificate, there 
is no other choice.


Can somebody please check whether the latest wget patches for Solaris 
(125215-05 and 125216-05) provide a version of wget newer than 1.12, and 
if so, whether patch downloads work with the current development version 
of PCA?


I'd also like to encourage anybody to test the new version with other 
versions of wget, and see whether it works in all environments. If patch 
downloads fail, please post output of "pca --debug -d 151615-01".


Best,
Martin.

Re: [pca] Patch download fails

[Martin Paul]

Am 23.03.2015 um 14:27 schrieb Ken Herold:

I get for example:

Resolving aru-akam-secure.oracle.com... 104.64.51.207
Connecting to aru-akam-secure.oracle.com|104.64.51.207|:443... connected.
ERROR: cannot verify aru-akam-secure.oracle.com's certificate, issued by
`/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA':
   Unable to locally verify the issuer's authority.


Thanks!


ERROR: certificate common name `download-secure.oracle.com' doesn't match
requested host name `aru-akam-secure.oracle.com'.


I'm not sure whether this a problem with the certificate itself or with 
wget. Anybody?


I've forwarded the problem to Don O'Malley, too. Hope he still works for 
Oracle in this area.


Best,
Martin.

Re: [pca] Patch download fails

[Martin Paul]

Thanks for providing the docs, Daniel!

Doesn't look as if they were updated. Doc ID 1199543.1 (Patch download 
automation for Sun products using wget) was last updated 11-Feb-2014 and 
it does only mention the known certificates. Just to be sure - could 
you/somebody download and post getupdates.pem mentioned in that doc?


BTW - Bernd Senf said that "--wgetopt=--secure-protocol=TLSv1" was 
required for patch downloads to work as well - are you using a local 
copy of wget or the one provided with Solaris? See this note in the 
above document:


IMPORTANT:

"https://getupdates.oracle.com web server does not fully support TLS 
1.2. Only OpenSSL versions from branch 1.0.0 will work - Oracle Solaris 
does not deliver higher versions at this time. Customers who are trying 
to access the URL using latest wget/OpenSSL (ie. from www.opencsw.org) 
version with TLS 1.2 support may get connection failures."


Best,
Martin.

Re: [pca] Patch download fails

[Martin Paul]

Seems as if a new server is involved during patch downloads, which PCA 
doesn't know about. I have now added the new SSL certificates to the 
development verson of PCA:


  http://www.par.univie.ac.at/solaris/pca/develop/pca

Unfortunately I do not have a MOS account anymore, so I cannot do any 
patch download tests myself. Could somebody please try the development 
version of PCA and tell me if patch downloads work again?


If it doesn't work, please post debug output of the attempt to the list.

It would also be great if somebody could check whether these documents 
were updated recently (I can't even look at those without a MOS account):


- Solaris 10 patch access
https://supporthtml.oracle.com/ep/faces/secure/km/DocumentDisplay.jspx?id=1006630.1&h=Y

- Patch download automation for Sun products using wget
https://supporthtml.oracle.com/ep/faces/secure/km/DocumentDisplay.jspx?id=1199543.1&h=Y

Best,
Martin.

[pca] Patch download fails

[Martin Paul]

Once again Oracle has changed its patch download infrastructure causing
PCA to fail when trying to download patches. If you see download errors
please try to use PCA with --wgetopt="--no-check-certificate".

Unfortunately I can not take a closer look at that right now for personal
reasons, so do not expect an updated version of PCA in the next days.

Best,
Martin.

Re: [pca] patch download

[Martin Paul]

Am 19.02.2015 um 01:31 schrieb Tim Hosfelt:

Is there a way to download a list of patches.  Due to security/firewalls I
can only set up one server to point to oracle and I would like to use that
server to download all the needed patches in the environment.  My hope is
to run the "pca --list missing" on all servers in my environment and then
create a list of unique patch ID's I can download to the server.  Put the
into an NFS share and patch all my servers from that share (I also can't
set up an apache server due to other security restrictions).


A local caching proxy would be the easiest solution, but you would need 
an HTTP server on the system which points to Oracle for that. 
Fortunately there are other options:


You can indeed create an NFS shared directory which you fill on the 
system which can connect to Oracle, and then share and use it on the 
clients with PCAs "--patchurl file:/nfs/pca/patches" option (use 
"xrefurl" for a central source of the patchdiag.xref file as well).


To pre-download the actually required patches on your local patch server 
it's best to use the method described under "CREATING PATCH REPORTS FOR 
REMOTE MACHINES" in the PCA docs. It allows you to run pca with all its 
options on the server with the package/patch information from the 
client. You would collect the output of uname/showrev/pkginfo from all 
clients on the server (maybe use NFS again), and then run "pca 
--fromfiles /nfs/hostA --download missing" in /nfs/pca/patches for all 
your hosts. At the end you will have a local collection of all patches 
missing on all clients.


hth,
Martin.

Re: [pca] pca is not working for me

[Martin Paul]

Sujit,

Am 29.01.2015 um 19:50 schrieb Sujit Acharyya-choudhury:

The machine has direct connection to the internet.  I downloaded pca
without problem, and I can do many other downloads.  I tried to run pca
as root, assuming it would require file permission.


You do no need to run PCA as root, unless you actually want to install 
patches (--install). Otherwise I recommend to run it as a regular user.


Can you run "pca --debug" and show us the output? This will make it 
easier to see what's going wrong.


Martin.

Re: [pca] patching Sol 10 branded zones hosted on Sol 11 (UNCLASSIFIED)

[Martin Paul]

Hi Michael,

personally I haven't used PCA on Solaris 11 with branded zones, but the 
uname output you show should not be the problem.


The only difference ("Generic_150400-18" vs "Generic_Virtual") doesn't 
matter for PCA, as it doesn't use that information. So you problem must 
be elsewhere.


If "pca -yi missingrs" doesn't show any patches, maybe PCA is right 
about it? Are there any R/S patches listed when you run "pca -yi missing".


You can send me the three files needed for --fromfiles from the affected 
system, so I can try it myself.



In the midst of this work the Solaris 10 system that is used as our pca proxy
has gone fubar'd and access to its replacement hardware (a hand-me-down) has 
been
delayed until Feb.  So in addition to trying to troubleshoot the missing vs 
missingrs
issue I am also trying to move our PCA proxy over to the Solaris 11 patch repo 
system.


Getting up the PCA proxy on another system shouldn't be too much work, 
there are step-by-step instructions in the PCA manual. You can use any 
system running apache (also Linux, if that helps).


hth,
Martin.

Re: [pca] patchdiag.xref

[Martin Paul]

Am 01.12.2014 18:43, schrieb Tim Hosfelt:

Is there a way to get older patchdiag.xref files from Oracle - I'd like to
get ones from early to mid September and October.


No, unfortunately Oracle doesn't provide an archive. Many PCA users do 
so, though, so if you post specific dates here I'm sure someone can help.


hth,
Martin.

Re: [pca] It's possible create patachdiag.xref file from "/var/sadm/patch" dir?

[Martin Paul]

Am 14.11.2014 12:04, schrieb Michele Vecchiato:

Hi guys,
  for many reasons i want try to create a "patchdiag.xref" file from a
Solaris 10 installed system directory "/var/sadm/patch" list.


I can only say that the information in /var/sadm/patch won't suffice. 
Not sure whether the rest of the required data can be collected from 
/var/sadm/pkg and/or pkginfo output.


Martin.

Re: [pca] Query about clients that are not DNS-enabled

[Martin Paul]

Hi,

Am 14.11.2014 08:13, schrieb Susie Haydon:

Any suggestions on how we can work around a client that does not have
DNS lookups enabled, but is connected to the web?


I though that using "--ohost 141.146.44.51" (IP address of 
getupdates.oracle.com) would work, but wget can't verify the certificate 
then. Putting "141.146.44.51 getupdates.oracle.com" into /etc/hosts 
should work, though.


Setting up a local patch server might be another option. Check PCA's 
docs for setup examples.


hth,
Martin.

[pca] Solaris 9 exiting Extended Support period

[Martin Paul]

To whom it may concern:

-- Solaris 9 exiting Extended Support period
https://blogs.oracle.com/patch/entry/solaris_9_exiting_extended_support

Interesting part:

"...  all patches created during the Extended Support period [ed: for 
Solaris 9] will revert to "Operating System" access entitlement on MOS 
so they are available to all customers will a valid support contract, 
not just those that purchased Extended Support."


and

"There will be a final patch release cycle in November for both Solaris 
8 and Solaris 9 to release bug fixes currently in process. After that, 
there'll be no new Solaris 8 or Solaris 9 patches created.  All existing 
patches will remain available."


Martin.

Re: [pca] can't get patches

[Martin Paul]

Hi,


I can't get patches for a few days, it was OK  on 08 October


Unfortunately I do not have an MOS account anymore, so I can't test the 
download myself. Maybe someone else on the list could try to download 
118666-75 with PCA to verify that it's a local problem on your side.



I've replace secure-protocol=TLSv1 by secure-protocol=SSLv2 (on line 795)ZZa 
few month ago as our network's guy block TLSv1 (don't ask me why ?)


ISTR that TLSv1 was required as downloads didn't work. I can't say 
whether this is still a hard requirement (doesn't seem so, if it worked 
for with SSLv2 in the last months).



---request begin---
GET 
/f/248/21808/15m/sun.download.akamai.com/21808/patches/patchroot/reports/118666-75.zip?FilePath=/21808/patches/patchroot/reports/118666-75.zip&File=118666-75.zip¶ms=Unp5Uy9mMmxoVzhYOHlFTTVqTllrUTpzdW5fbWV0YWRhdGFfZmlsZT0vMjE4MDgvcGF0Y2hlcy9wYXRjaHJvb3QvcmVwb3J0cy8xMTg2NjYtNzUuemlw&GroupName=SWUP&AuthParam=1414680487_aba2e0f4fbcfde17cb2562062414fd0b
 HTTP/1.1
User-Agent: Wget/1.15 (solaris2.10)

---response begin---
HTTP/1.1 404 Not Found


Seems as if the download gets pretty far, especially beyond the Oracle 
authentication process, and wget gets redirected to Akamai as it should. 
Seems as if the patch zip file cannot be found on Akamai's server then.


About the only advice I can give is to wait some more time and retry 
daily. Often it's just an intermediate problem.


Martin.

Re: [pca] patch access

[Martin Paul]

Am 10.10.2014 10:53, schrieb Thomas Roos:

Try this in /etc/pca.conf, worked for us. Couldn’t download patches anymore 
with dltries=2, because of all the redirects at the other end.

dltries=5


Actually the redirects should not matter in the "dltries" (they are 
handled by wget, pca only receives the final result).


But after years of fighting with Sun's and Oracle's patch download 
servers I have no problem with Voodoo-like remedies, as long as they work :)


Martin.

Re: [pca] patch access

[Martin Paul]

Am 08.10.2014 17:00, schrieb Ben Taylor:

Here's the output from one of the failures.

Looking for 151487-01 (134/134)
Trying Oracle
Trying https://getupdates.oracle.com/ (1/1)
Failed (Error 401: Unauthorized)
Failed (patch not found)

Password is the same that works with MOP.

Ideas?


Unfortunately I do not have an MOS account anymore, so I can't test 
myself. I'm pretty sure that we would have seen more such reports if it 
was a general problem.


In my experience, a problem like yours often resolves itself after one 
or two days. If not, try "pca --debug --download 151487-01" to get more 
details (and maybe post them here).


Another thing to check is whether the support contract connected to the 
MOS account is still valid (the MOS account might still work even if the 
right to download patches has ceased).


hth,
Martin.

Re: [pca] Question: Downloading patches to a central server using pca-generated patch reports

[Martin Paul]

Am 30.07.2014 11:29, schrieb Gordon Morrison:

So I just need to save the contents of / patch+pkg/* and
sysconfig/uname*.out for each target system in order to generate the list of
patches to download. Is this correct?


Exactly. Here's the list of files PCA expects to find in the explorer 
directory you point it at with "--fromfiles":


  $o{fromfiles}/patch+pkg/pkginfo-l.out
  $o{fromfiles}/patch+pkg/showrev-p.out
  $o{fromfiles}/sysconfig/uname-a.out

Everything else can be removed. This should keep required space minimal.

hth,
Martin.

Re: [pca] Question: Downloading patches to a central server using pca-generated patch reports

[Martin Paul]

Am 29.07.2014 21:24, schrieb Brookins, Neil (Philadelphia):

Perhaps the solution could be to implement a third type of report? We already 
have two types (–list and –listhtml) perhaps there should be a third option to 
list only the patches and not all the other data?


PCA's "--format" option can create reports and lists in whatever format 
is required (see e.g. Roland's reply). But the best solution for the 
original problem is exactly as you state:



What I do for this issue is different. I don’t try to re-use the report output 
as subsequent input. I just keep the files for the --fromfiles=DIR around for 
reuse.  I run the report with –list then when I’m ready to download patches I 
remove the –list and put –download in its place; rerunning the same command. 
Since I use the same --fromfiles=DIR each time it downloads the correct patches 
for that same report list which was previously generated.


hth,
Martin.

Re: [pca] Inconsistant Patch Failure with 148071-13

[Martin Paul]

Am 01.07.2014 22:16, schrieb Phredd Groves:


I am finding that on a small minority of our Solaris 10 systems, as I am
attempting to install the latest OpenSSL patch (148071-13), that the
installation sometimes fails, with the following output:

...

The following requested patches do not update any packages installed on
the system
No Packages from patch 148071-13 are installed on the system.


That's a pretty clear message from patchadd. Could you try to use 
patchadd directly, outside of PCA?



I have found, though, that subsequent attempts may succeed with no notable
change in the system configuration or to the pca configuration.


That's very unusual. Again - do your testing directly with patchadd and 
see if you can reproduce that.


PCA itself isn't really involved here.


It occurs to me that this may be related to how we use pca.  We have a
server set up that our systems pull the patches from and the
patchdiag.xref from so that we keep patching consistent across machines,
but I do not have the openssl patch incorporated into that, as I did not
find any way to add a single patch to the xref data without adding every
other patch that's come down the line since our last patch refresh.


Theoretically you can add single patches to the xref file, but you must 
take care of patch dependencies, which can get pretty complicated. It's 
best to use only unmodified xref files from Oracle instead.


Martin.

Re: [pca] A question about how Safe operates.

[Martin Paul]

Am 20.03.2014 16:46, schrieb McGraw, Robert P:

Can someone explain how safe works when patching with —no-safe.


At first - keep in mind that PCA does not install patches itself, it 
uses the OS command "patchadd" for that. So PCA is not involved into 
modifying any OS files. What --safe does is documented like this:


"Sometimes a patch re-delivers and silently overwrites files which have 
been modified locally. PCA tries to overcome this issue with its safe 
patch installation mode. Before installing a patch, PCA checks all files 
listed in the patch README for local modifications. If any modified file 
is in danger of being overwritten, a warning is shown and the patch is 
skipped."


PCA collects a list of files delivered in a patch and runs "pkgchk" 
against that list. Like this, comparing the actual file size/mode/etc 
against /var/sadm/install/contents it finds out if a file has local 
modifications. If so, PCA in safe mode will skip the patch.


Often a patch includes special install scripts for files included in the 
patch, which take care that files aren't simply overwritten by patchadd. 
Sometimes the intregrate changes into existing files, leaving local 
modifications alone. Sometimes they install the new file from the patch 
with an extension ".new" and leave it to the admin to integrate the changes.


PCA has a white list of patches/files, where it knows that the relevant 
patch includes special handling, to reduce the number of false warnings.


I use PCA like that:

Install all patches with --safe. I then look at all patches which were 
skipped due to safe mode, and find out why. Then install the patches 
without --safe, and react as necessary: re-integrate local changes which 
got overwritten, integrate local changes and changes in *.new files into 
the file in question, etc.


So --safe will just tell you "ohoh, watch out, there *might* be some 
manual intervention required after installing this patch, but I can't 
tell exactly what it is".


Hope that helps,
Martin.

Re: [pca] Tweaking patchdiag.xref

[Martin Paul]

Am 17.02.2014 11:02, schrieb Dagobert Michelsen:

Isn’t mkxref from
   http://www.par.univie.ac.at/solaris/pca/contrib.html
exactly what you are looking for?


That's a script written by me? I'm getting old. Completely forgot that 
this exists. Even now I can't remember why and for whom I created it :)


Martin.

Re: [pca] Tweaking patchdiag.xref

[Martin Paul]

Hi Sergio,

I don't have a straight solution for your task, but here are some ideas:

> 1) Is there any better way to do it?

Try using "pca --minimal missingr". The "minimal" option will make PCA 
work with the list of patches in the Recommended Patch Set. So this 
command should give you a list of missing applicable patches. When 
feeding PCA an empty "showrev" output (simulating an unpatches system), 
you should get the complete number of applicable patches.



2) is pca considering that info (field #10)?


yes, it uses it to determine whether a patch is applicable or not.


3) If yes, does anybody have any tip where can I extract that info from?


besides patchdiag.xref? The "VERSION" line in the /pkginfo files, 
to be found in the extracted patch zip file.



4) Did anybody have a requirement like this before? (compare against a fixed 
set of patches)


Not me.

hope it helps,
Martin.

Re: [pca] Can't download latest Xorg patch 125720-61

[Martin Paul]

Am 10.02.2014 15:10, schrieb Richard Skelton:

Hi Martin,
Guess what it worked this time on the third attempt :-)


Good to hear!

The behaviour of Oracle's download server is a real inspiration. 
Sometimes I think Oracle employs a group of people whose only work is to 
come up with creative methods to annoy me. A very successful group, that is.


Martin.

Re: [pca] Can't download latest Xorg patch 125720-61

[Martin Paul]

Am 10.02.2014 13:35, schrieb Richard Skelton:

I am running the pca-proxy.cgi from 20140129-01.
This patch has fails to download since it came out on Sunday


My proxy downloaded it fine a few hours ago.


Mon Feb 10 12:27:10 2014: Proxy request sent, awaiting response... 200 OK
Mon Feb 10 12:27:10 2014: Length: unspecified [text/html]
Mon Feb 10 12:27:10 2014: Saving to:
`/var/apache2/htdocs/pca/125720-61.zip'
Mon Feb 10 12:27:10 2014: 2014-02-10 12:27:10 (10.4 MB/s) -
`/var/apache2/htdocs/pca/125720-61.zip' saved [3150]


The Oracle server hands your PCA proxy a 3150 byte HTML file insteads of 
the patch. Can you edit pca-proxy.cgi and comment out the "unlink" 
statement in line 745? The retry the download and look at the contents 
of /var/apache2/htdocs/pca/125720-61.zip with a text editor. Maybe it 
provided a hint on what's wrong.


Martin.

Re: [pca] 18117543 patch 144872-02 is missing a hard requirement

[Martin Paul]

Am 28.01.2014 17:30, schrieb Dennis Clarke:

last night at 17 secs after midnight this 144872-03 was slid out the door.

Anyways, makes me wonder what bugid 18117543 is.


There's now a service alert document about this issue:

  Oracle Support Document 1617874.1
  Solaris 10 Patches 144872-02/144873-02 (WITHDRAWN) May Cause Boot
  Failure if Patches 147002-01/147003-01 Are Not Also Installed

  https://support.oracle.com/epmos/faces/DocumentDisplay?id=1617874.1

Martin.

Re: [pca] New patch fails to install because the patchfile is not a patchfile

[Martin Paul]

Hi,


Can PCA not check the downloaded file is a zip file?


Thanks for the report - I've added an appropriate check to the 
development version of PCA.


Actually PCA alreadys does extensive checking of all possible replies 
from the Oracle server, but that's a moving target. In that case it's 
especially weird: PCA asks the server explicitely for a ZIP file, and 
the server returns an HTML file instead of an appropriate HTTP error code.


Martin.

Re: [pca] 18117543 patch 144872-02 is missing a hard requirement

[Martin Paul]

Am 28.01.2014 17:30, schrieb Dennis Clarke:

last night at 17 secs after midnight this 144872-03 was slid out the door.

Seems odd to me that Solaris 10 patches are released on specific schedule
except for odd little creatures like this.

Anyways, makes me wonder what bugid 18117543 is.


Oracle support doesn't let me see what BugID 18117543 is about. The main 
difference seems to be that 144872-03 now requires 147002-01 (SunOS 
5.10: libxnet.so patch). My assumption would be that ifconfig requires a 
change or a new function in libxnet.so.1 provided by that patch.


Martin.

[pca] New release: 20140115-01

[Martin Paul]

A new release of PCA has just been published. Here's a list of new 
features and changes:


 * Add new CA certs for login.oracle.com
 * Use --secure-protocol=TLSv1 with wget on all connections to Oracle 
server

 * Fix bug in HTML output
 * Whitelist: add 148104, 148105
 * Whitelist: add 150525, 150526

Update:
  pca --update now

Download:
  http://www.par.univie.ac.at/solaris/pca/installation.html

MD5: 96415657cb8f53e4577cf02afb9ef707

Re: [pca] WARNING: cannot verify login.oracle.com's certificate

[Martin Paul]

Am 14.01.2014 16:35, schrieb Jeff Earickson:

I downloaded the development version and tried it.  A whole bunch of new
patches appeared.  I also discovered that my firewall was blocking a (new
to me) Oracle subnet for downloads: 209.17.0.0/18.

For me, this change was a silent failure.  I was not seeing patches, yet
thought that everything was ok.


I think that's a different issue: Oracle nowadays publishes Solaris 
patches only once per month, and this just happened yesterday. So that's 
what might have confused you.


The problem with PCA was only affecting patch downloads.

Martin.

Re: [pca] WARNING: cannot verify login.oracle.com's certificate

[Martin Paul]

Thanks to everybody who tested the development version.

A new stable release is out now. Problem solved.

Martin.

Re: [pca] WARNING: cannot verify login.oracle.com's certificate

[Martin Paul]

Hi Dennis and all,

as reported, patch downloads stopped to work yesterday. The first 
problem was that there seems to be a new certificate used for HTTPS on 
login.oracle.com, signed by different CA certificates than before.


While this problem could be worked around, patch downloads still failed 
as login.oracle.com answered all authentication requests with "401 
Unauthorized". This second problem seems to have gone away (or fixed by 
Oracle) over night.


I fixed the problem with the HTTPS certs by including the necessary CA 
certs in the current development release of PCA:


  http://www.par.univie.ac.at/solaris/pca/develop/pca

Please try that and see if the downloads work again and let me know 
about it. I will then release a new stable release of PCA.


Martin.

Re: [pca] Issue with wget on RHEL6.5

[Martin Paul]

Am 13.01.2014 14:42, schrieb Thomas Bleek:

I just noticed problems with download again. It seems to be a
certificate problem (CA). I tried the developer version just
downloadad, same problem. MOS is working.


Something is wrong with the certificates indeed - I get a similar error:

Connecting to getupdates.oracle.com|141.146.44.51|:443... connected.
ERROR: cannot verify getupdates.oracle.com's certificate, issued by 
`/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at 
https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 International 
Server CA - G3':

  Unable to locally verify the issuer's authority.

When using pca with --wgetopt "--no-check-certificate" I can get past 
the certificate authorization, but the download fails anyway:


Resolving login.oracle.com... 209.17.4.8
Connecting to login.oracle.com|209.17.4.8|:443... connected.
HTTP request sent, awaiting response... 401 Unauthorized
Authorization failed.

No idea on what's wrong. Sigh.

Martin.

Re: [pca] Issue with wget on RHEL6.5

[Martin Paul]

Happy new year to everbody!


I'm running PCA as a proxy on a RHEL6 machine, Apparently, since early
December and an update to 6.5, it fails connecting to
getupdates.oracle.com (through a web proxy) with a message saying:
Unable to establish SSL connection.


Yeah, you had reported this problem already back in May 2013, and I had 
added the temporary fix for the CSW version of wget back then. The root 
cause was (and is) a problem with Oracle's web server:


  https://www.opencsw.org/mantis/view.php?id=5068

Oracle's web admin team planned to upgrade the web server to support 
clients with recent versions of OpenSSL, but it seems as if this never 
happened. They put a note into Support Document 1199543.1, which is 
still there:


  IMPORTANT:

  https://getupdates.oracle.com web server does not fully support TLS
  1.2. Only OpenSSL versions from branch 1.0.0 will work - Oracle
  Solaris does not deliver higher versions at this time.
  Customers who are trying to access the URL using latest wget/OpenSSL
  (ie. from www.opencsw.org) version with TLS 1.2 support may get
  connection failures.


I'd say, just always add the parameter. It works with /usr/sfw/bin/wget
(in a recently patched S10 at least) as well as with wget on RHEL >= 5.


Did exactly that in the current development release of PCA now. It seems 
as if the --secure-protocol option is supported in all relevant versions 
of wget, so this should do no harm.


Thanks for the report!

Martin.

Re: [pca] Three patches Using /var/tmp/patchdiag.xref from Nov/10/13 fail to install on a T2000

[Martin Paul]

Am 12.11.2013 13:18, schrieb Richard Skelton:

This machine was built from a flash image which can install on Sun4u and
Sun4v


Maybe that's what's creating troubles here. After looking at the 
provided files, I found out that the affected system has multiple 
versions for different architectures installed for some of the packages.


E.g. patch 150109 patches SUNWcakr.v (which means it will only apply to 
sun4v systems). In your pkginfo output I see:


SUNWcakrCore Solaris Kernel Architecture (Root)
(sparc.sun4u) 11.10.0,REV=2005.01.21.15.53
SUNWcakr.2  Core Solaris Kernel Architecture (Root)
(sparc.sun4us) 11.10.0,REV=2005.01.20.17.25
SUNWcakr.3  Core Solaris Kernel Architecture (Root)
(sparc.sun4v) 11.10.0,REV=2005.08.25.02.12

So three instances of SUNWcakr are installed, for sun4u, sun4us and 
sun4v. That's no problem for PCA, it correctly identifies 150109 to 
apply to your system.


It seems as if patchadd has a problem with that situation, though. Even 
though the VERSION in  150109-01/SUNWcakr.v/pkginfo perfectly matches 
tht installed package (SUNWcakr.3, sparc.sun4v, 
11.10.0,REV=2005.08.25.02.12), it refuses to install the patch.


Try to remove SUNWcakr and SUNWcakr.2 and check whether PCA still shows 
the patch as missing and patchadd installs it. If so, you should 
probably adapt your installation procedure.


hth,
Martin.

Re: [pca] Three patches Using /var/tmp/patchdiag.xref from Nov/10/13 fail to install on a T2000

[Martin Paul]

Strange - this patches are explicitely for the sun4v architecture (which 
the T2000 has), and they installed fine on my test T3 (which is sun4v as 
well).


Can you run these commands and send me the 3 output files:

  uname -a > uname.out
  showrev -p > showrev.out
  pkginfo -x > pkginfo.out

Martin.

Re: [pca] Forever young patches?

[Martin Paul]

Laurent,


This is getting weird: the patches already mentioned for Studio and the
shared C++ lib are still 1 day old, and they were released what, one
week ago at least?
Something is wrong in the patch release process.


I've had a conversation with Don about this issue. There is a known 
problem which is most probably the root cause of this issue, and a fix 
should be in place tonight.


Martin.

Re: [pca] xref aged 1603 considered up to date?

[Martin Paul]

Glen,


Based on the end time (09:54:15) and the ctime of /var/tmp/patchdiag.xref 
(09:54:15) if looks like the pca error processing may have resulted in the 
updating of ctime.


It's probably because PCA moves patchdiag.xref to patchdiag.xref.tmp 
before trying the download, so it has a backup copy if the download fails.



(Note:  I checked the ctime for patchdiag.xref on several servers and it 
appears that NetBackup is causing ctime to be updated when the file is backed 
up.)


Yes, looks like, after some googling. It does that for a similiar 
purpose - marking files which have been backuped for the nexte 
incremental backup.


BTW, do you know PCA's "-y, --nocheckxref" option? It will make PCA skip 
the check for updates of the xref file. If you use it with a frozen 
patchdiag.xref file, everything should be fine.


Martin.

Re: [pca] xref aged 1603 considered up to date?

[Martin Paul]

Glen,


This does not seem right to me.  Am I missing something? Isn't the number of 
days since last December less than 1603? I thought pca would download a new 
xref file if the one it found was over 1 day old.

xref mtime: Thu Dec 20 20:45:08 2012
xref now  : Wed Oct 30 10:20:58 2013
xref ctime: Wed Oct 30 09:54:15 2013
xref age  : 1603


The "age" here is the difference between "xref now" (the current time) 
and "xref ctime" (the file/inode change time) in seconds. If it's more 
than 3 hours (10800 seconds), pca will download the xref file. "xref 
mtime" is the original modification time of the xref file.


It's been a long time since I wrote that code, and I remember that it 
took me a long time to get this right. The goal was to ensure that PCA 
always works with a current xref file; it's not very efficient to 
download the xref on every PCA run, though.


Sun/Oracle updates the file once per day. In the beginning, I tried to 
find out the time of day the update happens and hard coded it into PCA, 
so it updated the xref file exactly once per day. That didn't always 
work, and things got complicated when Sun/Oracle wasn't the only source 
of the xref file anymore, after support for local proxy etc. was added.


I then made PCA maintain the original modification time of the xref 
file, as this is what's shown when doing an "ls -l". It would have been 
very confusing, if PCA updated that timestamp. So I'm using the ctime as 
a marker which notes when PCA last tried to update the file. If it has 
done so in the last 3 hours, it does nothing. Otherwise it downloads the 
"new" xref file and then compares the timestamp in the file (header 
line), and only uses the fresh file if it's really new.


Like that, PCA usually gets the current xref file when I run it for the 
first time in the morning, but subsequent runs to download or install 
patches just use the file and don't re-download the file in the next 3 
hours.


Martin.

Re: [pca] a new "R" patch

[Martin Paul]

Am 30.10.2013 21:42, schrieb Glen Gunselman:

Even though Solaris is only releasing patches on some strange Monday of the 
month the other users of patchdiag.xref seem to have their own rules.


Yes, there have always been special rules for patches for "unbundled" 
software, like firmware, compilers, etc. ISTR that the shared library 
for C++ was also considered a part of this group, maybe it's maintained 
by the compiler team.


I also notice unusual updates of the date columns for some patches in 
the past days, i.e. only the release date is changed to a patch in the 
xref file, nothing else.


Martin.

Re: [pca] PCA htmlcorrectout - patch

[Martin Paul]

Hmm, your solution is much more elegant ...


One of the reasons I implemented the out() function was to centralize 
output in one configurable function. There are still many print() calls 
in the code, though. I must admit that I never test(ed) HTML-output, as 
I'm not using it.



I would prefer the additional output below the H2 header, not before.
But it is just matter of opinion.


I put it there to make it look as close to the non-HTML output as possible.

Martin.

Re: [pca] PCA htmlcorrectout - patch

[Martin Paul]

Hi Petr,


This patch makes the output correct HTML. The plain text output is
attachet to HTML page header.


Thanks for the report and the patch - I added it (with some 
modifications) to the development version of PCA which can be downloaded 
from:


  http://www.par.univie.ac.at/solaris/pca/installation.html

Martin.

[pca] Solaris 10 Patches Now On Monthly Release Cadence

[Martin Paul]

See this blog posting from Gerry Haskins:

  https://blogs.oracle.com/patch/entry/solaris_10_patches_now_on

I had already wondered as very few Solaris 10 patches have been released 
recently. Obviously yesterday was September's "the Monday closest to 
17th of each month" (what a specification, impossible to specify that in 
a calendar app), as a bunch of new Solaris 10 patches was released.


I don't see any advantage in "... enables customers to predict patch 
release dates and schedule maintenance windows" - personally I'd prefer 
to get (security) fixes ASAP. Plus, I could always decide on my own when 
to install patches anyway.


Martin.

[pca] PCA is 10!

[Martin Paul]

PCA is 10!

Scrolling down on the PCA-News web page, at the very bottom, one finds 
this message: "2003/09/09: First version. Introducing PCA 1.0". So it's 
really 10 years now since I decided to make this script public, after 
I've been using it for some time internally. It had 208 lines at that time.


Only one day later I received the first e-mail with the subject "pca" 
from Andrew Brooks, which was a lot like the many messages I received in 
the next ten years:


First, he thanked for the useful script. Such comments from PCA users 
turned out to be my main motivation to maintain and refine PCA in the 
following years. So thanks to all of you who ever sent positive comments!


Second, he provided an idea (and included code) for some new function (a 
new option -H to output HTML) which I immediately decided *not* to 
include in the official version of PCA :-) In my answer I stated that I 
wanted to keep PCA as simple as possible, not depending on some URLs 
staying consistent on Sun's web page. I always liked Unix for its 
tradition of simple commands which can be used in pipes to achieve great 
things.


Soon other PCA users provided more and more input and I started to add 
new functions and options over the time, always weighing simplicity 
against usefulness. The option to download patches from Sun directly was 
probably one of the most useful, and the one which caused me most work 
in the last years. Sun (and later Oracle) turned the simple process of 
downloading a patch file via FTP into a complicated procedure with 
authentication, server redirects, dependencies on certain HTTP features 
etc. which I always had to follow closely to keep the download functions 
in PCA working. There were moments when I seriously thought about giving 
up on it.


While I knew that Sun engineers were using PCA themselves, and Sun never 
succeeded in providing a own, working patch administration tool (I would 
have been the first to switch, believe me!) they never officially 
acknowledged PCA, although it was recommended on some Sun websites and PDFs.


As I got a lot of e-mails in the meantime from admins asking about the 
usage of PCA and me answering the same questions over and over again, I 
created the PCA mailing lists (for those interested in numbers, I have 
4827 messages in my folder with private PCA communication, and 3139 
messages on the PCA mailing list - I definitely wrote more text than 
code). This helped a lot, as power users now answered the queries from 
beginners. I also had a lot more contact to the users of PCA and was 
fascinated in how many different ways and procedures it was being used. 
I also got in contact with Gerry Haskins and Don O'Malley from Sun, 
which made it a lot easier to sort out problems and to get information 
about the internals of Sun's patch creation and publication. Thanks to 
both of them for their help and patience!


With the appearance of Solaris 11 and its IPS system, traffic on the 
mailing list was reduced a lot. As PCA is not needed anymore on Solaris 
11, it is now being used mostly by experienced admins running Solaris 10 
who already know what they do. Personally, I also think that PCA is 
feature complete for quite some time now, and as (now) Oracle doesn't 
change their patch infrastructure anymore, new versions of PCA have been 
reduced to a minimum.


As far as I'm concerned, that's very welcome. While I still work with 
some Solaris systems, we're moving away from Solaris here slowly, due to 
the high prices of Oracle hardware and support. Of course I'll keep PCA 
working as long as somebody is still using it.


Finally, let me state that I'm pretty proud of what PCA turned out over 
the years - it has saved numerous sysadmins around the world uncountable 
hours of work and frustration. This compensates for all the time I 
invested, even if it was frustrating now and then when performing 
complicated tests to ensure PCA's analysis being correct or hunting for 
obscure bugs. Would I publish PCA 1.0 once again if I could go back to 
2003? I think so :-) If only for the amount of positive feedback I got 
over all the years.


Let me end with a quotation which is the basis of my work on PCA (and 
also in general):


"Perfection is achieved, not when there is nothing more to add, but when 
there is nothing left to take away." (Antoine de Saint-Exupery)

Re: [pca] --minimal -l missingr not working as expected

[Martin Paul]

Am 08.08.2013 18:02, schrieb Terry Bohaning:

Patch  IR   CR RSB Age Synopsis
-- -- - -- --- --- ---
119213 26 < 27 RS- 547 NSS_NSPR_JSS 3.13.1: NSPR 4.8.9 / NSS 3.13.1 / JSS 4.3.2

What concerns me are the lines similar to patch 119213 where the age exceeds
the last set of patches that were installed.


Thanks a lot to Neil for the excellent explanation!

As far as 119213 is concerned, I can provide a few more details. Until 
2013-04-21 there were two revisions of this patch - 119213-26, which was 
marked "Recommended" but already obsoleted by 119213-27, since its 
publication date of 2012-02-08.


In the patchdiag.xref file from 2013-04-22, 119213-26 disappeared and 
119213-27 was marked "Recommended".


So on that day Oracle decided to include revision 27 in the set of 
recommended patches, although it was out for more than a year at that 
time. The mechanics behind such decisions are unclear and undocumented.


In that special case it's especially strange, as revision 27 includes 
these fixes:


13341290 DIS-TRUST DIGINOTAR ROOT CERTIFICATE
13341314 (CVE-2011-3389) RIZZO/DUONG CHOSEN PLAINTEXT ATTACK (BEAST) ON 
SSL/TLS 1.0


.. which definitely sound as if they should have been "Recommended" 
right after publication of the patch in 2012.


As for the auditors, it's like Neil said: You installed all recommended 
patches which were recommended at that time. Sure there have been new 
patches and recommendations after that time, but that's something to fix 
in the next patch cycle.


hth,
Martin.

Re: [pca] is there a general mail list related to Solaris admin etc ?

[Martin Paul]

Am 26.07.2013 18:53, schrieb Paul Lanken:

Does anyone know of a mail list somewhere that is more related to day to
day admin etc ?  Wasn't there a great thing called usenet once upon a time?


Usenet is still alive, and the comp.unix.solaris group still exists. And 
there's the solarisx86 mailing list 
(http://tech.groups.yahoo.com/group/solarisx86/).


Unfortunately there is not much traffic anymore in both of them, but 
some of the Sun engineers still hang out there.


Martin.

Re: [pca] patchdiag.xref download broken

[Martin Paul]

Am 22.07.2013 10:42, schrieb Jan Holzhueter:

seems like the patchdiag.xref download is broken atm.


I didn't try it in the last 72 hours, but as of now it seems to work again.

Martin.

Re: [pca] Missing flag in new patchdiag file

[Martin Paul]

Am 16.07.2013 22:54, schrieb askin...@symcor.com:

Just an FYI - as I'm starting a new patch run -- seems that Oracle has
missed the Recommended and Security flags on the new sparc kernel.

150400|01|Jul/12/13| | | |
150401|01|Jul/12/13|R|S| |


Yes, while it's normal that it might take a day or more to see R/S added 
to new/updated patches, it's strange here that the i386 version has the 
flags while the sparc version doesn't.


Let's see what happens in the next days.

Martin.

Re: [pca] interesting patch problem with Oracle Access Manager Version: 11.1.1.5.0

[Martin Paul]

I can confirm that the problem seemed to simply "go away" all on its
own sometime last night.


Ok, let's hope it was a one-time issue.


So there I was, coffee cup in hand.  Loiking at the clock and then an
idea struck me.

- idea to use patchdiag.CHECKSUMS file to verify patch integrity


Basically a good idea, and yes, you're not the first one to have it :)

Here's a thread from 2010:

  http://www.mail-archive.com/pca@lists.univie.ac.at/msg02255.html

Back then we found out that there is (was) a simple problem with the 
CHECKSUMS file: It missed checksums for a lot of patches, and some of 
the checksums were wrong - go figure!


At some time there were plans to include the ckecksum into 
patchdiag.xref, which would have been a great thing. Alas, it never 
happened.


Martin.

P.S.: I just read that Oracle kills the Sun Ray product line 
(https://blogs.oracle.com/virtualization/entry/important_information_about_oracle_desktop). 
What a pity!

Re: [pca] interesting patch problem with Oracle Access Manager Version: 11.1.1.5.0

[Martin Paul]

Am 15.07.2013 14:23, schrieb Jan Holzhueter:

So I had to cleanup my proxy to not have bad patches. (Maybe some check
if the downloaded file is a zipfile would be nice.)


There is a check in the pca code, but it seems as if it failed in this 
case.



Looks like it was a temp problem. This morning after the cleanup the
download of the broken patches went fine. (Not sure about the number.
But was more then 10.)


Thanks for the report, good to hear that!

Martin.

Re: [pca] interesting patch problem with Oracle Access Manager Version: 11.1.1.5.0

[Martin Paul]

Am 13.07.2013 21:49, schrieb Paul Lanken:

Under normal circumstances I am able to download a collection of missing
patches from the oracle patch server with PCA just fine.  Not sure if what
I am seeing is "abnormal" however I normally just use PCA to --download
the "missing" patches and then deal with things later.


That's definitely abnormal. Strange thing is that this is the first 
report I ever got about such an issue.


Right this morning I downloaded more than 50 patches within 15 minutes, 
and it was fine. Like many others I download all my patches via a pca 
local caching proxy, so all requests come from the same IP and use the 
same MOS account - no problem at all.


So either this is a new issue (maybe Oracle changed their server setup - 
Don, are you listening?) or it was a temporary problem.


Can you please try again in the next days and report whether the problem 
persists? If so please use the --debug option with pca and send the 
output of one of the failing patch downloads.


Martin.

Re: [pca] 11866[67]-53 is not Recommended.

[Martin Paul]

Am 24.06.2013 16:07, schrieb Brookins, Neil (Philadelphia):

FYI: This issue was resolved the very next day after I sent the email
below. The Java 5 patches now have the recommended flag set in
patchdiag.xref. So, this is just a case of the patchdiag.xref updates
just taking an extra day longer for some patches than others.


Yes, that's confusing. ISTR that Don O'Malley explained this procedure 
at some time in the past. Something about compiling the Recommended 
Patch Cluster happening the night following patch publication.


Martin.

Re: [pca] patch installation stucks

[Martin Paul]

Hi,

Am 24.06.2013 13:50, schrieb Daniel Pecka:

i have some problems with patching .. i didn't use pca quite long time
and now did `pca -V -i allrs --user=$me' and installation of patches
takes endless ..


You want "missingrs" instead of "allrs", otherwise pca will try to 
install already installed patches as well.


The Java patches usually are huge and therefore take a lot of time to 
install, but I can't remember any hangs when installing them.



ps. btw the state is Installing 119060-63 (11/375) after damned 3
hours and termation of 2 patches


Unless the machine is very old, this is definitely too slow. Check the 
process list ("top", etc.) to see if something is blocking the machine.


Martin.

Re: [pca] http://www.­par.­univie.­ac.­at/­solaris/­pca/ is down?

[Martin Paul]

Am 24.06.2013 21:53, schrieb Jason Greathouse:

This is causing pca updates to fail even if we specify update=never in the
pca-proxy.conf file on our pca-proxy.cgi servers.


This will definitely stop pca-proxy.cgi from trying to update itself, no 
connection to pca's home server should be attempted then.


Same applies for pca itself, when "update=never" is set. The 
"update=never" on the pca-proxy will not override the setting in the pca 
clients pca.conf - maybe that was the problem?


hth,
Martin.

Re: [pca] http://www.­par.­univie.­ac.­at/­solaris/­pca/ is down?

[Martin Paul]

Am 24.06.2013 21:53, schrieb Jason Greathouse:

Looks like http://www.­par.­univie.­ac.­at/­solaris/­pca/ and its sub 
directories
are currently down.


Yes - there's been a longish network outage (about 12 hours) here at the 
university, which should have been fixed as of 8:15 MET.


Sorry for the inconvenience,

Martin.

[pca] New release: 20130502-01

[Martin Paul]

A new release of PCA has just been published. Here's a list of new 
features and changes:


 * Do not pass on Recommended flag with --minimal option
 * Correct patch obsoletions from installed patches with --minimal option
 * Fix rare bug of certain patches not showing up with --minimal option
 * Remove link to patch README on wesunsolve.net in HTML output
 * Temporary workaround for problem with Oracle server and wget from 
OpenCSW

 * Whitelist: add 147143, 147144
 * Whitelist: add 147147, 148148, 148027, 148028
 * Whitelist: add 149173, 149174, 149175, 149176
 * Apply check: add 147416, 147419

Update:
  pca --update now

Download:
  http://www.par.univie.ac.at/solaris/pca/installation.html

MD5: 70c76b041938d4d57ba7f529a783011b

Re: [pca] PCA selects SPARC patch on X86

[Martin Paul]

Am 25.04.2013 23:36, schrieb Glen Gunselman:

After installing the Solaris 10 CPU_2013-04 on an X4500 I ran pca
-list missingrs.  Patch 147416-02 was listed as missing but the x86
version is 147419-02 is installed.


Thanks for the report. I've fixed it in the current development release 
of PCA, available from:


  http://www.par.univie.ac.at/solaris/pca/installation.html

Martin.

Re: [pca] Oracle webserver has an SSL bug -> incompatible with OpenSSL 1.0

[Martin Paul]

Hi Laurent,

thanks for the info! Please let us know when/if Oracle fixes their server.


Martin, there is a workaround in the first link that you might consider
to include in PCA when using OpenCSW's wget.


As a quick fix I changed PCA to run wget with "--secure-protocol=TLSv1" 
when the wget path contains "csw". That's far from perfect, but it 
should suffice to avoid this issue.


The fix is in the current development release of PCA (20130425-01).

Martin.

Re: [pca] Query regarding patches currently running

[Martin Paul]

Drew,

Am 19.04.2013 17:33, schrieb Drew Skinner:

First, I think I remember seeing that PCA can patch OBP/POST ~
ILOM/ALOM/ELOM. Not sure if that's right (remember I think I saw) 


No, PCA can only download the patches, but these cannot be installed 
with PCA/patchadd. Usually an install script is contained in the 
ZIP-File, and you should always read the included README.



For the systems I have that are listing themselves as downrev (OBP/POST ~
ILOM/ALOM/ELOM) I'm finding that the ILOM's are freezing during the
patching process.


That's unusual - I haven't heard about such an issue in the past. No 
idea why the host OS (and changes to it) would affect [A-Z]LOM. Anybody 
else seen any such weirdness?



Also, I'm seeing with the S10_u11 update that you can't fully update a
system with running zones. There are workarounds I can use, but I'm curious
if the above could be related.


I'm not using zones on my systems, so I have zero to none experience in 
patching systems with zones. Maybe if you describe your problems in more 
detail, somebody else can share his thoughts.


Martin.

Re: [pca] "Bad patch installed" and "does not match"

[Martin Paul]

Am 15.04.2013 10:23, schrieb Martin Paul:

It means that no package contained in 142373-03 is installed on your
system, and therefore the patch can't be applied (patchadd will tell you
the same, if you try to install the patch manually).

As 125719-49 requires 142373-03, it then fails to install.

Can you confirm that neither SUNWastfb nor UNSWastfbcf are installed,
and let me know which Cluster you installed (Entire Distribution,
Developer, etc.)?


Thanks to Martin B. I found the root cause of the problem - all systems 
with Solaris version lower than 10 5/09 are affected. It was this 
release which introduced the new SUNWastfb* packages.


The workaround is to install SUNWastfb* from a newer Solaris 10 
distribution to the old system. Then 142373-03 and 125719-49 will 
install fine.


Don: I guess that's a bug in 125719-49 - it shouldn't require a patch 
for packages which are not available in all Solaris 10 releases.


Martin.

Re: [pca] "Bad patch installed" and "does not match"

[Martin Paul]

Am 12.04.2013 20:38, schrieb Frank Langelage:

0 Patch 144560-04 is obsoleted by 147147-26, which has
already been installed on the system. It should be removed first.

Is it correct, that 144560-04 is listed as bad patch?


Basicall, yes. But I guess in this situation it's not really a problem. 
Too bad that nowadays the READMEs for bad patches don't seem to be 
available anymore. In Sun times, one could check them for the reason of 
the patch being marked bad.



How should I deal with this situation? Remove 147147-26 then 144560-04
and then reapply 147147-26 again?


Just leave it as it is. 147147-26 supersedes 144560-04 and installs 
newer versions of all files included in 144560-04, so there are no bad 
parts left on your system.



The following requested patches will not be installed because
at least one required patch is not installed on this system.

0 For patch 125719-49, required patch 142373-03 does not exist.


That's the second report I get about this. I don't see the problem on my 
test systems, though.



The missing patch is in patchdiag.ref
142373|03|Apr/11/13| | | |
|10|sparc;|SUNWastfb:10.0.0,REV=2009.02.20;SUNWastfbcf:10.0.0,REV=2009.02.26;|SunOS
5.10: AST Graphics Patch

What does "does not match" mean?


It means that no package contained in 142373-03 is installed on your 
system, and therefore the patch can't be applied (patchadd will tell you 
the same, if you try to install the patch manually).


As 125719-49 requires 142373-03, it then fails to install.

Can you confirm that neither SUNWastfb nor UNSWastfbcf are installed, 
and let me know which Cluster you installed (Entire Distribution, 
Developer, etc.)? Could it be that you removed packages manually after 
installing the machine (this would cause such problems)?


Martin.

Re: [pca] Missing sconadm on Solaris 10 1/13

[Martin Paul]

Am 22.03.2013 14:13, schrieb francis picabia:

I think we're going the same direction.  The maintenance contract
cost alone on Oracle is a deal breaker.  Sun used to give Universities
a good deal, but no longer.


Same thing here.

We are a small group doing research and education on HPC at the 
University of Vienna. A full (educational) RHEL license costs 50 EUR 
here - once. Software support (ie. patches) for our SPARC T3-2 is about 
(just trying to get a quote for renewal) 2000 EUR *per year*. Go figure.


For Linux, we have to stick to one of the major distributions, as only 
they are supported by the necessary tools, drivers, compilers for HPC 
components.


Marzin.

Re: [pca] Missing sconadm on Solaris 10 1/13

[Martin Paul]

Am 21.03.2013 17:48, schrieb francis picabia:

The strange thing is, I had this misplaced optimism that Ian Murdock
would fix Sun's wacky series of patch tools with something fast and
robust like dpkg or pkg-get.  I was totally wrong.


To be fair, they kind of did that in Solaris 11 (IPS/pkg).

Unfortunately I will never use that - for us, the next Solaris version 
after 10 will most probably not be 11, but "Red Hat".


Martin.

Re: [pca] patch 118666-42 fails on sparse root zones

[Martin Paul]

Am 04.03.2013 15:57, schrieb Brookins, Neil (Philadelphia):

This looks like a bug in the patch itself causing it to not handle sparse zones 
in a user friendly way. Note that the three other Java patches do not have this 
issue.  I don't think there is a problem with PCA itself; its simply reporting 
the errors that patchadd is reporting back.


Correct. I guess the way to go would be a support request to Oracle then.


rm: /a/usr/jdk/jdk1.5.0_40 not removed: Read-only file system
rm: /a/usr/jdk/jdk1.5.0_40 not removed: Read-only file system
ln: cannot create /a/usr/jdk/jdk1.5.0_40/jdk1.5.0: Read-only file system
ln: cannot create /a/usr/java/jdk1.5.0_40: Read-only file system


I think I've seen different errors in the past when the system wasn't 
rebooted after installing e.g. a kernel patch (does "df" show a lot of 
these /a-mounts?). PCA and patchadd don't enforce reboots, so maybe 
that's worth a look.


Martin.

Re: [pca] pca recommends non-recommended patch

[Martin Paul]

Neil,

Am 01.03.2013 18:41, schrieb Brookins, Neil (Philadelphia):

Here is the trace of the patch obsolescence in order,
starting from the current recommended through the newest:
139944-01 has the "R" flag. It was obsoleted by 148161-02
148161-02 does NOT have "R" flag. It was obsoleted by 148338-03.
148338-03 does NOT have "R" flag.


Yes, PCA is passing on the Recommended flag here from 139944 to the 
patch(es) which obsoleted it. Basically that's a good idea (as only 
148338 contains the recommended fix(es) from 139944 now), but not when 
the "--minimal" option is used.


I've put a fix into PCA which makes it not pass on the R flag with 
"--minimal". This should fix it; try the development release of PCA.


Once again, thanks for the report!

Martin.

Re: [pca] patch install fail

[Martin Paul]

Neil,


I'd like to automate this process in such a way that the tool would 
automatically know that these patches are not needed to be installed and avoid 
having the failures. The goal would be that patches are not attempted to be 
installed if they are already obsoleted by any newer patch. Would this new 
functionality be something that PCA could be enhanced to perform?


Actually this check is already done by PCA, and it works fine - unless 
the "--minimal" option is used. So you found another bug, which I have 
fixed now in the current development release of PCA. My tests look fine, 
but it would be great if you could try it on your system as well and let 
me know about the result.


If I'm right, this should also fix the other issue you reported 
(118844-20 being listed with --minimal although 118855-36 is installed).


Thanks for the report,
Martin.

Re: [pca] patch dependency issue w/ 118844-20

[Martin Paul]

Am 26.02.2013 22:49, schrieb Brookins, Neil (Philadelphia):

FYI: I'm still seeing the same behaviour as before even though I'm using a 
newer patchset.
So, I conclude that the suggestion regarding changing the xref has not yet been 
done.

I will continue to use the ignore option in PCA for now.
Patch: 118855-36 is already installed which is listed as Obsoletes: 118844-30


You're right, nothing has changed. Look at README for the Recommended 
Patchset from 2013.02.19:


https://updates.oracle.com/patch_cluster/10_x86_Recommended.README

...
118844-20  Obsoleted by: 118844-27 SunOS 5.10_x86: kernel Patch
118855-36  SunOS 5.10_x86: kernel patch
...

But the README (now) contains information about why this obsolete patch 
is included. Seems as if some changes in 118844 "are required to ensure 
correct installation of the patchset on Solaris 10 11/06 (Update 3) and 
earlier Solaris 10 Updates". The install_cluster script probably has 
extra logic to check the current Update release and only install 118844 
when necessary. PCA can't do the same, as the needed information isn't 
in the xref file or is wrong (obviously 118844-20 is not 100% obsolete). 
I could only duplicate code from the install_cluster script into PCA, 
but as the (unnecessary) installation of 118844-20 does no harm, I'll 
better leave it as it is.


Martin.

[pca] Missing sconadm on Solaris 10 1/13

[Martin Paul]

Check out Oracle Support Document 1528698.1 (How to register smpatch on 
Solaris 10 1/13):


  https://support.oracle.com/epmos/faces/DocumentDisplay?id=1528698.1

"As sconadm has been removed in Solaris 10 1/13 and there unfortunately 
is no working replacement at the moment, this document offers a 
workaround how to get Solaris 10 1/13 registered to be able to use smpatch."


So there's no out-of-the-box working patch tool in Solaris 10 1/13. On 
the other hand - was there ever any? :)


Martin.

Re: [pca] patchdiag.xref changes broken for 2 days.

[Martin Paul]

Am 21.02.2013 16:38, schrieb Brookins, Neil (Philadelphia):

I've been closely watching the daily changes in the patchdiag.xref in
the past 2 weeks. I've found a serious problem that will result in
PCA not applying patches that should be applied if certain versions
of patchdiag.xref are used.


Confirmed. Thanks for noticing this and especially the amount of details 
you provided, this helped a lot when looking at the issue.


I've put a fix into the development release of PCA - you can try that 
with the xref file "AS OF Feb/18/13". Comparing output of "pca --minimal 
missingr" between the stable and development releases of PCA, you'll 
notice that the fixed version will now show the last recommended 
revision of the Java patches.



The solution to this problem is to keep the older Java patch listed
as recommended in the patchdiag.xref until the new patch is added to
the same file.


Actually, Oracle does that. In xref "AS OF Feb/18/13", they add a new 
revision of 118666 (42), which is marked S but not R. The previous 
revision (41) is marked O (obsolete), but keeps the R flag. With 
"--minimal", PCA is supposed to ignore the O flag on rev. 41 and use 
that. The problem was that there are two other revisions of 118666 in 
xref, 19 and 34, and both are marked R/S/O as well. No idea why, and I 
really think that these should be removed by Oracle (the Java patches 
were the only ones I found with that pattern). The bug in PCA was that 
it used the first of these revisions (19) and not the last (41). That's 
what I've fixed now.


Thanks again for the report,
Martin.

Re: [pca] Solaris 10 1/13 preinstalled patches

[Martin Paul]

Hi Don,

Am 12.02.2013 20:00, schrieb Don O'Malley:

I'll take a look into this one and get back to you.


Thanks for the information you already provided. Apart from that, it 
might be worth to at least take a look at these two patches:



Patch  IR   CR RSB Age Synopsis
-- -- - -- --- --- ---
119213 26 < 27 RS- 369 NSS_NSPR_JSS 3.13.1: NSPR 4.8.9 / NSS 3.13.1 / JSS 4.3.2
149453 -- < 02 RS- 133 SunOS 5.10: CCR Update


Both of them are "S"ecurity patches, and both of them contain actual 
security fixes (which Oracle nowadays often paraphrases as "problem with 
X"):


-- 119213-27:

13341290 DIS-TRUST DIGINOTAR ROOT CERTIFICATE
13341314 (CVE-2011-3389) RIZZO/DUONG CHOSEN PLAINTEXT ATTACK (BEAST) ON 
SSL/TLS 1.0


-- 149453-02

7194816 problem with smpatch / updatemanager
6914463 problem with smpatch / updatemanager

It's kind of strange to get a Solaris release in Feb 2013 with existing 
security fixes from up to a year ago not being fixed out of the box.


Martin.

[pca] Solaris 10 1/13 preinstalled patches

[Martin Paul]

Hi Don/all,

A PCA user, who already installed Solaris 10 1/13, wondered why some 
rather old patches are not pre-installed (see below). As I've seen that 
happen with previous update releases, too, I've wondered about the same 
thing - does anybody have an idea about why certain - really old - 
patches are excluded?


Martin.

Patch  IR   CR RSB Age Synopsis
-- -- - -- --- --- 
---
118666 34 < 41 RS-   7 JavaSE 5.0: update 39 patch (equivalent to JDK 
5.0u39)
118667 34 < 41 RS-   7 JavaSE 5.0: update 39 patch (equivalent to JDK 
5.0u39), 64bit
118683 07 < 08 --- 200 SunOS 5.10: Patch for profiling libraries and 
assembler
119213 26 < 27 RS- 369 NSS_NSPR_JSS 3.13.1: NSPR 4.8.9 / NSS 3.13.1 / 
JSS 4.3.2

119788 -- < 12 --- 119 SunOS 5.10: Sun Update Connection Proxy 1.0.9
119963 24 < 27 R-- 145 SunOS 5.10: Shared library patch for C++
121081 06 < 08 R-- 999 SunOS 5.10: Connected Customer Agents 1.1.0
121118 19 < 20 RS- 173 SunOS 5.10: Update Connection System Client 1.0.20
123893 50 < 52 R--  76 SunOS 5.8 5.9 5.10 Common Agent Container (cacao) 
runtime 2.3.1.2

125136 39 < 42 RS-   4 JavaSE 6: update 39 patch (equivalent to JDK 6u39)
125137 39 < 42 RS-   4 JavaSE 6: update 39 patch (equivalent to JDK 
6u39), 64bit

145078 -- < 01 --- 829 SunOS 5.10: Firefox plugins patch
148150 02 < 03 --- 124 SunOS 5.10: Tomcat 4 removal patch
148861 -- < 01 --- 129 SunOS 5.10: Sun XVR-2500 Graphics Accelerator 
Patch (post-S10U8)

149453 -- < 02 RS- 133 SunOS 5.10: CCR Update