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]

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

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

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.

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

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.

[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]

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]

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]

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.

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

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.

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.

[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] 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]

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

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

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.

[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 Security 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

[pca] patch flood

[Martin Paul]

Judging from today's patch flood, it's pretty sure that Solaris 10U11 is 
right around the corner :)


As usual, I installed all the new patches with PCA on both sparc and x86 
- works fine. Users of PCA's --safe option might want to get the 
current development release, where I added some whitelist entries.


Martin.

Re: [pca] different directory for patches

[Martin Paul]

Am 23.01.2013 16:52, schrieb Stevenson, Bradley (NE):

Great! Does anyone know if the script will do disk space checking so it knows
How much disk space it needs to install the patches. Or does anyone have a
Script to do this ?


PCA doesn't do space checking. It's not that I wouldn't have thought 
about adding it, but I never found a reliable method to compute the 
required space, especially without extracting all patches before 
starting installation (like the cluster does).


With patchadd using temporary space (/tmp, /var/run), making (multiple) 
backup copies of replaced files it's hard to find a reliable and 
provable method to compute required space.


The good thing is that patchadd (which PCA uses for the actual patch 
installation) usually deals fine with interrupted patch installations, 
not leaving any partly installed patches.


hth,
Martin.

Re: [pca] different directory for patches

[Martin Paul]

Am 23.01.2013 15:06, schrieb Stevenson, Bradley (NE):

Was there a solution to this problem ?  We are considering the use of this tool 
in our
Environment but we do have linked directories for /var/sadm/pkg on some of our 
servers.


The solution is to *not* use a symbolic link for /var/sadm/pkg/. That's 
an issue with Suns/Oracles patch tools (like patchadd), BTW, and not PCA.


As Dagobert mentioned, use a loopback mount instead:

  rm /var/sadm/pkg
  mkdir /var/sadm/pkg
  mount -F lofs /apps/sadm/pkg /var/sadm/pkg

You can also make this permanent via vfstab.

hth,
Martin.

Re: [pca] different directory for patches

[Martin Paul]

Am 23.01.2013 15:30, schrieb Stevenson, Bradley (NE):

What if its /var/sadm that is linked. Would using the loopback
Method work in this case as well ?


Yes, it's highly recommended.

Google for /var/sadm symbolic link for more examples of this 
recommendation.


hth,
Martin.

Re: [pca] forcing https? (UNCLASSIFIED)

[Martin Paul]

Michael,

Am 17.01.2013 00:02, schrieb Gale, Michael D CTR (US):

But at the end, the session redirects to http://aru-akam.oracle.com and I get a 
connection refused.

Any suggestions on how to keep all the connections on https?  One of the 
requirements was for us to use only https.


Unfortunately PCA can't help you with that - it's Oracle's fault.

Background: Downloading a patch from Oracle is a rather complicated 
procedure. If you take a close look at PCA's debug output, you'll see 
that it tries to download the patch via wget from this URL:


  https://getupdates.oracle.com/all_unsigned/147440-27.zip

The Oracle server redirects wget to another server:

  https://login.oracle.com/pls/orasso...

And then another redirection to:

  https://updates.oracle.com/osso_login_success?...

Following is a redirection to the original URL:

  https://updates.oracle.com/all_unsigned/147440-27.zip

And then to the final URL (which is http, not https):

  http://aru-akam.oracle.com/adcarurepos/...

PCA - or better wget - can do nothing but to follow this chain of URLs.

I assume you get Connection failed because you don't allow outgoing 
HTTP connections in your firewall? See Document ID 1199543.1 in the 
Oracle knowledge base for a description of the required firewall 
exceptions when using wget to download patches.


Martin.

Re: [pca] Patch 147440-25 issue

[Martin Paul]

Am 17.10.2012 21:01, schrieb Culver, Michael:

Recently installed 147440-25 on a t5120 which rendered it unbootable.
After no help from Oracle on the matter I removed the patch and
regained access to the system.  Oracle's response is that because I
am not patching with the patch cluster the patches are being
installed in the wrong order.


