Dear FreeBSD Friends, i have FreeBSD 9.0 Stable Running the following roles for past four months. Everything is functioning smooth alright. I read that system should be upgraded frequently. i am afraid that if i upgrade something can break. i am planing to run it like that until FreeBSD 9.2 is out, perhaps two years before upgrade. i am not sure if this is a good idea. i seek your advice about the upgrade. ROLE: Postfix Mail Server With Virtual Users Support Using MySQL Database, Apache Web Server, Certificate Authority (CA). Squirrelmail, Postfix Admin, Maia MailGuard Postfix-Admin, SPF, Postgray Filter, spamassassin, Clamav. 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 Prabhpal Singh
On Apr 23, 2012, at 10:08 AM, Prabhpal S. Mavi wrote:> i have FreeBSD 9.0 Stable Running the following roles for past four > months. Everything is functioning smooth alright. I read that system > should be upgraded frequently. i am afraid that if i upgrade something can > break.It's a good idea to update when a relevant security advisory comes out for something you use (see portaudit and FreeBSD security announcements). Beyond that, it's up to you and your users to decide upon how much testing you need to do to validate changes. It's not expected that upgrading the FreeBSD OS or ports would break things, but software can get complicated and people make mistakes sometimes. In any event, if you have working backups, then you should always be able to restore back to a known-working condition. If you don't have backups, fix that before doing anything else. Regards, -- -Chuck
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 adviceThere 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
* Prabhpal S. Mavi wrote:> Dear FreeBSD Friends, > > i have FreeBSD 9.0 Stable Running the following roles for past four > months. Everything is functioning smooth alright. I read that system > should be upgraded frequently. i am afraid that if i upgrade something can > break. > > i am planing to run it like that until FreeBSD 9.2 is out, perhaps two > years before upgrade. i am not sure if this is a good idea. i seek your > advice about the upgrade. > > ROLE: Postfix Mail Server With Virtual Users Support Using MySQL Database, > Apache Web Server, Certificate Authority (CA). Squirrelmail, Postfix > Admin, Maia MailGuard Postfix-Admin, SPF, Postgray Filter, spamassassin, > Clamav. > [...]First you have to be aware that the stable tree in FBSD means something completly different than a release in Red Hat/CentOS land. Here stable is the stable branch which gets updates, bugfixes and new features. From this branch the next release is created. These updates and new features might not be as disruptive as in the development branch but still things change. So you might consider using a release branch instead, which only gets security and critical bugfixes. Critical really means critical here and not every bugfix around. In this regard a release branch is very stable :) So with stable you are really tracking a rolling release more like Debian testing or say a rolling release repository like the fasttrack repo in CentOS/Scientific Linux. While the release branch is more like staying on the same minor release in Red Hat. But the minor release in Red Hat gets far more updates even for not so serious bugs and sometimes even driver updates. The last part is AFAIU the reason that many people recomend the stable branch in FBSD, b/c you get bugfixes and some driver updates faster or even at all. If you would be on the release branch you would either have to switch to stable or wait for the next release branch to get these updates and fixes. As you are on stable i would suggest a test machine with the same setup, or at least a virtual machine with the same setup. Maybe a jail will do for you, else you could use something like virtualbox. Backups, always have backups and do some backups before doing something. Under Linux there is a nifty tool called etckeeper, it basically hooks into the package manager and tracks changes to /etc via version control. No idea if something like this is available under FBSD but you could roll your own ... If you use ZFS snapshots are easy and cheap, also there is basic Live Upgrade/Boot Environment support. http://anonsvn.h3q.com/projects/freebsd-patches/wiki/manageBE If you use ZFS, i really suggest you look into this one, b/c it allows you to switch your complete system around at will. Also, the updates can be tested on an exact production copy without affecting the running system. On the security side i would suggest some form of host basesd intrusion detection and some common sense hardening. Generally monitoring (alarming+capacity/trending) for a live service is a good idea, too. Accompanied by following the security advisories and using portaudit should be enough, i guess ... hth --lars
> * Prabhpal S. Mavi wrote: >> Dear FreeBSD Friends, >> >> i have FreeBSD 9.0 Stable Running the following roles for past four >> months. Everything is functioning smooth alright. I read that system >> should be upgraded frequently. i am afraid that if i upgrade something >> can >> break. >> >> i am planing to run it like that until FreeBSD 9.2 is out, perhaps two >> years before upgrade. i am not sure if this is a good idea. i seek your >> advice about the upgrade. >> >> ROLE: Postfix Mail Server With Virtual Users Support Using MySQL >> Database, >> Apache Web Server, Certificate Authority (CA). Squirrelmail, Postfix >> Admin, Maia MailGuard Postfix-Admin, SPF, Postgray Filter, >> spamassassin, >> Clamav. >> [...] > > First you have to be aware that the stable tree in FBSD means something > completly different than a release in Red Hat/CentOS land. > > Here stable is the stable branch which gets updates, bugfixes and new > features. From this branch the next release is created. > > These updates and new features might not be as disruptive as > in the development branch but still things change. > So you might consider using a release branch instead, which only gets > security and critical bugfixes. > > Critical really means critical here and not every bugfix around. > In this regard a release branch is very stable :) > > So with stable you are really tracking a rolling release more like > Debian testing or say a rolling release repository like the fasttrack > repo in CentOS/Scientific Linux. > > While the release branch is more like staying on the same minor release > in Red Hat. But the minor release in Red Hat gets far more updates even > for not so serious bugs and sometimes even driver updates. > > The last part is AFAIU the reason that many people recomend the stable > branch in FBSD, b/c you get bugfixes and some driver updates faster or > even at all. > > If you would be on the release branch you would either have to switch > to stable or wait for the next release branch to get these updates and > fixes. > > As you are on stable i would suggest a test machine with the same > setup, or at least a virtual machine with the same setup. Maybe a jail > will do for you, else you could use something like virtualbox. > > Backups, always have backups and do some backups before doing something. > Under Linux there is a nifty tool called etckeeper, it basically hooks > into the package manager and tracks changes to /etc via version control. > No idea if something like this is available under FBSD but you could > roll your own ... > > If you use ZFS snapshots are easy and cheap, also there is basic Live > Upgrade/Boot Environment support. > > http://anonsvn.h3q.com/projects/freebsd-patches/wiki/manageBE > > If you use ZFS, i really suggest you look into this one, b/c it allows > you to switch your complete system around at will. Also, the updates > can be tested on an exact production copy without affecting the running > system. > > On the security side i would suggest some form of host basesd intrusion > detection and some common sense hardening. > > Generally monitoring (alarming+capacity/trending) for a live service is > a good idea, too. > > Accompanied by following the security advisories and using portaudit > should > be enough, i guess ... > > hth > --lars > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >Dear All, First, thank you very much for your valuable advice time and efforts you did put to write the response. how can i exclude some ports from being update when using port manager utility? i mean which switch can i use or edit the file for exclude. Thanks / Regards Thanks / Regards Prabhpal