karen roach, 123RF

Offene Standards und Open Source sind das Dogma der Groupware Kolab. Die aktuelle Alpha der kommenden Version 3.1 erweitert mit den Protokolle Caldav und Carddav die Zahl der kompatiblen Clients immens: Bald sollen so Kolab-Daten auch auf I-OS, Mac OS X, Thunderbird und Evolution kommen.

Mit zunehmender Verbreitung mobiler Clients kommen Admins immer seltener darum herum, ihren Anwendern Remotezugriff auf Kalender und Adressdaten einzurichten. Trotz seiner Veranlagung als Open-Source- und Open-Standards-getriebene Groupware hat das einst vom Bundesamt für Sicherheit in der Informationstechnik (BSI) mitinitiierte Kolab [1] hierbei bislang wenig zu bieten: Nur die eigenen Clients (Kontact, das Webinterface Horde und später Roundcube, dazu proprietäre Outlook-Plugins) konnten die zentralen Kalender und Adressen nutzen. Mobilgeräte fanden nur über Microsofts Active-Sync-Protokoll oder (bis Kolab 3) übers veraltete Sync ML Kontakt zur quelloffenen Groupware.

Ab der anstehenden Version 3.1 bringt das Kolab-Team rund um die Schweizer Firma Kolab Systems auch die offenen Protokollstandards Caldav und Carddav für den Austausch von Terminen, Aufgaben und Kontakten in den Server: So lassen sich nun viele existierende Groupware-fähige Clients wie die Thunderbird-Extension Lightning, Evolution, OS-X-Anwendungen wie Apples I-Cal sowie I-OS- und Android-Systeme mit Kolab-Daten versorgen.

Damit das funktioniert, hat das Kolab-Team das Rad nicht neu erfunden, sondern integriert das bewährte PHP-Paket von Sabredav ([2], Abbildung 1), das den Webdav-Protokollstack als Server implementiert. Die damit in Kolab neu geschaffene Protokollschicht hört auf den Namen I-Rony [3] und ist ab der kommenden Version 3.1 fester Bestandteil des Groupwarepakets.

Abbildung 1: Auf der Webseite Mykolab.com bietet Kolab Systems einen Webdienst, der alle Funktionen der Kolab-Groupware beinhaltet. Im Bild der Filebrowser, den Sabredav bereitstellt

Eine komplette Testinstallation gelingt seit Kolab 3.0 schon mit ein bis zwei Tassen Kaffee und stellt keine großen Anforderungen mehr an den Admin. Das unter [4] Beschriebene gilt auch für die bei Redaktionsschluss vorliegende Alphaversion. Die Kolab-Entwickler empfehlen ein aktuelles Centos (am besten also 6.4) als Basis und fordern nur wenige Vorarbeiten: Ein FQDN ist nötig, SE Linux muss im Permissive-Modus laufen.

Nachdem der künftige Kolab-Administrator die drei RPMs aus Listing 1 installiert hat, setzt er mit »yum install kolab« komfortabel das gesamte Groupwarepaket auf. Dessen Konfiguration erledigt er mit dem Kommando »setup-kolab« , was unter anderem dabei hilft, die Admin-Passwörter der Dienste zu definieren.

01 # EPEL installieren
02 rpm -Uvh http://mirror.switch.ch/ftp/mirror/epel/6/i386/epel-release-6-8.noarch.rpm
03 # Kolab 3.1 Community Release Package installieren
04 rpm -Uvh http://mirror.kolabsys.com/pub/redhat/kolab-3.1/el6/development/i386/kolab-3.1-community-release-6-2.el6.kolab_3.1.noarch.rpm
05 # Kolab Development Package installieren
06 rpm -Uvh http://mirror.kolabsys.com/pub/redhat/kolab-3.1/el6/development/i386/kolab-3.1-community-release-development-6-2.el6.kolab_3.1.noarch.rpm

Stolperstein Standardkonfiguration

Über die URL »http://Kolab-Server/kolab-webadmin« sollte der Administrator nun Zugang zum Admin-GUI haben. Die Anmeldung klappt mit dem Usernamen »cn=Directory Manager« und dem zuvor definierten Admin-Passwort.

Es empfiehlt sich, als ersten Verwaltungsakt einen normalen User anzulegen. Mit diesem gelingt anschließend der Login in Roundcubemail, dem Kolab-Webclient, der unter »http://Kolab-Server/roundcubemail« erreichbar ist. Dabei kann als Benutzername beim Login einer der Aliase oder die Mailadresse dienen. Mit diesem User sind flugs einige Kalender, Adressen und Aufgaben erstellt, die Testmaterial für die Anbindung mit Dav-Clients liefern können.