That's nonsense, IMO. The order is determined by patch requirements, and 
patchadd (and therefore PCA) would refuse to install a patch unless its 
requirements are met.


I haven't heard about any problems with 147440-25 yet, but it's pretty 
new. But if there is a problem with it rendering systems unbootable, 
this surely will be noticed by others as well. Just to be sure: The 
patch README has a note about a minimum firmware revision, but that's 
pretty old and you probably checked that already.


Martin.

Re: [pca] Explorer Output

[Martin Paul]

Am 12.09.2012 18:21, schrieb Jeremy Loukinas:

Who else is using explorer outputs to create patch lists? looking for a
little direction.

Looking at our explorer output i have a few directories underneath..

/patch+pkg which contains showrev-p.out and pkginfo-i.out
/sysconfig contains uname -a.out.

I'm trying to figure out a clean way to pull all this together and run pca
on my explorer directory to find patches for each server.


The --fromfiles/-f option supports output from Explorer directly. Just 
specify the directory which contains the patch+pkg/ and sysconfig/ 
directories. PCA will find what it needs in the relevant subdirectories 
automatically.


Martin.

[pca] New release: 20120829-01

[Martin Paul]

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


 * Check for wget in update function
 * Ignore non-executable wget binaries
 * Whitelist: replace 145957 with 146232
 * Whitelist: replace 145958 with 146233
 * Apply check: add 119303, 119304, 119305
 * Apply check: add 147992, 147993
 * Apply check: add 112762
 * Apply check: add 112443

Update:
  pca --update now

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

MD5: 5741bdb76e7b28495673bf82d44fccdf

Re: [pca] option --rec=xxx not working?

[Martin Paul]

Am 22.08.2012 17:02, schrieb Brookins, Neil (Philadelphia):

Can  the --rec option be used with the --minimal option?  Or, is my
use of --minimal causing the elimination of the extra patch from the
result set?


I'm afraid that you will indeed have to run PCA twice for that.

The --minimal option is kind of special, in that it works right when 
reading the xref file. As 118777-16 is in the Recommended Patchset, PCA 
does not know about 118777-18 later when the --rec option is evaluated.


This is all due to PCA only being able to store and handle a single 
revision per patch. That was fine for a long time, as the xref never 
included information about older patch revisions, only the current. This 
changed only when Sun/Oracle added extra lines for the patches included 
in the Recommended Patchset. As it would have required an enormous 
amount of time to change the internal data structures in PCA to work 
with multiple patch revisions, I chose the much simpler approach, as 
described above.


The idea is that IF you use --minimal, you stick to exactly that patch 
set. This makes a lot of sense, as that's what Oracle recommends: You 
then have a supported and tested configuration. If you add single 
patches later on, you're on your own again.


Martin.

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

[Martin Paul]

Am 20.08.2012 22:27, schrieb Brookins, Neil (Philadelphia):

When I run PCA with the --minimal and missingr options it says I need to 
install 118844-20
However, I see that 118855-36 is already installed and this obsoletes 118844-30.
I'm not understanding why PCA still thinks I need 118844 when I have a newer 
patch installed that obsoletes this.


I can explain what happens, but I'm not sure about a solution for this 
problem. PCA, when using minimal sees this information in the xref file:



118844 --  20 RS- 999 Obsoleted by: 118844-27 SunOS 5.10_x86: kernel Patch


It does not look at any higher revision of 118844, so it does not see 
that 118844-30 was obsoleted by 118855. That's why it lists 118844-20.


When looking at the Recommended Patchset, you'll see that 118844-20 is 
included there as well:


  http://wesunsolve.net/bundle/id/20
  http://wesunsolve.net/readme/bn/20

So that correlates with the information in the xref file. Usually you 
won't see any problems when installing the Patchset (or --minimal 
--missingr) because 118844-20 will be installed *before* 118855-36, 
which is superfluous, but works.


I can't think of a way to take care of that in PCA - it behaves right, 
in showing exactlz the same patches as in the Recommended Patchset when 
using --minimal.


Is Don listening? Should 118844-20 be removed from the Recommended 
Patchset, and its synopsis in xref be changed to Obsoleted by 
118855-36 as well?


