On 24 November 2012, at 16:36, Tim Daneliuk wrote:

> On 11/24/2012 05:58 PM, Erich Dollansky wrote:
>> Hi,
>> On Sat, 24 Nov 2012 10:38:35 -0600
>> Tim Daneliuk <tun...@tundraware.com> wrote:
>>> 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).
>> why would you like to break a running system?
> That's exactly what I don't want to do.
>>> I am contemplating moving to the FBSD 9 family.  Is this branch ready
>> 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.
>> I retired my 7.4 only because of lightning strike this spring.
>> Robustness is my main goal here. Any change which brings only the risk
>> is avoided.
> 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.
> 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 

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 

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.

freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Reply via email to