Skip site navigation (1)Skip section navigation (2)
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: <http://docs.FreeBSD.org/cgi/mid.cgi?449296BC-0DDA-4312-A1BA-CC394C4A8BCD>