From sun at waistcoat.org.uk  Wed Jun  8 12:09:16 2011
From: sun at waistcoat.org.uk (Steve Goldthorpe)
Date: Wed, 8 Jun 2011 11:09:16 +0100
Subject: [pca] fix maximum patch level for a patch
Message-ID: <BANLkTi=QFpnLHszuoWdMd8Dij1z+Lg3Lsg@mail.gmail.com>

With patch 119534-24 and above, createflar creates version 3.0 flash
archives that cannot be read by Solaris 10u9 miniroots.  As Solaris 10u10 is
not out yet (which allegedly bring this capability), I have to ensure I only
patch to 119534-23 and not beyond.

To do this I'm manually hacking the patchdiag.xref file, can this be done
natively by pca?  If not is there scope for a new feature to enable this
behaviour - something live pca --maxpatchlevel=119534-23.

-Steve Goldthorpe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.univie.ac.at/pipermail/pca/attachments/20110608/92dd766c/attachment.html>

From martin at par.univie.ac.at  Wed Jun  8 13:11:10 2011
From: martin at par.univie.ac.at (Martin Paul)
Date: Wed, 08 Jun 2011 13:11:10 +0200
Subject: [pca] fix maximum patch level for a patch
In-Reply-To: <BANLkTi=QFpnLHszuoWdMd8Dij1z+Lg3Lsg@mail.gmail.com>
References: <BANLkTi=QFpnLHszuoWdMd8Dij1z+Lg3Lsg@mail.gmail.com>
Message-ID: <4DEF58CE.3000309@par.univie.ac.at>

Steve Goldthorpe wrote:
> With patch 119534-24 and above, createflar creates version 3.0 flash
> archives that cannot be read by Solaris 10u9 miniroots.  As Solaris 10u10 is
> not out yet (which allegedly bring this capability), I have to ensure I only
> patch to 119534-23 and not beyond.
> 
> To do this I'm manually hacking the patchdiag.xref file, can this be done
> natively by pca?  If not is there scope for a new feature to enable this
> behaviour - something live pca --maxpatchlevel=119534-23.

The only workaround is to add "--ignore 119534" to pca.conf or the command line, 
but then the patch will be ignored completely. You'd have to make sure that 
119534-23 is installed manually, if you need it.

Anything more fine-grained doesn't work for the usual reason: There is no 
information about past patch revisions included in patchdiag.xref. In your 
example, PCA could only assume that the meta-data (e.g. packages, required 
patches) for revision 23 is exactly the same as for the current revision (27, as 
of today). This is often not the case, and would end up in strange issues.

Hope that helps,

Martin.