Bei der getesteten Version gab es jedoch bis Redaktionsschluss ein Konfigurationsproblem, das die Benutzung von I-Rony verhinderte: Kolab publiziert seine Dav-Dienste unter der URL »http://Kolab-Server/iRony« . Diese liefert anfangs aber eine URL-Exception (Listing 2), die jedoch mit Hilfe aus der Kolab-Mailingliste einfach zu beheben war: In der I-Rony-Konfigurationsdatei »/etc/iRony/dav.inc.php« ersetzt der Administrator den Wert des Konfigurationsparameters »$rcmail_config[‘base_uri’]« durch »’/iRony/’« und startet mit »service kolabd restart« den Kolab-Daemon neu. Damit ist Kolab startklar für den Austausch von Daten über den I-Rony-Protokollstack.

01 <d:error>
02 <s:exception>Sabre\DAV\Exception\Forbidden</s:exception>
03 <s:message>Requested uri (/iRony/) is out of base uri (ony/public_html/)</s:message>
04 <s:sabredav-version>1.8.6</s:sabredav-version>
05 </d:error>

Anbandlversuche

Nun muss der designierte Client den ersten Verbindungsversuch über eines der Dav-Protokolle mit Kolab meistern. Grundsätzlich ist im Client die Kolab-Server-URL nach dem Schema »http://Kolab-Server/iRony« anzugeben. Alternativ kann der Anwender theoretisch sogar das Unterverzeichnis weglassen, denn standardkonforme Clients suchen zunächst nach der so genannten Principals Adress unter »../.well-known/caldav« .

Die Kolab-I-Rony-Konfiguration des Apache beinhaltet entsprechende Redirects, die diesen Aufruf nach »/iRony/« umleiten. Mit dem auf diese Weise abgefragten Usernamen lässt sich das korrekte Userverzeichnis lokalisieren.

Blitz, Donner und Evolution

Soweit die Theorie – in der Praxis machen allerdings auch verbreitete Groupware-Clients wie Lightning (Thunderbird) und Evolution bei dieser Gelegenheit mächtig Zicken, da sie Service-Discovery nicht oder zumindest nicht korrekt beherrschen. Bei solch problematischen Clients gibt der Anwender die vollständige Kalender- oder Adressbuch-URL an.

Besitzt ein Anwender mehrere Kalender, dann muss er in diesen Fällen jeden Kalender separat konfigurieren. Da zeigt es sich mal wieder, dass so mancher Mailclient nie für den Enterprise-Groupware-Betrieb gedacht war (wie Thunderbird) oder aber zu wenige Entwickler daran arbeiten (Evolution).

Leider kann sich der Anwender in Roundcube derzeit nur die ICS-Adresse und nicht die Caldav-URL des jeweiligen Kalenders anzeigen lassen. Daher braucht es einen anderen Weg, um an die URL des Kolab-Kalenders zu gelangen: Das naheliegende Verfahren dazu wäre, dem Kolab-Server seine Dav-Verzeichnisstruktur über den Aufruf der I-Rony-URL zu entlocken.

Widerspenstige Schnittstelle

Allerdings zeigt sich beim ersten Aufruf von »http://Kolab-Server/iRony« die Kolab-Schnittstelle wieder recht widerspenstig, quittiert sie doch Aufrufe mit der Meldung aus Listing 3. Zwar zeigt dies nur das korrekte Funktionieren der Schnittstelle an und ist daher nicht als Fehler zu werten, für Testzwecke erweist sich derlei aber als äußerst unpraktisch. Wer dem Modul auch diese Flausen austreiben will, ergänzt in der Apache-Konfiguration für I-Rony in »/etc/httpd/conf.d/iRony.conf« die Zeile »SetEnv DAVBROWSER 1«

01 <d:error>
02 <s:exception>Sabre\DAV\Exception\NotImplemented</s:exception>
03 <s:message>GET is only implemented on File objects</s:message>
04 <s:sabredav-version>1.8.6</s:sabredav-version>
05 </d:error>

Nach einem Httpd-Restart lassen sich nun endlich die I-Rony-URL aufrufen und die benutzerspezifische Verzeichnisstruktur erkunden (Abbildung 2).

Abbildung 2: I-Rony offenbart sein Innenleben nur bei etwas Nachhilfe.

Thunderbird als Kolab-Client

So gerüstet kann der Kolab-Admin nun Lightning als Kalender-Plugin [5] für Mozillas Mailprogramm Thunderbird installieren und mit der Groupware verbinden. Ein aktueller Thunderbird sollte es sein, ebenso bedarf es eines neueren Lightning. Über den Menüpunkt »Neuer Kalender« wählt der Admin im Konfigurationsdialog als Typ »Netzwerk« und als Format »Caldav« aus und definiert mit Hilfe der vorher ermittelten Caldav-URL seinen Kalender. Abschließend wird Thunderbird ihn wie in Abbildung 3 nach den Userdaten fragen. Sind die korrekt, dann synchronisiert Lightning klaglos Termine mit dem Kolab-Server (Abbildung 4).

