Skip site navigation (1)Skip section navigation (2)
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>