Horde Groupware

2019: Ende der Fahnenstange

Seit sechs Jahren hatte ich die Horde Groupware benutzt, um insbesondere meinen Kalender und mein Adressbuch zwischen meinem Palm und meinem Android-Handy mit SyncML zu synchronisieren (insbesondere auch ohne die Daten alle an Google zu geben.)

Nachdem ich mich jetzt genötigt sah, meine Webserver auf PHP 7 umzustellen, hab ich die Horde Groupware aber einfach nicht mehr dazu bringen können, vernünftige SyncML-Synchronisierungen hinzubekommen (vgl. Abschnitt ganz unten). Anscheinend wir Horde hier nicht mehr vernünftig gepflegt.

Da gleichzeitig der Palm aber nun definitiv am Ende seiner Lebenszeit angekommen ist, habe ich mich schweren Herzens entschlossen, den lieb gewonnenen Palm Desktop und die Horde Groupware zu begraben. Stattdessen verwende ich jetzt EGroupware, die eine ansprechende Weboberfläche besitzt und sich außerdem mit CalDAV/CardDAV vernünftig mit dem Android-Handy synchronisieren lässt.

Horde Groupware

Ich beschäftige mich hier mit der „Horde Groupware“, aktuelle Version 5.0.5 5.1.4 5.2.16 5.2.22.

Horde ist ein webbasierte Groupware, die auf dem noch allgemeineren Horde-Framework aufbaut. Horde enthält standardmäßig Groupware-Applikationen u. a. für Kalender, Adressbuch, Aufgaben und Notizen.

Aus meiner Sicht besonders intessant an Horde ist die Verfügbarkeit eines SyncML-Interfaces. Dieses erlaubt die Synchronisation mit mobilen Geräten. SyncML-Clients gibt es für alle möglichen Plattformen, insbesondere auch für Android und PalmOS. Der Android-Client bietet die Chance, die Daten aus dem Kalender und Adressbuch des eigenen Android-Geräts unabhängig von Google sichern und extern zugreifen zu können. Der PalmOS-Client bietet die Möglichkeit, die Daten von den (leider) sterbenden PalmOS-Geräten schön auf neuere Plattformen zu migrieren.

Sympathisch an Horde ist daneben, dass der Server LAMP-basiert und das Projekt LGPL-lizenziert ist.

Soweit zur Theorie. In der Praxis ergeben sich dann aber doch einige Fallstricke...

Performance

Die Performance meines Horde-Systems war nach der Installation "unterirdisch". Dies zeigte sich für mich besonders krass beim Sync (ein Kalender-Sync schaffte ca. 2 Einträge pro Sekunde, macht bei insgesamt 5.250-Kalender-Einträgen eine schlappe Dreiviertelstunde) und auch ein simples, komplettes Löschen eines solchen Kalenders legt das komplette System für eine gefühlte Ewigkeit lahm).

Im Web zu findende Performance-Verbessungstipps schienen mir wenig vertrauenserweckend.

Was mir geholfen hat: Umstellung aller von Horde genutzten MySQL-Tabellen von InnoDB auf MyISAM.

Eigentlich steht in meiner "my.cnf" explizit, dass als Default-Datenbankengine MyISAM genutzt werden soll, Horde scheint das aber zu überschreiben, was aber - zumindest für mein System - offensichtlich eine schlechte Entscheidung ist.

Abfragen lässt sich die aktuell verwendete Engine via mysql-Kommandozeile mit

show table status from db;

Ändern kann man den Engine-Type einfach mit

alter table content_schema_info engine=MyISAM;
alter table horde_activesync_cache engine=MyISAM;
...
alter table turba_objects engine=MyISAM;
...

Die Tabelle horde_imap_client_data lässt sich wegen einer dort verwendeten übergroßen Schlüssellänge nicht umstellen, na gut, dann eben nicht. Die Performance-Verbesserung ist auf jeden Fall dramatisch. Ein kompletter Reload eines Kalenders mit 5.250 Einträgen auf dem Server braucht nun 10 Minuten; immer noch nicht schnell, aber Welten gegenüber dem Ursprungszustand.

Nachtrag: Vermutlich kann man eine akzeptable Performance auch unter Verwendung der InnoDB-Engine hinbekommen, wenn man den MySQL-Server entsprechend konfiguriert/optimiert. Letzteres macht aber auf einem Server, der eigentlich nur MyISAM benutzt und die Horde-Installation nur "so nebenbei" bedienen soll, wenig Sinn.

Mehrere E-Mail-Adressen

Gerade in der heutigen Zeit total lächerlich: Das Adressbuch von Horde-Turba unterstützt pro Kontakt nur eine E-Mail-Adresse. Das Problem existiert seit Jahren, aber bisher hat sich keiner aufgerafft, das zu verbessern.

Der eigentliche Witz ist, dass im Code von Horde die Unterstützung für mehrere E-Mail-Adressen schon enthalten ist, allerdings ist das Ganze an den entscheidenden Stellen deaktiviert!

Prinzipiell unterstützt Turba zwei Features, die uns weiter helfen:

1. Neben der Standard-E-Mail-Adresse werden noch eine private und eine geschäftliche E-Mail-Adresse bereit gestellt.
   Dies klingt zwar auf den ersten Blick gut, hat aber den Haken, dass beispielsweise das PalmOS-Adressbuch die E-Mail-Adressen nicht in privat/geschäftlich klassifiziert. Der Sync-Vorgang ist daher nicht in der Lage, die Adressen in die richtigen Felder einzuordnen, die Daten gehen daher beim Sync verloren.
   Wenn jemand mehrere private oder mehrere geschäftliche Adressen hat, scheitert man an dieser Stelle aber ohnehin.
2. Alternativ unterstützt Horde-Turba ein Sammel-E-Mail-Feld, in dem einfach alle E-Mail-Adressen durch Kommata getrennt auflistet werden. (Beim abgehenden Sync werden die Adressen wieder in einzelne aufgedröselt.)
   Der große Vorteil ist hier, dass, solange die Längenbeschränkung des Feldes nicht überschritten wird, beliebige viele Adressen gespeichert werden können.
   Nachteil ist, dass die Klassifikation (privat, geschäftlich) verloren geht, die möglicherweise (z. B. im Android-Adressbuch) vorhanden sein könnte. Auch nicht schön: Die Standard-E-Mail-Adresse wird doppelt gelistet.

Wie aktiviert man diese Unterstüzung nun?

Ganz einfach:

Im Verzeichnis turba/config die Datei backends.php nach backends.local.php kopieren und in der lokalen Version folgende Änderungen anbringen:

Im Array "map" hinter der Zeile
    'email' => 'object_email',
noch die Zeilen
    'homeEmail' => 'object_homeemail',
    'workEmail' => 'object_workemail',
    'emails' => 'object_emails',
einfügen.

(In der aktuellen Version Groupware-Version 5.1.4 / Turba-Version 4.1.4 sind die homeEmail- und workEmail-Zeilen sogar schon enthalten, allerdings auskommentiert, hier also bei den beiden Zeilen nur die Kommentare entfernen und nur das "emails"-Feld neu ergänzen.)