From don.omalley at oracle.com  Wed Jun  8 14:53:54 2011
From: don.omalley at oracle.com (Don O'Malley)
Date: Wed, 08 Jun 2011 13:53:54 +0100
Subject: [pca] Oracle removed support from patchdiag.xref for --minimal
 option in pca?
In-Reply-To: <BANLkTi=Tc3bXeLTZ0utJ-i2Y1_p7wk=16w@mail.gmail.com>
References: <BANLkTi=sO96vBSn0jS818S8_vGZG5vLNBg@mail.gmail.com>	<4DDF680B.6010307@oracle.com>
	<BANLkTi=Tc3bXeLTZ0utJ-i2Y1_p7wk=16w@mail.gmail.com>
Message-ID: <4DEF70E2.2040008@oracle.com>

An HTML attachment was scrubbed...
URL: <https://lists.univie.ac.at/pipermail/pca/attachments/20110608/1db25454/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graphics1
Type: image/gif
Size: 2059 bytes
Desc: not available
URL: <https://lists.univie.ac.at/pipermail/pca/attachments/20110608/1db25454/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graphics1
Type: image/gif
Size: 2059 bytes
Desc: not available
URL: <https://lists.univie.ac.at/pipermail/pca/attachments/20110608/1db25454/attachment-0001.gif>

From variverrat at gmail.com  Wed Jun  8 15:46:44 2011
From: variverrat at gmail.com (Jeff)
Date: Wed, 8 Jun 2011 09:46:44 -0400
Subject: [pca] Oracle removed support from patchdiag.xref for --minimal
 option in pca?
In-Reply-To: <4DEF70E2.2040008@oracle.com>
References: <BANLkTi=sO96vBSn0jS818S8_vGZG5vLNBg@mail.gmail.com>
	<4DDF680B.6010307@oracle.com>
	<BANLkTi=Tc3bXeLTZ0utJ-i2Y1_p7wk=16w@mail.gmail.com>
	<4DEF70E2.2040008@oracle.com>
Message-ID: <BANLkTinjiYs3COozPdAWJso_byDvm5g29w@mail.gmail.com>

Thanks Don.  I agree that the CPU has an excellent install script.  The
problem with using the CPU is when you are deploying to hundreds of servers,
there is a significant amount of time involved in staging the large bundle
of patches when you really are only applying a very small subset between
CPU's.  PCA allows us to only grab what is needed on an individual server vs
having a script run through a long list of patches and see if they apply.

What I'll probably end up doing is keeping copies of the patchdiag.xref file
from around the time that the CPU is released and then compare the patch
list in the CPU against the patchdiag.xref until I find the one that
matches.  What would be even better is if the CPU contained a copy of
patchdiag.xref that can be used by PCA users to replicate the CPU.

On Wed, Jun 8, 2011 at 8:53 AM, Don O'Malley <don.omalley at oracle.com> wrote:

>  Hi Jeff,
>
> The Oracle Patch Strategy Best Practice is to download and install the CPU
> (ideally to an Alternate Boot Environment). The CPU does have the advantage
> of having an excellent install script (written by Ed Clark; a Senior
> Engineer on my team) and is tested by my team prior to release; two
> excellent reasons why we recommend that customers use it!
> It also supports application to an Alternate Boot Environment (ABE). (I
> know PCA supports patch application to an ABE too...)
>
> PCA is a third-party tool, which Martin kindly maintains and makes freely
> available, so is not the recommended way to apply the CPU. There is no
> special copy of the patchdiag.xref from the recommended patch cluster the
> CPU is cut from made available. (The day the CPU is released is not
> accurate, as we need to cut the CPU a week before to allow time to test.)
>
> I know that previously Chris Reece released a tool called Mkpcadir<http://www.jessies.org/%7Ecar/projects/mkpcadir/>,
> which created a patchdiag.xref based on the directory structure of the EIS
> (Enterprise Installation Standards) DVD.
> I do not know if someone else has created a similar tool that would do
> something similar for patch clusters???
>
> Each Patch Cluster (eg. Recommended Patch Cluster, CPU Patch Cluster) that
> Oracle produces does contain a patch_list file, which is a flat file listing
> the patches the cluster delivers in the order in which they should be
> applied.
> I'm not 100% sure of the correct syntax to use with PCA, but I think you
> should be able to rename this file patchlist.txt and provide it as an input
> to PCA.
> Perhaps Martin or someone else could confirm...
>
> HTH,
> -Don
>
>
>
> Jeff wrote:
>
> Guess I didn't understand that was the purpose of --minimal.  So based on
> your answer, there is no way to follow the Oracle Best Practices patch
> strategy of applying the CPU between update releases using pca?  Except
> maybe grabbing the patchdiag.xref on the day the CPU is released and
> comparing the patch revisions between patchdiag and the CPU?
>
>
> On Fri, May 27, 2011 at 4:59 AM, Don O'Malley <don.omalley at oracle.com>wrote:
>
>> Hi Jeff,
>>
>> The --minimal option never mapped to the contents of the CPU.
>>
>> The --minimal option is mapped to the Recommended Patch Cluster contents,
>> not the CPU. The CPU is effectively an archived version of the Recommended
>> Patch Cluster, so the 2 are closely related.
>> That said, with changes that we made to merge the Recommended Patch
>> Cluster and former Sun Alert Cluster (see Patch Corner - Merging the
>> Solaris Recommended and Sun Alert Patch Clusters<http://blogs.oracle.com/patch/entry/merging_the_solaris_recommended_and>for the details), we now only add the lowest revision of a patch required to
>> address SunAlert issues (Security, Data Loss and System Availability).
>> This means that over time customers need to apply less patches to keep up
>> to date with critical fixes.
>>
>> This is the reason that some patches in patchdiag.xref that are
>> Recommended are now longer the latest revs of patches.
>>
>> The only exception to this rule is patches required for the patch
>> utilities on Solaris to function correctly; these patches (eg. 119254) are
>> always kept at the latest available revision.
>>
>> HTH,
>> -Don
>>
>>
>>
>> Jeff wrote:
>>
>> I've been using the --minimal option for pca since it came out to
>> standardize patching based on the most recent CPU.  Today I noticed that is
>> looks like Oracle dropped support for in in patchdiag.xref.
>>
>> I'm using the patchdiag.xref I downloaded on May 15th and trying to apply
>> the patches from the April/2011 CPU using pca.  I find these patch
>> discrepancies between what is in the CPU and what is in patchdiag.xref:
>>
>> *April CPU    patchdiag*
>> 119254-80    119254-81
>> 122911-24    122911-25
>> 125215-03    125215-04
>> 141552-03    141552-04
>> 143559-07    143559-08
>> 144488-11    144488-14
>>
>> Previously, patdiag.xref would list both the version of the patch that was
>> in the CPU and the most recent version.
>>
>> Guess the question is to Martin or Don:  Do you know if this is
>> intentional?
>>
>> --
>> Jeff
>>
>>
>>  --
>>  <http://www.oracle.com/>
>> *Don O'Malley*
>>  Manager, Patch System Test
>> Revenue Product Engineering | Solaris | Hardware
>> East Point Business Park, Dublin 3, Ireland
>> Phone: +353 1 8199764
>> Team Alias: rpe_patch_system_test_ww at oracle.com
>>
>
>
>
> --
> Jeff
>
>
> --
>  <http://www.oracle.com/>
> *Don O'Malley*
>  Manager,Patch System Test
> Revenue Product Engineering | Solaris | Hardware
> East Point Business Park, Dublin 3, Ireland
> Phone: +353 1 8199764
> Team Alias: rpe_patch_system_test_ww at oracle.com
>



-- 
Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.univie.ac.at/pipermail/pca/attachments/20110608/cc3ea7d1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graphics1
Type: image/gif
Size: 2059 bytes
Desc: not available
URL: <https://lists.univie.ac.at/pipermail/pca/attachments/20110608/cc3ea7d1/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graphics1
Type: image/gif
Size: 2059 bytes
Desc: not available
URL: <https://lists.univie.ac.at/pipermail/pca/attachments/20110608/cc3ea7d1/attachment-0003.gif>

From gael.martinez at gmail.com  Wed Jun  8 16:08:41 2011
From: gael.martinez at gmail.com (Gael Martinez)
Date: Wed, 8 Jun 2011 09:08:41 -0500
Subject: [pca] Oracle removed support from patchdiag.xref for --minimal
 option in pca?
In-Reply-To: <BANLkTinjiYs3COozPdAWJso_byDvm5g29w@mail.gmail.com>
References: <BANLkTi=sO96vBSn0jS818S8_vGZG5vLNBg@mail.gmail.com>
	<4DDF680B.6010307@oracle.com>
	<BANLkTi=Tc3bXeLTZ0utJ-i2Y1_p7wk=16w@mail.gmail.com>
	<4DEF70E2.2040008@oracle.com>
	<BANLkTinjiYs3COozPdAWJso_byDvm5g29w@mail.gmail.com>
Message-ID: <BANLkTikSa80UD3tq4pAe5gir_vb7P3wHJg@mail.gmail.com>

On Wed, Jun 8, 2011 at 8:46 AM, Jeff <variverrat at gmail.com> wrote:

>   What would be even better is if the CPU contained a copy of
> patchdiag.xref that can be used by PCA users to replicate the CPU.
>

Why don't you use the patch_order file included in the CPU ? pca does accept
a list of patch in a  file ...

-- 
Ga?l Martinez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.univie.ac.at/pipermail/pca/attachments/20110608/cf49464d/attachment.html>

From variverrat at gmail.com  Wed Jun  8 19:13:45 2011
From: variverrat at gmail.com (Jeff)
Date: Wed, 8 Jun 2011 13:13:45 -0400
Subject: [pca] Oracle removed support from patchdiag.xref for --minimal
 option in pca?
In-Reply-To: <BANLkTikSa80UD3tq4pAe5gir_vb7P3wHJg@mail.gmail.com>
References: <BANLkTi=sO96vBSn0jS818S8_vGZG5vLNBg@mail.gmail.com>
	<4DDF680B.6010307@oracle.com>
	<BANLkTi=Tc3bXeLTZ0utJ-i2Y1_p7wk=16w@mail.gmail.com>
	<4DEF70E2.2040008@oracle.com>
	<BANLkTinjiYs3COozPdAWJso_byDvm5g29w@mail.gmail.com>
	<BANLkTikSa80UD3tq4pAe5gir_vb7P3wHJg@mail.gmail.com>
Message-ID: <BANLkTikJKe8WZ6uT7XY0W2nrHAw0BpEAzw@mail.gmail.com>

>From what I understand about how PCA works, if you specify a specific patch
revision in a list, it isn't able to check supercedings and dependencies,
because it doesn't have a match in patchdiag.xref.  So you would still end
up downloading all the patches and trying to apply them.

On Wed, Jun 8, 2011 at 10:08 AM, Gael Martinez <gael.martinez at gmail.com>wrote:

>
> On Wed, Jun 8, 2011 at 8:46 AM, Jeff <variverrat at gmail.com> wrote:
>
>>   What would be even better is if the CPU contained a copy of
>> patchdiag.xref that can be used by PCA users to replicate the CPU.
>>
>
> Why don't you use the patch_order file included in the CPU ? pca does
> accept a list of patch in a  file ...
>
> --
> Ga?l Martinez
>
>
>


-- 
Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.univie.ac.at/pipermail/pca/attachments/20110608/70c861a1/attachment.html>

From Craig.Bell at standard.com  Wed Jun  8 19:13:06 2011
From: Craig.Bell at standard.com (Craig Bell)
Date: Wed, 8 Jun 2011 17:13:06 +0000
Subject: [pca] fix maximum patch level for a patch
Message-ID: <DD971D87840E9E4E877B7790B72F27ED12433B@PDXWEXMBP002.corp.standard.com>

Steve Goldthorpe wrote:

> With patch 119534-24 and above, createflar creates version 3.0 flash
> archives that cannot be read by Solaris 10u9 miniroots.

Steve, I found this out the hard way. =-/  There's a workaround, if you like.
I don't know how you boot your install image; but can you patch your miniroot?
Applying 124630-51 or later allows extraction of v3.0 archives.

FWIW patching the miniroot is pretty easy with U9, I haven't needed to do this since U3.
I hear that U10 might be out in August, but I wanted this capability right away.
I opened a case, and Oracle agreed to add a new note to 119534 as follows:

> "The following note was added to the README of patch 119534-27:
>
> NOTE 11: Flash archives created after applying this patch will have a new
> version number: 3.0. The following patch must be applied to the
> miniroot of install images used for installing this new version
> of flash archives:
>
> 124630-51 (or greater) System Administration Applications, Network,
> and Core Libraries Patch "

Just let me know if you would like any more info. =-)  -cheers, CSB

Craig S. Bell  |  Senior UNIX Systems Engineer
The Standard
Standard Insurance Company
900 S.W. Fifth Avenue | Portland, OR 97204
Phone 971.321.6058 | Fax 971.321.5911
craig.bell at standard.com<mailto:email at standard.com> | www.standard.com<http://www.standard.com/>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.univie.ac.at/pipermail/pca/attachments/20110608/bdda7ed9/attachment.html>

From glenn.satchell at uniq.com.au  Thu Jun  9 06:13:31 2011
From: glenn.satchell at uniq.com.au (Glenn Satchell)
Date: Thu, 9 Jun 2011 14:13:31 +1000
Subject: [pca] Oracle removed support from patchdiag.xref for --minimal
 option in pca?
In-Reply-To: <BANLkTikJKe8WZ6uT7XY0W2nrHAw0BpEAzw@mail.gmail.com>
References: <BANLkTi=sO96vBSn0jS818S8_vGZG5vLNBg@mail.gmail.com>
	<4DDF680B.6010307@oracle.com>
	<BANLkTi=Tc3bXeLTZ0utJ-i2Y1_p7wk=16w@mail.gmail.com>
	<4DEF70E2.2040008@oracle.com>
	<BANLkTinjiYs3COozPdAWJso_byDvm5g29w@mail.gmail.com>
	<BANLkTikSa80UD3tq4pAe5gir_vb7P3wHJg@mail.gmail.com>
	<BANLkTikJKe8WZ6uT7XY0W2nrHAw0BpEAzw@mail.gmail.com>
Message-ID: <aa018b5cf1987ebe46349297382779b3.squirrel@mail.uniq.com.au>

Unless the specific patch is already installed, so it should only download
the new patches. So this is a win over downloading the whole 2GB patch
bundle.

If you strip the revision numbers off the list and use that, pca will get
the latest version of each patch. The CPU revisions are not necessarily
always the latest version.

regards,
-glenn

> From what I understand about how PCA works, if you specify a specific
> patch
> revision in a list, it isn't able to check supercedings and dependencies,
> because it doesn't have a match in patchdiag.xref.  So you would still end
> up downloading all the patches and trying to apply them.
>
> On Wed, Jun 8, 2011 at 10:08 AM, Gael Martinez
> <gael.martinez at gmail.com>wrote:
>
>>
>> On Wed, Jun 8, 2011 at 8:46 AM, Jeff <variverrat at gmail.com> wrote:
>>
>>>   What would be even better is if the CPU contained a copy of
>>> patchdiag.xref that can be used by PCA users to replicate the CPU.
>>>
>>
>> Why don't you use the patch_order file included in the CPU ? pca does
>> accept a list of patch in a  file ...
>>
>> --
>> Ga?l Martinez
>>
>>
>>
>
>
> --
> Jeff
>




From martin at par.univie.ac.at  Thu Jun  9 10:28:57 2011
From: martin at par.univie.ac.at (Martin Paul)
Date: Thu, 09 Jun 2011 10:28:57 +0200
Subject: [pca] supplevel option
In-Reply-To: <4DEF4CDC.9080601@clickandbuy.com>
References: <4DAC0169.7050904@par.univie.ac.at>
	<4DEF4CDC.9080601@clickandbuy.com>
Message-ID: <4DF08449.7030703@par.univie.ac.at>

Hi Kresimir,

> this seems to be cookie issue with "wget". If you save JSESSIONID cookie
> using mozilla browser into file (you may capture it with Live HTTP
> headers plugin for example) and then load this cookie file using
> "--load-cookies" wget option, wget will return XML file correctly.

Interesting, I thought that Oracle actively denies access to the XML file, 
despite the authentication with an MOS account. Have you compared access to the 
XML with access to a patch? These two must use different authentication 
procedures or cookies then.

> I tried curl and aria2c, same issue. Complex session cookies seem to
> present a problem to CLI downloaders.

Maybe you could post your findings to the wget mailing list and see what they 
say about it?

Thanks,

Martin.


From littlehelphere at gmail.com  Fri Jun 10 16:55:09 2011
From: littlehelphere at gmail.com (little help)
Date: Fri, 10 Jun 2011 10:55:09 -0400
Subject: [pca] Patch pre-requisites
Message-ID: <BANLkTi=f2Jo0rvW0xROZ0inWhND_iudcOw@mail.gmail.com>

I had a quick question about the pre-requisites when installing one patch.
I know pca determines dependence, etc and installs patches in that order.
However, how do you do this for one single patch.   For example - I want to
install
109326-17 : libresolv.so.2, in.named and BIND9 patch
Now libresolv.so.2 has C dependencies.  When I do a full pca check for my
host the C patches come right after the patch for patchadd.  However, there
are about 20+ patches before I get tot he libresolv patch. Are all these
patches dependencies?  I don't see how.  I look at the readme file for the
libresolv patch and do not see anything at all about dependencies.  Is there
a way to check what requirements this patch needs from pca - perhaps a flag,
etc?  Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.univie.ac.at/pipermail/pca/attachments/20110610/075c17d7/attachment.html>

From variverrat at gmail.com  Fri Jun 10 17:13:27 2011
From: variverrat at gmail.com (Jeff)
Date: Fri, 10 Jun 2011 11:13:27 -0400
Subject: [pca] Oracle removed support from patchdiag.xref for --minimal
 option in pca?
In-Reply-To: <aa018b5cf1987ebe46349297382779b3.squirrel@mail.uniq.com.au>
References: <BANLkTi=sO96vBSn0jS818S8_vGZG5vLNBg@mail.gmail.com>
	<4DDF680B.6010307@oracle.com>
	<BANLkTi=Tc3bXeLTZ0utJ-i2Y1_p7wk=16w@mail.gmail.com>
	<4DEF70E2.2040008@oracle.com>
	<BANLkTinjiYs3COozPdAWJso_byDvm5g29w@mail.gmail.com>
	<BANLkTikSa80UD3tq4pAe5gir_vb7P3wHJg@mail.gmail.com>
	<BANLkTikJKe8WZ6uT7XY0W2nrHAw0BpEAzw@mail.gmail.com>
	<aa018b5cf1987ebe46349297382779b3.squirrel@mail.uniq.com.au>
Message-ID: <BANLkTimxkAAbqPuH4RanVbxfPqsx8ov_+w@mail.gmail.com>

>From the way I understand how PCA works, when specifying a specific revision
of a patch, it does no checking prior to trying to install, since it can't
reference pre-reqs and supercedings in patchdiag.xref.  As a test, I grabbed
the patch list from the CPU readme and fed it into PCA, it downloaded and
tried to apply all 209 patches.

I prefer to stick with only the revisions in the CPU, since I hope there is
a greater chance they are well tested before released.  You don't need to
look any further then the last couple weeks when kernel patches 144488-13
through 144488-15 were withdrawn.


On Thu, Jun 9, 2011 at 12:13 AM, Glenn Satchell
<glenn.satchell at uniq.com.au>wrote:

> Unless the specific patch is already installed, so it should only download
> the new patches. So this is a win over downloading the whole 2GB patch
> bundle.
>
> If you strip the revision numbers off the list and use that, pca will get
> the latest version of each patch. The CPU revisions are not necessarily
> always the latest version.
>
> regards,
> -glenn
>
> > From what I understand about how PCA works, if you specify a specific
> > patch
> > revision in a list, it isn't able to check supercedings and dependencies,
> > because it doesn't have a match in patchdiag.xref.  So you would still
> end
> > up downloading all the patches and trying to apply them.
> >
> > On Wed, Jun 8, 2011 at 10:08 AM, Gael Martinez
> > <gael.martinez at gmail.com>wrote:
> >
> >>
> >> On Wed, Jun 8, 2011 at 8:46 AM, Jeff <variverrat at gmail.com> wrote:
> >>
> >>>   What would be even better is if the CPU contained a copy of
> >>> patchdiag.xref that can be used by PCA users to replicate the CPU.
> >>>
> >>
> >> Why don't you use the patch_order file included in the CPU ? pca does
> >> accept a list of patch in a  file ...
> >>
> >> --
> >> Ga?l Martinez
> >>
> >>
> >>
> >
> >
> > --
> > Jeff
> >
>
>
>
>


-- 
Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.univie.ac.at/pipermail/pca/attachments/20110610/b550f8e5/attachment.html>

From fchagnon at gmail.com  Fri Jun 10 19:28:21 2011
From: fchagnon at gmail.com (Fred)
Date: Fri, 10 Jun 2011 13:28:21 -0400
Subject: [pca] Patch pre-requisites
In-Reply-To: <BANLkTi=f2Jo0rvW0xROZ0inWhND_iudcOw@mail.gmail.com>
References: <BANLkTi=f2Jo0rvW0xROZ0inWhND_iudcOw@mail.gmail.com>
Message-ID: <BANLkTi=moZ4YZmCCt4P-O85nEd+fR1DVpA@mail.gmail.com>

You can determine the dependencies of a single patch by supplying the patch
ID in the ARGS list on the command line. For example:

$ pca -l 142341

Is that what you wanted?


On Fri, Jun 10, 2011 at 10:55 AM, little help <littlehelphere at gmail.com>wrote:

> I had a quick question about the pre-requisites when installing one patch.
> I know pca determines dependence, etc and installs patches in that order.
> However, how do you do this for one single patch.   For example - I want to
> install
> 109326-17 : libresolv.so.2, in.named and BIND9 patch
> Now libresolv.so.2 has C dependencies.  When I do a full pca check for my
> host the C patches come right after the patch for patchadd.  However, there
> are about 20+ patches before I get tot he libresolv patch. Are all these
> patches dependencies?  I don't see how.  I look at the readme file for the
> libresolv patch and do not see anything at all about dependencies.  Is there
> a way to check what requirements this patch needs from pca - perhaps a flag,
> etc?  Thanks.
>



-- 
Fred Chagnon
fchagnon at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.univie.ac.at/pipermail/pca/attachments/20110610/2762703c/attachment.html>

From littlehelphere at gmail.com  Mon Jun 13 16:37:00 2011
From: littlehelphere at gmail.com (little help)
Date: Mon, 13 Jun 2011 10:37:00 -0400
Subject: [pca] Patch pre-requisites
In-Reply-To: <BANLkTi=moZ4YZmCCt4P-O85nEd+fR1DVpA@mail.gmail.com>
References: <BANLkTi=f2Jo0rvW0xROZ0inWhND_iudcOw@mail.gmail.com>
	<BANLkTi=moZ4YZmCCt4P-O85nEd+fR1DVpA@mail.gmail.com>
Message-ID: <BANLkTi=sqiJgDCKPy6M3wWovC5WYJ-_B8A@mail.gmail.com>

Fred,
   Seems to be right - thanks for the tip.

On Fri, Jun 10, 2011 at 1:28 PM, Fred <fchagnon at gmail.com> wrote:

> You can determine the dependencies of a single patch by supplying the patch
> ID in the ARGS list on the command line. For example:
>
> $ pca -l 142341
>
> Is that what you wanted?
>
>
>
> On Fri, Jun 10, 2011 at 10:55 AM, little help <littlehelphere at gmail.com>wrote:
>
>> I had a quick question about the pre-requisites when installing one
>> patch.  I know pca determines dependence, etc and installs patches in that
>> order.  However, how do you do this for one single patch.   For example - I
>> want to install
>> 109326-17 : libresolv.so.2, in.named and BIND9 patch
>> Now libresolv.so.2 has C dependencies.  When I do a full pca check for my
>> host the C patches come right after the patch for patchadd.  However, there
>> are about 20+ patches before I get tot he libresolv patch. Are all these
>> patches dependencies?  I don't see how.  I look at the readme file for the
>> libresolv patch and do not see anything at all about dependencies.  Is there
>> a way to check what requirements this patch needs from pca - perhaps a flag,
>> etc?  Thanks.
>>
>
>
>
> --
> Fred Chagnon
> fchagnon at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.univie.ac.at/pipermail/pca/attachments/20110613/118f0f15/attachment.html>

From littlehelphere at gmail.com  Mon Jun 13 19:03:11 2011
From: littlehelphere at gmail.com (little help)
Date: Mon, 13 Jun 2011 13:03:11 -0400
Subject: [pca] Patch pre-requisites
In-Reply-To: <BANLkTi=sqiJgDCKPy6M3wWovC5WYJ-_B8A@mail.gmail.com>
References: <BANLkTi=f2Jo0rvW0xROZ0inWhND_iudcOw@mail.gmail.com>
	<BANLkTi=moZ4YZmCCt4P-O85nEd+fR1DVpA@mail.gmail.com>
	<BANLkTi=sqiJgDCKPy6M3wWovC5WYJ-_B8A@mail.gmail.com>
Message-ID: <BANLkTinqTfsx1z-HeLwQcDaLNtxsqprUcA@mail.gmail.com>

Actually I did a little more digging on this and the "-l" optin does not
seem to show the dependencies.  For example I ran the command against a
kernel patch

Below is the command and the results.  According to this no dependence.
pca -l 127721-03

Patch  IR   CR RSB Age Synopsis
------ -- - -- --- ---
-------------------------------------------------------
127721 -- < 06 RS-  63 SunOS 5.8: kernel patch

I then untarred the actual patch and looked at the patchinfo file.  You can
see the patch requires three other patches.  So now I guess I am back to the
beginning.  Any ideas how to get details on the dependencies for a patch?
Thanks.
more patchinfo
PATCHINFOVERSION="1.0"
PATCHID=127721-03
PATCH_CORRECTS='Automate-1.0'
PATCH_ARCH='sparc'
PATCH_OS='SunOS'
PATCH_OSRELEASE='5.8'
PATCH_PROPERTIES='clientroot clientusr rebootimmediate singleuser'
*PATCH_REQUIRES="108528-29 117000-05 117350-62"*
PATCH_OBSOLETES="108727-26 111439-03 112325-01 114671-04 116959-21"


On Mon, Jun 13, 2011 at 10:37 AM, little help <littlehelphere at gmail.com>wrote:

> Fred,
>    Seems to be right - thanks for the tip.
>
> On Fri, Jun 10, 2011 at 1:28 PM, Fred <fchagnon at gmail.com> wrote:
>
>> You can determine the dependencies of a single patch by supplying the
>> patch ID in the ARGS list on the command line. For example:
>>
>> $ pca -l 142341
>>
>> Is that what you wanted?
>>
>>
>>
>> On Fri, Jun 10, 2011 at 10:55 AM, little help <littlehelphere at gmail.com>wrote:
>>
>>> I had a quick question about the pre-requisites when installing one
>>> patch.  I know pca determines dependence, etc and installs patches in that
>>> order.  However, how do you do this for one single patch.   For example - I
>>> want to install
>>> 109326-17 : libresolv.so.2, in.named and BIND9 patch
>>> Now libresolv.so.2 has C dependencies.  When I do a full pca check for my
>>> host the C patches come right after the patch for patchadd.  However, there
>>> are about 20+ patches before I get tot he libresolv patch. Are all these
>>> patches dependencies?  I don't see how.  I look at the readme file for the
>>> libresolv patch and do not see anything at all about dependencies.  Is there
>>> a way to check what requirements this patch needs from pca - perhaps a flag,
>>> etc?  Thanks.
>>>
>>
>>
>>
>> --
>> Fred Chagnon
>> fchagnon at gmail.com
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.univie.ac.at/pipermail/pca/attachments/20110613/56f048c6/attachment.html>

From fchagnon at gmail.com  Mon Jun 13 19:28:06 2011
From: fchagnon at gmail.com (Fred)
Date: Mon, 13 Jun 2011 13:28:06 -0400
Subject: [pca] Patch pre-requisites
In-Reply-To: <BANLkTinqTfsx1z-HeLwQcDaLNtxsqprUcA@mail.gmail.com>
References: <BANLkTi=f2Jo0rvW0xROZ0inWhND_iudcOw@mail.gmail.com>
	<BANLkTi=moZ4YZmCCt4P-O85nEd+fR1DVpA@mail.gmail.com>
	<BANLkTi=sqiJgDCKPy6M3wWovC5WYJ-_B8A@mail.gmail.com>
	<BANLkTinqTfsx1z-HeLwQcDaLNtxsqprUcA@mail.gmail.com>
Message-ID: <BANLkTimTTgxwoxrWm+LEoH2ff6gb-je-vQ@mail.gmail.com>

Does the system you're running pca on already meet or exceed the other
unlisted requirements for that kernel patch? Remeber that pca is basically
telling you "This is what I will install, in this order, for the patch you
specify".

Fred

On Mon, Jun 13, 2011 at 1:03 PM, little help <littlehelphere at gmail.com>wrote:

> Actually I did a little more digging on this and the "-l" optin does not
> seem to show the dependencies.  For example I ran the command against a
> kernel patch
>
> Below is the command and the results.  According to this no dependence.
> pca -l 127721-03
>
> Patch  IR   CR RSB Age Synopsis
> ------ -- - -- --- ---
> -------------------------------------------------------
> 127721 -- < 06 RS-  63 SunOS 5.8: kernel patch
>
> I then untarred the actual patch and looked at the patchinfo file.  You can
> see the patch requires three other patches.  So now I guess I am back to the
> beginning.  Any ideas how to get details on the dependencies for a patch?
> Thanks.
> more patchinfo
> PATCHINFOVERSION="1.0"
> PATCHID=127721-03
> PATCH_CORRECTS='Automate-1.0'
> PATCH_ARCH='sparc'
> PATCH_OS='SunOS'
> PATCH_OSRELEASE='5.8'
> PATCH_PROPERTIES='clientroot clientusr rebootimmediate singleuser'
> *PATCH_REQUIRES="108528-29 117000-05 117350-62"*
> PATCH_OBSOLETES="108727-26 111439-03 112325-01 114671-04 116959-21"
>
>
>
> On Mon, Jun 13, 2011 at 10:37 AM, little help <littlehelphere at gmail.com>wrote:
>
>> Fred,
>>    Seems to be right - thanks for the tip.
>>
>> On Fri, Jun 10, 2011 at 1:28 PM, Fred <fchagnon at gmail.com> wrote:
>>
>>> You can determine the dependencies of a single patch by supplying the
>>> patch ID in the ARGS list on the command line. For example:
>>>
>>> $ pca -l 142341
>>>
>>> Is that what you wanted?
>>>
>>>
>>>
>>> On Fri, Jun 10, 2011 at 10:55 AM, little help <littlehelphere at gmail.com>wrote:
>>>
>>>> I had a quick question about the pre-requisites when installing one
>>>> patch.  I know pca determines dependence, etc and installs patches in that
>>>> order.  However, how do you do this for one single patch.   For example - I
>>>> want to install
>>>> 109326-17 : libresolv.so.2, in.named and BIND9 patch
>>>> Now libresolv.so.2 has C dependencies.  When I do a full pca check for
>>>> my host the C patches come right after the patch for patchadd.  However,
>>>> there are about 20+ patches before I get tot he libresolv patch. Are all
>>>> these patches dependencies?  I don't see how.  I look at the readme file for
>>>> the libresolv patch and do not see anything at all about dependencies.  Is
>>>> there a way to check what requirements this patch needs from pca - perhaps a
>>>> flag, etc?  Thanks.
>>>>
>>>
>>>
>>>
>>> --
>>> Fred Chagnon
>>> fchagnon at gmail.com
>>>
>>
>>
>


-- 
Fred Chagnon
fchagnon at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.univie.ac.at/pipermail/pca/attachments/20110613/c7a04ed4/attachment-0001.html>

From glenn.satchell at uniq.com.au  Tue Jun 14 00:09:59 2011
From: glenn.satchell at uniq.com.au (Glenn Satchell)
Date: Tue, 14 Jun 2011 08:09:59 +1000
Subject: [pca] Patch pre-requisites
In-Reply-To: <BANLkTimTTgxwoxrWm+LEoH2ff6gb-je-vQ@mail.gmail.com>
References: <BANLkTi=f2Jo0rvW0xROZ0inWhND_iudcOw@mail.gmail.com>	<BANLkTi=moZ4YZmCCt4P-O85nEd+fR1DVpA@mail.gmail.com>	<BANLkTi=sqiJgDCKPy6M3wWovC5WYJ-_B8A@mail.gmail.com>	<BANLkTinqTfsx1z-HeLwQcDaLNtxsqprUcA@mail.gmail.com>
	<BANLkTimTTgxwoxrWm+LEoH2ff6gb-je-vQ@mail.gmail.com>
Message-ID: <4DF68AB7.1060009@uniq.com.au>

There is some slight differences here.

When you give pca the patch *and* the revision number it assumes that 
you want information about *only* that one patch.

If you the patch number *without* the revision, then it looks up the 
patch and dependencies in patchdiag.xref and gives all to you.

 >             $ pca -l 142341
 >
 >             Is that what you wanted?

 >     Below is the command and the results.  According to this no 
dependence.
 >     pca -l 127721-03

Try using

	pca -l 127721

regards,
-glenn


On 06/14/11 03:28, Fred wrote:
> Does the system you're running pca on already meet or exceed the other
> unlisted requirements for that kernel patch? Remeber that pca is
> basically telling you "This is what I will install, in this order, for
> the patch you specify".
>
> Fred
>
> On Mon, Jun 13, 2011 at 1:03 PM, little help <littlehelphere at gmail.com
> <mailto:littlehelphere at gmail.com>> wrote:
>
>     Actually I did a little more digging on this and the "-l" optin does
>     not seem to show the dependencies.  For example I ran the command
>     against a kernel patch
>
>     Below is the command and the results.  According to this no dependence.
>     pca -l 127721-03
>
>     Patch  IR   CR RSB Age Synopsis
>     ------ -- - -- --- ---
>     -------------------------------------------------------
>     127721 -- < 06 RS-  63 SunOS 5.8: kernel patch
>
>     I then untarred the actual patch and looked at the patchinfo file.
>     You can see the patch requires three other patches.  So now I guess
>     I am back to the beginning.  Any ideas how to get details on the
>     dependencies for a patch?  Thanks.
>     more patchinfo
>     PATCHINFOVERSION="1.0"
>     PATCHID=127721-03
>     PATCH_CORRECTS='Automate-1.0'
>     PATCH_ARCH='sparc'
>     PATCH_OS='SunOS'
>     PATCH_OSRELEASE='5.8'
>     PATCH_PROPERTIES='clientroot clientusr rebootimmediate singleuser'
>     *PATCH_REQUIRES="108528-29 117000-05 117350-62"*
>     PATCH_OBSOLETES="108727-26 111439-03 112325-01 114671-04 116959-21"
>
>
>
>     On Mon, Jun 13, 2011 at 10:37 AM, little help
>     <littlehelphere at gmail.com <mailto:littlehelphere at gmail.com>> wrote:
>
>         Fred,
>             Seems to be right - thanks for the tip.
>
>         On Fri, Jun 10, 2011 at 1:28 PM, Fred <fchagnon at gmail.com
>         <mailto:fchagnon at gmail.com>> wrote:
>
>             You can determine the dependencies of a single patch by
>             supplying the patch ID in the ARGS list on the command line.
>             For example:
>
>             $ pca -l 142341
>
>             Is that what you wanted?
>
>
>
>             On Fri, Jun 10, 2011 at 10:55 AM, little help
>             <littlehelphere at gmail.com <mailto:littlehelphere at gmail.com>>
>             wrote:
>
>                 I had a quick question about the pre-requisites when
>                 installing one patch.  I know pca determines dependence,
>                 etc and installs patches in that order.  However, how do
>                 you do this for one single patch.   For example - I want
>                 to install
>                 109326-17 : libresolv.so.2, in.named and BIND9 patch
>                 Now libresolv.so.2 has C dependencies.  When I do a full
>                 pca check for my host the C patches come right after the
>                 patch for patchadd.  However, there are about 20+
>                 patches before I get tot he libresolv patch. Are all
>                 these patches dependencies?  I don't see how.  I look at
>                 the readme file for the libresolv patch and do not see
>                 anything at all about dependencies.  Is there a way to
>                 check what requirements this patch needs from pca -
>                 perhaps a flag, etc?  Thanks.
>
>
>
>
>             --
>             Fred Chagnon
>             fchagnon at gmail.com <mailto:fchagnon at gmail.com>
>
>
>
>
>
>
> --
> Fred Chagnon
> fchagnon at gmail.com <mailto:fchagnon at gmail.com>


From martin at par.univie.ac.at  Tue Jun 14 09:55:53 2011
From: martin at par.univie.ac.at (Martin Paul)
Date: Tue, 14 Jun 2011 09:55:53 +0200
Subject: [pca] Oracle removed support from patchdiag.xref for --minimal
 option in pca?
In-Reply-To: <BANLkTimxkAAbqPuH4RanVbxfPqsx8ov_+w@mail.gmail.com>
References: <BANLkTi=sO96vBSn0jS818S8_vGZG5vLNBg@mail.gmail.com>	<4DDF680B.6010307@oracle.com>	<BANLkTi=Tc3bXeLTZ0utJ-i2Y1_p7wk=16w@mail.gmail.com>	<4DEF70E2.2040008@oracle.com>	<BANLkTinjiYs3COozPdAWJso_byDvm5g29w@mail.gmail.com>	<BANLkTikSa80UD3tq4pAe5gir_vb7P3wHJg@mail.gmail.com>	<BANLkTikJKe8WZ6uT7XY0W2nrHAw0BpEAzw@mail.gmail.com>	<aa018b5cf1987ebe46349297382779b3.squirrel@mail.uniq.com.au>
	<BANLkTimxkAAbqPuH4RanVbxfPqsx8ov_+w@mail.gmail.com>
Message-ID: <4DF71409.6080008@par.univie.ac.at>

Jeff wrote:
>>From the way I understand how PCA works, when specifying a specific revision
> of a patch, it does no checking prior to trying to install, since it can't
> reference pre-reqs and supercedings in patchdiag.xref.  As a test, I grabbed
> the patch list from the CPU readme and fed it into PCA, it downloaded and
> tried to apply all 209 patches.

Yes, that's correct, both your assumption and the behaviour.

> I prefer to stick with only the revisions in the CPU, since I hope there is
> a greater chance they are well tested before released.

I think the "chkmin" script from PCA's "Contrib" webpage could help here. If you 
feed it the list of all patches from the CPU, it will reduce it to those which 
are not installed yet (in the specified revision or higher). You can then feed 
this reduced list back to PCA for installation. Something like this might give 
the wanted result:

   $ pca --install `cat cpu_patches.txt | ./chkmin`

Let us know if you try it!

Martin.


From martin at par.univie.ac.at  Tue Jun 14 14:50:02 2011
From: martin at par.univie.ac.at (Martin Paul)
Date: Tue, 14 Jun 2011 14:50:02 +0200
Subject: [pca] supplevel option
In-Reply-To: <4DAC0169.7050904@par.univie.ac.at>
References: <4DAC0169.7050904@par.univie.ac.at>
Message-ID: <4DF758FA.1050306@par.univie.ac.at>

As the method which PCA uses to determine the support levels for an MOS Account 
with the "--supplevel" doesn't work anymore for 2 months now, and as I found no 
other method to query the required information, I see no alternative to 
deprecating this option.

I've already made the required changes in the current development version:

   $ ./pca --supplevel
   DEPRECATED: Oracle broke the interface to query this information
   $

Too bad.

Martin.


From variverrat at gmail.com  Tue Jun 14 16:29:44 2011
From: variverrat at gmail.com (Jeff)
Date: Tue, 14 Jun 2011 10:29:44 -0400
Subject: [pca] Oracle removed support from patchdiag.xref for --minimal
 option in pca?
In-Reply-To: <4DF71409.6080008@par.univie.ac.at>
References: <BANLkTi=sO96vBSn0jS818S8_vGZG5vLNBg@mail.gmail.com>
	<4DDF680B.6010307@oracle.com>
	<BANLkTi=Tc3bXeLTZ0utJ-i2Y1_p7wk=16w@mail.gmail.com>
	<4DEF70E2.2040008@oracle.com>
	<BANLkTinjiYs3COozPdAWJso_byDvm5g29w@mail.gmail.com>
	<BANLkTikSa80UD3tq4pAe5gir_vb7P3wHJg@mail.gmail.com>
	<BANLkTikJKe8WZ6uT7XY0W2nrHAw0BpEAzw@mail.gmail.com>
	<aa018b5cf1987ebe46349297382779b3.squirrel@mail.uniq.com.au>
	<BANLkTimxkAAbqPuH4RanVbxfPqsx8ov_+w@mail.gmail.com>
	<4DF71409.6080008@par.univie.ac.at>
Message-ID: <BANLkTimGM_1uAiOOdRU6sjafCH2U8fzw=g@mail.gmail.com>

Thanks for the suggestion Martin, hadn't used chkmin before.

This was the syntax I ended up using, not pretty:  pca -l `./chkmin \`cat
AprCPU.lst\``

It does reduce the number of patches to 100, but the problem still exists
that pca doesn't verify the packages are installed that the patches applies
to if a specific revision is requested.  So in the case of the server I'm
testing, it was built with the SUNWCrnet cluster, so it has minimal packages
and the actual number that would be applied is around 10.

I really think the best solution is to either convince Oracle to package a
patchdiag.xref that cooresponds with the revisions in the CPU within the CPU
bundle, or for me to grab patchdiag.xrefs around the release date until I
find one that cooresponds with the bundle.

It's kinda crazy that the best way to manage patching on Solaris systems
after all these years continues to be PCA and would hope Oracle would
continue to support its' use since there really isn't any valid
alternative.  All I have to say is keep up the good work Martin, you are
keeping a lot of Solaris shops afloat.





On Tue, Jun 14, 2011 at 3:55 AM, Martin Paul <martin at par.univie.ac.at>wrote:

> Jeff wrote:
>
>> From the way I understand how PCA works, when specifying a specific
>>> revision
>>>
>> of a patch, it does no checking prior to trying to install, since it can't
>> reference pre-reqs and supercedings in patchdiag.xref.  As a test, I
>> grabbed
>> the patch list from the CPU readme and fed it into PCA, it downloaded and
>> tried to apply all 209 patches.
>>
>
> Yes, that's correct, both your assumption and the behaviour.
>
>
>  I prefer to stick with only the revisions in the CPU, since I hope there
>> is
>> a greater chance they are well tested before released.
>>
>
> I think the "chkmin" script from PCA's "Contrib" webpage could help here.
> If you feed it the list of all patches from the CPU, it will reduce it to
> those which are not installed yet (in the specified revision or higher). You
> can then feed this reduced list back to PCA for installation. Something like
> this might give the wanted result:
>
>  $ pca --install `cat cpu_patches.txt | ./chkmin`
>
> Let us know if you try it!
>
> Martin.
>
>


-- 
Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.univie.ac.at/pipermail/pca/attachments/20110614/47656127/attachment.html>

From littlehelphere at gmail.com  Tue Jun 14 17:37:25 2011
From: littlehelphere at gmail.com (little help)
Date: Tue, 14 Jun 2011 11:37:25 -0400
Subject: [pca] Patch pre-requisites
In-Reply-To: <4DF68AB7.1060009@uniq.com.au>
References: <BANLkTi=f2Jo0rvW0xROZ0inWhND_iudcOw@mail.gmail.com>
	<BANLkTi=moZ4YZmCCt4P-O85nEd+fR1DVpA@mail.gmail.com>
	<BANLkTi=sqiJgDCKPy6M3wWovC5WYJ-_B8A@mail.gmail.com>
	<BANLkTinqTfsx1z-HeLwQcDaLNtxsqprUcA@mail.gmail.com>
	<BANLkTimTTgxwoxrWm+LEoH2ff6gb-je-vQ@mail.gmail.com>
	<4DF68AB7.1060009@uniq.com.au>
Message-ID: <BANLkTi=Fdj7WDPTskCDNkfz0JEqx0DJroQ@mail.gmail.com>

Glenn,
   That seems to provide a bit more detail, which seems to make sense had I
not seen the patchinfo file.  I ran the pca command against the patch
without a revision (see below) and then ran the same command against the
dependencies to see if they had any pre-requisites (below).  It seems to
show one requirements (117350-62) but not the others.  Any ideas.
*PATCH_REQUIRES="108528-29 117000-05 117350-62"*

pca -l 127721
Patch  IR   CR RSB Age Synopsis
------ -- - -- --- ---
-------------------------------------------------------
128624 -- < 16 RS- 116 SunOS 5.8: LDAP2 client, libc, libthread and libnsl
libraries patc
117350 28 < 62 RS- 784 SunOS 5.8: kernel patch
127721 -- < 06 RS-  64 SunOS 5.8: kernel patch

pca -l 128624
Patch  IR   CR RSB Age Synopsis
------ -- - -- --- ---
-------------------------------------------------------
128624 -- < 16 RS- 116 SunOS 5.8: LDAP2 client, libc, libthread and libnsl
libraries patc

pca -l 117350
Patch  IR   CR RSB Age Synopsis
------ -- - -- --- ---
-------------------------------------------------------
128624 -- < 16 RS- 116 SunOS 5.8: LDAP2 client, libc, libthread and libnsl
libraries patc
117350 28 < 62 RS- 784 SunOS 5.8: kernel patch

pca -l 127721
Patch  IR   CR RSB Age Synopsis
------ -- - -- --- ---
-------------------------------------------------------
128624 -- < 16 RS- 116 SunOS 5.8: LDAP2 client, libc, libthread and libnsl
libraries patc
117350 28 < 62 RS- 784 SunOS 5.8: kernel patch
127721 -- < 06 RS-  64 SunOS 5.8: kernel patch



On Mon, Jun 13, 2011 at 6:09 PM, Glenn Satchell
<glenn.satchell at uniq.com.au>wrote:

> There is some slight differences here.
>
> When you give pca the patch *and* the revision number it assumes that you
> want information about *only* that one patch.
>
> If you the patch number *without* the revision, then it looks up the patch
> and dependencies in patchdiag.xref and gives all to you.
>
>
> >             $ pca -l 142341
> >
> >             Is that what you wanted?
>
> >     Below is the command and the results.  According to this no
> dependence.
> >     pca -l 127721-03
>
> Try using
>
>        pca -l 127721
>
> regards,
> -glenn
>
>
>
> On 06/14/11 03:28, Fred wrote:
>
>> Does the system you're running pca on already meet or exceed the other
>> unlisted requirements for that kernel patch? Remeber that pca is
>> basically telling you "This is what I will install, in this order, for
>> the patch you specify".
>>
>> Fred
>>
>> On Mon, Jun 13, 2011 at 1:03 PM, little help <littlehelphere at gmail.com
>> <mailto:littlehelphere at gmail.com>> wrote:
>>
>>    Actually I did a little more digging on this and the "-l" optin does
>>    not seem to show the dependencies.  For example I ran the command
>>    against a kernel patch
>>
>>    Below is the command and the results.  According to this no dependence.
>>    pca -l 127721-03
>>
>>    Patch  IR   CR RSB Age Synopsis
>>    ------ -- - -- --- ---
>>    -------------------------------------------------------
>>    127721 -- < 06 RS-  63 SunOS 5.8: kernel patch
>>
>>    I then untarred the actual patch and looked at the patchinfo file.
>>    You can see the patch requires three other patches.  So now I guess
>>    I am back to the beginning.  Any ideas how to get details on the
>>    dependencies for a patch?  Thanks.
>>    more patchinfo
>>    PATCHINFOVERSION="1.0"
>>    PATCHID=127721-03
>>    PATCH_CORRECTS='Automate-1.0'
>>    PATCH_ARCH='sparc'
>>    PATCH_OS='SunOS'
>>    PATCH_OSRELEASE='5.8'
>>    PATCH_PROPERTIES='clientroot clientusr rebootimmediate singleuser'
>>    *PATCH_REQUIRES="108528-29 117000-05 117350-62"*
>>    PATCH_OBSOLETES="108727-26 111439-03 112325-01 114671-04 116959-21"
>>
>>
>>
>>    On Mon, Jun 13, 2011 at 10:37 AM, little help
>>    <littlehelphere at gmail.com <mailto:littlehelphere at gmail.com>> wrote:
>>
>>        Fred,
>>            Seems to be right - thanks for the tip.
>>
>>        On Fri, Jun 10, 2011 at 1:28 PM, Fred <fchagnon at gmail.com
>>        <mailto:fchagnon at gmail.com>> wrote:
>>
>>            You can determine the dependencies of a single patch by
>>            supplying the patch ID in the ARGS list on the command line.
>>            For example:
>>
>>            $ pca -l 142341
>>
>>            Is that what you wanted?
>>
>>
>>
>>            On Fri, Jun 10, 2011 at 10:55 AM, little help
>>            <littlehelphere at gmail.com <mailto:littlehelphere at gmail.com>>
>>
>>            wrote:
>>
>>                I had a quick question about the pre-requisites when
>>                installing one patch.  I know pca determines dependence,
>>                etc and installs patches in that order.  However, how do
>>                you do this for one single patch.   For example - I want
>>                to install
>>                109326-17 : libresolv.so.2, in.named and BIND9 patch
>>                Now libresolv.so.2 has C dependencies.  When I do a full
>>                pca check for my host the C patches come right after the
>>                patch for patchadd.  However, there are about 20+
>>                patches before I get tot he libresolv patch. Are all
>>                these patches dependencies?  I don't see how.  I look at
>>                the readme file for the libresolv patch and do not see
>>                anything at all about dependencies.  Is there a way to
>>                check what requirements this patch needs from pca -
>>                perhaps a flag, etc?  Thanks.
>>
>>
>>
>>
>>            --
>>            Fred Chagnon
>>            fchagnon at gmail.com <mailto:fchagnon at gmail.com>
>>
>>
>>
>>
>>
>>
>> --
>> Fred Chagnon
>> fchagnon at gmail.com <mailto:fchagnon at gmail.com>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.univie.ac.at/pipermail/pca/attachments/20110614/7fbebab1/attachment-0001.html>

From glenn.satchell at uniq.com.au  Wed Jun 15 08:53:38 2011
From: glenn.satchell at uniq.com.au (Glenn Satchell)
Date: Wed, 15 Jun 2011 16:53:38 +1000
Subject: [pca] Patch pre-requisites
In-Reply-To: <BANLkTi=Fdj7WDPTskCDNkfz0JEqx0DJroQ@mail.gmail.com>
References: <BANLkTi=f2Jo0rvW0xROZ0inWhND_iudcOw@mail.gmail.com>
	<BANLkTi=moZ4YZmCCt4P-O85nEd+fR1DVpA@mail.gmail.com>
	<BANLkTi=sqiJgDCKPy6M3wWovC5WYJ-_B8A@mail.gmail.com>
	<BANLkTinqTfsx1z-HeLwQcDaLNtxsqprUcA@mail.gmail.com>
	<BANLkTimTTgxwoxrWm+LEoH2ff6gb-je-vQ@mail.gmail.com>
	<4DF68AB7.1060009@uniq.com.au>
	<BANLkTi=Fdj7WDPTskCDNkfz0JEqx0DJroQ@mail.gmail.com>
Message-ID: <239f7bf6ec27696f5d18030a378860f8.squirrel@mail.uniq.com.au>

Those other patches may have been superceded or obsoleted by newer
patches, and perhaps the superceded patches are already installed. Try
searching the patchdiag.xref file for the various patch numbers (without
revisions), eg

egrep '108528|117000|128624' /var/tmp/patchdiag.xref

regards,
-glenn

> Glenn,
>    That seems to provide a bit more detail, which seems to make sense had
> I
> not seen the patchinfo file.  I ran the pca command against the patch
> without a revision (see below) and then ran the same command against the
> dependencies to see if they had any pre-requisites (below).  It seems to
> show one requirements (117350-62) but not the others.  Any ideas.
> *PATCH_REQUIRES="108528-29 117000-05 117350-62"*
>
> pca -l 127721
> Patch  IR   CR RSB Age Synopsis
> ------ -- - -- --- ---
> -------------------------------------------------------
> 128624 -- < 16 RS- 116 SunOS 5.8: LDAP2 client, libc, libthread and libnsl
> libraries patc
> 117350 28 < 62 RS- 784 SunOS 5.8: kernel patch
> 127721 -- < 06 RS-  64 SunOS 5.8: kernel patch
>
> pca -l 128624
> Patch  IR   CR RSB Age Synopsis
> ------ -- - -- --- ---
> -------------------------------------------------------
> 128624 -- < 16 RS- 116 SunOS 5.8: LDAP2 client, libc, libthread and libnsl
> libraries patc
>
> pca -l 117350
> Patch  IR   CR RSB Age Synopsis
> ------ -- - -- --- ---
> -------------------------------------------------------
> 128624 -- < 16 RS- 116 SunOS 5.8: LDAP2 client, libc, libthread and libnsl
> libraries patc
> 117350 28 < 62 RS- 784 SunOS 5.8: kernel patch
>
> pca -l 127721
> Patch  IR   CR RSB Age Synopsis
> ------ -- - -- --- ---
> -------------------------------------------------------
> 128624 -- < 16 RS- 116 SunOS 5.8: LDAP2 client, libc, libthread and libnsl
> libraries patc
> 117350 28 < 62 RS- 784 SunOS 5.8: kernel patch
> 127721 -- < 06 RS-  64 SunOS 5.8: kernel patch
>
>
>
> On Mon, Jun 13, 2011 at 6:09 PM, Glenn Satchell
> <glenn.satchell at uniq.com.au>wrote:
>
>> There is some slight differences here.
>>
>> When you give pca the patch *and* the revision number it assumes that
>> you
>> want information about *only* that one patch.
>>
>> If you the patch number *without* the revision, then it looks up the
>> patch
>> and dependencies in patchdiag.xref and gives all to you.
>>
>>
>> >             $ pca -l 142341
>> >
>> >             Is that what you wanted?
>>
>> >     Below is the command and the results.  According to this no
>> dependence.
>> >     pca -l 127721-03
>>
>> Try using
>>
>>        pca -l 127721
>>
>> regards,
>> -glenn
>>
>>
>>
>> On 06/14/11 03:28, Fred wrote:
>>
>>> Does the system you're running pca on already meet or exceed the other
>>> unlisted requirements for that kernel patch? Remeber that pca is
>>> basically telling you "This is what I will install, in this order, for
>>> the patch you specify".
>>>
>>> Fred
>>>
>>> On Mon, Jun 13, 2011 at 1:03 PM, little help <littlehelphere at gmail.com
>>> <mailto:littlehelphere at gmail.com>> wrote:
>>>
>>>    Actually I did a little more digging on this and the "-l" option does
>>>    not seem to show the dependencies.  For example I ran the command
>>>    against a kernel patch
>>>
>>>    Below is the command and the results.  According to this no
>>> dependence.
>>>    pca -l 127721-03
>>>
>>>    Patch  IR   CR RSB Age Synopsis
>>>    ------ -- - -- --- ---
>>>    -------------------------------------------------------
>>>    127721 -- < 06 RS-  63 SunOS 5.8: kernel patch
>>>
>>>    I then untarred the actual patch and looked at the patchinfo file.
>>>    You can see the patch requires three other patches.  So now I guess
>>>    I am back to the beginning.  Any ideas how to get details on the
>>>    dependencies for a patch?  Thanks.
>>>    more patchinfo
>>>    PATCHINFOVERSION="1.0"
>>>    PATCHID=127721-03
>>>    PATCH_CORRECTS='Automate-1.0'
>>>    PATCH_ARCH='sparc'
>>>    PATCH_OS='SunOS'
>>>    PATCH_OSRELEASE='5.8'
>>>    PATCH_PROPERTIES='clientroot clientusr rebootimmediate singleuser'
>>>    *PATCH_REQUIRES="108528-29 117000-05 117350-62"*
>>>    PATCH_OBSOLETES="108727-26 111439-03 112325-01 114671-04 116959-21"
>>>
>>>
>>>
>>>    On Mon, Jun 13, 2011 at 10:37 AM, little help
>>>    <littlehelphere at gmail.com <mailto:littlehelphere at gmail.com>> wrote:
>>>
>>>        Fred,
>>>            Seems to be right - thanks for the tip.
>>>
>>>        On Fri, Jun 10, 2011 at 1:28 PM, Fred <fchagnon at gmail.com
>>>        <mailto:fchagnon at gmail.com>> wrote:
>>>
>>>            You can determine the dependencies of a single patch by
>>>            supplying the patch ID in the ARGS list on the command line.
>>>            For example:
>>>
>>>            $ pca -l 142341
>>>
>>>            Is that what you wanted?
>>>
>>>
>>>
>>>            On Fri, Jun 10, 2011 at 10:55 AM, little help
>>>            <littlehelphere at gmail.com <mailto:littlehelphere at gmail.com>>
>>>
>>>            wrote:
>>>
>>>                I had a quick question about the pre-requisites when
>>>                installing one patch.  I know pca determines dependence,
>>>                etc and installs patches in that order.  However, how do
>>>                you do this for one single patch.   For example - I want
>>>                to install
>>>                109326-17 : libresolv.so.2, in.named and BIND9 patch
>>>                Now libresolv.so.2 has C dependencies.  When I do a full
>>>                pca check for my host the C patches come right after the
>>>                patch for patchadd.  However, there are about 20+
>>>                patches before I get tot he libresolv patch. Are all
>>>                these patches dependencies?  I don't see how.  I look at
>>>                the readme file for the libresolv patch and do not see
>>>                anything at all about dependencies.  Is there a way to
>>>                check what requirements this patch needs from pca -
>>>                perhaps a flag, etc?  Thanks.
>>>
>>>
>>>
>>>
>>>            --
>>>            Fred Chagnon
>>>            fchagnon at gmail.com <mailto:fchagnon at gmail.com>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Fred Chagnon
>>> fchagnon at gmail.com <mailto:fchagnon at gmail.com>
>>>
>>
>>
>




From martin at par.univie.ac.at  Wed Jun 15 11:06:51 2011
From: martin at par.univie.ac.at (Martin Paul)
Date: Wed, 15 Jun 2011 11:06:51 +0200
Subject: [pca] Oracle removed support from patchdiag.xref for --minimal
 option in pca?
In-Reply-To: <BANLkTimGM_1uAiOOdRU6sjafCH2U8fzw=g@mail.gmail.com>
References: <BANLkTi=sO96vBSn0jS818S8_vGZG5vLNBg@mail.gmail.com>	<4DDF680B.6010307@oracle.com>	<BANLkTi=Tc3bXeLTZ0utJ-i2Y1_p7wk=16w@mail.gmail.com>	<4DEF70E2.2040008@oracle.com>	<BANLkTinjiYs3COozPdAWJso_byDvm5g29w@mail.gmail.com>	<BANLkTikSa80UD3tq4pAe5gir_vb7P3wHJg@mail.gmail.com>	<BANLkTikJKe8WZ6uT7XY0W2nrHAw0BpEAzw@mail.gmail.com>	<aa018b5cf1987ebe46349297382779b3.squirrel@mail.uniq.com.au>	<BANLkTimxkAAbqPuH4RanVbxfPqsx8ov_+w@mail.gmail.com>	<4DF71409.6080008@par.univie.ac.at>
	<BANLkTimGM_1uAiOOdRU6sjafCH2U8fzw=g@mail.gmail.com>
Message-ID: <4DF8762B.9050205@par.univie.ac.at>

Jeff wrote:
> It does reduce the number of patches to 100, but the problem still exists
> that pca doesn't verify the packages are installed that the patches applies
> to if a specific revision is requested.  So in the case of the server I'm
> testing, it was built with the SUNWCrnet cluster, so it has minimal packages
> and the actual number that would be applied is around 10.

I see, you're right. It only makes sense if you stick to the "Entire 
Distribution" cluster.

> I really think the best solution is to either convince Oracle to package a
> patchdiag.xref that cooresponds with the revisions in the CPU within the CPU
> bundle, or for me to grab patchdiag.xrefs around the release date until I
> find one that cooresponds with the bundle.

Agreed, it would be best if Oracle provided a matching patchdiag.xref with each 
CPU. Chances for that are pretty low, I guess. Same for finding an xref file 
from a certain date which matches the CPU exactly.

As Don already mentioned, the ultimate solution would be to create a new 
patchdiag.xref from scratch with the data from the patches in the CPU. All the 
required information should be in patchinfo (PATCHID, PATCH_ARCH, 
PATCH_REQUIRES), the README (Synopsis, Date) and the SUNW*/pkginfo files 
(VERSION). The R/S flags aren't in there, but they won't matter.

Anybody want to try it? :) I guess I could come up with a rough script, it's the 
fine-tuning and testing which scares me off, as it will take a lot of time.

