Hi everyone,
I was wondering what is a good patch strategy?
1.How often do you patch your system .. every 3 months or ever 6 months?
2.What tool do you use to patch your system and why do you choose it over the others. CPM , QPK , HWE ?
3.Do you commit your patches? And what tool do you use to commit them? cleanup, swmodify.
4.Issues that you have ran into and how you went about fixing them.
Thanks,
Richard
Note: If you are the author of this question and wish to assign points to any of the answers, please login first.For more information on assigning points ,click
here
Start applying December bundles in March along with Dianostics. They go through development, test, pre-production and production stages. By the time we implement them into production, they will be around 4 months old and well tested.
June bundles in August.
We also collect recommended patches (mainly security) and make it as a seperate bundle. It goes along with the standard bundles. If there any critical patches released that are absolutely necessary, we apply them on adhoc basis. But that's a very rare occurance.
So, all our systems are uniform with a decent set of pathces.
1.My patching strategy is once in 3 months, as on i receive the Support Plus CD from HP.
2. QPK
3.No
4. I haven't faced any problem after applying QPK patches
Here is what I have so far for me.
FYI: all this is on a crash and burn system so if you have any advice or
suggestions for me please let me know.
1.I plan on using QPK and HWE every 3 months. Since from what I have read the
patches have been tested and the CPM patches seem to be the newest patches
that might be a little buggy. Last night I loaded QPK , and out of curiosity
I also submitted it for CPM to see what it comes up with but CPM was down so
I have not had a chance to go try again.
2.run swconfig \* to configure any patches that were not configured.
4.run check_patches
to check for errors. Now I have had some errors one was the
Neither PHSS_16841 nor PHSS_17571 is currently active. # now sure how to fix
this
ANd another issue With old patches still being on the system. If I did
Swlist ???l fileset ???a state | grep installed
I would see some old patches that have been updated by newer patches. I
found this out because I looked up the patch #???s in ???individual patches??? and
the patch that is showing up on the list is an old patch. I do an swlist ???l
fileset ???a | grep new_patch_number and the new patch is there and
configured. So I did:
swmodify -x patch_commit=true PATCH_NUMBER
and that didn???t work for me .. so I did
swmodify -a state=configured PATCH_NUMBER
and that cleared that up for me hopefully this didnt affect my IPD.
I still have an swverify error that I have attached.
Our strategy is twice a year, straight off the patch bundle CD. We also utilise/create a seperate bundle where there has been extra critical or security patches. If we tried to do this more often we find ourselves continually patching machines.
We start with a test server, leave it for at least two weeks before moving onto a designated developement server. Once we are happy with one, we deploy it to the rest of development. Typically this cycle can be where we are at least two months behind.
Once we are happy we deploy these to production systems at times when we can get past our change control mechanism and we can get the outage time from the business. Once this cycle has completed, we are just about ready to start the cycle again.
I can't help with your current release, sorry
Cheers
Michael
As long as our production systems are working well on our servers, we do not consider installation of any patches.
It is only when we have problems or need to install new products that we query about the existance of new patches - but only patches that are required for the new products!
I read all announcements, and if one of them seems to solve a known problem or can increase my system's performance, I install it on the development system asap. If it indeed proves to be an improvement, I will also do it on the production machines.
C-compiler patches and libraries are good examples of such patches.
For the rest I will wait for the 3-month CD's and do those asap on the development system, and a month later on the production machines if no nasty things turn up.
I'm doing this so soon, because I want to know what will fail before my clients run into failures.
Our patch stragegy seems pretty similar to others.
We install the patches approx every six months, but never the very latest set. We geneally install one set behind of software updates and the hardware 3 months after issue.
We do commit patches, generally using cleanup, getting rid of anything that has been superceeded more than twice. On some of the less important systems with less space we get rid of stuff superseeded once.
When a set of quarterly patches comes out, we apply the previous set. This allows time for problems with the patch set to be found. Prior to installing the QP we alwys check to see if any of the individual patches have been recalled and, if so, either remove them or replace them with a superseding version.
1. We patch every three months. We start with a test/dev box on one hardware platform [one rp8400, one L box, etc.] and patch it. The next month, if those patches seemed stable, we patch the remaining boxes. We will apply a single patch or two as needed to fix a specific problem or a security hole, but that is usually pretty rare.
2. We're prety spoiled. We're a CSS customer on our production boxes so we have a Response Center Advocate who we send the results of a script and they send us patch bundles. For other patches we use the quarterly patch bundles.
3. We use 'cleanup' to commit our patches and generally we just do it to free up space.
4. No real issues. We've only had to back out one or two patches in about four years, and that hasn't happened in a long time. We're pretty conservative in our patching so we haven't gotten burned with any problems.
Our strategy is that we patch every six months from the Support CD. We do both the QPK and HWE. But when it comes to our production servers, we patch them once from the CD and once from a patch analysis done by HP.
I use the cleanup command, but I only use before applying the CD to patch my system.
When I first build a system, I install the latest patch bundles available. After that, I generally don't patch my production machines unless I need to resolve a particular problem. I do apply bundles to my sandbox and development machines when the mood strikes me.
At the time I took over systems administration, our organization's patch strategy was, if it aint broke, don't try and fix it.
This failed miserably. We now do the following:
Quarterly releases when they come out(made necessary by Oracle support requirements).
Security patches, installed as often as twice a month, test systems first, two weeks later production.
Hardware Patches, we just recently go our old D class servers to sucessfully install HWE, our plan is to stay current quarterly.
If we have specific problems brought to light by q4 dump analysis or specific support issue, we follow the same plan as we do with security patches.
For example, this weekend is a patch maintenance weekend, I'm allowed to install on production systems. Two weeks ago, I upgraded sendmail in test. No it goes production. Test gets the new binaries next maintenance window. I've recently tested the CIFS patch, due to security bulliten, since it tests well, all systems will probably get it this weekend.
I rate our policy as sane, but agressive. In the past every time we back off circumstances force us to roll forward anyway.
SEP
OT: Prayers for the forces in Iraq. Condolences to the families. Prayers for peace and freedom for Iraq. Prayers for a just peace in the world.
New systems are ignited with older recovery tapes and brought up to current patches before releasing to production. It is very often these systems that have the OS problems, due to current patches.
The older systems ONLY get patched if they have a problem since most times, that is the only time we get to take them out of production besides having a hardware problem.
I have several 10.20 machines that have been running for 1350-1400 days and they were only taken down at that time for a power outage several years ago.
All of these machines are not on the internet, being on the internet requires you to have all the most recent patches or close to it.
Our patch strategy when we started with HPUX about 7 years ago was to apply patches quarterly, but that got to be a problem real quick keeping all the 200 machines with current patches and scheduling downtime and personnel to do the job.
1) I like to apply the standard (SupportPlus) patch bundles twice a year.
2) I always apply the HWE, QPK and OnlineDiag (STM) bundles for 11.0. For 11.11 it would be the HWE, GOLDBASE, GOLDAPPS, and OnlineDiag also in the order shown.
3) Before application of any of the standard bundles, I run 'cleanup -c 1'. This regains space in '/var' and commits patches superseded at least once. leaving a cushion to which to return as the next set of patches are applied.
4) I try to avoid potential issues by waiting about a month *after* a new SupportPlus set appears. Then, I carefully review the contents of each bundle (HWE, GOLDBASE, GOLDAPPS, etc.) noting any patch recalls. If I find any, I either skip the patch during installation and/or download a replacement which I install in a final pass after the standard ones.
You, can accomplish this bundle review by following the "View Support Plus Releases" link. Click on each bundle you are going to install. Patch "warning"s and suggested replacement patches are noted within. The Patch Database shopping-cart paradigm makes downloading a group of replacement patches into a depot for one-shot installation so simple that this step is a *must* in my opinion.
I forgot to include the link in the case you are not familar with it. Go to Maintenance and Support -> Patches [Standard Patch Bundles] -> View Support Plus Releases:
Printable version
