The UCLA Mathematics Department needs to share event calendars and contact
lists (department directory) among staff members, as well as personal task
lists and possibly generic notes. The software that can do this is called a
Personal Information Manager Suite (PIM). It involves both a
department-wide server and client software to be used by each staff member.
A number of issues surround the choice and installation of a PIM suite.
Our department is covered by the Family Educational Records Privacy Act (FERPA), which means that PIM objects potentially could contain confidential data. As the known cloud vendors do not indemnify us for a loss of confidentiality, we need to run our own server. A medical operation would have similar issues under the Health Insurance Portability and Accountability Act (HIPAA).
For reasons of expense, adaptability to our needs, skills of support personnel, and politics, we require open source software (OSS).
We have a fully functioning Information Technology (IT) infrastructure. Software that takes it over and revamps it is not welcome, if only because converting to the replacement infrastructure system (even if it's an improvement) is risky and requires a lot of IT support effort, and we want to make this effort on our own schedule and terms.
As our people need to share PIM objects, this implies network access, inevitably extending to the global Internet. Software that runs only on the local host is not sufficient for us, and a limitation to the local LAN (for security reasons) would be troublesome.
User training is difficult, particularly for the more elderly users. The more existing software works the same as before, the better we and our users like it.
Before starting to hunt for packages I developed a design for an ideal PIM suite as seen by me.
We have investigated several PIM suites. (List of suites investgated and sources.) To summarize the results:
The ideal is to make Zimbra work in our environment, because there are political benefits from federating with our division, which has deployed this PIM suite as an alternative and political counterweight to Microsoft Exchange. But given its philosophy of taking over your whole system, I'm nervous about being able to accomplish this. The biggest attraction of Zimbra is its engine for indexing and searching stored mail; this is Apache's Lucene. Of course, if we adopt Zimbra the mail vanishes into the maw of the proprietary beast. According to co-workers, Thunderbird has a good mail indexer also (I can't identify the package by name); in other words, we don't have to install Zimbra to get an indexer.
Experiences installing Zimbra
As a second choice, we should seriously investigate the Kolab server and make it work with Horde. We should find out why our users aren't using what we provide, and if there are configuration or training issues, we should address them. Assuming Kolab can be made to work, our users can also get to it via KDE's Kontact; KDE is quite popular in our department. Unfortunately Kolab turns out to have the same kinds of problems as Zimbra but on a smaller scale: it runs in a quasi-pseudo-virtual machine and so does not actually take over your whole system infrastructure, but integration issues have been just about as extensive as for Zimbra. Likely I could get Kolab working eventually, but it's turned into an unreasonable time sink, so I'm proceeding to the third choice.
Experiences installing Kolab
The third choice is Ximian Evolution. This is a
semi-proprietary product for PIM and e-mail. It was purchased several years
ago by Novell and was given corporate-level support. The key parts are now
under GPL, and may always have been thus, and Evolution has been adopted as the
official PIM suite for Gnome. Mail reading is a major element of
Evolution, similar to the relation between Thunderbird and Lightning.
According to the documentation, Evolution does not include a server engine, but
it can utilize an external CalDAV server (as well as integration with Novell's
Groupwise and Microsoft Exchange).
The lack of an included server leaves us with the need to keep looking. Users who want to try Evolution may do so. But my experience was not good: Evolution was not able to open Mathnet's CalDAV calendar (installed for testing) and it got several segfaults. I think it needs to evolve some more.
Upon reading the documentation, I think Citadel looks a little more palatable than I originally thought. It does have the disadvantage that mail is stored in a Berkeley DBM database (rather than directly accessible flat files), but it has native host OS integration for authorization, and has important features which I want: the calendar server, IMAP, XMPP, and a server-side web interface. The mail indexer, if used, is libsieve.
With Citadel the experience has beenwhat features are not perfect in our environment, while the others could not be made to work in the time available. Here are my reports about installing and evaluating Citadel.
Unfortunately Citadel is very promising but has a few design features that prevent use of big sections of the code. I'm very disappointed that Citadel didn't work out since potentially it could have solved several of our service problems in one integrated package.
My next focus was on calendar servers that implement the CalDAV protocol (follow the link for a list). I investigated the following ones:
This may possibly be a complete server, but the support for authentication is not clear.
Experience trying this out which abruptly hit a stone wall.
Of the CalDAV servers, SOGo appears to be the most likely. Its attractive features are:
(The following conclusion was written about Citadel, but further evaluation has led me to give up on that. But most of the same issues pertain to SOGo.) Definitely it is worth setting up a SOGo server and mocking up the PIM object structure. Particular points to work on:
Individual PIM object collections.
Shared calendar event and contact lists. Access control.
Shared calendar: tested, works.
Compose mail on Webcit, attach a vCard or other PIM object, send it, and see if the recipient can import the PIM object. Also try this on Thunderbird with Lightning (for calendar events).
Stress test to see how badly the iCalendar protocol is subject to race conditions.
Learn and document how to set up an iPhone or an Android hand computer to use our PIM server.
Verify that the iPhone or Android mail readers interoperate with IMAP as spoken by Citadel.
Find out how a user can download PIM objects or collections to the client host, and how to upload them again. Similarly for entire mailboxes.
Figure out how to do backups on Citadel, particularly of individual users' mailboxes, and how to restore them. A generic IMAP utility likely will be useful here.
Find out what we're supposed to do with PIM objects of expired users. Review the general issue of object disposal after an expiration time.
According to the documentation, Citadel has a garbage collection process that runs typically once a day. If you're using host OS integration, if a user's account disappears on the host, his PIM objects and mail are collected painlessly.
Rooms such as mailboxes can be configured individually or by inheritance to toss messages more than so many days old, or to keep them until explicitly removed.
SOGo also has a cleanup utility, which I need to learn about and get working.
Look at the Mathematics Computing Group (MCG) workflow and see how it could be made easier with XMPP instant messages. Similarly for office staff and faculty. (I guess we won't be using Citadel for this, but ejabber or another server could still be useful.)
Currently a test SOGo server is running on Simba (HTTPS). MCG members are welcome to check it out; use your Mathnet loginID and password. From home, VPN is required to get to Simba.