> All I have to say is keep up the good work Martin, you are
> keeping a lot of Solaris shops afloat.

Thanks for that!

Martin.


From Ateeq.Altaf at talis.com  Wed Jun 15 12:03:33 2011
From: Ateeq.Altaf at talis.com (Ateeq Altaf)
Date: Wed, 15 Jun 2011 11:03:33 +0100
Subject: [pca] Oracle removed support from patchdiag.xref for --minimal
 option in pca?
In-Reply-To: <4DF8762B.9050205@par.univie.ac.at>
References: <BANLkTi=sO96vBSn0jS818S8_vGZG5vLNBg@mail.gmail.com>
	<4DDF680B.6010307@oracle.com>
	<BANLkTi=Tc3bXeLTZ0utJ-i2Y1_p7wk=16w@mail.gmail.com>
	<4DEF70E2.2040008@oracle.com>
	<BANLkTinjiYs3COozPdAWJso_byDvm5g29w@mail.gmail.com>
	<BANLkTikSa80UD3tq4pAe5gir_vb7P3wHJg@mail.gmail.com>
	<BANLkTikJKe8WZ6uT7XY0W2nrHAw0BpEAzw@mail.gmail.com>
	<aa018b5cf1987ebe46349297382779b3.squirrel@mail.uniq.com.au>
	<BANLkTimxkAAbqPuH4RanVbxfPqsx8ov_+w@mail.gmail.com>
	<4DF71409.6080008@par.univie.ac.at>
	<BANLkTimGM_1uAiOOdRU6sjafCH2U8fzw=g@mail.gmail.com>
	<4DF8762B.9050205@par.univie.ac.at>
