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.<\/p>\n
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<\/tt> 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.<\/p>\n
Turns out Compress::Zlib was too old<\/a>. Well, not the system provided Compress::Zlib<\/tt>, but the Zimbra provided Compress::Zlib<\/tt>. 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.<\/p>\n 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<\/tt>. 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 :)<\/p>\n 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: Specifying the Perl PATH, also didn’t help. The forums mentioned just installing from cpan<\/tt>, Scalar::Util<\/tt> and letting the install progress. It still failed.<\/p>\n I thought I’d try a clean<\/strong> 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.<\/p>\n For fun reading, check out their forums: [SOLVED] Big Fubar on 5 FOSS GA Upgrade<\/a> (how was it solved?), Upgrade 4.5.7 -> 5.0 GA Failed<\/a>, centos4 upgrade to 5.0 errors<\/a>. I’m sure this magical list can go on and on. All purported solutions<\/em> generally, do not work.<\/p>\n Moral of the story? Even with backups, don’t try upgrading Zimbra on a production box. Be prepared to cry, a lot.<\/p>\n Technorati Tags: zimbra<\/a>, zimbra collaboration suite<\/a>, zcs<\/a>, zcs5<\/a>, qa<\/a>, ga<\/a>, upgrades<\/a><\/p>\n
\nUpdating from 5.0.0_RC3
\n5 is only avaliable with the XS version at \/opt\/zimbra\/zimbramon\/lib\/IO\/Socket\/SSL.pm line 30
\nBEGIN failed--compilation aborted at \/opt\/zimbra\/zimbramon\/lib\/IO\/Socket\/SSL.pm line 30, <DBCONFIG> line 21.
\nCompilation failed in require at \/opt\/zimbra\/zimbramon\/lib\/Net\/LDAP.pm line 970, <DBCONFIG> line 21.
\n<\/tt>
\nThis has largely got to do with the RHEL4 supplied Perl, as referenced by zimbra bug #22466<\/a>. 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<\/tt> (and was newer than the version on the system). Verified that Zimbra saw it too – check out .bashrc<\/tt> in \/opt\/zimbra<\/tt> (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.<\/p>\nShare this:<\/h3>