I took the opportunity today evening to get myself upgraded (from 4.5.3_GA_733) to the latest (5.0.0_GA_1869) open source version of Zimbra – ZCS 5.0 GA. The database migration took about the longest, mainly due to some schema changes. Lots of starts and stops to the database. Its now running MySQL 5.0.45 Community.
What prompted the upgrade? A few days ago, I got a bunch of new packages, and rebooted the server (new kernel). To my dismay, Zimbra started to have issues – amavisd wouldn’t start. This meant that there was a large amount of mail, sitting in the queue, not being delivered. Things you don’t normally check for, immediately, anyway.
Turns out Compress::Zlib was too old. Well, not the system provided Compress::Zlib, but the Zimbra provided Compress::Zlib. Kind of annoying when there are two packages of software, sitting on your system, right? However, the benefits of having an easy-to-administer and use mail system, somehow I think outstrips all the pain associated.
I found the web interface in ZCS 4.5.3 to be a bit limited, even when logged in as an administrator. There was absolutely no way to restart, failed services. For this, I actually needed to login via SSH, and use zmcontrol. Running SSH on a non-standard port, and not having your laptop nearby (or remembering the non-standard port) can allow you to have some fun :)
So after fixing ZCS 4.5.3, and realising that it had some gaping holes, I decided to upgrade. The upgrade process went on pretty smoothly, till I saw:
Updating from 5.0.0_RC3
5 is only avaliable with the XS version at /opt/zimbra/zimbramon/lib/IO/Socket/SSL.pm line 30
BEGIN failed--compilation aborted at /opt/zimbra/zimbramon/lib/IO/Socket/SSL.pm line 30, <DBCONFIG> line 21.
Compilation failed in require at /opt/zimbra/zimbramon/lib/Net/LDAP.pm line 970, <DBCONFIG> line 21.
This has largely got to do with the RHEL4 supplied Perl, as referenced by zimbra bug #22466. However, it seems that it was fixed in 5.0.0_GA_1809. Problem still seems to be around in 5.0.0_GA_1869. Verified that it existed – /opt/zimbra/zimbramon/lib/i386-linux-thread-multi/Scalar/Util.pm (and was newer than the version on the system). Verified that Zimbra saw it too – check out .bashrc in /opt/zimbra (the home directory for the zimbra user) for the various PATHs that Zimbra sees/requires. However, I was running this install, not as the zimbra user, so the Perl PATHs had to be specified.
Specifying the Perl PATH, also didn’t help. The forums mentioned just installing from cpan, Scalar::Util and letting the install progress. It still failed.
I thought I’d try a clean install. By golly, it failed on RHEL4. An upgrade of a clean install from ZCS 4.5.10 also failed. I’m almost convinced that Zimbra spent very little time QA’ing ZCS on RHEL4. Sure, RHEL5 probably works a charm, but the drive of enterprise software is not upgrading the OS too often. This is where I can so see, FreeBSD succeeding – pity there isn’t an official Zimbra/FreeBSD port.
For fun reading, check out their forums: [SOLVED] Big Fubar on 5 FOSS GA Upgrade (how was it solved?), Upgrade 4.5.7 -> 5.0 GA Failed, centos4 upgrade to 5.0 errors. I’m sure this magical list can go on and on. All purported solutions generally, do not work.
Moral of the story? Even with backups, don’t try upgrading Zimbra on a production box. Be prepared to cry, a lot.
Technorati Tags: zimbra, zimbra collaboration suite, zcs, zcs5, qa, ga, upgrades