Paul Boddie's Free Software-related blog

I have recently had the inclination to evaluate Free Software groupware solutions in more detail, and perhaps the first that came to mind was Kolab: a long-running project that provides a range of groupware functions including e-mail, calendaring, address books, task management, and various other functions for a fairly wide range of organisation sizes. Of course, there are plenty of Free Software groupware projects offering complete and integrated solutions as well as individual components for use with existing infrastructure; the Debian Wiki page on groupware provides a fair (but probably incomplete) overview of the more interesting projects.

Installing and Configuring Kolab

Intrigued by accounts that Kolab is fairly easy to install on Debian Wheezy – the latest stable release of the Debian GNU/Linux software distribution – I set out to investigate, making use of my own tools to set up a User Mode Linux environment in which I could install the software. Initially, I tried to re-use an existing virtual environment, but a quick attempt to configure the software using the setup-kolab program was not successful, and a brief excursion via the #kolab IRC channel (on freenode), indicated that I might be better off starting with a completely fresh installation of Wheezy. Although I imagine it is possible to deal with the problems I encountered – setup-kolab did not like the presence of an existing LDAP server – the easiest way to troubleshoot is to start with a known configuration and see if things can be made to work from there.

Installation of Kolab 3.0 on Debian is fairly straightforward, as described both in the manual and more concisely in the blog article mentioned above (and also in older reports). The Kolab packages in Debian are set up to prefer the postfix packages to the apparent default of the exim4 packages and thus want to replace the latter. This might be a problem in some environments, and it may be possible to retain Exim for use with Kolab, but I haven’t investigated this. A somewhat undesirable feature of the currently available packages is that they are unsigned: Debian makes extensive use of package signatures to prevent tampering, and although it can be an annoyance to sign and publish packages and to publish the necessary keys for verification, hopefully Kolab will make its way into Debian as a collection of official packages once again.

Some Current Pitfalls

With a fresh system, setup-kolab seems fairly happy, and with the initial configuration performed it is possible to log into the administration interface, although it seems to be necessary to explicitly start the Apache server first. One strange problem with the Debian packages seems to be in the absence of a library file in the correct location, and this manifests itself in the administration interface as the absence of any way to add users. I fixed this for my system as follows:

ln -s /usr/lib/i386-linux-gnu/nss/libsoftokn3.so /usr/lib/libsoftokn3.so

(Unlike the message linked above describing this fix, I still use a machine with the i386 architecture, not the x86_64 architecture, and the underlying problem seems to be related to the way that libraries are now stored to permit support multiple architectures on the same computer.)

I also noticed that some Kolab component, at least after some administrative tasks have been performed, tries to communicate with the IMAP server unsuccessfully but persistently. To reset their relationship, the following seemed to be required:

service cyrus-imapd restart

Some other complaints emerged on the console about mailbox creation, perhaps due to some resources I created, but it is possible to verify the state of the mailboxes as follows:

kolab list-mailboxes

I noticed that no matter which resource type I specified, the type of created resources would always be “Beamer”.

This probably doesn’t matter so much for actual resource booking, but I imagine that there’s a problem here needing to be fixed. It is possible that the Debian packages suffer from the above problems but that these problems have since been fixed in the project’s repository and in subsequent non-Debian package or distribution releases; I haven’t verified this, however.

Fun With Administration

Administration is never really much fun, but the administrative interface seems to provide a reasonable way of adding users and resources, populating the different information stores with user and mailbox details.

With the packaging issues mentioned above all sorted out, users can be added in the users section:

And resources can be added in the resources section:

Given that Kolab is based on conventional services like LDAP directories, IMAP mailboxes, and so on, if you needed to integrate with existing infrastructure and accommodate existing user populations, you probably wouldn’t spend much time in the administrative interface, but it is nice to see that an interface exists for quick edits to the system.

What About the Users?

With some users set up, one might be interested in seeing things from their perspective. Out of the box, the Debian packages provide a Roundcube webmail interface:

On the inside, the interface is much like the Roundcube many people have come to know. For instance, the mail interface is more or less what you would expect. Here, the folders on the left are IMAP folders that are also available to IMAP clients, but to start with there obviously aren’t any mails to look at:

Amongst the usual view buttons at the top of the window, featuring the mail, address book and settings, we find additional buttons for the calendar and tasks. First, the address book:

Here, it seems to pick up other users added via the administrative interface. Meanwhile, the calendar interface is probably slightly more interesting to look at because it’s something that you don’t usually get in Roundcube:

The calendar widgets seem to be rather familiar and those who do more JavaScript programming than I do will probably be able to identify the project that pioneered them. Nevertheless, they seem to behave mostly as I would expect from having used them elsewhere on other sites and services. One strange thing is the date numbering above the days in the week view (“Mon 6-10” meaning “Monday 10th June”, for example) which I imagine could be customised somewhere, although I didn’t see a setting to do exactly that.

Fun With Events

Given the existence of the calendar in Roundcube, and given that calendaring interests me already, I decided to make an attempt at creating a new event, inviting a participant, and requesting a resource. Dragging an area in the calendar caused the event dialogue to appear:

The location field appears to be non-autocompleted free text, but it would be nice to have a menu of recognised locations or resources, and perhaps there is some kind of setting or extension to provide that. With the main details filled out, on I went to the participants tab:

Just like the mail interface in Roundcube, the calendar also supports address lookups and offers autocompletion of names. However, I found that autocompletion didn’t take place for resources, so I ended up having to invite resources by using their full e-mail addresses (which were defined previously in the administrative interface). For example, for the “Forest” resource, I had to specify resource--forest@example.com as a participant. Maybe this is also something that should be done another way, but I didn’t manage to figure it out.

Finding the availability of participants seems possible. Kolab does support the retention of free/busy information, so for those people making this information available to Kolab, their status should be visible in the user interface:

In principle, it should be possible for people to exchange free/busy information via e-mail and for the recipient to record this information and use it to schedule events, but I haven’t looked into whether Kolab or Roundcube support this at their respective levels. I found that in the availability view, it is possible to change the role of each participant by clicking on the icon next to their name, and this made it possible to give a resource the appropriate role. Again, if there were a better way of choosing a resource that I missed, maybe this wouldn’t be necessary.

With an event created and participants invited, Kolab manages to notify those participants, and to make things interesting I decided to configure Kontact in a KDE 4 environment (running in Debian Squeeze) to connect on behalf of the invited participant. Here is what that participant sees when they check their mail:

Although it is rather small in the above screenshot, Kontact shows a collection of links that allow the recipient to act on an incoming event notification. Here is a close-up:

For Kontact to be able to do this, it appears that the kdepim-groupware package is required, and indeed this functionality supports the iTIP technology mentioned above (here, in an invitation context instead of the free/busy context discussed above). It is important to understand that the open standards underpinning this workflow do not require that everyone have a login to a common server and manipulate information on that server directly: a critical feature of the iCalendar-related standards is that people are able to schedule events collaboratively without all being part of the same monolithic organisation and/or infrastructure. It is also interesting to see that where a recipient’s e-mail program cannot handle the workflow defined by iTIP, the message includes a link to the Roundcube webmail that can be used to signal a participant’s attendance or absence.

When a participant responds using one of the links provided in the message, the organiser gets a notification. Here, the Roundcube user gets to see a mail message telling them that the participant accepted the invitation:

Upon pressing the update button provided, the status of the event is updated in the calendar:

Here, the organiser is shown with a crown next to his name, the participant (using Kontact) has accepted the invitation to the event, and the resource has apparently been secured.

In Conclusion

There are obviously plenty of other experiments that could be performed here, as well as other features that could be explored. For instance, some more evaluation of the free/busy information, how local and remote users interact with it, and how well those with non-iTIP mail clients fare with over-the-Web notification of attendance or absence might be in order. Publishing calendars for over-the-Web consumption is also apparently supported, and it might be interesting to see how well Kolab supports the general “invite people you hardly know” event-planning paradigm that the likes of Doodle have been attempting to popularise.

It seems that Kolab at the very least supports basic calendar functionality in association with standards-compatible clients, and perhaps a brief investigation with Thunderbird (plus Lightning) and even more elementary mail and calendar clients might be informative. Since Kolab is Free Software, of course, the chances of resolving any shortcomings are increased for those willing and able to peruse and modify the code, and maybe I will take a closer look at that, too.

As noted above, calendaring and scheduling systems are already an interest of mine. The only problem now is that there’s just so much to look at and yet so little time to do so!