Date: Sun, 8 Dec 2002 19:48:48 -0500 From: Chris BeHanna <chris@pennasoft.com> To: stable@freebsd.org Subject: Re: update strategies Message-ID: <200212081948.48217.chris@pennasoft.com> In-Reply-To: <20021208144552.GB269@number6.magda.ca> References: <867kelp9t9.fsf@number6.magda.ca> <2E37135F-0AB4-11D7-B2B7-003065A9024A@ish.com.au> <20021208144552.GB269@number6.magda.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 08 December 2002 09:45 am, David Magda wrote:
> > I'm new here, so I'm not telling you how to suck eggs. Perhaps there
> > are historical reasons for this hierarchy. But I want to make sure I do
> > the right thing. Is this the safest approach:
>
> [...]
>
> I'll let others comment on this procedure: I'm not experienced enough
> with admin'ing boxes yet to really say.
The safest approach:
1) On production servers, use the RELENG_4_x branch (currently,
x = 7). Deploy first on a test box that as nearly as possible
mimics your production environment. Beat on it until you are
comfortable with it, then deploy *that* *same* *build* on your
production hardware (e.g., export /usr/src and /usr/obj over
NFS, mount on the production box, and do the
installkernel/installworld/mergemaster thing).
Given modern hardware, a full buildworld cycle each time the
patchlevel is bumped is not onerous[1], especially if you kick
the build off when you leave at the end of the day--it's ready
for you the following morning. This is a "just in case there
are changes in a few places in the tree that interact"
anti-foot-shooting measure.
2) Workstations are more forgiving. Follow the -STABLE mailing
list. During a window of time in which no one has reported
serious bugs on any of the hardware you use, or with any of the
software you use, cvsup and do a build/install/mergemaster
cycle. If the workstation serves a critical purpose and can't
brook downtime from the occasional -STABLE hiccup, then track
the RELENG_4_x branch, just as you would for a server, and try
it out on a test box first, just as you would for a server.
3) In all cases, the following steps are prudent:
a) Make sure to back up /usr/src and /usr/obj *before* you cvsup,
so that you can put your system back to a known good state
if something goes really wrong.
b) Make sure to back up, at the least, /etc, /usr/local/etc,
and any critical data you have before updating--this
includes the contents of databases.
c) Prior to updating, copy your kernel config, LINT, and
GENERIC to (e.g.) YOURKERNEL.old, LINT.old, and GENERIC.old.
After the update, running diff -u on LINT and GENERIC will
clue you in to new options that you may or may not want to
apply to your kernel config.
d) When running cvsup, it is prudent to run it twice, with a
gap of five or ten minute between runs. That way, if your
first cvsup occurred in the middle of a large commit, the
second cvsup will pick up any files that the first missed.
This way, a critical system component with many changes
spanning many files won't end up in an intermediate state in
your local source tree. Note that if you see changes being
downloaded in your 2nd cvsup, you should wait five minutes
and then cvsup again. Repeat the cycle until cvsup doesn't
change any more files.
e) Read and obey /usr/src/UPDATING before and during your
upgrade--always.
f) Save the timestamp of your last cvsup. When reporting
problems, make sure you mention this timestamp in the
report--it is the identifier for the snapshot of the source
tree that you are running. Be sure you note the timezone of
the timestamp--if you do something like:
date >> cvsup.log
cvsup -g -L2 my_supfile 2>&1 | tee cvsup.out
date >> cvsup.log
Then the timezone will be your local timezone, so mention
it (by the by, CVS itself stores timestamps as GMT).
[1] On my 1.33 GHz Athlon w/256MB PC2100 ECC, and my source and object
trees living on a vinum-controlled two-disk RAID-0 stripeset (a
pair of old IBM 7200rpm 9GB U2W SCSI drives), I can do a buildworld
in less than 30 minutes. Currently, that build is I/O-bound. If
anyone has done a build with a similar CPU using a malloc disk,
I'd be interested in the results.
--
Chris BeHanna http://www.pennasoft.com
Principal Consultant
PennaSoft Corporation
chris@pennasoft.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200212081948.48217.chris>