Stephan A. Rickauer wrote:
Nick Holland schrieb:
There are a lot of measures to how the upgrade process works out. Here
are SOME:
1) Frequency (i.e., how often do you need to do upgrades)
2) Difficulty (how much human work is involved)
3) Ugency (when an upgrade is needed, how important is it that it
is done *NOW*)
4) Downtime (when you do the upgrade, do you need to do it at
3:00am, or can you do it during production hours?)
5) Flexibility (what cute tricks can you do to make the process simpler,
safer, easier, etc.)
I agree. Furthermore, one has to distinguish between upgrades of an
entire OS release level and patching a running system. The latter is not
This is somewhat related to what I wrote earlier -- the severity of
"upgrading an entire OS release level" is (with some subjectivity)
insignificant compared to what I have seen on other OSes. This is a
clear benefit of the short release cycle, and it would be a waste not to
use it, e.g. by upgrading only once a year. Consider upgrading an
"intrusive patch", i.e. something you might already be used to on other
OSes, except that it doesn't happen every month but every six months. I
say that, because if you'd choose to do the patching as I do (see Nick's
point #5), upgrading is pretty much the same work as patching, with only
a few extra steps.
The largest part of the procedure is explained in the release(8) man
page. To recapitulate, the steps required for upgrading OpenBSD manually are
0. Get the install media: Buy a CD, or download, or make your own
release(8) at the appropriate time on a local build box tracking
-current
1. Install and boot new kernel
2. Untar install sets
3. Update /etc and /dev
4. Reboot
This is quite similar to patching the way I do it, except that it's ok
to take a shortcut and /etc and /dev may be left alone:
0. Make a new -stable release(8)
1. Install new kernel (shortcut: it's ok not to reboot here)
2. Untar install sets
for x in <list of sets>; do tar xpfz $x -C /; done
3. Reboot
This release(8) stuff is the reason why I highly suggest to have some
support infrastructure -- a build machine in addition to test boxes.
I am using a few self-written scripts for making releases; bloaty sh
stuff from 1.5 years ago -- they work nicely, but aren't fit for wide
public release and probably in desperate need of a rewrite. Interested
parties may request them, though, and I will give them to anyone who can
convince me that (s)he doesn't actually need them (wrt release(8)
knowledge.) Anyways, with these scripts, that anyone could just as well
write for him- or herself, I start a screen and "come back later" -- two
hours later, give or take, I have nice -stable install sets that I can
deploy and a bootable install .iso image if I need it. This is lots of
work for the computer, and very little to do for me. I estimate some 10
minutes of actual human work, and during the course of following
-stable, even more things could be automated than what I currently do.
*patching* - only saying that since some posts seem to treat patching
and OS upgrade similarly).
They *are* really similar, see above. :-)
One main reason why companies are interested in 'enterprise products' of
vendors like Redhat and SuSE etc. is the five (!) year lifecycle (at
least with SuSE, don't know with RH). That means you buy your hardware,
install the OS, patch five years and toss the systems afterwards. That
As Henning@ is quoted from somewhere in another mail, he has some boxes
that were upgraded since OpenBSD 2.7. Those are from more than 5 years
ago, and since he even made it through the a.out->ELF change, I can't
think of anything that would prevent this from going on another 10 years
... well, except for utter and complete hardware destruction or those
boxes becoming too slow for their future purpose(s).
Moritz