Im Array 'tabs' den Eintrag für _("Communications") ergänzen zu
    _("Communications") => array('email', 'emails', 'homeEmail', 'workEmail', ...

(In der aktuellen Version Groupware-Version 5.1.4 / Turba-Version 4.1.4 sind die homeEmail- und workEmail-Felder schon enthalten, werden aber nicht angezeigt, solange die Felder weiter oben auskommentiert waren; hier also nur noch das "emails"-Feld ergänzen.)

Im Array "search" die neuen Felder ergänzen:
    'search' => array(
        'name',
        'email',
        'emails',
        'homeEmail',
        'workEmail'
    ),

Nun muss für die neuen Backend-Objekte 'object_homeemail', 'object_workemail' und 'object_emails' noch Platz in der Turba-Datenbanktabelle angelegt werden. Dazu in der MySQL-Kommandozeile folgende Kommandos verwenden:

alter table turba_objects add object_emails    varchar(255) after object_email;
alter table turba_objects add object_homeemail varchar(255) after object_emails;
alter table turba_objects add object_workemail varchar(255) after object_homeemail;

(Auch hier gilt wieder: In der aktuellen Version Groupware-Version 5.1.4 / Turba-Version 4.1.4 sind die object_homeemail- und object_workemail-Felder in der Datenbank schon enthalten, hier nur das "object_emails" ergänzen.)

Das war es im Prinzip schon! Zur Verbesserung der Performance für Suchoperationen ist es sinnvoll, auf den Feldern noch Indexe anzulegen, im Zweifelsfall funktioniert es aber auch ohne:

alter table turba_objects add index i_emails (object_emails);
alter table turba_objects add index i_homeemail (object_homeemail);
alter table turba_objects add index i_workemail (object_workemail);

Übersetzungen

Zwar kommt das Web-Interface für Horde-Groupware komplett in deutsch übersetzt daher. An der einen oder anderen Stelle sind die Übersetzungen allerdings etwas gewöhnungsbedürftig. Mir stieß beispielsweise das Feld "Bundesstaat oder Provinz geschäftlich" besonders auf. Dass die Beschriftung dieses Feldes, das in Deutschland eigentlich sowieso keiner braucht, sich hier auf zwei Zeilen ausdehnt, kann keiner gebrauchen.

Auf Grund der von Horde verwendeten Message-Kataloge lassen sich einzelne Meldungen aber leicht ändern. Hier exemplarisch für das oben zitierte Feld.

Im Verzeichnis turba/locale/de/LC_MESSAGES in der Datei turba.po den Text suchen und austauschen. Danach den Message-Katalog mit dem Kommando

msgfmt turba.po -o turba.mo

neu übersetzen. Fertig.

Unter Umständen cacht Horde die Seiten, daher kann es sein, dass die Änderungen nicht sofort sichtbar werden. Das Aus- und wieder Einloggen in der Weboberfläche kann z. B. helfen, die Änderungen zu aktivieren.

Adressformat

Wo ich schon dabei bin, mich über den "Bundesstaat" aufzuregen: Unschön ist auch, dass im Adressbuch in den zusammengefassten Feldern "Adresse privat" bzw. "Adresse geschäftlich" das englische Adressformat mit nachgestellter Postleitzahl benutzt wird. Aber auch das lässt sich leicht ändern.

Wir nehmen uns dazu nochmals im Verzeichnis turba/config die Datei backends.local.php vor, die wir oben angelegt hatten. Dort den Eintrag für "homeAddress" wie folgt ändern (darauf achten, dass man den richtigen Eintrag erwischt, erkennbar datan dass er auch "homeStreet" enthält):

    'homeAddress' => array('fields' => array('homeStreet',
					     'homePostalCode',
					     'homeCity'),
                               'format' => "%s \n %s  %s"),

Analog ändern wir die Felder "workAddress" und (in der neuen Groupware-Version auch) "otherAddress". Ich hab hier das Bundesland nun einfach mal komplett weggelassen... Your mileage may vary.

Das weiter oben beschriebene Cache-Problem gibt es auch bei der Änderung der Adressformate, auch hier hilft aus- und wieder einloggen.

Update

Gerade habe ich ein Update von 5.1.4 nach 5.2.16 durchgeführt.

Das Ganze funktionierte im Prinzip mit

pear upgrade -a horde/groupware

wobei erst einige andere Updates nötig waren. Auch gab es Probleme, weil mein PHP das openssl-Modul noch nicht hatte, was von den Servern (nach pear channel-update pear.horde.org, analog für pear.php.net und pecl.php.net) nun gefordert wurde.

Danach gab es ein paar Problemchen.

Nach dem Einloggen als Admin und Aufruf der Konfiguration beschwerte sich das System Datenbank-Migrations-Skripte nicht gefunden. Bitte überprüfen Sie PEARs data_dir Konfigurationseinstellung. Ein Hinweis im Web lieferte den Tipp, dass man das mit

ln -s /etc/php5/cli/pear.conf /etc/php5/apache2/

beseitigen kann.

Das Ausführen der Migration liefert dann für Horde_Dav den Fehler

QUERY FAILED: Specified key was too long; max key length is 1000 bytes CREATE UNIQUE INDEX `index_horde_dav_objects_on_id_external_and_id_collection` ON `horde_dav_objects` (`id_external`, `id_collection`)

Dazu konnte ich noch keine Lösung finden, da ich kein DAV mache, tangiert mich das hoffentlich auch momentan nicht.

Schlimmer wog die Tatsache, dass jeder Zugriff mittels der Weboverfläche auf das Adressbuch mir einen Serverfehler lieferte. Unter /var/log/messages fand ich dann:

HORDE: [turba] SQL QUERY FAILED: Unknown column 'object_category' in 'field list'

Problem war hier früher von mir modifizierte Version in der Backend-Konfiguration, die dazu führte, dass das in der aktuellen Version nicht mehr enthaltene Datenbankfeld zum Fehler führt. Nach dem Bearbeiten der Datei /usr/share/ php5/PEAR/www/horde/turba/config/ backends.local.php war das Problem dann aber verschwunden.

PHP 7

Ich ziehe zur Zeit um auf einen neuen Server. Die Horde-Groupware hab ich nach altem Rezept aus dem Repository installiert, Version ist nun 5.2.22.

Ein Problem hatte ich damit, dass auf dem neuen Server ein PHP 7.0.x läuft, momit Horde wohl (noch) nicht an allen Stellen kompatibel ist. So bekam ich die schöne Fehlermeldung

ParseError: syntax error, unexpected 'new' (T_NEW) in /usr/share/php/File/Fstab.php:110

Glücklicherweise ist „Fstab“ nur ein optional zu benutzendes Modul. Man kann den Fehler durch einfaches Deinstallieren des Moduls umgehen:

pear uninstall File_Fstab

Leider ist das Ganze wenig erfolgreich. Zwar scheint das System im Wesentlichen zu Laufen, leider scheitert das SyncML zum Server beharrlich:

HORDE: WBXML global token processing instruction is unsupported [pid 18291 on line 325 of "/usr/share/php/Horde/Xml/Wbxml/Decoder.php"]

Die Fehlermeldung ist um so unverständlicher, als sich die Codeteile hier gegenüber der früheren Horde-Version gar nicht geändert haben. Tatsächlich führte ein Rollback auf die Version 5.2.16 (der nicht ganz unkritisch war, weil mit der alten Version und dem neuen PHP das oben zitierte "unexpected T_NEW" in relativ vielen Modulen auftaucht und dort manuell behoben werden musste), zu keiner Besserung. Das SyncML schlägt nach wie vor fehl.

Fazit: Die aktuelle Horde-Groupware ist mit PHP 7 bislang offensichtlich nicht funktionsfähig, zumindest, was den SyncML-Teil angeht.

Ressourcen im Netz

• Horde-Groupware-Homepage: http://www.horde.org/

• Wikipedia-Artikel: http://de.wikipedia.org/wiki/ Horde_(Framework)