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

Reply via email to