Migrating to and using Scalix 10

Last week this post on my local Linux user group got me rethinking email servers. The last time I did this was about six months ago when I made the move away from Hula onto Zimbra. At the time I looked at Scalix 9 but was deterred by its need for X-Windows during the install process and the overwhealming amount of installation documentation that came with the 100+mb download. I decided to go with Zimbra because it offered a text-based installer and some very nice looking UI features on the webmail client.

Unfortunately over time I have become tired of Zimbra for a number of reasons:

• The installation essentially takes over the host operating environment and installs its own version of popular open source applications like MySQL and Apache. Consequently keeping up with security patches involves upgrading the entire mail system which is no straightforward task.
• Zimbra is very resource intensive and takes what seems like forever to initally load and shutdown. This seems to mainly revolve around their management tools which store all configuration information in an LDAP database and dynamically build the traditional configuration text files on loading.
• Because most configuration information is stored in the LDAP datasource making configuration tweaks by editing the traditional text cofiguration files is not possible. Instead you must read through the Zimbra administration documentation to identify LDAP attributes to tweak in order to achieve the intended output. This is frustrating and not very transparent when things go wrong.
• The webmail interface is slow to operate and load (especially for dial-up/slow DSL users). After about three months I disabled the webmail interface and began using Roundcube's php IMAP frontend. There was a loss of functionality but at least performance was smooth on any connection.
• Because of the way Zimbra sets up its own services it is hard to integrate it successfully into an existing environment. I only have one IP address and port 80/443 is forwarded through to my LAMP server. After a great deal of experimenting I could not get the LAMP server to natively host the Zimbra webmail client, instead I had to resort to using a nasty mod_proxy configuration (which probably attributed to the slowness for external users).
• Zimbra does not offer Outlook/iSync connectors for its open source users, in order to get access to these connectors you must pay many $$$ a year in licensing costs. In small installations this is just not cost-effective.

Scalix 10 on the other hand addresses many of the shortcomings I found in Scalix 9 and Zimbra.

• It ships with a console based installer which is a welcome sight. Rather than providing its own stack it integrates into your operating systems existing applications (Sendmail, Apache, Cyrus-SASL and even Java if you want). This makes keeping your server up to date with the latest security patches a lot easier and upgrading to the latest and greatest Scalix release less of a concern.
• The webmail interface is based entirely in Java (running in Tomcat) and can be easily setup to be accessed from an external web-server (such as a dedicated LAMP box) using mod_jk.
  Scalix even in the free Community Edition version offers 25 free Outlook Connector licenses which makes it practical for use within small businesses.
• Rather than storing all configuration data in an LDAP datasource most configuration occurs in the standard text files for the system with a little bit of tweaking taking place in the /var/opt/scalix/ directory. This makes tweaking a lot easier as information found on the Web can be directly applied to Scalix.
• There seems to be a great deal of support available for Scalix ranging from the comprehensive bundled documentation and Knowledge Base through to the Community Forums and Wiki. Between those four sources of information I haven't yet found a problem that has not been able to be resolve.
  

Installation

I installed Scalix on a virtual Xen instance which contained a minimum install of SUSE 10. After accepting the license agreement the installer ran through a system and dependency check. At this point it returned a nice list of changes I needed to make to the system before installation could occur. This mainly revolved around the installation of some packages and a tweak of the /etc/hosts file in order to reduce the risk of confusion later on. It also gave me a warning about memory which would be easily solved later on by giving the Xen instance access to more server memory.

Once the dependencies were met Scalix happily installed. At the end of the process I was asked if I wished to install included versions of Java/Tomcat or use my own. I opted to use the bundled versions out of simplicity and on looking at the configuration files after the installation I can see it is a straightforward job if you wish to change your mind and use a different JVM or J2EE server once things have gone into production.

With Scalix, Java and Tomcat installed, the server reconfigured and the basic admin account setup all the services were started and the installer finished. It was the moment of truth so I fired up a web browser and made my way to the Scalix administration console.

Disabling mod_deflate because of Firefox 1.5 on OSX

At this point I came across my first issue and it was not really with Scalix. For some reason Firefox 1.5 for OSX on my Mac cannot handle content compressed with mod_deflate very well. Consequently the Scalix administration interface took forever to load. Switching to a different browser fixed this problem but as Firefox was my default browser I decided to disable mod_deflate for the time being.

