From owner-freebsd-questions@FreeBSD.ORG Sun Nov 25 05:35:25 2012 Return-Path: <owner-freebsd-questions@FreeBSD.ORG> Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 190BF513 for <freebsd-questions@freebsd.org>; Sun, 25 Nov 2012 05:35:25 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from zoom.lafn.org (zoom.lafn.org [108.92.93.123]) by mx1.freebsd.org (Postfix) with ESMTP id C3B518FC0C for <freebsd-questions@freebsd.org>; Sun, 25 Nov 2012 05:35:24 +0000 (UTC) Received: from [10.0.1.4] (pool-98-112-217-228.lsanca.fios.verizon.net [98.112.217.228]) (authenticated bits=0) by zoom.lafn.org (8.14.3/8.14.2) with ESMTP id qAP5ZLec029270; Sat, 24 Nov 2012 21:35:22 -0800 (PST) (envelope-from bc979@lafn.org) Subject: Re: Is FreeBSD 9 Production Ready? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Doug Hardie <bc979@lafn.org> In-Reply-To: <50B1681E.8070700@tundraware.com> Date: Sat, 24 Nov 2012 21:35:21 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <449296BC-0DDA-4312-A1BA-CC394C4A8BCD@lafn.org> References: <50B0F80B.6090400@tundraware.com> <20121125065854.1198fee8@X220.ovitrap.com> <50B1681E.8070700@tundraware.com> To: Tim Daneliuk <tundra@tundraware.com> X-Mailer: Apple Mail (2.1283) X-Virus-Scanned: clamav-milter 0.97 at zoom.lafn.org X-Virus-Status: Clean Cc: FreeBSD Mailing List <freebsd-questions@freebsd.org> X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: User questions <freebsd-questions.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-questions>, <mailto:freebsd-questions-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-questions> List-Post: <mailto:freebsd-questions@freebsd.org> List-Help: <mailto:freebsd-questions-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-questions>, <mailto:freebsd-questions-request@freebsd.org?subject=subscribe> X-List-Received-Date: Sun, 25 Nov 2012 05:35:25 -0000 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.