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 /usr/local/etc. 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. _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