Message-ID: <FBE2585E3535CE458F72C8B9A093A9C8AF71AC4D@ex-01.kc.talis>

Could we approach this a different way by first getting a list of missing patches relevant to a patchdiag slightly *newer* than the CPU, then filter that list with the list of patches on the CPU?

e.g.,

pca missing > patches.missing.full

for patch in `cat cpu_patches.lst | cut -d- -f1`; do
        patch_id=`echo $patch | cut -d- -f1`
        grep ^$patch_id patches.missing.full && echo $patch > cpu_patches_check.lst
done; pca -l $(chkmin $(cat cpu_patches_check.lst))

The chkmin is to avoid re-installing the same release of a patch if the patchdiag.xref contains a newer release than the CPU.

I haven't tried any of the above to see if it produces a list as I'm dreading trying to navigate Oracle support to see if there's a way to get the recent CPU patch_order file without downloading the 2GB zip file.

Ateeq

-----Original Message-----
From: pca-bounces at lists.univie.ac.at [mailto:pca-bounces at lists.univie.ac.at] On Behalf Of Martin Paul
Sent: 15 June 2011 10:07
To: PCA (Patch Check Advanced) Discussion
Subject: Re: [pca] Oracle removed support from patchdiag.xref for --minimal option in pca?

Jeff wrote:
> It does reduce the number of patches to 100, but the problem still exists
> that pca doesn't verify the packages are installed that the patches applies
> to if a specific revision is requested.  So in the case of the server I'm
> testing, it was built with the SUNWCrnet cluster, so it has minimal packages
> and the actual number that would be applied is around 10.

