Get On, Clip In, Fall Off

SuSE OpenExchange

I'm currently investigating SuSE's OpenExchange groupware doodad at work - the idea is that it does everything (or approximately everything, anyway) that MS Exchange Server does, but without the trouble, ignominy and outright shame that comes from having to use Exchange. While SuSE are keen to sell it as a 'black box' that once installed takes care of all your mail and groupware needs, there's a lot more to it than an install-and-forget product.

You can install it by simply booting from CD, taking the defaults and plugging in things like your domain name if you just want an out-of-the-box mail server with groupware, but it's also possible to go much further as underneath that it's a fully functional Linux box running a slightly cut-down version of SuSE Enterprise Linux.

I installed OpenExchange Server 4.1 out of the box. After a couple of slightly obscure problems that were down to the specific hardware RAID controller the test system used, it came up in a working state and didn't need much fiddling to bring it into service as a local mail machine, albeit one with only one user so far (i.e. me). Simply point a web browser at the machine, log in with the admin password you specified during installation and you're running. Impressively simple given the complexity of the system, but for the interested geek that's just the beginning. Log into the machine at the console or ssh into it and you're off and running.

Underneath the slick interface is a collection of well-known open source and therefore extremely hackable (in the good sense, that is) software. Tomcat and Apache handle HTTP and servlets, user mail is handled by the excellent Cyrus IMAP daemon, and the back-end database that holds most of the groupware data and other stuff is PostgreSQL. User data and various other bits and pieces live in OpenLDAP, and it even has Tobi Oetiker's superb RRDTool buried in there to provide graphs of various system stats in the web interface. The base OS is SuSE Enterprise Linux. SuSE have done a superb job here - from the point of view of the end user, or even of the administrator in many cases, there's no need to worry about what's going on at the OS level because the system's almost completely configurable via the web-based admin interface.

If you want to look underneath all that and tear the system to bits, though, there's nothing to stop you so long as you're careful. I'm currently working on making the black-box install we have of SLOX on the test machine integrate with the rest of our systems for administrative purposes - this includes adding things like sudo and cfengine to make it behave in the same way as the rest of our UNIX and Linux machines and arranging NFS mounts for sysadmin's home directories.

This approach to design paid off for me earlier today when we ran into a problem - the SLOX system would bounce mail to users @ourdomain.ac.uk who didn't have a SLOX account (which as it's only a testbed, that's nearly all of them) because by default it assumes that it's canonical for the domain it's put in. This is a reasonable design decision, given that most sites only have one mail system, but for us it was a problem. The problem was easily solved, though, by setting up a copy of our central aliases file (which has about 250,000 entries in it) for consultation by Postfix on the SLOX box. This provided a fallthrough (it's consulted after the machine's local aliases and the user list) which means that mail to unqualified usernames or to usernames@ourdomain.ac.uk which don't exist on the SLOX box get delivered correctly via the core MTA machine. I don't even want to know how we'd have gone about fixing this problem with Exchange, but as the guts of the system are so open in SLOX that it was a piece of cake to make this kind of somewhat non-standard but critical change.

We're planning on doing more stuff with SLOX here if all goes well with the testing, and more stuff on the subject will doubtlessly appear here in the future.

OpenExchange is often overlooked because as a boxed product it's not free as in beer (the groupware backend is proprietary software, and that's essentially what needs to be licensed). As much as this may offend OSS purists, it's an extremely functional product which could help save you from having to run Exchange just to provide calendaring for Outlook users, a function which a lot of workplaces are considering increasingly critical. And better than that, you'll be providing groupware with far more stability, configurability and tunability than, uh, the system's main competitor.

Posted by mpk at February 12, 2004 5:55 PM | TrackBack