HP-UX Patch Strategies

[Rob_Taylor]

Hi,

A big question and a survey. What patch philosphy do you use?
1. Latest and greatest
2. Wait six months to load new patch set
3. Wait one year to load new patch sets
4. Other

[Pete Randall]

Rob,

You should be getting a wide variety of responses, I expect: all the way from "if it ain't broke" to your number 1 - L&G.

I think the safest, sanest approach is to apply the previous bundle rather than the latest, and add any further patches on an as needed basis - no need to be cutting edge!


Pete

[John Payne_2]

Rob,

I only install the following: Support Plus patches (Quality Pack patches, HW Enablement), and security patches. It should be noted that the Quality pack is not really "Latest and Greatest", these patches under go a lot of testing, HP would just leave the "Greatest" tag, not the "Latest" to them.

I schedule 2 times a year for patching, since the majority of my machines are HPUX 11.11, I schedule for February and late July. This gives time for the bundle to be released (Dec and June every year), and for me to test them on the sandboxes and on Stage.

I have had no problems in the least with this schedule, and I have had no problems in the least with my patching strategy.

You might be interested in the Patch Management paper HP wrote: http://docs.hp.com/en/5991-5309/5991-5309.pdf

Hope it helps
John

[DCE]

It depends

I have worked for one comapany that wanted the currect patch bundle applied after every release

The next company was - if it isn't broken, don't fix it - i.e. not patch application unless the system either had a problem, or an OS upgrade was required (then they patched to the latest level.

The company I currently an working with uses golden image with the a certain bundle it, and then waits until the patch bundles are out of date (i.e. superceded patches are required) before applyng a new bundle to all systems.

[John Guster]

2 times a year Feb. and Aug. as HP release patches on June and Dec. as suggested by other as well.

You can go to HP site do a patch assessment select conservative as patch strategy, then select patch options proper for your environment.
Hope help. Cheers.

[Rita C Workman]

Our patch strategy:

* Try for twice a year.
* Always conservative...Never bleeding edge.
* We run patch analysis and then I pass that to our HP contact and have they check and prepare our custom patch CD. I really have a great support contract !!! I rarely use the Quarterly Support CD's (although I do get them just in case !)

Rgrds,
Rita

[Bill Hassell]

I would add one other choice (which I would NEVER use):

5. If it ain't broke, don't touch it.

This is the Ostrich Method. It is the worst possible scenario because it assumes that the sysadmin will know when the system is broken and that the broken part will have no significant effect on operations. For IT managers that insist on the IIAB method, the cure is to force them to read the complete description file for just 50 patches. (notice I said force? It's part of the cure) Once they see the extremely complex relationships between various parts of the system as well as the consequences of the problems, they will rethink the strategy.

The other part of a good patch strategy is your test lab (you do have one, correct?) This is where you have systems to test the applications and the patches prior to production release.

I agree with the twice a year strategy. I would also add that using the check_patches script before and after is a good validation step. And often overlooked is the security_patch_check script. The SPC not only finds missing security patches, it also looks for warnings and recalled patches. Download SPC from software.hp.com and always pull the most recent version of the data file.

[Bob E Campbell]

I recommend that people look at this in distinct selection and deployment parts. For most of the bigger customers I have worked with a production system will only be patched once or twice a year. For those boxes, there is a significant cost associated with maintenance windows.

These same admins will review new patches weekly, and security bulletins as released. Based upon their review, the content for the next window is built over time. How many times that set is made available for production systems depends on testing resources. The new SWA tool can help keep track of new patches and Security Bulletins (http://hp.com/go/swa).

Remember that a good Ignite-UX or Dynamic Root Disk (DRD) backup can support a more agressive patch strategy, and the lack of one can cause the most cautious to fail.

Bob

[A. Clay Stephenson]

While I typically patch twice a year, after rippling through both a Sandbox and a Test environment, there is one phrase that I always search the patch database for: "possible data corruption". Those should be investigated immediately and if found to be applicable, then applied as soon as possible. There is nothing worse than some bug that drops bits here and there and might not be found for months --- long past the point where reasonable recovery is even possible.

Before applying patches (and weekly as a matter of course), I also create "lifeboat" disks made by dd'ing the raw boot devices to identical disks. I can be back up before you can say "Ignite" should anything go wrong.

[Rob_Taylor]

thanks everyone for your input. It will be very useful in our determination of what method(s) to use in our shop.

[Steven E. Protter]

Shalom,

4.) Other

We work with customers and the process of getting a patch installed involves substantial negotiation.

When a patch set is released, we test it on individual systems to insure it does no harm.

After that we go to a lab that simulates the database or cluster environment and install there. After that comes peformance testing to make sure there is no negative impact on performance.

After this depends on the customer. Some will take the patch set on the "does no harm" theory. Some will demand it be installed in a simulation environment.

Prior to going on any system an Ignite make_tape_recovery or make_net_recovery is done.

The cycle is pretty much driven by HP's patch release cycle but it can take 6-9 months to get a patch set into production.

We also include security patchs and oracle patches in the bundle to minimize the number of times we boot customer systems.

SEP

[Rob_Taylor]

Thanks everyone!