Patch treadmill

[Tim Killinger]

I (we) are new to UX and we're becoming familiar with the whole process of UX adminstration.

We took delivery of our 11.0 box in February of last year - the box was built and loaded by HP last January.

There seems to be many, many references across any forum posting for the need to frequently apply patches. Also patches appear to be released at a very frequent and regular pace.

We're porting our Oracle app from OpenVMS, where patches were typically necessary only when symptoms surfaced. In other words the accepted policy was "don't fix it unless it's broke"

As 'old' as 11.0 is (1997) I would think the number of recent patches needed would be small.

Question - is it a common or advisable admin practice to apply any and all patches as they become available to stay "current", or is it most common to do just what you need?

How do determine on an ongoing basis your systems "patch status".

Is patching as frequent and necessary as the discussion threads seem to indicate?

Any thoughts and opinions on the issue of UX patches are appreciated!

[A. Clay Stephenson]

The problem with the "don't patch it if it ain't broke" method is "how do you know?".
Some of the patches marked critical correct problems which can lead to data corruption under obscure and unusual circumstances. You might find that you have a corrupt database and no backups old enough to fix the problem.

My general advice is to load the latest Quality Pack; in general, those patches have been tested rather well. Some admins prefer to stay one QPK behind so that almost all the bugs have been found by someone else. My approach is to immediately install the latest patchset on a Sandbox and let it run for two weeks or so. Next, install in the test environment and if no problems are found then install in production during a scheduled maintenance window. That scheme has resulted in zero unplanned downtime in over four years and counting.

At the very least, you should examine all the patches marked 'Critical' and determine if those might apply to your box.

[Paul Sperry]

please see the why I love QPK thread.
I believe it's the way to go.

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xa2cc7680e012d71190050090279cd0f9,00.html

[Michael Tully]

Hi,

As a matter of practise we do not apply the latest patch bundle. At a minimum we always at least one set behind.
We will however install patches where a bug has prevented us doing something particular.

For example during next month we intend to roll out the September 2002 patch bundle across our production systems. We have had this bundle loaded on our test and development servers for a while.

As we are rapidly expanding our number of HP systems, we have put into practise procedures on keeping reasonably up to date but making sure that we are not in danger of using the bleeding sword. one of the problems I see of being too far behind is that there is always the potential of running into a problem that has already been fixed. There are a number of hidden nasties.....

I guess, Horses for courses.

My Aussie 3 cents worth
Michael

[Sridhar Bhaskarla]

Hi,

"don't fix unless it's broke" is not applicable to patches in my view.

If you don't patch, you will get good surprizes time to time which may cost you production time.

You need to regularly patch your servers. There are different kinds of approaches and I vote for "conservative" approach.

HP releases patch bundles every Quarter and they are cumulative. If you are in december, then you don't need to install December level bundles. You can install either September or June's bundles depending on how conservative you are.

Make a patch policy for your HP systems. Patch twice every year and differ your level by atleast -1 version to that of the HP's current release.

-Sri

[Rajeev Shukla]

It is always advisable to apply the latest patches released in Support Plus CD from HP. And at any stage if you want to test the patching status of your system you can use Custom Patch Manager
http://us-support2.external.hp.com/wps/bin/doc.pl/sid=138b920d0f946b9765

But it sometimes makes hard to take down time and apply patches on ststem running 365 days(to clearly say, some systems are hard to be released for patches and people) in those cases like our few servers we dont apply patches until and unless it is released as critical by HP and they inform us(for which you can register yourself) and we havent faced any problem on those servers.

Rajeev

[James R. Ferguson]

Hi Tim:

You might take a look at the ITRC Support_Plus link's FAQ's. This may help you understand the packaging available, the certification that goes into the bundles, and the cyclical frequency with which patch bundles appear:

http://www.software.hp.com/SUPPORT_PLUS/

Before you begin to patch, I urge you to read the Patch Management white paper:

http://docs.hp.com/hpux/pdf/5967-3578.pdf

This document offers some good general explanations of sound strategies, too.

If you're interested in using the Custom Patch Manager, you'll find more information here:

http://us-support3.external.hp.com/wps/bin/doc.pl/sid=2777fd3205a8cd4803

Yet another execellent overview of patching can be found in the chapter-6 of the Software Recovery Handbook:

http://www1.itrc.hp.com/service/iv/docDisplay.do?docId=/DE_SW_UX_swrec_EN_01_E/Patches.pdf

Regards!

...JRF...

[John Payne_2]

Wow, I was quoted.

Anyway, yes, there 'seem' to be alot of patches. If you stay regular, (not necessarily up-to-date. We are always 6 months behind on the QPK's...) you will be ok. The thing is that the patches usually hit a single subsystem or product. HP doesn't just lump all patches into one huge patch for you to install. Of the QPK, generally there are a smaller number than the total that have to be applied when you go to a regular install schedule.

As far as how current you want to stay, it's up to you. It depends on your level of risk. We are very, very comfortable with the QPK's. We run them on a sandbox for 4-6 months before putting them on production machines, and have not had a problem with even the sandbox machines. We try to only have QPK worthy patches (3-star patches) installed, but with some security alerts, we occasionally end up with a 2-star patch or 2 installed in production.

I have met people who think otherwise, but we have had GREAT success with the QPK's...

Look at the patching page at: http://www.software.hp.com/SUPPORT_PLUS/
That will give you some more insight as to what HP is doing with patches. You will also find it worth your while to subscribe to the security bullitins digest.

Hope it helps

John

[Steven E. Protter · Accepted solution]

If its not broke, don't fix or patch it was our previouis administrator's motto.

It hurt me badly and cost me many nights sleep when I took over.

Good practice is to set a reasonable policy and stick to it.

Oracle document id 43507.1 provides a list of patches Oracle feels are required for all HP-UX supported OS's

Here is a link if you have a metalink account.
http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=43507.1

If note, here is a current copy. Please nobody turn me into oracle, they hate when I paste their docs into HP.
attached.

Note that you need java in order to run oracle apps and an oracle db.

Here is a link to the patches required for java, which you should install prior to database installation.

http://www.hp.com/products1/unix/java/infolibrary/patches.html

Please reward myself and others that answered you with some points.

Steve

[avsrini]

Hi,
This is a long going discussion. It was time, when people was not feeling comfortable applying the recent patches to the system.
But now HP is making sure they test the patch before releasing it in QPK. So you can very well rely on QPK's. and it is supported by HP.

Also i suggest the idea of being one level behind of QPK.

But for critical patches, you should try to make it as soon as possible.

You can register for regular patch updates in itrc, for your own hardware / OS platform.

Also it is a good policy to check you DB / application vendors sites for patch requirements of HPUX. Because
they also might be getting calls and resolved the issues in advance. This will ensure us in smooth operation.

Hope you will find some guidelines from the above posts to formulate your own policy.

Srini.