Date: Mon, 12 May 2003 15:20:32 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: Leroy/Admin/Manager <leroy@3dmasters.net> Cc: questions@freebsd.org Subject: Re: Upgrade or Install new version of freebsd for Sendmail 8.12.9 Message-ID: <20030512142032.GA30532@happy-idiot-talk.infracaninophile.co.uk> In-Reply-To: <000001c31854$5e90c010$0264a8c1@3dmdomain.local> References: <000001c31854$5e90c010$0264a8c1@3dmdomain.local>
next in thread | previous in thread | raw e-mail | index | archive | help
--82I3+IH0IqGh5yIs
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, May 12, 2003 at 12:01:52AM -0700, Leroy/Admin/Manager wrote:
> First i would like to say freebsd is the best server software i have ever
> used in my life time. Still to this day i am not sure how update a worki=
ng
> server with DNS and sendmail running with over 100 customers using the
> system.
I take it you aren't asking precisely about the standard mechanisms
for updating a FreeBSD system which are well documented on the
www.freebsd.org site or in many excellent websites and books readily
available all round the world? Rather that you are asking what
strategies you can employ to update software on a busy system with
minimal required downtime and minimal chance of anything going
horribly wrong.
If I'm wrong about that, then I'll refer you to the Handbook --
Chapter 21:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cutting-edge.=
html
which is a good starting point.
Now, on the deeper question of what strategies you can use to reduce
your risk to production systems:
i) Choose an appropriate base version of FreeBSD to work from.
That's pretty much got to be a -RELEASE branch for the sort of
application you're talking about. At the moment, I'd choose
4.8-RELEASE (RELENG_4_8_0) --- 5.x is not yet fit for purpose.
The -RELEASE branches were created specifically to address the
situation you're facing: important updates (usually security
related) that have to be applied without all the baggage of new
development work that goes into -STABLE or -CURRENT.
ii) Don't fall into the trap of thinking you can set up the system
and then ignore it while it works away happily for evermore. The
best way to ensure that you don't have problems when updating
systems is to keep doing it: updates in small jumps are a lot less
likely to go wrong, and having people available that have rehearsed
the procedures many times reduces the risks due to fat-finger
accidents. That's especially important when you have to upgrade
at short notice due to the discovery of a serious security flaw
--- something that happens rather more often than you might think.
Therefore you should make a regular maintenance schedule for your
important servers -- doesn't have to be particularly often: every
three or four months should be enough.
iii) On the theme of "practice, practice, practice!", it helps to
have spare kit available which is fairly similar to your
production equipment, but isn't usually performing a vital
customer-facing function in day to day use. These could nominally
be machines available for testing or as spares that could be
swapped in should the main machines fail. If you maintain a
parallel installation of the same software as on your servers,
then you can upgrade this and test things out before committing to
the important hardware. They would also be ideal for NFS
exporting /usr/obj or for building packages if your main machines
don't have the CPU cycles to spare for that.
iv) SysAdmin 101: never do anything you can't undo. Usually this
equates to making sure you have a good backup before attempting to
upgrade and that you can readily back out your changes by
restoring an older system on top of them should you need to.
Again, doing emergency restores from backup is easier if you've
done it before. I've heard of places where standard procedure on
receiving new equipment is to run a practice "recover an existing
system from backup tapes onto the new hardware" after which the
system would probably be wiped clean and rebuilt from scratch for
its intended role.
v) The ideal "minimal service interruption" method of updating,
is, as you've mentioned below, to build the updated system on
another machine and swap it in wholesale for the original. Not
only does this let you do all the testing you need off-line, but
should things go wrong, it's trivial to switch back to the
original machine. Even better is if you're running load-balanced
over multiple servers when you can introduce a new machine or
remove an old one without any visible customer impact at all.
> What i question is: Do i have to upgrade my version of freebsd to complie
> the new version of sendmail 8.12.9? or can i patch my old complier? If so
> what are the commands to do this patching? Or what are the commands to
> update fully working system to a new version of freebsd?
That depends: is your goal specifically to run sendmail-8.12.9? Or is
it rather to switch to a version of sendmail that is immune to the
flaws detailed in
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-03%3A07.sendma=
il.asc ?
If it's the former, and you're running a sufficiently old version of
FreeBSD that sendmail-8.12.9 isn't part of the base system, then look
into installing one of the mail/sendmail ports --- although there is
no guarrantee that the ports will compile on an older FreeBSD version.
If it's the latter, then following the instructions on patching the
system in part V) of the security advisory will get you all patched up
and ready in a brace of shakes. You shouldn't need to update the
system compiler to do that.
As for updating the whole system: it boils down to:
# cd /usr/src
# make update -or- cvsup -or- otherwise obtain an up-to-date
copy of the sources
# less UPDATING
# make buildworld buildkernel KERNCONF=3DFOO
# make installkernel KERNCONF=3DFOO
-- all of which can be done in multiuser mode and probably without
noticably impacting on customers --
# shutdown -r now
(Interrupt the reboot during the 10 second countdown, and boot to
single user..)
boot: boot -s
# fsck -p
# mount -a
# swapon -a
# cd /usr/src
# make installworld
# mergemaster
# reboot
With practice, you can easily do this whole single user part of the
update in under 15 minutes.
> In the passed i have just copied all my data off the server and reinstall=
ed
> DNS and Sendmail and disk quotas. Then copied all my DNS info and Sendmail
> settings back to the new server to get the job done.
As I said, if you have the hardware available and can afford the time,
then rebuilding the system onto a new machine and swapping that in is
a really good way to go about this sort of job.
Cheers,
Matthew
--=20
Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks
Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey Marlow
Tel: +44 1628 476614 Bucks., SL7 1TH UK
--82I3+IH0IqGh5yIs
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)
iD8DBQE+v62wdtESqEQa7a0RAg23AJ9594s1JLX5c1O2Z3AXlqPqvRw3PgCeNspY
yTe88QvMJNp263eyIQizHhc=
=fL6Y
-----END PGP SIGNATURE-----
--82I3+IH0IqGh5yIs--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030512142032.GA30532>