Patch installs - Why?

[FLQ]

Hi all,

I need to have some infos on patch installs.

I want to provide to my boss a policy for applying patches on HP-Ux v11.xx and 10.20.

Why should I install patches?
If it's not broken, why should I try fixing it?

This is a hot topic at work as the opinions differ considerably.

My opinion is that if the machine performs well without all the new patches installed, I would not want to disturb it.

TIA for pointers, answers, etc ...


Francis

[Sebastian Galeski_1]

Patches should be installed because:
1. many of them add new features
2. many eliminate secure holes
3. they eliminate possible well know causes of problems

But You have to be carefully with patch installation particulary for main subsystems (LVM, TCP/IP etc.)

[Victor_5]

Good question, I never think about it. I know in real life, some machines are running well without any patch. I was in charge of one K class in my previous position, the server was running very well for 7 months without any patch installed. However, for my current position, we need to apply required patches monthly.

From my point of view, it is MUST to install all required patches. After vender released their OS, they realized some problems or some potential issues, so they need to develop some patches to fix those known issues or potential issues. Another reason is that the software need upgrade, patch also needed at that time.

Sometimes, it is hard to convince your manager, I suggest you can study those patches' description, you will know what they are doing, definitely those info will support you.

[PIYUSH D. PATEL]

hi,

you need to tell them that patches are to be installed to protect the system from Panics and crash after giving some commands. There are various types of patches. You may not be facing any problems currently but in future you system may not behave properly.

Patches fix the bugs in certain commands, kernel etc.

PHKL= Kernel Patch
PHNE= Networking patche
PHCO= command patches
PHSS= Subsystem patches

Piyush

[Rainer von Bongartz]

If you don't have any problems with your box AND don't intend to add new functionality in the future you might as well let them run 'as they are'

BUT:


Before adding new SW or upgrading existing SW you should definitly install the latest patch Bundle.




Regards
Rainer

[A. Clay Stephenson]

This is a far from trivial question but the very first question to ask yourself is : How do you know that your machine is performing well?". Many times very subtle errors creep in and remain hidden until long past time for an reasonable recovery - especially those that corrupt small bits of data under unusual circumstances.

If you look at the patches, you will find that a fairly high fraction of them are marked 'Critical' - indicating that problems have been observed or at least there is a known serious defect in the software.


I can tell you that I have not had a second of unplanned downtime in any of my HP servers in almost 4 fours now and that I regularly apply the patchsets as part of periodic maintenance.

I actually move the patchsets through three levels (and this is really the safest method though a little expensive):

1) Apply the periodic patchset to a 'sandbox'; this is a machine that is only used to test new OS releases, patches, new database releases and patches, or any new or untried scripts. Anything goes on this box. An old server or one acquired on the used market does very nicely for this.

2) If no problems were observed in the sandbox environment, install the patchset in the test environment. This is the box that developers work on.

3) Finally (usually about 2 weeks later) with no problems observed install in production during scheduled downtime.

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

A Plan B method used my many admins I know is to delay the deployment of the patchsets by one release and wait fore any recalls or notices; this may be a good compromise if you don't have an environment that allows for fairly extensive pre-testing - but still be aware of those marked critical.


Food for thought, Clay

[FLQ]

thanks to all that answered..

unfortunately, I still cannot assign points to you guys because when I do I get a 404

Do you know what could be the problem?

TIA

Francis

[Wim Rombauts]

I stick with "install patches to fix problems". I my machine shows no sign of trouble, I will not install new patches.

Installing a new patch allways has the risk to receive a patch warning sometime later. You yourself could introduce problems on your machine just by installing a patch that solves a critical problem that never occured on your machine, but triggers an unknown side effect.

[Paula J Frazer-Campbell]

Hi

If the server is running OK then why mess with it.
The policy of patching because they have been released can cause problems.

Look at each patch very carefully, find out what it does - EXACTLY

If it is of definite benefit then and ONLY then consider installing it on a system that is running well.

I know all the reasons for sticking patches all over your OS , security, enhanced commands etc.

Just my 2pence worth.


Paula

[James R. Ferguson]

Hi:

I'll add two technical pointers:

1) When you begin a new patch update (as in the application of a Quality Pack bundle from the SupportCD), create a current baseline by using 'cleanup -c 1'. This frees space in the /var/adm/sw directory and commits all but one level of patches.

2) Avoid using the "no save" ('patch_save_files=false') option when you install a patch. if 'patch_save_files' is false during the patch's installation, the patch cannot be backed-out. The option is generally used when /var/adm/sw space is low.

Regards!

...JRF...

[Bill McNAMARA_1]

If it's not broken, why should I try fixing it?


.. because eventually it will break!
(and has for someone else)

Although often a patch is an enhancement, but is unfortunately most often a panic/corruption/leak fix.

Honestly, you should read the patch release notes and always test on a non production server first...
although you probably know that.

Later,
Bill

[Helen French]

Just an addition:

Do a search in this forum and find out how many problems have been solved by applying the patches. You may not know what went wrong in the system or about a security hole ! Think about the patch resolved issues, after trying hard to solve that by wasting your time. Every new patch release has some fix on that and is surely the result of a known issue/bug. I would keep my system up to date with software updates (patches) rather than expecting a down time in future !

[pap]

I will straight forward come to the point. Why we should apply the patches?

1. Patches fixes the previous defects in core HP-UX software that has been observed by Hewlett packard.

2. Everyday new software versions for various application softwares are released, whenever new version for any of the software applications (third party products or HP supported producs) they will work properly if your machine is uptodate. Otherwise you will not be able to figure out what's going on in case of any problems. Hence if you are running lots of application softwares on your machine, it is essential that your machine should be up to date with latest patches.

3. Patches improves the functionality of the system and applying some patches improve your system performance significantly.

4. As mentioned in previous replies above, you never know what is the performance level of your machine at this time and after applying the patches. HP developes patches keeping everything in mind and if there is any risk in applying a perticular patch, it definately mentions the warning signal. Hence there shouldn't be a problem.

5. You can install the patches using CUSTOM PATCH MANAGER from ITRC if you have support contract with HP.This method is highly recommended while applying number of patches.It will analyse your machine completely and recommends patches required to apply. You can just select the HP's recommended patches during the Cusdtom patching. Thare will not be any risk in doing this.

Hope Above points will help you in making the decision.

-pap

[John Payne_2]

I have a 2 patch level rotation. Immediately when I get a new patch bundle, I install it on a sandbox machine. (Which resembles production evironment in most respects.) I let the patch budle 'burn' for 3 monthes. When the next patch bundle arrives, I install it on the sandbox and migrate the three-month-old patch to production.

The Quality Pack of patches is the cream of the crop patches. It takes some time for them to make it to the bundle. (You may want to read the docs about how they changeed it.) I have never seen one of these patches harm one of my systems. (We are not on the bleeding edge..)

Before I adopted this policy, we never patched. Then, much later, we started having system crashes and performance degradation. Th crashes were the worst, because you would call HP, and they would always want you to first apply a large number of patches, and then wait and see what happened. This usually ended up with a second crash. On the other hand, just last week, our application guys were complaining about a problem that they were seeing with inetd. On researching the problem, I found that there was a patch that resolved the issue. The patch happened to be in the next 'production' patch bundle for us. We had it installed in the sandbox already for 10 weeks, and we just moved the patching schedule up a couple of weeks to resolve the issue. This made us very comfortable applying the patch to fix the problem for them.

These patches are usually fairly benign by the time they get to the patch bundle, assuming you are regularly patching already. A patch rotation further reduces your risk for an outage because of a bad patch.

Hope it Helps

John