I see, you're right. It only makes sense if you stick to the "Entire
Distribution" cluster.

> I really think the best solution is to either convince Oracle to package a
> patchdiag.xref that cooresponds with the revisions in the CPU within the CPU
> bundle, or for me to grab patchdiag.xrefs around the release date until I
> find one that cooresponds with the bundle.

Agreed, it would be best if Oracle provided a matching patchdiag.xref with each
CPU. Chances for that are pretty low, I guess. Same for finding an xref file
from a certain date which matches the CPU exactly.

As Don already mentioned, the ultimate solution would be to create a new
patchdiag.xref from scratch with the data from the patches in the CPU. All the
required information should be in patchinfo (PATCHID, PATCH_ARCH,
PATCH_REQUIRES), the README (Synopsis, Date) and the SUNW*/pkginfo files
(VERSION). The R/S flags aren't in there, but they won't matter.

Anybody want to try it? :) I guess I could come up with a rough script, it's the
fine-tuning and testing which scares me off, as it will take a lot of time.

> All I have to say is keep up the good work Martin, you are
> keeping a lot of Solaris shops afloat.

Thanks for that!

Martin.


This email and any attachment to it are confidential. Unless you are the intended recipient, you may not use, copy or disclose either the message or any information contained in the message. If you are not the intended recipient, you should delete this email and notify the sender immediately.

Any views or opinions expressed in this email are those of the sender only, unless otherwise stated. All copyright in any Capita material in this email is reserved.

All emails, incoming and outgoing, may be recorded by Capita and monitored for legitimate business purposes.

Capita exclude all liability for any loss or damage arising or resulting from the receipt, use or transmission of this email to the fullest extent permitted by law.


From martin at par.univie.ac.at  Wed Jun 15 12:24:56 2011
From: martin at par.univie.ac.at (Martin Paul)
Date: Wed, 15 Jun 2011 12:24:56 +0200
Subject: [pca] Oracle removed support from patchdiag.xref for --minimal
 option in pca?
In-Reply-To: <FBE2585E3535CE458F72C8B9A093A9C8AF71AC4D@ex-01.kc.talis>
References: <BANLkTi=sO96vBSn0jS818S8_vGZG5vLNBg@mail.gmail.com>	<4DDF680B.6010307@oracle.com>	<BANLkTi=Tc3bXeLTZ0utJ-i2Y1_p7wk=16w@mail.gmail.com>	<4DEF70E2.2040008@oracle.com>	<BANLkTinjiYs3COozPdAWJso_byDvm5g29w@mail.gmail.com>	<BANLkTikSa80UD3tq4pAe5gir_vb7P3wHJg@mail.gmail.com>	<BANLkTikJKe8WZ6uT7XY0W2nrHAw0BpEAzw@mail.gmail.com>	<aa018b5cf1987ebe46349297382779b3.squirrel@mail.uniq.com.au>	<BANLkTimxkAAbqPuH4RanVbxfPqsx8ov_+w@mail.gmail.com>	<4DF71409.6080008@par.univie.ac.at>	<BANLkTimGM_1uAiOOdRU6sjafCH2U8fzw=g@mail.gmail.com>	<4DF8762B.9050205@par.univie.ac.at>
	<FBE2585E3535CE458F72C8B9A093A9C8AF71AC4D@ex-01.kc.talis>
Message-ID: <4DF88878.5080506@par.univie.ac.at>

Ateeq Altaf wrote:
> Could we approach this a different way by first getting a list of missing
> patches relevant to a patchdiag slightly *newer* than the CPU, then filter
> that list with the list of patches on the CPU?

Should get you close. It also depends whether you succeed in finding the closest 
patchdiag.xref. As soon as it contains at least one patch with a newer rev than 
in the CPU, things get complicated.

Another idea is to use archived copies of the various xref files and try to find 
the one which contains all (or at least the most) of the patches+revisions in 
the CPU list. Then you could that with "pca -l all_patch_IDs_of_CPU".

> I haven't tried any of the above to see if it produces a list as I'm dreading
> trying to navigate Oracle support to see if there's a way to get the recent
> CPU patch_order file without downloading the 2GB zip file.

I'm donwloading the 2GB file right now as I wanted to take a look at it - it 
takes more than 12 hours. This should make clear why we all try to avoid the 
CPU, I guess.

There's a "Read Me" button in the flash interface of MOS, which leads to a file 
including the patch list.

Martin.


From opn.src.rocks at gmail.com  Wed Jun 15 13:21:38 2011
From: opn.src.rocks at gmail.com (Rajiv Gunja)
Date: Wed, 15 Jun 2011 07:21:38 -0400
Subject: [pca] Oracle removed support from patchdiag.xref for --minimal
 option in pca?
In-Reply-To: <4DF88878.5080506@par.univie.ac.at>
References: <BANLkTi=sO96vBSn0jS818S8_vGZG5vLNBg@mail.gmail.com>
	<4DDF680B.6010307@oracle.com>
	<BANLkTi=Tc3bXeLTZ0utJ-i2Y1_p7wk=16w@mail.gmail.com>
	<4DEF70E2.2040008@oracle.com>
	<BANLkTinjiYs3COozPdAWJso_byDvm5g29w@mail.gmail.com>
	<BANLkTikSa80UD3tq4pAe5gir_vb7P3wHJg@mail.gmail.com>
	<BANLkTikJKe8WZ6uT7XY0W2nrHAw0BpEAzw@mail.gmail.com>
	<aa018b5cf1987ebe46349297382779b3.squirrel@mail.uniq.com.au>
	<BANLkTimxkAAbqPuH4RanVbxfPqsx8ov_+w@mail.gmail.com>
	<4DF71409.6080008@par.univie.ac.at>
	<BANLkTimGM_1uAiOOdRU6sjafCH2U8fzw=g@mail.gmail.com>
	<4DF8762B.9050205@par.univie.ac.at>
	<FBE2585E3535CE458F72C8B9A093A9C8AF71AC4D@ex-01.kc.talis>
	<4DF88878.5080506@par.univie.ac.at>