The quick solution would be to use PCA's ignore option to ignore 
118844 on the affected system. That will do no harm, as it is definitely 
superseded by 118855-36.


Martin.

Re: [pca] multiple pca-proxy.cgi file

[Martin Paul]

Am 15.08.2012 17:01, schrieb Aasim Ajaz:

I made changes on client pca.cgi

  (basename($0) =~ /pca-proxy.*cgi/)  ($o{proxy}=1);
   basename($0) =~ debug)  ($o{debug}=1);


You should make this change in pca-proxy-sol10.cgi, not in the client. 
Sorry if this wasn't clear.


Martin.

Re: [pca] multiple pca-proxy.cgi file

[Martin Paul]

Am 10.08.2012 22:26, schrieb Aasim Ajaz:

and updated pca-proxy.cgi  to change pca-proxy.conf to pca-proxy-sol10.conf
and it works ; however when I change the pca-proxy.cgi to
pca-proxy-sol10.cgi the following shows up


PCA has an internal check, which makes it work as a pca-proxy only when 
its filename is pca-proxy.cgi. You will have to change that in the 
code. The original code is:


  (basename($0) eq pca-proxy.cgi)  ($o{proxy}=1);

Change it to e.g.:

  (basename($0) =~ /pca-proxy.*cgi/)  ($o{proxy}=1);

hth,
Martin.

Re: [pca] Fix to PCA so it stops trying to apply Veritas patches to wrong OS

[Martin Paul]

Chris,

sorry for the late reply. I'm stuck in the middle of a move of our 
research group to a new building (and being integrated into a larger 
organisation), so it's not easy to find some spare time for PCA issues 
right now.


As for VRTS patches, you're right about the basic problem. I've added 
the extra rules for 119303/119304/119305 to PCA now for a beginning.


I'm wondering though whether all of the other patches you list are real 
world problems: While many patches are listed as unbundled, their 
package version is often specific enough for PCA to match it to a 
certain OS release or architecture. E.g. often the packages version of 
VRTSxxx is different for sparc and i386, so the package in question will 
never appear on the wrong architecture.


Have you seen all of the patches listed wrongly on a real world system, 
or did you grep all Veritas patches from patchdiag.xref to compile the 
rules?


Don't get me wrong - I'll happily add exceptions for all affected 
patches to PCA (and I still think this is a viable solution, as once 
added they will apply to everybody, so most people never have to 
bother). But on the other hand I only want to add required rules, as the 
list has to be maintained, too.


Martin.

Re: [pca] Linux box as local patch server?

[Martin Paul]

Lee Roth wrote:

Question: Can anyone think of a reason that the PCA local patch server
could NOT reside on a Linux server?


No, that should be fine. While I'm not using such a setup here, I've had reports 
from people who run a PCA local caching proxy on Linux machines successfully.


Martin.

Re: [pca] Hurray to PCA and We Sun Solve! They have spared me numerous hours of tedious work

[Martin Paul]

Thanks to Sean for providing feedback!


What do you think? could this be integrated into vanilla pca, or
should we make a fork?


For now I think it would be better to implement this in a wrapper to PCA or in a 
separate client. As far as I understand it, only output from PCA which is 
already provided would be required for your proposal.


Maybe Sean would be happy if there simply was a file upload option for the patch 
list on wesunsolve anyway? I think the list of patches he has isn't from PCA, 
but from some external source.


Martin.

[pca] New release: 20120326-01

[Martin Paul]

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


 * Fix timing calculation for patch sessions longer than 24 hours
 * Add warning when --minimal is used with anything but missingr
 * When using option minimal, show that in the List: header
 * Always put URL at the end of wget command line
 * Change author's e-mail address
 * Documentation: Recommend use of --minimal with missingr only
 * Whitelist: add 148165, 148166
 * Whitelist: add 147673, 147674
 * Whitelist: add 146399
 * Whitelist: modify 147441
 * Apply check: replace 145786 with 146068
 * Apply check: replace 125952/125953 with 147673/147674

Update:
  pca --update now

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

MD5: 25008a7f871b93f28806053fd9abfad3

