Date: Mon, 23 Apr 2012 21:56:10 +0100 From: Matthew Seaman <matthew@FreeBSD.org> To: prabhpal@digital-infotech.net Cc: freebsd-stable@FreeBSD.org Subject: Re: FreeBSD_9.0_Port_Upgrade Message-ID: <4F95C1EA.5020702@FreeBSD.org> In-Reply-To: <542d8a7ba1b614d2260f117a29e412cb.squirrel@mail.digital-infotech.net> References: <542d8a7ba1b614d2260f117a29e412cb.squirrel@mail.digital-infotech.net>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5D69907F154DC68810DC63EC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 n= o > issue, i should follow golden rule. don't fix if not broken. i personal= ly > 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= =2E > these are the things prevent me from upgrade. i am actually working wit= h > CentOS / Debian for past 7 years for an ISP. Just did the first setup w= ith > 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 --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --------------enig5D69907F154DC68810DC63EC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+VwfEACgkQ8Mjk52CukIxvPgCdFw5X1Jer6Ln6E/3dn65WE3Lu aKYAnRXg5e+wmT4JCeK1OFv8Jomh/q9f =2EU7 -----END PGP SIGNATURE----- --------------enig5D69907F154DC68810DC63EC--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F95C1EA.5020702>