Installing Zimbra on Arch Linux

Zimbra is a modern groupware solution with an AJAX web interface. It combines email, contacts, shared calendar, tasks, instant messaging, spell checking, and online documents into a single product. The web interface is solid and rivals Gmail’s in terms of ease of use and intuitiveness. Email accounts are stored in LDAP and provide a global address list for everyone in your organization. Instant messaging is built-in through the web interface (but not turned on by default yet since it is still in beta). The spam protection is comprehensive and combines SpamAssassin and DSPAM. SpamAssassin combines many methods of detection while DSPAM is an adaptive filter. Anti-virus is built-in as well and included is ClamAV. Since AMaViS is being used it can be reconfigured use any anti-virus of your choice. It can be made to work with Microsoft Outlook and Apple Mail through proprietary connectors. The worst part about the whole thing is that it is a Java application which uses a lot of RAM.

Many different 32-bit operating systems are naively supported (RHEL4/5, Fedora Core 7, Debian 4, MacOS 10.4/10.5, OpenSUSE 10.2, SUSE Linux Enterprise Server 10 and Ubuntu 6.04/8.04) and a few 64-bit systems too (RHEL4/5, SUSE Linux Enterprise Server 10 and Ubuntu 6.04/8.04). I decided to install an existing package and rebuild anything that wouldn’t work out of the box. I figured it would be the easiest way without having to build from source. Though it does seem rather hackish to do…it works.

It turns out, the only problems I ran into were with the Perl modules. There were of course some shared libraries that were missing or in different locations but that was easy enough to fix. There were a couple differences in command behavior (crontab, su) and file permissions which had to be fixed. To get the file permissions correct I installed Zimbra on CentOS 5 (x86_64) and immediately after the install completed I shut down Zimbra and saved the file permissions (I did have to change the ownership of /opt/zimbra/postfix/conf to zimbra). I wrote another Python script to create any directories/symlinks that didn’t exist and to set the permissions. There is also a Perl script that attempts to load every library needed so that you can easily tell which ones were missing. You might have additional packages to install since my installation is based on what packages were included with Slicehost’s image for Arch Linux (which by the way is x86_64). I haven’t tested this on a 32-bit machine yet. I don’t expect any major problems except the Perl modules.

The installation script is only for clean installs of Red Hat Enterprise Linux 5 Open Source Edition 5.0.14 GA Release (64bit x86) on Arch Linux (fully updated, x86_64). I haven’t tested anything else yet and I wouldn’t use this in a production environment without extensive testing. Upgrading may work but you probably want to try that in a virtual machine or on a different machine. It’s not to say that this won’t work for you, but I did a minimal amount of testing. I ran the Zimbra install on a fresh machine and once it completed I logged into the admin interface and made sure everything worked with out generating an error. I sent an email from my Gmail account to Zimbra and replied to it through the web interface (I’m not sure if I had anti-virus enabled). I pretty much left it alone long for several hours and came back to see if the stats generated in the admin interface. I checked my email again and saw that a few of the services said they went from stopped to running (but not vise-versa). I checked this against the logs and I found that this didn’t really happen (every status was running). I suspect this is related to running Zimbra with such a low amount of RAM. The only other thing I did for testing was to make sure that there was no Perl errors about missing Perl modules. I haven’t seen anything in my logs about any other errors either.

Now that my disclaimer is out of the way you can begin by downloading Zimbra and my install script for version 5.0.14. (see updates below for newer versions). Once Zimbra has finished downloading, extract it and then copy arch_install_5.0.14.tar.gz into that directory. Now extract my install script over Zimbra’s. Now we are going to install any dependencies needed for Zimbra.

pacman -Sy sudo libidn fetchmail gmp expat libldap libsasl libstdc++5 perl-archive-zip perl-authen-sasl perl-berkeleydb perl-convert-asn1 perl-date-calc perl-dbi perl-html-parser perl-dbd-mysql perl-io-stringy perl-net-dns perl-net-ssleay perl-yaml perlxml rpmextract termcap-compat

There are a few Perl modules that we need but aren’t available so we have to build them from CPAN.

modprobe ipv6 # You will get errors during the tests if you don't do this.
cpan

Choose “yes” to have cpan configure everything for you. Now that cpan is loaded, you’re going to install the modules. The Net::LDAPapi module will fail testing since it wants to connect to a real LDAP server. As long as the build completed successfully then you need to force the installation of the module.

install Compress::Raw::Zlib Convert::UUlib IO::Socket::INET6 Net::LDAPapi Socket6 Unix::Syslog

Once it gets to configuring the Net::LDAPapi module it will ask you the following questions. Accept the defaults except for the SASL include files.

Select your Development Kit:
  1.  OpenLDAP (default)
  2.  Mozilla
Choose: [1]
Location of LDAP include files: [/usr/include]
Location of LDAP library files: [/usr/lib]
Location of SASL include files if needed:  /usr/include # Enter this

When Net::LDAPapi starts testing the module just hit enter through everything unless you happen to have a LDAP server up and running.