Message-ID: <BANLkTinhe3+ihqnqm-Pcmqo4q7Uz7YWrzA@mail.gmail.com>

Martin,
I kind of disagree on using CPU for couple of reasons.
1. CPU tends to change within the given release, hence the different
revisions (Am I wrong in this assessment?)
2. CPU tends to install on the minimum patch revision which will get the OS
off the vulnerability. I like to patch my servers with given Xref, which
will solve all the issues. Example April 2011 CPU has patches from March and
before, where most of them are obsolete/replaced when the CPU came out. So
if we look at the latest patch included in that CPU (April 01 2011), then we
can safely assume that if we use April 01 2011 Xref, we should get all the
patches via PCA.

Please let me know if I have my theory straight. Thanks

-GGR
--
Rajiv G Gunja
Blog: http://ossrocks.blogspot.com


On Wed, Jun 15, 2011 at 06:24, Martin Paul <martin at par.univie.ac.at> wrote:

> Ateeq Altaf wrote:
>
>> Could we approach this a different way by first getting a list of missing
>> patches relevant to a patchdiag slightly *newer* than the CPU, then filter
>> that list with the list of patches on the CPU?
>>
>
> Should get you close. It also depends whether you succeed in finding the
> closest patchdiag.xref. As soon as it contains at least one patch with a
> newer rev than in the CPU, things get complicated.
>
> Another idea is to use archived copies of the various xref files and try to
> find the one which contains all (or at least the most) of the
> patches+revisions in the CPU list. Then you could that with "pca -l
> all_patch_IDs_of_CPU".
>
>
>  I haven't tried any of the above to see if it produces a list as I'm
>> dreading
>> trying to navigate Oracle support to see if there's a way to get the
>> recent
>> CPU patch_order file without downloading the 2GB zip file.
>>
>
> I'm donwloading the 2GB file right now as I wanted to take a look at it -
> it takes more than 12 hours. This should make clear why we all try to avoid
> the CPU, I guess.
>
> There's a "Read Me" button in the flash interface of MOS, which leads to a
> file including the patch list.
>
> Martin.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.univie.ac.at/pipermail/pca/attachments/20110615/581ba2d2/attachment.html>

From martin at par.univie.ac.at  Wed Jun 15 14:02:57 2011
From: martin at par.univie.ac.at (Martin Paul)
Date: Wed, 15 Jun 2011 14:02:57 +0200
Subject: [pca] Oracle removed support from patchdiag.xref for --minimal
 option in pca?
In-Reply-To: <BANLkTinhe3+ihqnqm-Pcmqo4q7Uz7YWrzA@mail.gmail.com>
References: <BANLkTi=sO96vBSn0jS818S8_vGZG5vLNBg@mail.gmail.com>	<4DDF680B.6010307@oracle.com>	<BANLkTi=Tc3bXeLTZ0utJ-i2Y1_p7wk=16w@mail.gmail.com>	<4DEF70E2.2040008@oracle.com>	<BANLkTinjiYs3COozPdAWJso_byDvm5g29w@mail.gmail.com>	<BANLkTikSa80UD3tq4pAe5gir_vb7P3wHJg@mail.gmail.com>	<BANLkTikJKe8WZ6uT7XY0W2nrHAw0BpEAzw@mail.gmail.com>	<aa018b5cf1987ebe46349297382779b3.squirrel@mail.uniq.com.au>	<BANLkTimxkAAbqPuH4RanVbxfPqsx8ov_+w@mail.gmail.com>	<4DF71409.6080008@par.univie.ac.at>	<BANLkTimGM_1uAiOOdRU6sjafCH2U8fzw=g@mail.gmail.com>	<4DF8762B.9050205@par.univie.ac.at>	<FBE2585E3535CE458F72C8B9A093A9C8AF71AC4D@ex-01.kc.talis>	<4DF88878.5080506@par.univie.ac.at>
	<BANLkTinhe3+ihqnqm-Pcmqo4q7Uz7YWrzA@mail.gmail.com>
Message-ID: <4DF89F71.7080405@par.univie.ac.at>

Rajiv,

> I kind of disagree on using CPU for couple of reasons.

Maybe you got me wrong - it's not that I use the CPU myself - I agree with what 
you say. Personally, I don't see much sense in installing an outdated revision 
of a patch. Why not get *all* available fixes, when I'm installing a patch 
anyway? If possible, I always install all missing patches.

I do understand the reasoning behind the CPU and why people use it, though - 
it's what fixes all security issues with the least possible amount of changes to 
the system.

Martin.


From martin at par.univie.ac.at  Wed Jun 15 14:09:13 2011
From: martin at par.univie.ac.at (Martin Paul)
Date: Wed, 15 Jun 2011 14:09:13 +0200
Subject: [pca] Patch pre-requisites
In-Reply-To: <BANLkTi=Fdj7WDPTskCDNkfz0JEqx0DJroQ@mail.gmail.com>
References: <BANLkTi=f2Jo0rvW0xROZ0inWhND_iudcOw@mail.gmail.com>	<BANLkTi=moZ4YZmCCt4P-O85nEd+fR1DVpA@mail.gmail.com>	<BANLkTi=sqiJgDCKPy6M3wWovC5WYJ-_B8A@mail.gmail.com>	<BANLkTinqTfsx1z-HeLwQcDaLNtxsqprUcA@mail.gmail.com>	<BANLkTimTTgxwoxrWm+LEoH2ff6gb-je-vQ@mail.gmail.com>	<4DF68AB7.1060009@uniq.com.au>
	<BANLkTi=Fdj7WDPTskCDNkfz0JEqx0DJroQ@mail.gmail.com>
Message-ID: <4DF8A0E9.6060503@par.univie.ac.at>

little help wrote:
> Glenn,
>    That seems to provide a bit more detail, which seems to make sense had I
> not seen the patchinfo file.  I ran the pca command against the patch
> without a revision (see below) and then ran the same command against the
> dependencies to see if they had any pre-requisites (below).  It seems to
> show one requirements (117350-62) but not the others.

Three things:

PCA will recursively resolve the dependencies, so you don't need to re-run it 
manually multiple times.

If a required patch is already installed, it will not be shown.

To see the inner workings of resolving dependencies, run "pca --debug".

Martin.


From variverrat at gmail.com  Wed Jun 15 15:20:19 2011
From: variverrat at gmail.com (Jeff)
Date: Wed, 15 Jun 2011 09:20:19 -0400
Subject: [pca] Oracle removed support from patchdiag.xref for --minimal
 option in pca?
In-Reply-To: <BANLkTinhe3+ihqnqm-Pcmqo4q7Uz7YWrzA@mail.gmail.com>
References: <BANLkTi=sO96vBSn0jS818S8_vGZG5vLNBg@mail.gmail.com>
	<4DDF680B.6010307@oracle.com>
	<BANLkTi=Tc3bXeLTZ0utJ-i2Y1_p7wk=16w@mail.gmail.com>
	<4DEF70E2.2040008@oracle.com>
	<BANLkTinjiYs3COozPdAWJso_byDvm5g29w@mail.gmail.com>
	<BANLkTikSa80UD3tq4pAe5gir_vb7P3wHJg@mail.gmail.com>
	<BANLkTikJKe8WZ6uT7XY0W2nrHAw0BpEAzw@mail.gmail.com>
	<aa018b5cf1987ebe46349297382779b3.squirrel@mail.uniq.com.au>
	<BANLkTimxkAAbqPuH4RanVbxfPqsx8ov_+w@mail.gmail.com>
	<4DF71409.6080008@par.univie.ac.at>
	<BANLkTimGM_1uAiOOdRU6sjafCH2U8fzw=g@mail.gmail.com>
	<4DF8762B.9050205@par.univie.ac.at>
	<FBE2585E3535CE458F72C8B9A093A9C8AF71AC4D@ex-01.kc.talis>
	<4DF88878.5080506@par.univie.ac.at>
	<BANLkTinhe3+ihqnqm-Pcmqo4q7Uz7YWrzA@mail.gmail.com>
Message-ID: <BANLkTim8eja5MX+mzOZySzG8PNd8_B2eng@mail.gmail.com>

Different sysadmins have different reasons for their patching strategy.  I
am a business sysadmin, I value stability above all things.  I patch to fix
stability issues and security vulnerabilities.  I use the CPU because I have
700+ servers to patch and need a baseline to standardize on, because of the
length of time it takes to go through a patch cycle.  I also want to follow
Oracle's documented best practices so when stuff breaks and they tell me to
install a patch to fix it, I can ask why it wasn't in the CPU.

I also hope Oracle spends more time testing the CPU as an integrated group.
Nothing is more frustrating then the way Sun/Oracle releases patches for
someone looking at stability.  I would rather the patch was thoroughly
tested before release rather then quickly released.  We've seen over and
over several revisions of the same patch released within the same week,
mostly to fix problems introduced with patches released earlier in the
week.  For me, the creation of the CPU was a good thing, rather then the
insanity of the old recommended patch bundle that changed several times a
week.
Hopefully Oracle will change the old Sun patching culture, they seem to
prize stability with their database products.  My assumption is it will also
change with Solaris 11 and IPS, since the updates will be by package instead
of the kludge they use now.



On Wed, Jun 15, 2011 at 7:21 AM, Rajiv Gunja <opn.src.rocks at gmail.com>wrote:

> Martin,
> I kind of disagree on using CPU for couple of reasons.
> 1. CPU tends to change within the given release, hence the different
> revisions (Am I wrong in this assessment?)
> 2. CPU tends to install on the minimum patch revision which will get the OS
> off the vulnerability. I like to patch my servers with given Xref, which
> will solve all the issues. Example April 2011 CPU has patches from March and
> before, where most of them are obsolete/replaced when the CPU came out. So
> if we look at the latest patch included in that CPU (April 01 2011), then we
> can safely assume that if we use April 01 2011 Xref, we should get all the
> patches via PCA.
>
> Please let me know if I have my theory straight. Thanks
>
> -GGR
> --
> Rajiv G Gunja
> Blog: http://ossrocks.blogspot.com
>
>
>
> On Wed, Jun 15, 2011 at 06:24, Martin Paul <martin at par.univie.ac.at>wrote:
>
>> Ateeq Altaf wrote:
>>
>>> Could we approach this a different way by first getting a list of missing
>>> patches relevant to a patchdiag slightly *newer* than the CPU, then
>>> filter
>>> that list with the list of patches on the CPU?
>>>
>>
>> Should get you close. It also depends whether you succeed in finding the
>> closest patchdiag.xref. As soon as it contains at least one patch with a
>> newer rev than in the CPU, things get complicated.
>>
>> Another idea is to use archived copies of the various xref files and try
>> to find the one which contains all (or at least the most) of the
>> patches+revisions in the CPU list. Then you could that with "pca -l
>> all_patch_IDs_of_CPU".
>>
>>
>>  I haven't tried any of the above to see if it produces a list as I'm
>>> dreading
>>> trying to navigate Oracle support to see if there's a way to get the
>>> recent
>>> CPU patch_order file without downloading the 2GB zip file.
>>>
>>
>> I'm donwloading the 2GB file right now as I wanted to take a look at it -
>> it takes more than 12 hours. This should make clear why we all try to avoid
>> the CPU, I guess.
>>
>> There's a "Read Me" button in the flash interface of MOS, which leads to a
>> file including the patch list.
>>
>> Martin.
>>
>>
>


-- 
Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.univie.ac.at/pipermail/pca/attachments/20110615/24908527/attachment-0001.html>

From littlehelphere at gmail.com  Wed Jun 15 16:00:36 2011
From: littlehelphere at gmail.com (little help)
Date: Wed, 15 Jun 2011 10:00:36 -0400
Subject: [pca] Patch pre-requisites
In-Reply-To: <4DF8A0E9.6060503@par.univie.ac.at>
References: <BANLkTi=f2Jo0rvW0xROZ0inWhND_iudcOw@mail.gmail.com>
	<BANLkTi=moZ4YZmCCt4P-O85nEd+fR1DVpA@mail.gmail.com>
	<BANLkTi=sqiJgDCKPy6M3wWovC5WYJ-_B8A@mail.gmail.com>
	<BANLkTinqTfsx1z-HeLwQcDaLNtxsqprUcA@mail.gmail.com>
	<BANLkTimTTgxwoxrWm+LEoH2ff6gb-je-vQ@mail.gmail.com>
	<4DF68AB7.1060009@uniq.com.au>
	<BANLkTi=Fdj7WDPTskCDNkfz0JEqx0DJroQ@mail.gmail.com>
	<4DF8A0E9.6060503@par.univie.ac.at>
Message-ID: <BANLkTikxAU--vasz-uRoXt_EOUjTEn8E0g@mail.gmail.com>

Excellent Martin.  The "--debug" flag puts it all in perspective.  Once
again great tool.  Just need to to learn the inner workings so I can
leverage it for all its worth.
Glenn - thanks for your input and feedback as well.

On Wed, Jun 15, 2011 at 8:09 AM, Martin Paul <martin at par.univie.ac.at>wrote:

> little help wrote:
>
>> Glenn,
>>   That seems to provide a bit more detail, which seems to make sense had I
>> not seen the patchinfo file.  I ran the pca command against the patch
>> without a revision (see below) and then ran the same command against the
>> dependencies to see if they had any pre-requisites (below).  It seems to
>> show one requirements (117350-62) but not the others.
>>
>
> Three things:
>
> PCA will recursively resolve the dependencies, so you don't need to re-run
> it manually multiple times.
>
> If a required patch is already installed, it will not be shown.
>
> To see the inner workings of resolving dependencies, run "pca --debug".
>
> Martin.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.univie.ac.at/pipermail/pca/attachments/20110615/fd15dad3/attachment.html>

From martin at par.univie.ac.at  Thu Jun 16 14:26:23 2011
From: martin at par.univie.ac.at (Martin Paul)
Date: Thu, 16 Jun 2011 14:26:23 +0200
Subject: [pca] patchdiag.xref for CPU
Message-ID: <4DF9F66F.80802@par.univie.ac.at>

After the idea came up to create a special patchdiag.xref which only includes 
the patches of a Critical Patch Cluster (CPU), I couldn't resist and gave it a try.

