Rajiv Gunja | 1 Feb 17:33 2011
Picon

Re: patch delta between two dates

Sent.

-GGR

--

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


On Fri, Jan 28, 2011 at 17:07, Coskun, Aydin <Aydin.Coskun <at> blueshieldca.com> wrote:

Hey Rajiv,

 

I just noticed the luinstpatches.sh in your Create_Patch_Bundle.sh and could not find it in your website. Can you provide this as well?

 

~ Aydin

 

From: pca-bounces <at> lists.univie.ac.at [mailto:pca-bounces <at> lists.univie.ac.at] On Behalf Of Coskun, Aydin
Sent: Thursday, January 27, 2011 8:26 AM


To: PCA (Patch Check Advanced) Discussion
Subject: Re: [pca] patch delta between two dates

 

Thank you Rajiv ,

 

From: pca-bounces <at> lists.univie.ac.at [mailto:pca-bounces <at> lists.univie.ac.at] On Behalf Of Rajiv Gunja
Sent: Thursday, January 27, 2011 6:59 AM
To: PCA (Patch Check Advanced) Discussion
Subject: Re: [pca] patch delta between two dates

 

Aydin,
Email including the script sent.

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

On Wed, Jan 26, 2011 at 14:31, Coskun, Aydin <Aydin.Coskun <at> blueshieldca.com> wrote:

Hi Rajiv,

In your wrapper script there is a reference to uninstall script but it is not posted on your blog. Can you share it?

 

 ~ Aydin

 

From: pca-bounces <at> lists.univie.ac.at [mailto:pca-bounces <at> lists.univie.ac.at] On Behalf Of Rajiv Gunja
Sent: Wednesday, January 26, 2011 11:27 AM
To: PCA (Patch Check Advanced) Discussion
Subject: Re: [pca] patch delta between two dates

 

Van,
I have a wrapper script and create patch bundles for servers in 1 location - local PCA Patch Proxy. This method allows me to keep a copy of the list of patches generated along with the Xref file with which it was generated on the PCA Patch Proxy server. pca -l missing in html format or text format on a web-server does work well when audit needs to performed.
Storing multiple files per server with date will work if you have less than 200 servers, I have about 3000 servers, so 1 html file with date in its filename works better for me.

On the server, where the patch is being installed, I have a wrapper script, which writes to /var/log/installpatches.log and each time a bundle is installed, the older one is backed up and the new log is appended to this file. This file also contains the date/time on which it was installed.

Please check my blog for the wrapper script, if you need more information, please send me an email.
Thanks

-GGR

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

On Wed, Jan 26, 2011 at 13:37, Van Bommel, Paul <Paul.VanBommel <at> gdcanada.com> wrote:

I've been asked to provide a list of patches that have been applied to a
system over a period of time. (about a year). These have been applied in
3-4 patching sessions.

We use PCA and it works very well. We record details in a single
directory on each system per patching session. Things like the download
and install output in a log  file, the patchdiag.xref used on that date,
any local pca.conf file, and the patch zip files. The zip files
sometimes get cleaned out from the local system to save space.

My log file has a lot of details, and I was able to generate a list of
"Successfully" installed patches, but I don't trust this technique. Am I
on the right track here. (egrep '^Installing|^Successful' log.txt)

I'm starting to think I should have recorded the three files used by PCA
uname.out, showrev.out, and pkginfo.out with all the other files I was
storing. Then run PCA on the old input files with the last "baseline"
patchdiag.xref

Does anyone have a good technique to determine the delta of patches
added in a period of time. (using PCA or other tools)

What info do you record in a patch session to make your life easier when
questions like this popup?
The worst part is that I cannot go back in time to produce these file. I
can only start recording now.
I wish the base OS had some kind of version control. (not ZFS, something
in the package/patch database)

Thanks in advance.
Paul Van Bommel


The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message.
Thank you.

 

 


Craig Bell | 2 Feb 22:22 2011