Re: [pca] Method to stop applying patches when a patch fails to apply?

[Martin Paul]

Cashion, David (DXZ) wrote:

For instance, sometimes a kernel patch will fail to fully apply for various
reasons.  Since it shows up as being installed, the other patches that depend
on that kernel patch will successfully install. 


Hm, that's weird, I've never seen that. I always thought that this is taken care 
of by patchadd - when it noticed that a patch wasn't installed completely, it 
backs out all changes it made. When patchadd isn't atomic, things will become 
unpredictable.



I'm not sure how the CPU patchset determines if a kernel patch was
successfully applied, but the patchset script will notice the incomplete
kernel patch installation and try to reapply it.


I couldn't find anything in the patchset install script on a quick glance (it's 
a lng script). But I really think that it should be patchadd which should 
take care of that, not some other script.


Without knowing the exact conditions of such a partly-failed patch install, it 
will be impossible to add a workaround to PCA, I'm afraid. If you have more 
details, feel free to post them here and/or report it to Oracle.


Martin.


Thanks much, David Cashion







--
  Martin Paul \ System Administrator
  University of Vienna \ http://www.par.univie.ac.at/
Faculty of Computer Science \ Nordbergstrasse 15/C/3, A-1090 Wien
 Research Group Scientific Computing \ Tel +43 1 427739403 Fax +43 1 42779394

Re: [pca] pca-proxy.cgi questions

[Martin Paul]

Lee, Jarrett wrote:

How does PCA handle multiple clients checking in with the local patch server
simultaneously? What if two servers ask for the same patch before the patch
downloads completely? Does it have a mechanism that knows the original
request to download the patch has not yet completed?


That's no problem, PCA takes care of that. When a client asks for a patch which 
is currently being downloaded due to some other request, PCA will complete the 
download and then deliver the patch to both clients. This seems to be pretty 
robust, I can't remember any recent problem reports about such issues.



We plan to have a few hundred servers downloading patches at one time. Will
this be fine? Anybody else already doing this?


I don't have hundreds of clients, but I've heard from others that have. So this 
should be fine. If you do experience any trouble, let me know. Even more, tell 
us when you have your setup running and working - success stories are always 
welcome :)


If you want to spread the load to multiple servers, you might be interested to 
hear that you can even build a cascade of pca proxies - just point one proxy at 
another by setting xrefurl/patchurl on a secondary proxy to the primary proxy.


hth,
Martin.

Re: [pca] old revisions marked BAD and OBSOLETE

[Martin Paul]

Dennis Clarke wrote:

now then, next item on the hit list is 118822-12 which is a kernel patch
from way back that is listed in the patchdiag.xref file thus :

core-sparc-SunOS5.10 # grep ^118822\|12 ../xref/patchdiag.xref
118822|12|| |S|O| B|10|119578-03;||SunOS 5.10: kernel Patch


I see four old revisions of 118822 in xref, which are marked BAD and OBSOLETE:

118822|12|| |S|O| B|10|...
118822|14|| |S|O| B|10|...
118822|15|| |S|O| B|10|...
118822|21|| |S|O| B|10|...

No idea why they're included. I think this came up before, but no one could 
provide an explanation yet. Do you have a real problem with these entries, or 
are you just wondering why they're there?



So I am guessing that the O in the sixth field means Obsolete ?


Yes. So they can be ignored.

Martin.

Re: [pca] 6620575 problem with sockfs

[Martin Paul]

Dennis Clarke wrote:

Another fine bit of police work reveals that patch 148601-01 is a
security patch but not flagged as Recommended which is weird.


As of today's patchdiag.xref file, it *is* marked RECOMMENDED. I think Don 
explained the procedure here once. AFAIR, adding a patch to the Recommended 
Patch Cluster does not necessarily happen at the same time as publishing the 
patch. So seeing some lags here is normal. If you follow the changes in the xref 
files closely, you'll see that patches often get marked RECOMMENDED a few days 
after they were first published.


Martin.

Re: [pca] pca.sh exit code status

[Martin Paul]

Chris Gibson wrote:

Should it not show an exit of 1? Also I would I exclude the exit status
of 3, 4 and 5 as we are patching ABE's and don't care about the reboot
notification.


I know, PCA's exit values are from perfect. The problem is that the requirements 
of the users are quite different, and it seems to be impossible to express all 
the demanded information in a single numerical value. So as I couldn't find a 
solution which would please everybody, I didn't put much effort into this.


In your case the best alternative would be to look for the Download Summary 
and Install Summary lines in PCA's output in your wrapper script. There you 
can get detailed information about all patch downloads and installations, 
separated into successful/skipped/failed patches.


Hope that helps,

Martin.

Re: [pca] confirming the validiting of a home grown patch_order file

[Martin Paul]

Thomas Gouverneur wrote:

I've managed to de-obsolete patches where dependencies weren't included
into the patchdiag.xref so now PCA should really be happy with the
output..


Yes, the obsoletion chain now looks fine in the example I tried. Let's see 
whether somebody else will give it a try.


Martin.

Re: [pca] Option --minimal questions

[Martin Paul]

Neil,


1) I understand that --minimal option is normally designed to be used with 
either missingr or missingrs operands.
I've tested --minimal option with the missing operand and its having some 
effect, but it's not clear to me what it's doing?
Is the behaviour of --minimal defined for use case that is omitting  r and s?


No - the only patch group where it makes sense to use --minimal is missingr. 
When using it e.g. with missing, you will get a mixture of the most recent 
revision of all non-R patches and the minimal revision of all patches which are 
marked R.


It doesn't help to use it with missings neither. Only the recommended patches 
are listed in patchdiag.xref in a way that can be used to find out the minimal 
revision. Patches marked S are sometimes misleading: The S does only mean 
that there is a security fix in any revision, not necessarily in the latest.


All that is not really a problem, though: With --minimal -l missingr you are 
supposed to get the equivalent of the latest Recommended Patch Set, which by 
definition contains all patches with security fixes for Solaris, which is 
probably what you're after anyway.



2) When using the --list or --listhtml options, I see that the header displays List: missing where 
missing is the operand. This is useful to the viewer of the list to see what operand was invoked. However, the option 
--minimal is not showing up in the header anywhere. So, If I am viewing the list I can't easily tell if the list is latest 
version or minimal. Should the designation of latest vs. minimal be visible in the list output? One idea is to change the 
CR in the header to say either MR or LR for Minimal Release, or Latest Release, respectively.


You usually can recognize it pretty easily when --minimal is used, because 
then the patch list will include some patches with Obsoleted by ... in the 
synopsis. But you're right, this could be more obvious. I've therefore added a 
change in the current development release (20120202-01) which modifies the 
List: header to look like that when --minimal is used:


  List: missingr-minimal (227/139380)


3) I found a use case that leads to installing a patch which is immediately 
overwritten with a newer patch. This shouldn't break anything, but its less 
than optimal.


Is it possible that you were running pca --minimal -l missingrs here instead 
of using only the missingr patch group? This would pull in 147935 (which is S, 
but not R), while when used as intended only 146861 should show up.


If this doesn't explain the behaviour you see, please send me output from these 
commands on the affected system, so I can see what's going on:


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


I would have expected that PCA would check each patch being added to the list 
and remove the earlier ones from the list that are obsoleted by later patches 
to be installed. Maybe this checking is not being done? It would be a useful 
feature to speed up patching by not installing patches that should be skipped.  
This check can be automated using the information provided in the 
patchdiag.xref.


This check is done, which is why you usually don't see any obsolete patches in 
the list of missing patches. Only --minimal is different here.


Thanks for feedback, and let me know if something is still unclear.

Martin.

Re: [pca] confirming the validiting of a home grown patch_order file

[Martin Paul]

Thomas,


So, from that point, I think that I can forget to remove patches being
obsoleted by other PATCH_IDS (like if 11 was obsoleted by 22,
we don't cause trouble by including both inside patchdiag.xref, right ?
as PCA only got trouble when two patches with the same revision are
present).


Maybe you could just add required patches recursively in a first step, and then 
go over the file again and only keep one line per patch-ID - the one with the 
highest revision number. I think that should be fine for PCA, as it's the same 
style as used by the official patchdiag.xref.