This involved tweaking Scalix's Apache configuration files. In doing so I was pleasantly surprised to find that the Scalix installer had been very neat and courteous when making its modifications. I have seen a number of applications make horrendous system configuration changes but Scalix was a good server citizen. It had added three extra .conf files into /etc/apache2/conf.d and each were well named and commented. The installer had also modified the /etc/sysconfig/apache2 file to add the jk and deflate modules to Apache and this change too had been performed in an appropriate manner. I disabled the configuration file in /etc/apache2/conf.d associated with mod_deflate, restarted Apache and everything worked as expected in Firefox.

Adding user accounts and doing basic system maintenance

Using the web-based Scalix Administration Console (SAC) it is possible to perform all the basic mail administration tasks like adding/deleting users and monitoring mail queues. The console is designed to enable the management of multiple mail servers but the functionality available through it is not as extensive as other administration interfaces I have used. For example there are no options to edit what mail services (pop/imap/smtp/webmail) start on boot or modify details about a particular service (like port numbers, security settings, etc). Changes like this are possible but it requires console-based editing of configuration files. Personally I do not see this as a bad thing but if you are pro-GUI administrator making the switch from Exchange or Zimbra you will probably be disappointed.

When creating user accounts you can select whether the account is Premium (Outlook, IMAP, POP3), Standard (IMAP/POP3) or Internet (Webmail only) which is a nice touch. The Community Edition of Scalix allows only 25 Premium accounts, any more than that and you must upgrade to a paid-for version. Upgrading to a different version of Scalix is as simple as purchasing a license and entering its details into the SAC. This means a Scalix Community Edition server can be installed, tested and demoed at zero-cost and then painlessly upgraded if and when the server goes into full-scale production.

Migrating existing mail

Scalix provide a suite of tools for seamlessly migrating users from Exchange which is their core target audience. Unfortunately as I was not running Exchange I could not test these out. It seems like the standard way of migrating non-Exchange mail onto Scalix was through the manual creation of user accounts and then transfer of mail using the Perl-based imapsync tool. There maybe a smarter way of doing this but the Scalix documentation I found did not provide any hints.

Imapsync is a very functional piece of software but it is a little troublesome to setup if you are not used to Perl. It requires a number of libraries that by default are not installed with Perl but fortunately are all available in CPAN. Once the tool is running migration was straight-forward but it is important to set the --setinternaldates flag so that migrated mail retains the original arrival time (otherwise everything will get listed as turning up on the same day). The process does take a while and is fairly resource intensive, running the imapsync process from a third computer during a time when mail activity is low is recommended.

Using Scalix

With the user accounts and mail transferred it was now a case of using it. The Webmail interface works very well and is a lot snappier than Zimbra's. It is also relatively straightforward to configure Webmail to be routed through an intermediate server providing other Web services. Doing so requires some understanding of mod_jk which is a bit of a dark art though not as bad as regular expressions or mod_rewrite. Fortunately the installed Scalix configuration files are well commented and provide even mod_jk novices with enough insight that setting configurations like this up should not be too much of a problem.

There was a weird bug with Scalix and OSX Mail's Kerberos implementation. On setting up an IMAP account in Mail the application automatically sets itself to exchange passwords using Kerberos but this does not work (my guess is an incompatibility between the two implementations). This issue can be solved by changing the authentication encryption to MD5 in Mail. The weird thing is when setting up Scalix as an SMTP service Mail automatically sets encryption to MD5 and works quite happily without further user input.

Scalix with Outlook

I do not use Outlook but I was interested in trying out the Scalix Connector for Outlook. Setting up the connector was more than a simple case of pointing Outlook to Scalix and telling it that it was actually Exchange. The process required the installation of a Scalix Connector package on the Windows client and then migration of the standard Outlook account to a special Scalix-enabled version. Fortunately all of these tasks can be automated to enable network roll-out but I found the documentation just a little bit too light in places to feel really comfortable about what I was doing. Once setup the results were pretty impressive, 99% of all the Exchange functionality is available using the connector and it appeared to be very fast and stable.

Shortcomings for the non-technical administrator

By default Scalix does not ship with any anti-virus or anti-spam software. There are numerous pieces of documentation on how to set these things up but it revolves around making configuration file changes using the console. Here again Exchange administrators will not feel too comfortable and would probably prefer the Web-based check box functionality of Zimbra when it comes to setting up anti-spam and virus services. But if you are prepared to get your hands a little dirty the end-results will be a lot better, more flexible and most importantly when things go awry you will have a better understanding of what exactly is going on.

Conclusion

For those administrators out there that do not want to mess with complex console work Scalix is not for them. Installing and configuring Scalix will take more time than Exchange which will offset some of the licensing savings. However once it is up and running it is very stable and flexible system with all the power of Exchange without the licensing, security and reliability concerns that come with Microsoft software.