Enter LDAP Server:
Enter port:
Enter Search Filter (ex. uid=abc123):
Enter LDAP Search Base (ex. o=Org, c=US):

Once everything has finished you will have to force the installation of Net::LDAPapi since the tests failed.

force install Net::LDAPapi

We are ready to begin installing Zimbra. You’ll notice I’ve added an install type option since Zimbra looks to see which RPMs you have (FOSS/Network Edition) by using the rpm command. The last option is needed since Zimbra expects you to install the package on the platform it was made for.

./install.sh --install-type foss --platform-override

You must answer yes to the following so that everything is installed. You can always turn off any services that you don’t actually use through the admin interface after the install completes.

Install zimbra-ldap [Y] y

Install zimbra-logger [Y] y

Install zimbra-mta [Y] y

Install zimbra-snmp [Y] y

Install zimbra-store [Y] y

Install zimbra-apache [Y] y

Install zimbra-spell [Y] y

Install zimbra-proxy [N] y

The installation should complete successfully and there shouldn’t be any errors at all. Once it is completed you’ll probably want to make sure that all of the required Perl modules are available by running.

./required_perl_modules.pl

Don’t worry if you get messages like this. The same thing happened on my CentOS box which I’ve been using Zimbra on for a while now.

Prototype mismatch: sub main::strftime ($\@;$) vs none at /usr/share/perl5/core_perl/Exporter.pm line 66, <DATA> line 409.
 at /usr/lib/perl5/core_perl/POSIX.pm line 26
Prototype mismatch: sub main::ctime ($;$) vs (;$) at /usr/share/perl5/core_perl/Exporter.pm line 66, <DATA> line 409.
 at ./required_perl_modules.pl line 65

If those are the only two errors you get then everything should be setup correctly. There is one last thing we have to correct manually. Postfix expects there to be a /etc/aliases and /etc/aliases.db. Well probably just the last one. You can also make a symlink if you would like.

cp /opt/zimbra/postfix/conf/aliases /etc/
/opt/zimbra/postfix/sbin/postalias /etc/aliases

As the final step, I restarted Zimbra to make sure everything came up without any errors.

/etc/rc.d/zimbra restart &
tail -f /opt/zimbra/startup.log

Host somedomain.com
        Stopping stats...Done
        Stopping mta...Done
        Stopping spell...Done
        Stopping snmp...Done
        Stopping archiving...Done
        Stopping antivirus...Done
        Stopping antispam...Done
        Stopping imapproxy...Done
        Stopping mailbox...Done
        Stopping logger...Done
        Stopping ldap...Done
Host somedomain.com
        Starting ldap...Done.
        Starting logger...Done.
        Starting mailbox...Done.
        Starting imapproxy...Done.
        Starting antispam...Done.
        Starting antivirus...Done.
        Starting snmp...Done.
        Starting spell...Done.
        Starting mta...Done.
        Starting stats...Done.

Now you can login to the admin interface and make any changes that you need. Don’t forget to add zimbra to your /etc/rc.conf if you want it to start on boot.

Update (May 02, 2009)

I finished testing this out on a i686 version of Arch Linux. I found a few bugs for both architectures and added another missing dependency (termcap-compat). I also ran across another problem since Slicehost configures certain things by default (or was a default in Arch 2007.02). Slicehost seems to allow all traffic for sshd via TCP wrappers but at home I only had a single host allowed. While viewing one of the admin screens I got an error and found out that it was the TCP wrapper that was blocking access to it.

Update (May 05, 2009)

Looks like Zimbra released a new version (5.0.16). I updated the installation script. I didn’t test this out on x86_64 and I don’t have an updated list of file permissions. You will need to install Zimbra in a CentOS 5/RHEL5 64-bit virtual machine. Then once the installation completes stop Zimbra and run zimbra_get_file_perms.py inside /opt/zimbra and save it to a file. You should edit the file and remove any references to 2009 (usually a file with a date) and you will need to remove the symlink that is in ./conf/ca. The symlink points to ca.pem and will cause an error during installation (it gets created during the install). I also didn’t realize the user zimbra was getting added to the postfix and tty groups which makes editing the owner on /opt/zimbra/postfix/conf directory unnecessary.

Update (May 13, 2009)

Looks like I missed a file that was suppose to be included in the updated installer. I also added 3 more files that had to be modified (cron related) so that it wouldn’t get permission denied errors when doing a df. I also fixed the modifications I made to /etc/sudoers since it was blindly adding them each time the installer ran instead of clearing out the old ones. I’ve been running Zimbra successfully for about a week now with out any major issues.

Update (May 29, 2009)

I missed another file (/etc/logrotate.d/zimbra). I’ve also modified it so that it sends a HUP to syslog-ng and not syslogd. There is another fix that I found today as well. You will need to edit the user zimbra’s crontab. There are two entries that are supposed to run on day 7 but cron complains failed user zimbra parsing 7. Just change them to any day of the week you like.