Upgrade Zimbra from 4 to 6



This article was copied from http://mojocode.com/content/zimbra-upgrade-saga-going-40-60


Zimbra Saga--Going from 4.0 to 6

[The author does not comment about the version of linux he was using, however there are issues with versions 4 through 4.5.10 versus versions 4.5.11 through 6.
For Fedora, Version 4.5.10 was set for Fedora Core 5.
Versions 4.5.11 and up run on Fedora 7.
I recommend using fedora 5 to get to version 4.5.11, however you may be able to get the older version 4s to run on Fedora 7 using the --override-platform option, I was able to do this with an older version of 4.5.x but haven't tried it with 4.0.x
When you are ready to go to 5 and above, tar the /opt/zimbra on the old server and switch to Fedora 7.
install zimbra 4.5.11 with the -s (software only) flag.
untar the zimbra backup from the old machine into /opt
Then re-set the file rights using /opt/zimbra/libexec/zmfixperms (as root)
Now continue with the upgrade up through version 6.
Once at version 6 you can tar the /opt/zimbra directroy again and move it to a newer linux.
Warning: when going from an older version of linux (indluding Fedora 7) to a new version of linux. Perl underwent some changes that affect the compiled libraries in zimbra. When moving zimbra from an older machine:
Install zimbra with the -s, untar the directory, then run the install again as though you were performing the upgrade so that the libraries get upgraded, otherwise you will get perl Perl_Istack)_sp_ptr errors.
Lee Lofgren 6/23/2010]

By steve - Posted on 15 November 2009




Recommended advice from Zimbra, I decided to do the upgrade in jumps:
4.0.5 > 4.5.0
4.5.0 > 4.5.11
4.5.11 > 5.0.20
5.0.20 > 6.0.2

The problems started with the first upgrade...

First thing I did, and my saving grace, was to backup the entire zimbra directory (this would allow me the fastest recovery should things (and they did) go wrong):

/etc/init.d/zimbra stop
tar cvf zimbra.4.0.5.tar /opt/zimbra > zimbra.4.0.5.log
/etc/init.d/zimbra start

I repeated this (using the current version number) each time, just before I started the next upgrade.
4.0.5 > 4.5.0

When I followed the rest of the directions, everything would start up OK, then fail right after attempting to import the saved settings from config.save. That would work, but then right after that, when it tried to stop the services, it would fail with a "Updated failed" error.

I looked at the upgrade log files in /tmp install.log.xxxx and zmsetup.log.xxxx, but they weren't too much help.

Turned out I had two issues that were messing me up.

1. The host name was not complete. The older installation didn't care as much about host settings, but 4.5 cares a lot. I fixed that in /etc/hosts and the internal DNS. Then I had to fix it by changing the configuration files as described here: http://wiki.zimbra.com/index.php?title=Zmsetservername

[I highly recommend setting up an internal dns server on this machine and pointing the domain and mx records back to it. It is absolutely necessary if your are upgrading off-line or running a test upgrade.
It is also necessary if you are behind a port-forwarding firewall. Zimbra 4.5 and newer tries to contact many of the ports through the public ip address and these won't have been forwarded.
Note: This DNS server is only for this machine, and maybe for computers on the same internal network. It should not be the master/slave dns servers that are used by the public internet. Lee Lofgren 6/23/2010]

2. The upgrade stomps all over the /opt/zimbra folder, which doesn't matter most of the time, but in this particular installation, the /opt folder was in a small volume and /var was in a large volume, so the original installation used a workaround with a symbolic link /opt/zimbra pointing to /var/opt/zimbra. This worked for running the old installation, but was a problem for the upgrade. It deleted the symbolic link and I ended up with files in /opt/zimbra and /var/opt/zimbra, so the upgrade couldn't continue.

Fortunately, I had enough room in /opt to restore from my tar file to /opt/zimbra (then I made sure the old installation would run again before continuing), then I fixed the host issues before attempting another upgrade.

That did the trick and I was able to get things running as 4.5.0.

I tested everything out with that configuration and everything seemed to be fine, so I moved on to the 4.5.11 upgrade.
4.5.0 > 4.5.11

First thing I found out was that I was missing the libstdc++5 package, so I got that from Ubuntu:

apt-get install libstdc++5

The installation then started to run, but was held up because there is a minimum requirement of 5gb needed on a volume before upgrade would run. I had 4gb, so I was close, but there wasn't much to clean out of that volume, just the OS and Zimbra.

I ended up clearing out the logger database and that freed up about 2gb: http://www.zimbra.com/forums/administrators/29461-how-reset-reinitialize...

That helped a lot and I was able to complete the upgrade.

At this point, it looked pretty good running 4.5.11, but an attempt to send a test message reported an error in the web interface.

To fix this, I had to fix the old entry in the MTA settings so that it was pointing to the correct host name. That, plus a restart of Zimbra, allowed messages to be sent.
4.5.11 > 5.0.20

First thing I found here was that there was a new requirement for the libltdl3 library, so a quick apt-get fixed that:

apt-get install libltdl3

While doing the upgrade, I did the database integrity check (highly recommended), and it started throwing errors like:

mysql.help_category
error : Table upgrade required. Please do "REPAIR TABLE `help_category`" to fix it!

Looking around, it seemed like I was going to have to do some manual repairs, but this article: http://wiki.zimbra.com/index.php?title=Issues_with_database_integrity reported that I didn't. I tried re-starting the install script and, sure enough, the repair had already been done.

The rest of the upgrade was uneventful.
5.0.20 > 6.0.2

At this point, I was out of time (I'd allocated 6 hours and had spent 8 hours), so I bailed on going to 6.0.2 after reading about some bugs in the interface and other issues. This will have to wait for a future date, but my mission was mostly accomplished.