Does PCA Use the OS Field?

My question is, does PCA use the OS field in the patchdiag.xref when trying to 
determine which patches to apply to a system?

I'm trying to create a custom xref file to include the latest Vertias patches to 
use with PCA. I'd like to include patches for all somewhat recent versions of 
Solaris(8, 9 and 10). I have a working file, patches apply fine, except that 
versions of patches I've marked as 8 or 9 are still trying to be applied to 10, 
and vise versa. So they come back as failed. This is not the end of the world, 
but annoying. 

Here is an example of the xref line that PCA is still trying to apply to a S10 
system:

142633|07|Feb/01/11|R| | |  |9|sparc;|VRTSvxfs:5.1,REV=7Oct2009;| VRTSvxfs 
5.1SP1RP1: Patch for File System 5.1-Sun5.9

[:~]# pca -l --nocheckxref --xrefdir=/root
Using /root/patchdiag.xref from Jul/26/11
Host:  (SunOS 5.10/Generic_144488-17/sparc/sun4u)
List: missing (7/1538)

Patch  IR   CR RSB Age Synopsis
------ -- - -- --- --- -------------------------------------------------------
142633 -- < 07 R-- 181  VRTSvxfs 5.1SP1RP1: Patch for File System 5.1-Sun5.9
...

If PCA doesn't consider this field, is there another way of modifying the xref 
to limit a patch to a specific OS?

Thanks,

Re: Does PCA Use the OS Field?

Jason Greathouse wrote:
> My question is, does PCA use the OS field in the patchdiag.xref when trying to 
> determine which patches to apply to a system?

No. I found out that the contents of this field couldn't be relied upon, so it 
only uses packages+versions (and architecture). I've thought about scanning the 
synopsis field for strings like "SunOS 5.9" etc. but this isn't set in a 
consistent manner neither.

I'm dealing with that by adding extra rules to PCA itself for affected patches, 
which is kind of odd, but turned out to work fine.

Many of the VRTS patches are already checked in PCA, I've now added 
142633/142634, too. Go get the current development release of PCA (20110802-01) 
which should fix the issue.

Thanks for the report,

Martin.

Heads-up: New download service

Re: Heads-up: New download service

Re: Heads-up: New download service

Don O'Malley wrote:
> Everything went very smoothly, but you may notice that there is now an 
> additional level of redirection added to patch downloads.
> Requests to getupdates.oracle.com now redirect to updates.oracle.com via 
> login.oracle.com (for authentication).

Downloads work for me, but it looks different from your example - at the end I'm 
getting the patch from "http://aru-llnw-dl.oracle.com/aaruna04/...". Was there a 
switch from akamai to limelight, or does this depend on where the client is 
coming from?

Martin.

Re: Heads-up: New download service

Paul, Don et al,

I too am seeing the Limelight networks addresses and I am in the US,
not Europe.  My pca debug sessions hung on aru-llnw.oracle.com and
aru-llnw-dl.oracle.com; I ended up adding 208.111.128.0/24 into my
firewall rules to get pca working again.

Paul, it would be nice if pca spit up a message if a URL connection
times out, even if you are not running in debug mode.  That would be a
clue that
either something was down at the Oracle end, or there is a
change/firewall issue.  Otherwise you tend to assume that things are
working normally.

Don, I have noticed a big drop-off in Solaris 10 patches in the past
month to six weeks.  Is this because a new release of Solaris 10 is
about to happen?

Jeff Earickson
Colby College

On Tue, Aug 2, 2011 at 9:03 AM, Martin Paul <martin <at> par.univie.ac.at> wrote:
> Don O'Malley wrote:
>>
>> Everything went very smoothly, but you may notice that there is now an
>> additional level of redirection added to patch downloads.
>> Requests to getupdates.oracle.com now redirect to updates.oracle.com via
>> login.oracle.com (for authentication).
>
> Downloads work for me, but it looks different from your example - at the end
> I'm getting the patch from "http://aru-llnw-dl.oracle.com/aaruna04/...". Was
> there a switch from akamai to limelight, or does this depend on where the
> client is coming from?
>
> Martin.
>
>

Re: Heads-up: New download service

Jeff Earickson wrote:
> Paul, it would be nice if pca spit up a message if a URL connection
> times out, even if you are not running in debug mode.

I agree in that it would be nice, but it won't happen. I'm leaving all the 
download stuff to wget - and I'm very glad that I don't have to care about that 
in PCA - which will timeout eventually, but I have no plans to write ugly code 
looking at wget's (debug) output to see what's going on. With all the redirects 
and all the changes in Sun's/Oracle's backend infrastructure in the past, this 
would be a nightmare.

Martin.

Re: Heads-up: New download service

Paul,

I was hoping for something simple like examining the return code for
wget.  But googling on the topic of wget return codes, took me to
here:

http://www.gnu.org/software/wget/manual/html_node/Exit-Status.html

These codes are very vague (maybe code 4 would work).  The note about
return codes for older versions convinces me that you are right.
Ugh.

Jeff Earickson
Colby College

On Tue, Aug 2, 2011 at 9:45 AM, Martin Paul <martin <at> par.univie.ac.at> wrote:
> Jeff Earickson wrote:
>>
>> Paul, it would be nice if pca spit up a message if a URL connection
>> times out, even if you are not running in debug mode.
>
> I agree in that it would be nice, but it won't happen. I'm leaving all the
> download stuff to wget - and I'm very glad that I don't have to care about
> that in PCA - which will timeout eventually, but I have no plans to write
> ugly code looking at wget's (debug) output to see what's going on. With all
> the redirects and all the changes in Sun's/Oracle's backend infrastructure
> in the past, this would be a nightmare.
>
> Martin.
>
>

Re: Heads-up: New download service

New release: 20110805-02

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

  * Deprecate option supplevel after Oracle broke query interface
  * Fix showing errors when running pca proxy in debug mode
  * Whitelist: add 144500, 144501
  * Whitelist: replace 143647/143648 with 145957/145958
  * Whitelist: replace 143957/143958 with 146489/146490
  * Whitelist: replace 143645/143646 with 146232/146233
  * Whitelist: add 146673, 146674
  * Whitelist: modify 144489
  * Whitelist: remove obsolete patches
  * Whitelist: remove patches for products which reached EOSL
  * Apply check: add 147056
  * Apply check: add 142633, 142634
  * Apply check: remove patches for products which reached EOSL
  * Update list of contributors

Update:
   pca --update now

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

MD5: 7a5806de0fa1c4b6ed8973afadf4a397