GGR/Martin/Kevin,
 
Thanks for your suggestions and advices.  We will discuss and decide
which patching strategy we will adopt.  
 
Thanks
 
Ying Xu <y...@littonloan.com>
Unix Group
Office: 713-218-4508
BB: 832-671-6633
4828 Loop Central Dr. Houston TX 77081
 
 

________________________________

From: pca-boun...@lists.univie.ac.at
[mailto:pca-boun...@lists.univie.ac.at] On Behalf Of Rajiv Gunja
Sent: Sunday, November 01, 2009 12:43 PM
To: PCA (Patch Check Advanced) Discussion
Subject: Re: [pca] patch maintenance schedule


Ying,

Each environment/Org has to decide on what patching strategy they need
to use depending on their situation.

In our environment, we have about 4000 to 5000 SUN servers in Dev, Test
and Production environments.

We concentrate mostly on Production servers for security issues and we,
as in SA teams discuss which SUN alerts we should look at and which SUN
alerts should be taken what precedence.

Depending on the SUN alerts, either we (SA) takes the decision to add it
to our quarterly patch bundle or we get input from middleware or
database teams, whose products are affected by the SUN Alert.

We freeze patchdiag.xref quarterly and change our patch bundle
generation script to point to that quarter' Xref file. If we do add new
Patches from outside that Xref file, we install those patches manually
either before patching or after patching the OS.

Example: Currently our Xref file is frozen on May 29 2009 and 119254-70
has been indentified as a patch which needs to be installed before all
other patches. So we manually install this patch before we start
patching the OS.

So depending on your environment and needs, you have to decide how often
you want to patch your servers and which Xref files to use. Sometimes
SUN comes out with Patches which cause more trouble than solving it,
example: 141414-09.

Hope this helps. 

-GGR

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



2009/10/29 Martin Paul <mar...@par.univie.ac.at>


        Xu, Ying (Houston) wrote:
        

                We would like to use security patch
                cluster to make minimal changes to the environment but
fix sun alert
                issues.
                


        Here's one possible procedure you could use, e.g. for a monthly
patch cycle:
        
        On a certain date, e.g. mid-month, you install all the current
security patches using the same patchdiag.xref file on all your test
machines (e.g. "pca -i missings"). Determine whether a reboot is
required or recommended (pca will tell you). Keep and store the
patchdiag.xref in some central directory (or on a local patch server),
e.g. /xref/20091115/. With a local caching proxy (see pca docs) you will
also ensure that all patches are already stored locally when the
production machines are patched.
        
        On the last day of the month - your patch day - you install the
same set of patches on all production machines by pointing pca at the
frozen xref file (e.g. "pca -X /xref/20091115/ -i missings"). If a
reboot is required, do that after patch installation.
        
        As the production machines install the same patch set as the
test machines, and you had two weeks to sort out any possible issues,
the patch install on the production machines could be done
automatically.
        
        This could be combined with the usage of Live Update of course,
where you would patch an inactive boot environment and reboot to that
after patch installation.
        
        hth,
        
        Martin.
        
        
        


-------------------------------------------------------------------------------------------

DISCLAIMER: This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the sender
by replying to this message and then delete it from your system. Use,
dissemination or copying of this message by unintended recipients is not
authorized and may be unlawful. Please note that any views or opinions
presented in this email are solely those of the author and do not necessarily
represent those of the company. Finally, the recipient should check this email
and any attachments for the presence of viruses. The company accepts no
liability for any damage caused by any virus transmitted by this email.

Reply via email to