On another side, couldn't we add an option to PCA to allow obsoleted
patches to be used ?


I'd prefer not to do that :) It's hardly foreseeable whether this could cause 
problems in some obscure situations. With that change, PCA would accept that the 
xref file in itself doesn't have to be consistent, and not even I know the code 
good enough to anticipate what's gonna happen ..


I think there's another viable solution: One could assume the only thing that 
happens when patch 11-01 is obsoleted by 22-02 is that its O flag is 
set and the synopsis is prefixed with Obsoleted by: 22-02 . So it should 
cause no harm if you simply remove these two things in the generated xref file. 
It seems to be a right thing to do - at the time when a patch required 11-01 
for the first time, this of course wasn't obsolete yet.


Again one could also argue that the most correct thing to do would be to follow 
the requirements/obsoletion chain until reaching a non-obsolete patch and to 
include that one (plus all the redirections, for PCA to know), even if this 
pulls in new dependencies. But then especially people with hand-tuned patch 
lists won't like that. *sigh* :)


Martin.

Re: [pca] confirming the validiting of a home grown patch_order file

[Martin Paul]

 - populating the xref
 - Assume only one rev (the last used in dependencies) is present per
   patch
 - Removing any obsolete flag and Obsoleted by: text inside the
   synopsis.

Correct?


Yup, think so.


I can also do it this way... I got all the info I need, I can even
imagine to allow the user to choose which method is the best for him


Yes, at the end having an option would probably be best.


Like if you would apply the 10 Recommended patch cluster without
downloading every single patch which is in it. You simply could
generate xref from the list of patches it contains and then run pca
against this xref... wouldn't that be a wonderful world ?


The basic design of Sun's patching design using patchdiag.xref really isn't (or 
wasn't) all that bad. Besides just having one current master xref file, one can 
put it to good use which such custom xref files; Sun, with the access to all the 
patch metadata could've done wonderful things. Alone the fact that one can use a 
frozen copy of an xref file to put a certain patching milestone on any given 
machine even months later is a great thing, used by many. It's just sad that all 
this has an expiration date on it since Solaris 11 and IPS appeared.


Martin.

Re: [pca] confirming the validiting of a home grown patch_order file

[Martin Paul]

Thomas Gouverneur wrote:

 - I've fixed the header for PCA to admit the date parsing (i hope at
   least ;))


Nearly :) You should replace month numbers by their 3-letter-abbreviations in 
the date (01 - Jan, 02 - Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov,Dec).



 - I've also fixed the multiple-release present, it now take the
   biggest release of a patch present into every dependancy.


Yes, the number of patches in the generated xref file has now been reduced.


So, whenever there is a bad patch, should I look at the first upper
revision which is not a bad patch ? is it safe to do that ?


Yes, that's what I'd do.


Any other remark ?


I still see empty patch lines. E.g. in the xref file generated for a list with 
 only patch 148301-01 on it, the resulting xref file contains:


  125369|05|Jan/01/70| | | |  
  125547|01|Jan/01/70| | | |  

There's also:

  123839|01|Jan/01/70| | | |  

which wouldn't have to be included anyway, as it is obsoleted by 126897-02, 
which is included due to some other dependency requirement.


Martin.

Re: [pca] confirming the validiting of a home grown patch_order file

[Martin Paul]

Don O'Malley wrote:
Basically, as soon as you start to use patches in the form of xx-yy with 
PCA it will (and has to) assume that you take care of the dependencies and the 
ordering yourself. If you have a self-maintained list of patches, it's 
probably easiest to to try to install them on a test machine to get the 
correct ordering.

Dumping all the patches in a single directory and using 'patchadd -M' may 
help...


A recent idea for a service that Oracle could provide was to allow a customer to 
submit a list of patch-IDs and revisions, and to get a copy of patchdiag.xref 
which includes exactly these patches (plus required patches) in return.


This patchdiag.xref file could then be fed into PCA via its xrefdir option, 
and it would allow the admin to verify any system against (and patch up to) this 
very patchset.