I downloaded the "CPU OS Cluster 2011/04 Solaris 10 SPARC" and hacked up a 
script (mkxref, see attachment) which extracts the necessary information from 
the patch READMEs, patchinfo and pkginfo files and creates a patchdiag.xref 
file. The idea is that this can then be used with PCA to patch systems to the 
state of the CPU without actually having to download the +2GB file (on every 
system).

Take care: The script is mostly untested. It's hard to verify whether the 
patchdiag.xref it creates is 100% correct. It works with PCA, and I've compared 
a few sample patches with their entries in the real xref file, and they looked 
fine. The Recommended/Security flags are missing (they are not in the patchinfo 
file), but this shouldn't matter.

I'm including both the script and the patchdiag.xref file I created from the 
above mentioned CPU. If anybody does some experiments with it, I'd be happy to 
hear about it. Theoretically, one can generate xref files for any set of patches 
with the script, which might be of use in other regards than with the CPU as well.

Martin.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mkxref
URL: <https://lists.univie.ac.at/pipermail/pca/attachments/20110616/0163158d/attachment-0002.pl>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patchdiag.xref
URL: <https://lists.univie.ac.at/pipermail/pca/attachments/20110616/0163158d/attachment-0003.pl>

From variverrat at gmail.com  Thu Jun 16 15:37:37 2011
From: variverrat at gmail.com (Jeff)
Date: Thu, 16 Jun 2011 09:37:37 -0400
Subject: [pca] patchdiag.xref for CPU
In-Reply-To: <4DF9F66F.80802@par.univie.ac.at>
References: <4DF9F66F.80802@par.univie.ac.at>
Message-ID: <BANLkTi=49viens5S2=Xa8y_9f6d96+NTuQ@mail.gmail.com>

This is awesome Martin, my guess is it might make a patchdiag file more
accurate then the real one since it would use the info that patchadd would
use to decide if it needs to be installed.

I'll give it a test and see if the results match if I installed the CPU from
the bundled install scripts, but I think this is a great solution.

On Thu, Jun 16, 2011 at 8:26 AM, Martin Paul <martin at par.univie.ac.at>wrote:

> After the idea came up to create a special patchdiag.xref which only
> includes the patches of a Critical Patch Cluster (CPU), I couldn't resist
> and gave it a try.
>
> I downloaded the "CPU OS Cluster 2011/04 Solaris 10 SPARC" and hacked up a
> script (mkxref, see attachment) which extracts the necessary information
> from the patch READMEs, patchinfo and pkginfo files and creates a
> patchdiag.xref file. The idea is that this can then be used with PCA to
> patch systems to the state of the CPU without actually having to download
> the +2GB file (on every system).
>
> Take care: The script is mostly untested. It's hard to verify whether the
> patchdiag.xref it creates is 100% correct. It works with PCA, and I've
> compared a few sample patches with their entries in the real xref file, and
> they looked fine. The Recommended/Security flags are missing (they are not
> in the patchinfo file), but this shouldn't matter.
>
> I'm including both the script and the patchdiag.xref file I created from
> the above mentioned CPU. If anybody does some experiments with it, I'd be
> happy to hear about it. Theoretically, one can generate xref files for any
> set of patches with the script, which might be of use in other regards than
> with the CPU as well.
>
> Martin.
>
>
>
>


-- 
Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.univie.ac.at/pipermail/pca/attachments/20110616/25c6b9ad/attachment.html>

From variverrat at gmail.com  Thu Jun 16 15:41:01 2011
From: variverrat at gmail.com (Jeff)
Date: Thu, 16 Jun 2011 09:41:01 -0400
Subject: [pca] patchdiag.xref for CPU
In-Reply-To: <BANLkTi=49viens5S2=Xa8y_9f6d96+NTuQ@mail.gmail.com>
References: <4DF9F66F.80802@par.univie.ac.at>
	<BANLkTi=49viens5S2=Xa8y_9f6d96+NTuQ@mail.gmail.com>
Message-ID: <BANLkTiniCq=yO0DOcqfbk37=HG0bdtv-Hw@mail.gmail.com>

Just to add another thought.  Another great use for this would be with the
bundles that are created to patch to a update level rather then doing a
LiveUpgrade.

I'll try it against the Update 9 patch bundle and see what happens.

On Thu, Jun 16, 2011 at 9:37 AM, Jeff <variverrat at gmail.com> wrote:

> This is awesome Martin, my guess is it might make a patchdiag file more
> accurate then the real one since it would use the info that patchadd would
> use to decide if it needs to be installed.
>
> I'll give it a test and see if the results match if I installed the CPU
> from the bundled install scripts, but I think this is a great solution.
>
>
> On Thu, Jun 16, 2011 at 8:26 AM, Martin Paul <martin at par.univie.ac.at>wrote:
>
>> After the idea came up to create a special patchdiag.xref which only
>> includes the patches of a Critical Patch Cluster (CPU), I couldn't resist
>> and gave it a try.
>>
>> I downloaded the "CPU OS Cluster 2011/04 Solaris 10 SPARC" and hacked up a
>> script (mkxref, see attachment) which extracts the necessary information
>> from the patch READMEs, patchinfo and pkginfo files and creates a
>> patchdiag.xref file. The idea is that this can then be used with PCA to
>> patch systems to the state of the CPU without actually having to download
>> the +2GB file (on every system).
>>
>> Take care: The script is mostly untested. It's hard to verify whether the
>> patchdiag.xref it creates is 100% correct. It works with PCA, and I've
>> compared a few sample patches with their entries in the real xref file, and
>> they looked fine. The Recommended/Security flags are missing (they are not
>> in the patchinfo file), but this shouldn't matter.
>>
>> I'm including both the script and the patchdiag.xref file I created from
>> the above mentioned CPU. If anybody does some experiments with it, I'd be
>> happy to hear about it. Theoretically, one can generate xref files for any
>> set of patches with the script, which might be of use in other regards than
>> with the CPU as well.
>>
>> Martin.
>>
>>
>>
>>
>
>
> --
> Jeff
>



-- 
Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.univie.ac.at/pipermail/pca/attachments/20110616/08145626/attachment.html>

From variverrat at gmail.com  Thu Jun 16 21:23:16 2011
From: variverrat at gmail.com (Jeff)
Date: Thu, 16 Jun 2011 15:23:16 -0400
Subject: [pca] patchdiag.xref for CPU
In-Reply-To: <BANLkTiniCq=yO0DOcqfbk37=HG0bdtv-Hw@mail.gmail.com>
References: <4DF9F66F.80802@par.univie.ac.at>
	<BANLkTi=49viens5S2=Xa8y_9f6d96+NTuQ@mail.gmail.com>
	<BANLkTiniCq=yO0DOcqfbk37=HG0bdtv-Hw@mail.gmail.com>
Message-ID: <BANLkTimPvHdgrv3Xybv43Y-rtfwpT4NRhQ@mail.gmail.com>

OK, I tested this and it works great.  Using the patchdiag created from the
CPU, I was able to download, install and reboot the server in the amount of
time it would take me to copy the 2GB tarball and start extracting it, and
instead of having to try installing each of the 200+ patches like the
installcluster script, I installed only what I needed.  A huge time savings,
and the end results were the same patches got installed whether I used pca
with the custom patchdiag or the installcluster script.

I also tried the same thing using the Update 9 patch cluster.  The patch
cluster contains 648 patches, that was knocked down to 120 patches, so you
can definitely see a huge timesavings there.  Only thing I had to do was
install patch 144401-09 manually, which is only available in the Update 9
cluster, not downloadable from MOS.  That patch modifies the /etc/release
file to reflect that you are running at the patch equivalent of Update 9.

Awesome job Martin, great solution to the problem.

On Thu, Jun 16, 2011 at 9:41 AM, Jeff <variverrat at gmail.com> wrote:

> Just to add another thought.  Another great use for this would be with the
> bundles that are created to patch to a update level rather then doing a
> LiveUpgrade.
>
> I'll try it against the Update 9 patch bundle and see what happens.
>
>
> On Thu, Jun 16, 2011 at 9:37 AM, Jeff <variverrat at gmail.com> wrote:
>
>> This is awesome Martin, my guess is it might make a patchdiag file more
>> accurate then the real one since it would use the info that patchadd would
>> use to decide if it needs to be installed.
>>
>> I'll give it a test and see if the results match if I installed the CPU
>> from the bundled install scripts, but I think this is a great solution.
>>
>>
>> On Thu, Jun 16, 2011 at 8:26 AM, Martin Paul <martin at par.univie.ac.at>wrote:
>>
>>> After the idea came up to create a special patchdiag.xref which only
>>> includes the patches of a Critical Patch Cluster (CPU), I couldn't resist
>>> and gave it a try.
>>>
>>> I downloaded the "CPU OS Cluster 2011/04 Solaris 10 SPARC" and hacked up
>>> a script (mkxref, see attachment) which extracts the necessary information
>>> from the patch READMEs, patchinfo and pkginfo files and creates a
>>> patchdiag.xref file. The idea is that this can then be used with PCA to
>>> patch systems to the state of the CPU without actually having to download
>>> the +2GB file (on every system).
>>>
>>> Take care: The script is mostly untested. It's hard to verify whether the
>>> patchdiag.xref it creates is 100% correct. It works with PCA, and I've
>>> compared a few sample patches with their entries in the real xref file, and
>>> they looked fine. The Recommended/Security flags are missing (they are not
>>> in the patchinfo file), but this shouldn't matter.
>>>
>>> I'm including both the script and the patchdiag.xref file I created from
>>> the above mentioned CPU. If anybody does some experiments with it, I'd be
>>> happy to hear about it. Theoretically, one can generate xref files for any
>>> set of patches with the script, which might be of use in other regards than
>>> with the CPU as well.
>>>
>>> Martin.
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Jeff
>>
>
>
>
> --
> Jeff
>



-- 
Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.univie.ac.at/pipermail/pca/attachments/20110616/bf43dbf5/attachment.html>

From martin at par.univie.ac.at  Fri Jun 17 12:21:35 2011
From: martin at par.univie.ac.at (Martin Paul)
Date: Fri, 17 Jun 2011 12:21:35 +0200
Subject: [pca] patchdiag.xref for CPU
In-Reply-To: <BANLkTimPvHdgrv3Xybv43Y-rtfwpT4NRhQ@mail.gmail.com>
References: <4DF9F66F.80802@par.univie.ac.at>	<BANLkTi=49viens5S2=Xa8y_9f6d96+NTuQ@mail.gmail.com>	<BANLkTiniCq=yO0DOcqfbk37=HG0bdtv-Hw@mail.gmail.com>
	<BANLkTimPvHdgrv3Xybv43Y-rtfwpT4NRhQ@mail.gmail.com>
Message-ID: <4DFB2AAF.5090803@par.univie.ac.at>

Jeff,

Thanks a lot for giving the script a try and reporting the results. I'm 
surprised that it worked so fine on the first attempt. Using it with the Update 
cluster is an interesting application, too - good idea!

I have now put the mkxref script on the "Contrib" section of the PCA webpage. If 
others use it and find any bugs, please let me know. If this proves to be useful 
and I get more feedback from other admins, I might later integrate the 
functionality into PCA itself.

Martin.

Jeff wrote:
> OK, I tested this and it works great.  Using the patchdiag created from the
> CPU, I was able to download, install and reboot the server in the amount of
> time it would take me to copy the 2GB tarball and start extracting it, and
> instead of having to try installing each of the 200+ patches like the
> installcluster script, I installed only what I needed.  A huge time savings,
> and the end results were the same patches got installed whether I used pca
> with the custom patchdiag or the installcluster script.
> 
> I also tried the same thing using the Update 9 patch cluster.  The patch
> cluster contains 648 patches, that was knocked down to 120 patches, so you
> can definitely see a huge timesavings there.  Only thing I had to do was
> install patch 144401-09 manually, which is only available in the Update 9
> cluster, not downloadable from MOS.  That patch modifies the /etc/release
> file to reflect that you are running at the patch equivalent of Update 9.
> 
> Awesome job Martin, great solution to the problem.
> 
> On Thu, Jun 16, 2011 at 9:41 AM, Jeff <variverrat at gmail.com> wrote:
> 
>> Just to add another thought.  Another great use for this would be with the
>> bundles that are created to patch to a update level rather then doing a
>> LiveUpgrade.
>>
>> I'll try it against the Update 9 patch bundle and see what happens.
>>
>>
>> On Thu, Jun 16, 2011 at 9:37 AM, Jeff <variverrat at gmail.com> wrote:
>>
>>> This is awesome Martin, my guess is it might make a patchdiag file more
>>> accurate then the real one since it would use the info that patchadd would
>>> use to decide if it needs to be installed.
>>>
>>> I'll give it a test and see if the results match if I installed the CPU
>>> from the bundled install scripts, but I think this is a great solution.
>>>
>>>
>>> On Thu, Jun 16, 2011 at 8:26 AM, Martin Paul <martin at par.univie.ac.at>wrote:
>>>
>>>> After the idea came up to create a special patchdiag.xref which only
>>>> includes the patches of a Critical Patch Cluster (CPU), I couldn't resist
>>>> and gave it a try.
>>>>
>>>> I downloaded the "CPU OS Cluster 2011/04 Solaris 10 SPARC" and hacked up
>>>> a script (mkxref, see attachment) which extracts the necessary information
>>>> from the patch READMEs, patchinfo and pkginfo files and creates a
>>>> patchdiag.xref file. The idea is that this can then be used with PCA to
>>>> patch systems to the state of the CPU without actually having to download
>>>> the +2GB file (on every system).
>>>>
>>>> Take care: The script is mostly untested. It's hard to verify whether the
>>>> patchdiag.xref it creates is 100% correct. It works with PCA, and I've
>>>> compared a few sample patches with their entries in the real xref file, and
>>>> they looked fine. The Recommended/Security flags are missing (they are not
>>>> in the patchinfo file), but this shouldn't matter.
>>>>
>>>> I'm including both the script and the patchdiag.xref file I created from
>>>> the above mentioned CPU. If anybody does some experiments with it, I'd be
>>>> happy to hear about it. Theoretically, one can generate xref files for any
>>>> set of patches with the script, which might be of use in other regards than
>>>> with the CPU as well.
>>>>
>>>> Martin.
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Jeff
>>>
>>
>>
>> --
>> Jeff
>>


