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

[French, David]

Though I don't know, my guess would be toward session cookies.  Wget by default will save and use cookies in the same session, but this means each invocation starts fresh.  Since pca kicks off a new wget process with each call to download(), nothing is saved across invocations.

Maybe you can try to add this to your pca.conf file:

	wgetopt=--save-cookies=/tmp/PCA_Cookies.txt --load-cookies=/tmp/PCA_Cookies.txt

The idea would be each invocation would now use same cookies and hopefully be in same session, alleviating your issue.

Good luck, like I said I'm not sure it will help, but worth a shot.

	--Dave

> -----Original Message-----
> From: pca-bounces at lists.univie.ac.at [mailto:pca-bounces at lists.univie.ac.at]
> On Behalf Of Paul Lanken
> Sent: Saturday, July 13, 2013 12:50 PM
> To: pca at lists.univie.ac.at
> Subject: [pca] interesting patch problem with Oracle Access Manager
> Version: 11.1.1.5.0
> 
> Under normal circumstances I am able to download a collection of missing
> patches from the oracle patch server with PCA just fine.  Not sure if what I
> am seeing is "abnormal" however I normally just use PCA to --download the
> "missing" patches and then deal with things later.  This allows me to get a feel
> for my downtime given that Solaris 10 with a pack of zones takes simply
> forever to patch, usually downtime is 24 to 48 hours on a Sun Fire
> V890 with 16 or more zones.  So I have to schedule things for once or twice a
> year.
> 
> Anyway, the problem I see is that after the tenth patch ( or thereabouts ) is
> downloaded via /usr/sfw/bin/wget and PCA into an archive directory that is
> specified by the env var PCA_PATCHDIR I end up with a few normal looking
> patches and a pile of strange things that are clearly not patches :
> 
> # cd archive
> # ls -l
> total 498921
> -rw-r--r-- 1 root root 4287550 Apr 30 01:49 119315-28.zip
> -rw-r--r-- 1 root root 96753460 Apr 20 01:55 119757-27.zip
> -rw-r--r-- 1 root root 1070808 Jul 13 02:35 119906-21.zip
> -rw-r--r-- 1 root root 73405 Jul 13 02:36 120199-21.zip .
> .
> .
> -rw-r--r-- 1 root root 1994351 Jul 13 02:44 148561-05.zip
> -rw-r--r-- 1 root root 2083 Jul 13 19:26 148689-01.zip
> -rw-r--r-- 1 root root 2083 Jul 13 19:26 148691-01.zip
> -rw-r--r-- 1 root root 2083 Jul 13 19:26 148693-01.zip
> -rw-r--r-- 1 root root 2083 Jul 13 19:26 149022-04.zip
> -rw-r--r-- 1 root root 2083 Jul 13 19:26 149063-01.zip
> -rw-r--r-- 1 root root 2083 Jul 13 19:26 149067-01.zip
> -rw-r--r-- 1 root root 2083 Jul 13 19:26 149112-01.zip
> -rw-r--r-- 1 root root 2083 Jul 13 19:26 149167-02.zip
> -rw-r--r-- 1 root root 2083 Jul 13 19:26 149171-02.zip
> 
> These little files are all html generated by Oracle Access Manager
> Version: 11.1.1.5.0 which
> have a warning in them :
> 
>     The user has already reached the
>     maximum allowed number of sessions.
>     Please close one of the existing sessions
>     before trying to login again.
> 
> 
> So I see that after patch number ten or twenty the Oracle site simply
> disallows access perhaps.  Not sure really.
> 
> So then I tried to download the patches one at a time.  There are a lot of
> them but again after about ten or so I see this on the screen :
> 
> Using /root/pca_data/xref/patchdiag.xref from Jul/12/13
> Host: neptune (SunOS 5.10/Generic_148888-05/sparc/sun4v)
> List: 149729-02 (1/0)
> 
> Patch IR CR RSB Age Synopsis
> ------ -- - -- --- --- -------------------------------------------------------
> 149729 -- < 02 --- 2 SunOS 5.10: ike patch
> 
> Looking for 149729-02 (1/1)
> Trying Oracle
> Trying https://getupdates.oracle.com/ (1/3) Done
> ------------------------------------------------------------------------------
> Download Summary: 1 total, 1 successful, 0 skipped, 0 failed
> 
> 
> So that patch should be fine ... however it isn't.  It is the same little piece of
> html.
> 
> Not sure what the correct action to take here is .. any thoughts?
> 
> Paul