Date: Sat, 24 Nov 2012 21:35:21 -0800 From: Doug Hardie <bc979@lafn.org> To: Tim Daneliuk <tundra@tundraware.com> Cc: FreeBSD Mailing List <freebsd-questions@freebsd.org> Subject: Re: Is FreeBSD 9 Production Ready? Message-ID: <449296BC-0DDA-4312-A1BA-CC394C4A8BCD@lafn.org> In-Reply-To: <50B1681E.8070700@tundraware.com> References: <50B0F80B.6090400@tundraware.com> <20121125065854.1198fee8@X220.ovitrap.com> <50B1681E.8070700@tundraware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 24 November 2012, at 16:36, Tim Daneliuk wrote: > On 11/24/2012 05:58 PM, Erich Dollansky wrote: >> Hi, >>=20 >> On Sat, 24 Nov 2012 10:38:35 -0600 >> Tim Daneliuk <tundra@tundraware.com> wrote: >>=20 >>> I am currently running FBSD 8.3-STABLE on a production server that >>> provides http, dns, smtp, and so on for a small domain. This is not >>> a high arrival rate environment but it does need to be rock solid >>> (which FBSD 4-8 have been). >>=20 >> why would you like to break a running system? >=20 > That's exactly what I don't want to do. >=20 >>>=20 >>> I am contemplating moving to the FBSD 9 family. Is this branch = ready >>=20 >> I would stay with 8.x until the end of its support and move only then >> to a new branch. It could be then 9.x or 10.y. I would then - but = only >> then - prefer the 10.y branch. >>=20 >> I retired my 7.4 only because of lightning strike this spring. >>=20 >> Robustness is my main goal here. Any change which brings only the = risk >> is avoided. >=20 > I used to take this approach. However, I discovered the pain of = fixing > a configuration that jumped several major releases was way higher than > tracking them each as they became stable. I did the 9.1-PRE upgrade = today > and - once the new system was compiled and ready to be installed - had > only very minor conversion issues. >=20 > In my case, the most painful part of conversion is the mail = infrastructure. The > server in question is the domain's mail server and it has a LOT of = moving > parts with custom configurations: sendmail, greylisting, mailscanner, = spam > assassin, mailman, SASL ... That is pretty much always what breaks. = Doing > smaller "leaps" tends to make this more tractable to control. I am in a similar situation. Reliability is more important than = anything else. I run similar mail configurations on one server, = although I use different machines for incoming and outgoing mail. Jumps = across versions have been more difficult. I have kept records of the = steps I used for each upgrade and theose help me prepare for the next = one. I am in the middle of jumping from 7.2 to 9.1. One machine is = completely converted and working just fine. I had reliability problems = with 9.0. It kept rebooting or crashing every few days. I am on = 9.1-RC2 at the moment and its been up and working for 34 days now. I = will upgrade it to 9.1 when its released. This one had to be upgraded = early because it was new hardware. The old machine completely died. I = have another server also running 9.1-RC2 but it is not moved into = production yet. It is primarily a news server and has a large news = cache that has to be moved. I am waiting for 9.1 for that. On some of my test machines I have found that 9.1 is the first release = to support the built-in wireless NICs. The "service" command is really = helpful. I frequently can't remember which service is in etc and which = in /usr/local/etc. =20 The largest problem I encountered in the upgrade was the disk structure. = My disks were setup when using FreeBSD 3.5/3.7. As a result, the root = partition is way too small today. I was able to shoe horn 7.2 in by = deleting the kernel symbol files while they were being installed. = 9.0/9.1 just didn't fit at all. Restructuring the disks is a time = consuming job and fairly error prone in getting everything back that is = needed to run production. There is also the issue that the default = formatting uses SU+J which is not compatible with dump live filesystems. = Now I am going to have to find the time to bring the systems down to = remove journaling with no one on-site who has a clue what they are = doing. I currently have 9.1-RCx running on 5 systems and have not had any = stability issues with it. One system is in production but the others = are lightly used. One of them is a 200 MHz machine with either 32 Meg = or 64 Meg memory. It seems to be faster then when it ran 8.2 but I = haven't actually done any measurements.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?449296BC-0DDA-4312-A1BA-CC394C4A8BCD>