SEO

I'm currently developing a solution that will deploy 2 servers to each
of ~2000 sites. With that number of machines and no skilled technician
on site I'm concerned about patch rates (among other things). Can
anyone here point me to a site for reliable unbiased patching rate for
SuSE Enterprise Linux, HP-UX, AIX and Windows Server?
Thanks in advance,
Chuck

> Can anyone here point me to a site for reliable unbiased
> patching rate for SuSE Enterprise Linux, HP-UX, AIX and
> Windows Server?

Sounds like you're concerned with patches/time or critical patches/time
that would need to be done by someone on site.

I don't know of any site that has information on that, but if patching
rate = the number of patches released by a vendor over time, then it
should be possible to calculate it based on the dates of the last few
patch bundles for a target OS and the number of patches in each patch
bundle.

If you are looking for number of critical patches/month, you could do
something like this:

1. Download all the latest patch bundles for an OS.

2. Use a patch utility to count the patches and extract their dates.
If that's not possible, you could go to the vendor's patch site, count
the patches there, and try to find an associated date for each patch or
bundle on the site.

SLES patch dates:
rpm -q -a -P --info | grep "Build Date:"

HP-UX patch dates:
swlist -d -a readme -l patch @
/usr/local/adm/GOLDQPK11i_B.11.11.0406.5.depot | grep 'Creation'

AIX patch dates:
Couldn't find patch dates using either lslpp or instfix. May have to
use brute force on this one and just grab the date for patch bundles
off of IBMs AIX patch site if it's available.
http://www.ibm.com/eserver/support/fixes/

Windows patch dates:
Similar story here. Not sure how to get the patch dates. May only be
able to get the dates of the last few Service Packs and try to find a
count of critical hotfixes included in each.

3. Then you could calculate the patch rate (patches/time) by dividing
the # patches or patch bundles by days, weeks, or months.

This was the only thing I could come up with. I know it's pretty
sketchy...

Interesting question though. Hope someone has some more useful info on
this for you. Now I'm curious about it too.

"Bryan Brock" <bbrock@gmail.com> writes:

>> Can anyone here point me to a site for reliable unbiased
>> patching rate for SuSE Enterprise Linux, HP-UX, AIX and
>> Windows Server?

>Sounds like you're concerned with patches/time or critical patches/time
>that would need to be done by someone on site.

>I don't know of any site that has information on that, but if patching
>rate = the number of patches released by a vendor over time, then it
>should be possible to calculate it based on the dates of the last few
>patch bundles for a target OS and the number of patches in each patch
>bundle.

>If you are looking for number of critical patches/month, you could do
>something like this:

>1. Download all the latest patch bundles for an OS.

>2. Use a patch utility to count the patches and extract their dates.
>If that's not possible, you could go to the vendor's patch site, count
>the patches there, and try to find an associated date for each patch or
>bundle on the site.

>SLES patch dates:
>rpm -q -a -P --info | grep "Build Date:"

>HP-UX patch dates:
>swlist -d -a readme -l patch @
>/usr/local/adm/GOLDQPK11i_B.11.11.0406.5.depot | grep 'Creation'


The date of "Creation" or "Build" often has nothing to do with when the
patch comes out. And you are looking at a quality pack, which is released
on a schedule, so you know how many of those there are for HP-UX. It is
somewhere in between Microsoft's monthly patch bundles that collect a
dozen or more patches, and a service pack that collects hundreds (except
HP releases all the component patches separately so you don't have to wait
if you need one right away) When you look at Linux you have to realize
that SuSE and Redhat include about 5GB of stuff, so the patch totals for
Linux are misleading because patches for some obscure version of a CD
burning app that is only exploitable by a local user isn't really
something you care about on a server -- but Microsoft will still count
against Linux when they want to claim how it has more security problems
than Windows)

I don't think the OP is even asking the right question. What he really
wants are servers that can be administrated remotely in large numbers
without undue effort. Most people would agree that eliminates Windows,
but between Linux, HP-UX and AIX they'd be on roughly equal footing. Once
you have your scripts set up, it isn't really any harder to patch 2000
servers than it is to patch 20.

--
Douglas Siebert dsiebert@excisethis.khamsin.net

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety" -- Thomas Jefferson

> What he really wants are servers that can be administrated
> remotely in large numbers without undue effort.

That's more to the point, and makes more sense than the patching rate I
was trying to calculate.

However, I do think the frequency of critical patches that require a
reboot would be a useful thing to know, but that's probably not what
the OP wants here. It would also require a different method than the
rather dubious one I provided.

> Once you have your scripts set up, it isn't really any harder to
> patch 2000 servers than it is to patch 20.

True, and since there are a limited number of configurations (2),
automation would be straightforward.

Your answers have improved the question and I apprecite both tacks.
The suspicion that I am after a supportability quotient is correct.
The two factors that concern me the most are how many critical patches
per month, based on history, I can expect for each of these OS's and of
those how many will require a reboot. I'll delve further based on your
suggestions. One note to add, while it is true that:

> Once you have your scripts set up, it isn't really any harder to
> patch 2000 servers than it is to patch 20.

It is worth noting that as the number of sites grows it does get
increasingly difficult to ensure that the patches actually apply,
particularly the reboot ones in an environment with a very small
maintenance window that frequently is eclipsed by production jobs.
It's a bit like herding cats.

camattern@acm.org wrote:

: It is worth noting that as the number of sites grows it does get
: increasingly difficult to ensure that the patches actually apply,
: particularly the reboot ones in an environment with a very small
: maintenance window that frequently is eclipsed by production jobs.
: It's a bit like herding cats.

with HP-UX you can combine all patches that require a reboot into one
depot, apply all the patches from that depot and only have one reboot.
You can put other patches in there as well and still only have one
reboot.

--
Jim Hollenback
jholly@cup.hp.com
my opinion.

jholly@cup.hp.com (Jim Hollenback) writes:

>camattern@acm.org wrote:

>: It is worth noting that as the number of sites grows it does get
>: increasingly difficult to ensure that the patches actually apply,
>: particularly the reboot ones in an environment with a very small
>: maintenance window that frequently is eclipsed by production jobs.
>: It's a bit like herding cats.

>with HP-UX you can combine all patches that require a reboot into one
>depot, apply all the patches from that depot and only have one reboot.
>You can put other patches in there as well and still only have one
>reboot.


Since it sounds like the OP is worrying about patches outside the normal
scheduled OS patch maintenance process requiring reboots, I don't think
its a big issue for HP-UX, AIX or Linux, since a critical security-related
patch requires a reboot only very rarely on Unix based systems, in
contrast to Windows.

The exception of course would be a critical fix in the form of a patch to
correct a problem you are encountering, like a kernel bug that is causing
a crash. But such fixes are (hopefully) far less frequent than the flood
of security advisories that come out these days!

--
Douglas Siebert dsiebert@excisethis.khamsin.net

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety" -- Thomas Jefferson