Abbildung 3: Bitte Kolab-Credentials eingeben – Thunderbird, Lightning und Kolab arbeiten über Sabredav zusammen. Das klappt jedoch nicht immer reibungslos.

Abbildung 4: Links Roundcube, der Webmailclient von Kolab, rechts der gleiche Kalender in Thunderbird. Weil der Mozilla-Mailer nicht für den Unternehmenseinsatz gedacht war, zeigt er als Groupware-Client Schwächen.

Allerdings fehlt noch so manches Feature, etwa die Unterstützung für Aufgaben. Sollen Thunderbird-Anwender in ihrem Mailclient auch auf Kolab-Adressbücher zugreifen können, muss der Administrator mit dem Sogo Connector [6] ein weiteres Plugin installieren, um die im Mozilla-Mailer fehlende Carddav-Unterstützung nachzurüsten.

Evolution ohne Revolution, aber mit Kolab-Groupware

Auch der bei Gnome-Anwendern beliebte Groupware-Client Evolution ([7], Abbildung 5) lässt sich zunächst problemlos mit Kolab verbinden und glänzt erfreulicherweise bereits von Haus aus mit Support sowohl für Caldav wie auch für Carddav. Die Probleme fangen erst später an. Auch bei Evolution gilt: Beim Konfigurieren der Dav-Dienste ist jeweils die komplette URL zu spezifizieren. Die Dialoge hierfür finden sich unter »Datei | Neu | Name des Dienstes« .

Abbildung 5: Evolution funktioniert mit Einschränkungen: Kontakte anlegen geht nicht, Kalenderfunktionen dagegen schon. Insgesamt scheinen nicht mehr viele Entwickler an der Gnome-Groupware zu arbeiten.

Beim Kalender und bei den Aufgaben wählt der Administrator den Typ »CalDAV« , beim Adressbuch den Typ »WebDAV« . Zu beachten ist bei Letzteren: Aufgrund eines Bugs in Evolution funktioniert das Anlegen von Kontakten nicht bei Carddav-Servern [8].

EM-Client auf Windows – schlicht und effizient

Der EM Client ([9], Abbildung 6) beweist als reines Windows-Programm, dass auch in der Microsoft-Welt sauber implementierte Webschnittstellen heimisch sind. Hier klappt die Auto-Discovery ohne weitere Umstände, bei der Konfiguration muss der Anwender lediglich die Kolab-URL eingeben. Hierzu legt er im Menü »Extras | Konten | Neues Konto« ein Konto vom Typ »Kalender/CalDAV« an. Anschließend muss er im Kontextmenü unter »Delegation« die korrekten Berechtigungen für den jeweiligen User setzen.

Abbildung 6: Ein Windows-Tool bietet die beste Anbindung an den Caldav/Carddav-Server: EM Client.

Der Client listet sodann alle freigegebenen Kalender automatisch. Aufgaben erscheinen ebenfalls ohne weiteres Zutun, inklusive in Kolab definierter und zugewiesener Tags. So wünschte sich das auch der Thunderbird- oder Evolution-Anwender. Um Kontakte zu synchronisieren, legt der EM-Benutzer auf gleichem Wege ein separates Konto an, wählt dabei aber die Option »Kontakte/CardDAV« . Als sehr hilfreich erweist sich auch das integrierte Fehlerprotokoll, das für viel Transparenz sorgt, falls der Admin auf Probleme stößt.

Sonderbehandlung für tragbare Apple-Geräte

Apples Mobilgeräte iPhone und iPad vertragen sich erfreulich gut mit Kolabs I-Rony-Dienst (Abbildung 7). Allerdings bedarf die Kontakte-Synchronisation über Carddav einer Sonderbehandlung: Das I-OS-Adressbuch findet sich nicht zurecht, wenn Carddav nicht im Hauptverzeichnis, also dem Webserver-Root, ansprechbar ist. Für die Apple-Anwender liefert das Kolab-Team eine beispielhafte Virtual-Host-Konfiguration, welche die Probleme der Apple-Clients behebt (Listing 4).

