This is a follow up of an earlier summary (somebody else's).
Quite a while back I grew tired of calling CSC and being told my most
recent panic was fixed by patch OSFxxx-yyy which they will send.
My response was finally:
"How do I get these patches to avoid problems before they occur".
>From that, I heard of the consolodated patches.tar.Z file(s) which contain
all patches for a given osfvX.Y release.
This file is FTP-able if you know where to look. To my knowledge this is
not documented by Digital which means it is subject to change or
disappearance. It is changing (evolving), the 6/26 osfv32d-1 README
format changed to facilitate automated parsing of the file.
What we have done here is set up a script to periodically (once a week)
scan the appropriate FTP directory for the appearance of a new (updated)
patches.tar.Z for our releases of the operating system. If one is found
we automatically: get it, un-tar it, de-consolodate it to individual
patches, identify the new and superceding patches, and print the patch
abstracts for determination of which we need, which we don't, and which we
have to ask Digital about. The de-consolodating procedure writes "safe"
install scripts for application of each patch. By "safe" I mean it
preserves the original file identified by the appropriate patch so
regressing any patch to any previous level is possible.
This is working... we've applied select patches out of the 5/16 and 6/11
files and will apply some out of 6/26 in a few weeks in our next cycle.
It looks like every 2 to 3 weeks we'll find 5 to 12 patch readmes on
our printer for review.
I am somewhat hesitant to mention this for fear these "unsupported patches"
might disappear. However, any large production shop needs access to this
information (and more) and it took us some time to find it.
There are several problems with what we are doing (besides the obvious
that it's not supported by Digital):
1. The format of the patches isn't yet standardized.
Our de-consolodating and install scripts can break with any future release.
2. The patches are only available in consolodated form.
Although 6/26 contained only 12 new or superceding patches (76 total),
we had to ftp the entire 20mb file. We schedule the ftp for after hours
to reduce network impact, but this is still large enough to be
inappropriate for hundreds of Digital customers to be regularly FTP'ing.
The consolodated README should be available separately as should individual
patches for customers who are staying relatively current.
There will always be a need for the consolodated file, too.
3. The install instructions should be formalized with install scripts.
Obviously, one should never follow the install examples and rename an
original to *.orig... what do you do with the next patch which touches
the same file? We use "*.Pre:OSF360-xxx", a better method might be to
use links and name the for the actual to the current patched version instead.
>From simply the "File(s)" entries we were able automate writing scripts to
issue sum for validation and by known file type (.so or .a) perform ln's to
preserve originals on a running system. What we haven't yet done is automatic
retention of all file protections (e.g., setuid images) and ln's of images
which should retain original inode's for active processes.
This is all quite doable. The individual readme's still must be reviewed
carefully before application, and often when you're done applying you must
then rebuild the kernel and boot (or in some cases just restart daemons).
However, the automated pieces greatly (!) reduce the chances of mis-applying
a patch, provide for patch back-out if necessary, maintain a log of
applied patches, and greatly reduces the overhead when you need to apply
the patches across a collection of systems ("only" five for us, for others
it could be much worse).
4. There is no validation one is replacing an appropriate version.
In addition to supplying the sum of the replacing file, they should
ideally provide the sum(s) of the file(s) it is intended to replace.
While one has to have some faith that the conosolodated patches.tar file
contains the appropriate mix of patch versions, if one has a custom
patch one must re-contact digital to determine which level is applicable
or for a rebuild of the custom patch. Also, without this mechanism one
could carelessly patch an older version on top of a newer version.
5. While it became critical for us to develop interim tools for
our needs, this has no benefit for other Digital customers.
If the procedures come from Digital we all have the benefit of them and
there is a commitment to continue them (even if they aren't officially
supported).
6. For smaller or stable shops, automated (above) is too much.
For those cases, just better documentation of what's available
is adequate. I personally wouldn't object to quarterly announcement
to this list of the latest consolodated files which are available
(I could easily do that, but it's oversteping bounds as a customer).
* * *
For those of you familiar with IBM's SMP/E maintenance tool you
probably recognize alot of what it does in the above. The stuff
available in patches.tar equates roughly with IBM's PTF's ("program
temporary fixes") vs. the custom patches known in IBM-ese as
APAR's ("authorized program analysis report") which are the
'this might work for you, or, as yet not generally validated' type
of patch.
I'm not quite sure why Digital hasn't learned yet that patches
are a routine part of system software. I personally suggest
application of the recent AdvFS consolodated patches and any
patch identified as "A potential security vulnerability has been
discovered". The indivdual README files in some cases are well
done, in some cases additional information would be nice(!) for
determining whether it's applicable for local conditions.
If there is sufficient interest I can build a kit of the tools we
developed for our needs. My preference is that if others see the
need we try to encourage Digital to produce or at least
informally adopt some tools. If somebody with Digital is listening
and can clue me in on the plans for future patch delivery,
I for one would appreciate knowing it (so I know whether to
wait or enhance local procedures). I have heard rumors of Digital
planning to offer a patch service like this for customers, but
as yet those in Digital I've asked have been unable to answer.
If somebody tells me something I'm not supposed to summarize,
please identify that (otherwise I will).
Kurt Carlson, University of Alaska, (907)474-6266, sxkac_at_alaska.edu
(opinions, as always, are my own)
With humor intended:
"Digital has it now" [if you can find it]
"Whatever it takes" [if you can get their attention]
Received on Tue Jul 02 1996 - 00:44:03 NZST