On Mon, Jul 15, 2013 at 8:33 AM, Martin Paul martin.p...@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 NN-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 21
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
