[AUUG-Talk]: Patch mgmt approaches?

[Stuart Remphrey]

Along the lines of the last "what resources do you use" survey,
anyone like to contribute thoughts on pkg/patch mgmt on Unices?
Good tools or other resources, pet hates, policy/planning...


For our part, our group manages mostly Solaris (some Redhat). For
tools
we currently use Sun TLP (traffic light patching => green/yellow/red
reports)
may look at Update Connection Enterprise, "pca" (Perl util), possibly
others.


On production apps we tend to use a 2-3+ month old patch baseline,
minus subsequently-withdrawn patches, to improve the chance
they've seen some use in the wild. For our workstations or pilots
we're most likely to use the latest available.

A patch cycle is followed per application group: apply to test
systems,
test, approve, apply *same* to prod and dev; on to next app group.
So they're in-sync within an application group, as far as hardware
allows,
but not necessarily across disjoint applications.


TLP generates patch sets based on analysing a system config snapshot
(an "explorer" output file, to deduce installed
hardware/software/firmware),
cross-referenced to Sun Alert and patch databases. The initial patch
list
is generated, dependencies resolved, basic black/whitelists accounted
for
and patch cluster built (patch dir, patchorder file, install script
tarball).
Unfortunately there's no post-black/whitelist dependency
re-evaluation.
Symlinks ("phases") are kept per app, to the current(/next) patch set.

This patch application process loop can take days to months for an
app,
depending on resource availability (admins, testers) and app workflow
(access to the systems, scheduled downtime & notification periods).


"Live Upgrade" is used to apply pkg/patches to a second (inactive)
copy of the O/S, while the rest is running, to reduce the downtime
required to install the patches, which helps get access in the first
place.
It also leaves the previous O/S in place in case we need to roll back.

LU has worked for most pkgs/patches, although we no longer use it for
VERITAS VxVM et al as while it now tends to patch the correct
binaries,
it then tends to restart the vx* daemons using them, which probably
no longer match what's loaded into the kernel! Not good to find out
if your dev/test uses just SVM and prod uses VxVM...

Rgds, Stuart.