zones and $TMPDIR

  Hello all – I recently ran into an issue using pca(8) with zones and $TMPDIR.  Have you seen this before?
 
  Background:  I used pca v20101221-01 to patch S10U3 (metacluster SUNWCXall) with alternate locations for backdir, patchdir, and xrefdir set in pca.conf.  That seems to work fine with native containers.  Beyond that, setting $TMPDIR seems to break something (possibly pkgadd as invoked by patchadd) in the NGZ phase.
 
  All noreboot patches (including 119254-78) went on fine in multi-user mode (zone was in “running” state).  I rebooted directly to runlevel S for this phase.   Pre-patch validation goes fine, and the GZ applies successfully; but then I see errors, and patchadd fails  Every patch failed with these same errors:
 
 
# grep dir /usr/local/etc/pca.conf
xrefdir=/apps/patch
patchdir=/apps/patch/tmp
backdir=/apps/patch/backout
 
# TMPDIR=/apps/patch/tmp pca –i missingrs
List: missingrs (32/4376)
 
Patch  IR   CR RSB Age Synopsis
------ -- - -- --- --- -------------------------------------------------------
118712 23 < 24 R-- 173 SunOS 5.10: Sun XVR-100 Graphics Accelerator Patch
 
Looking for 118712-24 (1/32)
Found patch file
 
Installing 118712-24 (1/32)
Unzipping patch
Running patchadd
 
<snip>
 