From variverrat at gmail.com  Fri Jun 17 15:28:43 2011
From: variverrat at gmail.com (Jeff)
Date: Fri, 17 Jun 2011 09:28:43 -0400
Subject: [pca] patchdiag.xref for CPU
In-Reply-To: <4DFB2AAF.5090803@par.univie.ac.at>
References: <4DF9F66F.80802@par.univie.ac.at>
	<BANLkTi=49viens5S2=Xa8y_9f6d96+NTuQ@mail.gmail.com>
	<BANLkTiniCq=yO0DOcqfbk37=HG0bdtv-Hw@mail.gmail.com>
	<BANLkTimPvHdgrv3Xybv43Y-rtfwpT4NRhQ@mail.gmail.com>
	<4DFB2AAF.5090803@par.univie.ac.at>
Message-ID: <BANLkTinVDk68Fod8g5xKF1gxei-ZsdzjeQ@mail.gmail.com>

Something that comes to mind as a good use for this if it were integrated
into pca is a way to get around the problems associated with specifying a
version of a patch that isn't in the current patchdiag.xref.

As an example, say I want to install a back revision of the kernel patch,
144488-11. Currently if I were to do "pca -i 144488-11", it wouldn't do any
dependency checking and just try to install 144488-11.  A new procedure
would have pca download a copy of 144488-11, grab the dependency info from
within the zip, replace the info in a temporary patchdiag.xref, and then do
the normal dependency checks.  This would take longer since it would have to
pre-download patches before doing a final dependency check and possibly
downloading some additional patches, but I don't see why it wouldn't work.

On Fri, Jun 17, 2011 at 6:21 AM, Martin Paul <martin at par.univie.ac.at>wrote:

> Jeff,
>
> Thanks a lot for giving the script a try and reporting the results. I'm
> surprised that it worked so fine on the first attempt. Using it with the
> Update cluster is an interesting application, too - good idea!
>
> I have now put the mkxref script on the "Contrib" section of the PCA
> webpage. If others use it and find any bugs, please let me know. If this
> proves to be useful and I get more feedback from other admins, I might later
> integrate the functionality into PCA itself.
>
> Martin.
>
>
> Jeff wrote:
>
>> OK, I tested this and it works great.  Using the patchdiag created from
>> the
>> CPU, I was able to download, install and reboot the server in the amount
>> of
>> time it would take me to copy the 2GB tarball and start extracting it, and
>> instead of having to try installing each of the 200+ patches like the
>> installcluster script, I installed only what I needed.  A huge time
>> savings,
>> and the end results were the same patches got installed whether I used pca
>> with the custom patchdiag or the installcluster script.
>>
>> I also tried the same thing using the Update 9 patch cluster.  The patch
>> cluster contains 648 patches, that was knocked down to 120 patches, so you
>> can definitely see a huge timesavings there.  Only thing I had to do was
>> install patch 144401-09 manually, which is only available in the Update 9
>> cluster, not downloadable from MOS.  That patch modifies the /etc/release
>> file to reflect that you are running at the patch equivalent of Update 9.
>>
>> Awesome job Martin, great solution to the problem.
>>
>> On Thu, Jun 16, 2011 at 9:41 AM, Jeff <variverrat at gmail.com> wrote:
>>
>>  Just to add another thought.  Another great use for this would be with
>>> the
>>> bundles that are created to patch to a update level rather then doing a
>>> LiveUpgrade.
>>>
>>> I'll try it against the Update 9 patch bundle and see what happens.
>>>
>>>
>>> On Thu, Jun 16, 2011 at 9:37 AM, Jeff <variverrat at gmail.com> wrote:
>>>
>>>  This is awesome Martin, my guess is it might make a patchdiag file more
>>>> accurate then the real one since it would use the info that patchadd
>>>> would
>>>> use to decide if it needs to be installed.
>>>>
>>>> I'll give it a test and see if the results match if I installed the CPU
>>>> from the bundled install scripts, but I think this is a great solution.
>>>>
>>>>
>>>> On Thu, Jun 16, 2011 at 8:26 AM, Martin Paul <martin at par.univie.ac.at
>>>> >wrote:
>>>>
>>>>  After the idea came up to create a special patchdiag.xref which only
>>>>> includes the patches of a Critical Patch Cluster (CPU), I couldn't
>>>>> resist
>>>>> and gave it a try.
>>>>>
>>>>> I downloaded the "CPU OS Cluster 2011/04 Solaris 10 SPARC" and hacked
>>>>> up
>>>>> a script (mkxref, see attachment) which extracts the necessary
>>>>> information
>>>>> from the patch READMEs, patchinfo and pkginfo files and creates a
>>>>> patchdiag.xref file. The idea is that this can then be used with PCA to
>>>>> patch systems to the state of the CPU without actually having to
>>>>> download
>>>>> the +2GB file (on every system).
>>>>>
>>>>> Take care: The script is mostly untested. It's hard to verify whether
>>>>> the
>>>>> patchdiag.xref it creates is 100% correct. It works with PCA, and I've
>>>>> compared a few sample patches with their entries in the real xref file,
>>>>> and
>>>>> they looked fine. The Recommended/Security flags are missing (they are
>>>>> not
>>>>> in the patchinfo file), but this shouldn't matter.
>>>>>
>>>>> I'm including both the script and the patchdiag.xref file I created
>>>>> from
>>>>> the above mentioned CPU. If anybody does some experiments with it, I'd
>>>>> be
>>>>> happy to hear about it. Theoretically, one can generate xref files for
>>>>> any
>>>>> set of patches with the script, which might be of use in other regards
>>>>> than
>>>>> with the CPU as well.
>>>>>
>>>>> Martin.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Jeff
>>>>
>>>>
>>>
>>> --
>>> Jeff
>>>
>>>
>


-- 
Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.univie.ac.at/pipermail/pca/attachments/20110617/f6490d6a/attachment.html>

From martin at par.univie.ac.at  Fri Jun 17 16:23:26 2011
From: martin at par.univie.ac.at (Martin Paul)
Date: Fri, 17 Jun 2011 16:23:26 +0200
Subject: [pca] patchdiag.xref for CPU
In-Reply-To: <BANLkTinVDk68Fod8g5xKF1gxei-ZsdzjeQ@mail.gmail.com>
References: <4DF9F66F.80802@par.univie.ac.at>	<BANLkTi=49viens5S2=Xa8y_9f6d96+NTuQ@mail.gmail.com>	<BANLkTiniCq=yO0DOcqfbk37=HG0bdtv-Hw@mail.gmail.com>	<BANLkTimPvHdgrv3Xybv43Y-rtfwpT4NRhQ@mail.gmail.com>	<4DFB2AAF.5090803@par.univie.ac.at>
	<BANLkTinVDk68Fod8g5xKF1gxei-ZsdzjeQ@mail.gmail.com>
Message-ID: <4DFB635E.8000300@par.univie.ac.at>

Jeff wrote:
> A new procedure
> would have pca download a copy of 144488-11, grab the dependency info from
> within the zip, replace the info in a temporary patchdiag.xref, and then do
> the normal dependency checks.

Not that I wouldn't have thought about that before :)

I'm not sure how practical it would be, though, as even with a local caching 
proxy this might take forever for patches with many requirements. And then I 
start thinking whether it wouldn't be better to cache the information, or even 
collect it centrally (so not every user has to extract it on his own), and then 
I end up thinking about what we really need: A master patchdiag.xref with all 
patch revisions. But Oracle doesn't produce it, and they most probably won't 
allow anybody else to compile (from patchinfo, or a collection of past xref 
files) and distribute it for legal reasons.

Martin.


From variverrat at gmail.com  Fri Jun 17 16:32:12 2011
From: variverrat at gmail.com (Jeff)
Date: Fri, 17 Jun 2011 10:32:12 -0400
Subject: [pca] patchdiag.xref for CPU
In-Reply-To: <4DFB635E.8000300@par.univie.ac.at>
References: <4DF9F66F.80802@par.univie.ac.at>
	<BANLkTi=49viens5S2=Xa8y_9f6d96+NTuQ@mail.gmail.com>
	<BANLkTiniCq=yO0DOcqfbk37=HG0bdtv-Hw@mail.gmail.com>
	<BANLkTimPvHdgrv3Xybv43Y-rtfwpT4NRhQ@mail.gmail.com>
	<4DFB2AAF.5090803@par.univie.ac.at>
	<BANLkTinVDk68Fod8g5xKF1gxei-ZsdzjeQ@mail.gmail.com>
	<4DFB635E.8000300@par.univie.ac.at>
Message-ID: <BANLkTimDeBbTZQTr4v0YBN_m-=fTOU_25g@mail.gmail.com>

Maybe these guys can build and host it:

http://sunsolve.espix.org/

They seem to be bringing back all the patch research functionality we lost
when Oracle shutdown Sunsolve.

Hopefully they don't get sued into oblivion, but since they don't host the
patches, just point to them in MOS, they are probably OK.

On Fri, Jun 17, 2011 at 10:23 AM, Martin Paul <martin at par.univie.ac.at>wrote:

> Jeff wrote:
>
>> A new procedure
>> would have pca download a copy of 144488-11, grab the dependency info from
>> within the zip, replace the info in a temporary patchdiag.xref, and then
>> do
>> the normal dependency checks.
>>
>
> Not that I wouldn't have thought about that before :)
>
> I'm not sure how practical it would be, though, as even with a local
> caching proxy this might take forever for patches with many requirements.
> And then I start thinking whether it wouldn't be better to cache the
> information, or even collect it centrally (so not every user has to extract
> it on his own), and then I end up thinking about what we really need: A
> master patchdiag.xref with all patch revisions. But Oracle doesn't produce
> it, and they most probably won't allow anybody else to compile (from
> patchinfo, or a collection of past xref files) and distribute it for legal
> reasons.
>
> Martin.
>
>


-- 
Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.univie.ac.at/pipermail/pca/attachments/20110617/93bd915f/attachment-0001.html>

From john.boxall at bmo.com  Fri Jun 17 16:40:30 2011
From: john.boxall at bmo.com (Boxall, John)
Date: Fri, 17 Jun 2011 10:40:30 -0400
Subject: [pca] patchdiag.xref for CPU
In-Reply-To: <4DFB635E.8000300@par.univie.ac.at>
References: <4DF9F66F.80802@par.univie.ac.at>
	<BANLkTi=49viens5S2=Xa8y_9f6d96+NTuQ@mail.gmail.com>
	<BANLkTiniCq=yO0DOcqfbk37=HG0bdtv-Hw@mail.gmail.com>
	<BANLkTimPvHdgrv3Xybv43Y-rtfwpT4NRhQ@mail.gmail.com>
	<4DFB2AAF.5090803@par.univie.ac.at>
	<BANLkTinVDk68Fod8g5xKF1gxei-ZsdzjeQ@mail.gmail.com>
	<4DFB635E.8000300@par.univie.ac.at>
Message-ID: <A10410C5543C704290DF14DE983A1E1D0817E8E61A@BMFGEXCMB07.adroot.bmogc.net>

Martin,

It's called the Ops Center (or UCE) Knowledge Base, for which you have spend large sums of money. And then it isn't always right either. 

John 
 



From dclarke at blastwave.org  Sun Jun 19 11:55:45 2011
From: dclarke at blastwave.org (Dennis Clarke)
Date: Sun, 19 Jun 2011 05:55:45 -0400 (EDT)
Subject: [pca] Kernel Patch 144488-17 and bugid 5105920
Message-ID: <33659.10.0.66.17.1308477345.squirrel@interact.purplecow.org>


Has anyone been able to get access to this patch? For that matter, the
README and bugid 5105920 seem to be "secret". By "secret" I mean "we fixed
something but we are not telling you what".

Dennis




From dclarke at blastwave.org  Sun Jun 19 17:15:52 2011
From: dclarke at blastwave.org (Dennis Clarke)
Date: Sun, 19 Jun 2011 11:15:52 -0400 (EDT)
Subject: [pca] Kernel Patch 144488-17 and bugid 5105920
Message-ID: <42381.10.0.66.17.1308496552.squirrel@interact.purplecow.org>


> Dennis,
>
> I was able to download 144488-17 and 144489-17 and
> install them a couple of days ago:
>
> ls -al /var/sadm/patch/144488*
> total 168
> drwxr-xr-x   2 root     root         512 Jun 17 17:20 ./
> drwxr-xr-x 1117 root     root       23552 Jun 17 17:26 ../
> -rw-r--r--   1 root     root       40253 Jun 17 14:32 README.144488-17
> -rw-r--r--   1 root     root       15112 Jun 17 17:20 log
> -rwxr-xr-x   1 root     root        1833 May 31 02:29 postbackout*
> -rwxr-xr-x   1 root     root        2433 May 31 02:29 prebackout*
>
> The relevant part of the readme:
>
> Problem Description:
>
> 7047558 backout 7016532 - fix requires more work
>
> I have not tried to search for the above ids nor the one you ask about.
>
> Stuart

thank you for the info. Oddly enough that bug report is not listed at MOS.

What I see is this :


Patch 144488-17: SunOS 5.10: kernel patch
Last Updated	2011-06-17 15:28:25    Size   34.5 MB
Product / Family Solaris Operating System
Support Level Operating System
Release	Solaris 10 Operating System
Classification	Security
Platform Oracle Solaris on SPARC (64-bit)

Bugs Resolved by This Patch (opened in a new window)
4461538
4799074
4849539
4947121
5081180
5105708
5105920
6246564
6248421
6263346

BugId 5105920 is interesting. If you choose to look.

Dennis




From bob.wickline at lmco.com  Mon Jun 20 16:29:11 2011
From: bob.wickline at lmco.com (Wickline,
	Bob (N-STERLING COMPUTERS CORPORATION))
Date: Mon, 20 Jun 2011 08:29:11 -0600
Subject: [pca] EXTERNAL:  Kernel Patch 144488-17 and bugid 5105920
In-Reply-To: <33659.10.0.66.17.1308477345.squirrel@interact.purplecow.org>
References: <33659.10.0.66.17.1308477345.squirrel@interact.purplecow.org>
Message-ID: <86DCB058A06C6F40AF77D1A7275F379B021FD6C35F@HDXMSPE.us.lmco.com>

http://sunsolve.espix.org/bugid/id/5105920


-----Original Message-----
From: pca-bounces at lists.univie.ac.at [mailto:pca-bounces at lists.univie.ac.at]
On Behalf Of Dennis Clarke
Sent: Sunday, June 19, 2011 4:56 AM
To: pca at lists.univie.ac.at
Subject: EXTERNAL: [pca] Kernel Patch 144488-17 and bugid 5105920


Has anyone been able to get access to this patch? For that matter, the
README and bugid 5105920 seem to be "secret". By "secret" I mean "we fixed
something but we are not telling you what".

Dennis



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 10273 bytes
Desc: not available
URL: <https://lists.univie.ac.at/pipermail/pca/attachments/20110620/2c4a9eb3/attachment.bin>

