FreeBSD_9.0_Port_Upgrade

[Matthew Seaman]

On 23/04/2012 18:08, Prabhpal S. Mavi wrote:
> i want to know the advice from experts, what is best? is it really
> important to update the system to new ports available. Or once i have no
> issue, i should follow golden rule. don't fix if not broken. i personally
> want my system to update at all time and exclude critical ports. i read
> that sometimes serious problems can occur after Perl upgrade in FreeBSD.
> these are the things prevent me from upgrade. i am actually working with
> CentOS / Debian for past 7 years for an ISP. Just did the first setup with
> FreeBSD. please advice

There isn't a one-size-fits-all best answer to this sort of question.
How often you update, how much down time you are willing to tolerate,
how much effort you are willing to put in to trade off against the risk
of outage depends on the particulars of your system and your user-base.

It's a balance of various risks against effort.

Not updating at all means the system should just keep running as it is
now (assuming there aren't any great variations in usage levels or so
forth.)  But if any security vulnerabilities are found then you will be
vulnerable to system compromise.

However, security problems are generally few and far between.  If you
only upgrade applications exposed to security problems, you run the risk
that the updated version will have got out of synch with the rest of
your installed application base.  This is a common cause of problems in
the ports.

So you update the application with the security problem, plus anything
it depends on, and any other application that depends on something that
got updated.  That's more like a viable strategy, except you now have to
put some effort into working out exactly what needs to be updated.

It is also the case that doing infrequent updates involving many
applications and over large deltas in version numbers has pretty much
the highest risk of something going wrong.

So to avoid that, you track updates as they go into ports, and keep
everything pretty much up to date.  This means that updates tend to
happen to one application at a time (so generally a smaller chunk of
work, and easier to deal with), and you go from one version to the next
(so less chance of breakage because of application changes).  Also, you
aren't doing updates as an emergency response to security
vulnerabilities all the time, so you can plan and schedule your updates
in advance.  Plus you will be doing updates regularly, so the process
will become familiar to you and practice makes mistakes much less likely.

Except that now you're following exactly the strategy that so terrifies
people at first sight: you track new releases of software as they come
out, which surely leaves you vulnerable to regressions in that software.
 Well, yes.  But regressions in such popular applications as apache,
mysql and postfix are very quickly discovered and fixed in the ports.
Also, those projects have very good developers working for them and good
testing regimes, so such regressions are rare in any case.

To ameliorate those risks, well, as part of your updating process, you
can update your ports tree, and then take maybe two weeks where you
watch the freebsd-ports@ mailing lists or various mailing lists specific
to your applications of interest and see if there are any reports of
trouble.  If it's all clear, then you can update with reasonable
confidence.  (Although I will state here that although this delay is a
good concept, in my experience it only very rarely proves to have been
necessary.)

In fact, probably the biggest risk when updating is that you, the admin,
makes a mistake.  Making updates into a routine, regular task helps.
But the biggest way you can save yourself from grief comes right out of
Sysadmin-101: *never do anything you cannot directly undo*.  This means:
always have a plan for being able to back-out your changes before you
start.  You can keep backup copies of the ports you are updating
(portmaster(8) does this automatically, although it doesn't have a
specific command to revert to a saved package; that you have to do
manually), or you can use filesystem snapshots (particularly good with
ZFS) or you can just rely on good old filesystem backups.

If you're running a particularly important system that really cannot
afford unscheduled outages, then really you want to have a development
server that you can practice the updates on and use for testing (plus
you can make package tarballs on the development server, which will cut
down the time needed to work on the live server).  Or you may have a hot
spare system, or you can split up a HA pair or many other means of
reducing the risks of something going sufficiently wrong that it affects
service.  Even if you can't afford spare hardware for a dev system, you
could use a jail on your live server to much the same effect.

	Cheers,

	Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20120423/3703650e/signature.pgp