Patching non-global zones...
Patching zone myzone
Booting non-global zone myzone for patching...
Adding patches...
mkdir: Failed to make directory "/apps/patch/tmp/patchadd-251911498"; No such file or directory
ERROR: Unable to make temporary directory /apps/patch/tmp/patchadd-251911498
Patchadd is terminating.
/usr/lib/patch/patchadd[18]: /apps/patch/tmp:  not found
Done!
Restoring state for non-global zone myzone...
Patch 118712-24 failed in non-global zone myzone.
Failed (exit code 36)
Failed (11:30:38/00:00:32/00:00:46, 1/32, 0/0/1)
<snip>
 
 
  My specified directories do exist in the NGZ.  When I boot myzone into runlevel S (or place it in the “ready” state), then <zonepath>/apps/patch/* can be traversed.  I verified this when I successfully re-ran the same pca command without $TMPDIR, and everything worked as expected – my alternate directories are honored in the NGZ, and patchadd succeeds every time.
 
  I’m not sure if I’m simply doing it wrong, or if this is some sort of limitation of $TMPDIR with the SysV package tools and containers.    Any ideas?
 
  Alternate theory:  I recall years ago (probably on 5.8) that patchadd invoked certain sub-commands as EUID “nobody”, and occasionally I would see the odd failure when my current working directory was only accessible by root.  Maybe this is something similar to that.   Could it be that my <zonepath>/apps/patch/tmp directory needs permissions 1777, like /var/tmp uses?
 
  Let me know if you have any ideas, maybe I just missed something simple.   Thanks everyone!   -cheers, CSB
 
Jones, Eric CIV SRF 1236 | 3 Feb 02:44 2011
Picon

Sun contracts

Hello, about 4 or 5 weeks ago I asked if anyone know how to get a Sun
contract so servers could be updated.
I finally found the oracle government rep who said she had to generate a
quote for us.
That was about 4 weeks ago on the phone and I haven't heard anything yet and
this person hasn't replied to my email on.
Barring the snow storms I'm guessing folks back east are going to work.
Does anyone know of a Oracle/Sun rep who would like to make some money
selling a Sun software contract for 9 servers?
Apparently no one at Oracle is hungry for sales.
Nothing on the site to click and purchase unless you have Oracle/Sun on non
Oracle hardware.

 Eric R. Jones
SRF JRMC
C1236
DSN 315-243-4196

STICK \'stik\ n. 1: A boomerang that doesn't work.
Attachment (smime.p7s): application/x-pkcs7-signature, 7700 bytes
Picon

Re: Sun contracts

Eric,
 
  I forwarded your email to my Oracle account rep; hopefully he has a simple solution.
 
 
Scott
 
-----Original Message-----
From: pca-bounces <at> lists.univie.ac.at [mailto:pca-bounces <at> lists.univie.ac.at] On Behalf Of Jones, Eric CIV SRF 1236
Sent: Wednesday, February 02, 2011 5:44 PM
To: PCA (Patch Check Advanced) Discussion
Subject: EXTERNAL:[pca] Sun contracts
 
Hello, about 4 or 5 weeks ago I asked if anyone know how to get a Sun
contract so servers could be updated.
I finally found the oracle government rep who said she had to generate a
quote for us.
That was about 4 weeks ago on the phone and I haven't heard anything yet and
this person hasn't replied to my email on.
Barring the snow storms I'm guessing folks back east are going to work.
Does anyone know of a Oracle/Sun rep who would like to make some money
selling a Sun software contract for 9 servers?
Apparently no one at Oracle is hungry for sales.
Nothing on the site to click and purchase unless you have Oracle/Sun on non
Oracle hardware.
 
Eric R. Jones
SRF JRMC
C1236
DSN 315-243-4196
 
STICK \'stik\ n. 1: A boomerang that doesn't work.
 
Jones, Eric CIV SRF 1236 | 3 Feb 03:14 2011
Picon

Re: Sun contracts

Thanks, there used to be a link where you could purchase from the website
but now I guess you need a rep. 

 Eric R. Jones
SRF JRMC
C1236
DSN 315-243-4196

STICK \'stik\ n. 1: A boomerang that doesn't work.
-----Original Message-----
From: pca-bounces <at> lists.univie.ac.at [mailto:pca-bounces <at> lists.univie.ac.at]
On Behalf Of Nishimura, Scott L (IT Solutions)
Sent: Thursday, February 03, 2011 11:03 AM
To: PCA (Patch Check Advanced) Discussion
Subject: Re: [pca] Sun contracts

Eric,

  I forwarded your email to my Oracle account rep; hopefully he has a simple
solution.

 
Scott

-----Original Message-----
From: pca-bounces <at> lists.univie.ac.at [mailto:pca-bounces <at> lists.univie.ac.at]
On Behalf Of Jones, Eric CIV SRF 1236
Sent: Wednesday, February 02, 2011 5:44 PM
To: PCA (Patch Check Advanced) Discussion
Subject: EXTERNAL:[pca] Sun contracts

Hello, about 4 or 5 weeks ago I asked if anyone know how to get a Sun
contract so servers could be updated.
I finally found the oracle government rep who said she had to generate a
quote for us.
That was about 4 weeks ago on the phone and I haven't heard anything yet and
this person hasn't replied to my email on.
Barring the snow storms I'm guessing folks back east are going to work.
Does anyone know of a Oracle/Sun rep who would like to make some money
selling a Sun software contract for 9 servers?
Apparently no one at Oracle is hungry for sales.
Nothing on the site to click and purchase unless you have Oracle/Sun on non
Oracle hardware.

Eric R. Jones
SRF JRMC
C1236
DSN 315-243-4196

STICK \'stik\ n. 1: A boomerang that doesn't work.

Attachment (smime.p7s): application/x-pkcs7-signature, 7700 bytes
Gael Martinez | 3 Feb 06:14 2011
Picon

Re: Sun contracts

try to download mysql :) reps will be calling/mailing you very quickly :)
 
Regards

On Wed, Feb 2, 2011 at 8:14 PM, Jones, Eric CIV SRF 1236 <Eric.Jones <at> srf.navy.mil> wrote:
Thanks, there used to be a link where you could purchase from the website
but now I guess you need a rep.


 Eric R. Jones
SRF JRMC
C1236
DSN 315-243-4196

STICK \'stik\ n. 1: A boomerang that doesn't work.
On Behalf Of Nishimura, Scott L (IT Solutions)
Sent: Thursday, February 03, 2011 11:03 AM
To: PCA (Patch Check Advanced) Discussion
Subject: Re: [pca] Sun contracts

Eric,

 I forwarded your email to my Oracle account rep; hopefully he has a simple
solution.


Scott

-----Original Message-----
From: pca-bounces <at> lists.univie.ac.at [mailto:pca-bounces <at> lists.univie.ac.at]
On Behalf Of Jones, Eric CIV SRF 1236
Sent: Wednesday, February 02, 2011 5:44 PM
To: PCA (Patch Check Advanced) Discussion
Subject: EXTERNAL:[pca] Sun contracts

Hello, about 4 or 5 weeks ago I asked if anyone know how to get a Sun
contract so servers could be updated.
I finally found the oracle government rep who said she had to generate a
quote for us.
That was about 4 weeks ago on the phone and I haven't heard anything yet and
this person hasn't replied to my email on.
Barring the snow storms I'm guessing folks back east are going to work.
Does anyone know of a Oracle/Sun rep who would like to make some money
selling a Sun software contract for 9 servers?
Apparently no one at Oracle is hungry for sales.
Nothing on the site to click and purchase unless you have Oracle/Sun on non
Oracle hardware.

Eric R. Jones
SRF JRMC
C1236
DSN 315-243-4196

STICK \'stik\ n. 1: A boomerang that doesn't work.




--
Gaël Martinez


Martin Paul | 3 Feb 09:39 2011
Picon
Picon

Re: zones and $TMPDIR

Craig Bell wrote:
> Hello all - I recently ran into an issue using pca(8) with zones and $TMPDIR.
> Have you seen this before?

Not me. I have only minimal experience with patch zones (and zones in general). 
So I can only comment on this sub-question:

> Alternate theory:  I recall years ago (probably on 5.8) that patchadd invoked
> certain sub-commands as EUID "nobody", and occasionally I would see the odd
> failure when my current working directory was only accessible by root.  Maybe
> this is something similar to that. 

This problem still exists in Solaris 10 9/10, but the error looks different than 
in your example:

# pwd
/tmp/patch
# ls -la
total 352
drwx------   3 root     root         253 Feb  3 09:32 .
drwxrwxrwt   7 root     sys         1300 Feb  3 09:33 ..
drwxr-xr-x   3 root     root         726 Nov 30 23:28 146279-01
# patchadd 146279-01
Validating patches...

Loading patches installed on the system...

Done!

Loading patches requested to install.

Done!

Checking patches that you specified for installation.

Done!

Approved patches will be installed in this order:

146279-01

Checking installed patches...
Executing prepatch script...

Patch 146279-01 failed to install due to a failure produced by pkgadd.

See /var/sadm/patch/146279-01/log for details

Patchadd is terminating.
# cat /var/sadm/patch/146279-01/log

This appears to be an attempt to install the same architecture and
version of a package which is already installed.  This installation
will attempt to overwrite this package.

/tmp/patch/146279-01/SUNWbnuu/install/checkinstall: 
/tmp/patch/146279-01/SUNWbnuu/install/checkinstall: cannot open
pkgadd: ERROR: checkinstall script did not complete successfully
Dryrun complete.
No changes were made to the system.
#

Martin.

Craig Bell | 3 Feb 20:27 2011

Re: zones and $TMPDIR

Martin Paul wrote:
> Not me. I have only minimal experience with patch zones (and zones in general).
 
  No worries, thanks Martin.  Many zones users prefer to detach them before patching, and then use “zoneadm attach –u” (Update on Attach) afterwards to speed up the patch process.  I left this particular full-root zone attached, and let patchadd handle it directly.
 
  I spun another crackpot theory: When patchadd calls zone_enter(), the existing $TMPDIR (relative to GZ root) carries over, and does reflect the chroot()ed zonepath.  In other words, package tools in the NGZ try to access a temporary directory accessible only in the GZ.
 
  That may not even be technically possible, but I’ve seen stranger things before, and I’m admittedly short of ideas.  =-)  Perhaps some other readers have run into this…  Anyways, I agree that my syndrome doesn’t look quite the same as the EUID nobody issue.  Thx…  -c
 
 
Rajiv Gunja | 3 Feb 21:06 2011
Picon

Re: zones and $TMPDIR

Craig,
Please note that 'Update on attach' will only work for OS patches(this was mentioned on Oracle's blog), it will not update Application patches if present on the NGZ.

<at> our office, we create LU environment and patch the GZ with NGZ using PCA.
We prefer this method over shutting down the server to single user mode, as there was a bug which would not boot up the zones, back when zones were still in infancy. Note: We use whole root zones and not sparse zones.

If you want to know how we do, drop me a line and I can send you our process.

-GGR
--

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


On Thu, Feb 3, 2011 at 14:27, Craig Bell <Craig.Bell <at> standard.com> wrote:
Martin Paul wrote:
> Not me. I have only minimal experience with patch zones (and zones in general).
 
  No worries, thanks Martin.  Many zones users prefer to detach them before patching, and then use “zoneadm attach –u” (Update on Attach) afterwards to speed up the patch process.  I left this particular full-root zone attached, and let patchadd handle it directly.
 
  I spun another crackpot theory: When patchadd calls zone_enter(), the existing $TMPDIR (relative to GZ root) carries over, and does reflect the chroot()ed zonepath.  In other words, package tools in the NGZ try to access a temporary directory accessible only in the GZ.
 
  That may not even be technically possible, but I’ve seen stranger things before, and I’m admittedly short of ideas.  =-)  Perhaps some other readers have run into this…  Anyways, I agree that my syndrome doesn’t look quite the same as the EUID nobody issue.  Thx…  -c
 
 

Coskun, Aydin | 3 Feb 21:15 2011

Re: zones and $TMPDIR

Can you send it to me as well?

~ Aydin

 

From: pca-bounces <at> lists.univie.ac.at [mailto:pca-bounces <at> lists.univie.ac.at] On Behalf Of Rajiv Gunja
Sent: Thursday, February 03, 2011 12:06 PM
To: PCA (Patch Check Advanced) Discussion
Subject: Re: [pca] zones and $TMPDIR

 

Craig,
Please note that 'Update on attach' will only work for OS patches(this was mentioned on Oracle's blog), it will not update Application patches if present on the NGZ.

<at> our office, we create LU environment and patch the GZ with NGZ using PCA.
We prefer this method over shutting down the server to single user mode, as there was a bug which would not boot up the zones, back when zones were still in infancy. Note: We use whole root zones and not sparse zones.

If you want to know how we do, drop me a line and I can send you our process.

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


On Thu, Feb 3, 2011 at 14:27, Craig Bell <Craig.Bell <at> standard.com> wrote:

Martin Paul wrote:

> Not me. I have only minimal experience with patch zones (and zones in general).

 

  No worries, thanks Martin.  Many zones users prefer to detach them before patching, and then use “zoneadm attach –u” (Update on Attach) afterwards to speed up the patch process.  I left this particular full-root zone attached, and let patchadd handle it directly.

 

  I spun another crackpot theory: When patchadd calls zone_enter(), the existing $TMPDIR (relative to GZ root) carries over, and does reflect the chroot()ed zonepath.  In other words, package tools in the NGZ try to access a temporary directory accessible only in the GZ.

 

  That may not even be technically possible, but I’ve seen stranger things before, and I’m admittedly short of ideas.  =-)  Perhaps some other readers have run into this…  Anyways, I agree that my syndrome doesn’t look quite the same as the EUID nobody issue.  Thx…  -c

 

 

 


Gmane