This would not only be useful for such home-grown patch lists (which Oracle 
doesn't like anyway), but also for patching prerequisites enforced by some 
applications. E.g. Sun Studio, which always had a list of certain required 
and/or recommended patches to be installed to make it work flawlessly. It's a 
common FAQ as to how to verify such a list. If a patchdiag.xref with these 
patches would be provided, again checking and patching would be a breeze.


Any spare time, Don? :)

Martin.

Re: [pca] confirming the validiting of a home grown patch_order file

[Martin Paul]

Thomas Gouverneur wrote:

I've tried to make a PoC for all this...


You're quick :)

Can you please change the header in the generated xref file to match the one 
from the original, ie:


## PATCHDIAG TOOL CROSS-REFERENCE FILE AS OF Jan/26/12 ##

PCA is quite picky with the syntax of the first line and won't accept the file 
if it doesn't match. You can put the FOR BUNDLE xxx part into another comment 
line (they are ignored by PCA).


Even in a simple example with just one patch on the list, which pulls in a 
kernel patch, I once again realized how complicated all those patch dependencies 
have become, and how difficult it is to prove correctness. One thing I noticed 
is that the xref file contains lines like 119254|14|Jan/01/70| | | |  . It 
seems as if the xref creator doesn't check whether a patch has already been 
included with a higher revision, and then adds these half-empty lines. When 
different patches require different revisions of some other patch, only one line 
with the newest required revision should be included.


I also saw a bad patch (B) included in the xref file (120272-12). I guess the 
script should look for the patch which obsoleted it and include that one instead.


The format of the lines themselves seems to be OK. Are you generating them from 
your patch database or are they taken from your archive of patchdiag.xref files?


Guess that more people have to try that with real-world examples to see whether 
the output makes sense and delivers a patch set which can indeed be applied. 
Trying to analyze that with a handful of theoretical samples seems just too 
complicated and cumbersome.


Martin.

Re: [pca] confirming the validiting of a home grown patch_order file

[Martin Paul]

Gael Martinez wrote:

What would be the fastest/cleanest way with pca to confirm/correct the
right patching order for all patches placed in a flat file ?


Assuming that the patches are specified in patchID + revision format 
(xx-yy), PCA can't help you much here. The problem is that PCA uses the 
information from patchdiag.xref to build the patch dependency tree, but the file 
only contains information about the most recent revision of each patch.


patchadd knows about those dependencies because it uses the patchinfo file 
contained in the patch zip file. For PCA to do the same for a list of patches, 
it would have to download all patches first instead of relying on the xref file, 
which is kind of impractical.


Basically, as soon as you start to use patches in the form of xx-yy with PCA 
it will (and has to) assume that you take care of the dependencies and the 
ordering yourself. If you have a self-maintained list of patches, it's probably 
easiest to to try to install them on a test machine to get the correct ordering.


Martin.

Re: [pca] no Patch Download?

[Martin Paul]

Hi,


seems that I am not able to get any patch from Oracle this morning, 404 
responses all the time.


The ones I just tried (146054-06, 146055-06) downloaded fine. Is it still 
failing for you?


Martin.

Re: [pca] no Patch Download?

[Martin Paul]

Thomas Bleek wrote:

Perhaps only new patches?


The ones I tried were the newest anyway, but yours work for me as well:

Patch  IR   CR RSB Age Synopsis
-- -- - -- --- --- ---
145899 --  08 RS-   4 SunOS 5.10: SVM patch

Looking for 145899-08 (1/2)
Trying Oracle
Trying https://getupdates.oracle.com/ (1/1)
Done
--
145919 --  03 ---   4 SunOS 5.10: autofs Patch

Looking for 145919-03 (2/2)
Trying Oracle
Trying https://getupdates.oracle.com/ (1/1)
Done
--
Download Summary: 2 total, 2 successful, 0 skipped, 0 failed


Trying http://ftp.gfz-potsdam.de/cgi-bin/pca-proxy.cgi
Failed (Error 404: 145899-08 not found)


Can you either try to download them without the proxy (directly from Oracle) or 
check debug output on the pca-proxy.cgi?


Martin.