01 <VirtualHost *:443>
02     ServerName caldav.yourkolab.com
03     ServerAdmin support@yourkolab.com
04
05     DocumentRoot /usr/share/iRony/public_html/
06
07     ErrorLog logs/caldav.yourkolab.com-error_log
08     CustomLog logs/caldav.yourkolab.com-access_log combined
09
10     <Directory "/usr/share/iRony/public_html/">
11         AllowOverride All
12         Order Allow,Deny
13         Allow from All
14
15         RewriteEngine On
16         RewriteBase /
17         RewriteRule ^\.well-known/caldav   / [R,L]
18         RewriteRule ^\.well-known/carddav  / [R,L]
19
20         RewriteCond  %{REQUEST_FILENAME}  !-f
21         RewriteCond  %{REQUEST_FILENAME}  !-d
22         RewriteRule  (.*)                 index.php  [qsappend,last]
23
24     </Directory>
25
26 </VirtualHost>

Abbildung 7: Mit I-Rony kommen erstmals auch die Besitzer von Apple-Geräten in den Kolab-Genuss, hier der Kalender eines iPad.

Die Konfiguration am Gerät erfolgt anschließend wie gewohnt in den Systemeinstellungen unter dem Punkt »Mail, Kontakte, Kalender« mit dem Anlegen eines neuen Kontos. Bei der Serveradresse gibt der Anwender die Basis-URL des Kolab-Servers an und spezifiziert wie bei den anderen Clients die Kolab-Mailadresse als Username. Neben der Kalender- und der Kontakte-Anbindung werden damit auch Aufgaben synchronisiert, die I-OS in der Erinnerungen-App verwaltet (Abbildung 8).

Abbildung 8: Die iPhone-App Erinnerungen gleicht auf Wunsch alle Aufgaben mit dem Kolab Server ab.

Vorzeigbar: Mac OS X

I-Rony unterstützt auch die zweite auf dem Desktop verbreitete proprietäre Plattform: Apples Mac OS X mit der Standard-Kalenderapplikation Ical (Abbildung 9). Die funktioniert recht unkompliziert, mit der Einrichtung nach dem Howto auf [10] funktioniert alles out of the Box, worauf der Hersteller auch einigermaßen stolz ist.

Abbildung 9: Auch Mac OS X spielt bei I-Rony mit: Sowohl Kontakte, Kalender, Aufgaben und natürlich E-Mails lassen sich in Apples Tools (Apple Mail, Contacts, Ical) integrieren.

Die Anbindung von I-Books und I-Macs dürfte wohl neben den mobilen Geräten eine der wichtigsten Triebfedern hinter I-Rony gewesen sein, und deshalb verwundert die Qualität der Anbindung auch nicht. Zu groß und lukrativ ist der Markt der zahlungskräftigen Apple-Kundschaft, als dass ihn Kolab dauerhaft links liegen lassen könnte.

Fazit: Positiv

Der Neuling I-Rony verrichtet seine Arbeit genau, wie er soll: unauffällig und zuverlässig. Nach nur wenigen Vorarbeiten für den Administrator, die bei der Release der Version 3.1 sicherlich nicht mehr nötig sein werden, entsteht eine mächtige standardkonforme Schnittstelle für das Sharing von Kalendern, Kontakten und Aufgaben. Kolab öffnet sich damit für eine Fülle am Markt etablierter Clients.

Auch Macs bei Kolab Systems

Auf Rückfrage des Linux-Magazins bestätigt Thorsten Grote, der “Kolab Evangelist” im Dienste von Kolab Systems, die Ergebnisse: “Einer unserer I-Rony Entwickler hat selbst einen Mac, vermutlich wird daher diese Plattform am besten unterstützt. Persönlich finde ich es auch ein wenig schade, dass Evolution und Thunderbird dabei so schwächeln, I-Rony macht deren Perspektive deutlich besser. Früher gab es ja noch die Thunderbird-Extension Sync Kolab [11], die wir jetzt aber nicht mehr empfehlen. Wir raten lieber zu den Dav-Protokollen. Und auch wenn das alles recht einfach zu installieren ist, empfehlen wir trotzdem unseren gehosteten Dienst. Da ist alles vorkonfiguriert, besonders für Anwender, die keinen eigenen Server betreiben wollen.”

Die Probleme verursachen aber vor allem die Clients. Vor allem die teilweise lückenhafte Umsetzung der Service-Discovery kann selbst erfahrenen Anwendern das Leben schwer machen.

Dank Sabredav unterstützt Kolab mit der kommenden Release 3.1 nun auch Webdav und ermöglicht es damit deutlich einfacher, Dateien über den integrierten Webclient zu verwalten. Über eine Middleware lassen sich verschiedene Dateispeicher nutzen und sogar eine Integration mit Owncloud oder Dropbox realisieren. (mfe)

Der Autor

Andrej Radonic arbeitet (vor allem rund um Virtualisierung, Cloud und Groupware) als freier Journalist, Fachbuchautor und Vorstand der Intersales AG.