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

[Paul Lanken]

On Mon, Jul 15, 2013 at 8:33 AM, Martin Paul <martin.paul at univie.ac.at> wrote:
> Am 15.07.2013 14:23, schrieb Jan Holzhueter:
>
>> So I had to cleanup my proxy to not have bad patches. (Maybe some check
>> if the downloaded file is a zipfile would be nice.)
>
>
> There is a check in the pca code, but it seems as if it failed in this case.
>
>
>> Looks like it was a temp problem. This morning after the cleanup the
>> download of the broken patches went fine. (Not sure about the number.
>> But was more then 10.)
>
>
> Thanks for the report, good to hear that!

I can confirm that the problem seemed to simply "go away" all on its
own sometime
last night.  I did have a downtime window for Saturday night but
missed it entirely
because I could not get the patches in a reasonable fashion.  Something odd and
clearly, based on this maillist, an obscure issue never before seen.

So please let me share an idea, because I found myself in a sysadmin situation
where I had a downtime window approved on production hardware and was watching
it slip past.  Felt a bit of stress that night however Neil G.
Brookins, ( see this thread )
changed my life with his posting.  I was wondering about what to do with some of
the bigger Niagara servers which have thirty zones or more.  Normally
I get a downtime
window starting Friday night and run all weekend to apply patches. Stupid me.

Regardless, I was stuck a bit. Saw a few patches being downloaded and
then a whole
stack of files that all looked like NNNNNN-RR.zip ( where N and R are
digits ) but the
files were just html error messages.  I thought I could sed/awk/cut/tr
script-fu my way
around this and send the PCA process into a loop until I had all the
patches. I even
wrote a script to get the list of missing patches first and then post
process that with
awk to create another script which used PCA to pull down the patches
one at a time
with a "sleep 30" in between each call to PCA.  Ugly but it also did not help.

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

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

I am sure you have heard it all before.  Hardly new.  There is a
public file available
at this url :  ( from my panicy scriptint that night )

    # do not pass user and passwd for this ... it is public
    # Be silent about this. The info is nice to have and not a need at
this time.
    $PCA_WGET --output-file=/dev/null --quiet --continue
--no-check-certificate \
      --output-document=$PCA_XREFDIR/patchdiag.CHECKSUMS \
      https://getupdates.oracle.com/reports/CHECKSUMS > /dev/null 2>&1

    if [ ! -f $PCA_XREFDIR/patchdiag.CHECKSUMS ]; then
        /bin/printf "WARN : patchdiag.CHECKSUMS could not be fetched.\n"
    fi

So then in that file, for any given patch ( I guess ) there is an MD5
hash but it
is on a separate line from the patch filename.

So for this patch :

    148931-03 Jul/12/13 Oracle Solaris Studio 12.3: Patch for
Performance Library

I see this :

# /usr/xpg4/bin/grep -n "148931-03" pca_data/xref/patchdiag.CHECKSUMS
366421:148931-03.zip

# cat -n pca_data/xref/patchdiag.CHECKSUMS | head -366424 | tail -4
366421  148931-03.zip
366422  MD5: b848434ebf59e507e347cb99ff7eb1ba
366423  SysV Sum: 63367   256161
366424  Sum: 46010   256161

So some script-fu with sed and tr etc etc can get me the MD5 hash.

.... and down the rabbit hole I go to verify the patches etc etc.

I am sure you have heard it all before.

Paul