Heute habe ich ein wenig mit eGroupware und Funambol herumexperimentiert. Schlussendlich habe ich nun eine vollständige Syncronisation von allen Kontakten, Aufgaben und Terminen geschafft. Mittels Funambol kann auf Microsoft Outlook®, Thunderbird®, Windows Mobile® PDA, IPod® oder auch auf Java-Fähige Handys gesynct werden.
Zunächst muss eGroupware heruntergeladen und installiert werden. Die Installation von eGroupWare ist etwas tricky, wenn es hierzu ein weiteres Tutorial benötigt, kann ich eins schreiben, dies ist jedoch momentan nicht der Fokus meines Beitrags.
Wichtig sind jetzt aber die Einstellungen des Clients. Über “Tools” -> “Options” kann man die Einstellungen erreichen. Über den Button “Account” errecht man die benutzerspezifischen Einstellungen. Bei “Location” trägt man die Adresse der Groupware mit einem Slash und rpc.php ein, also beispielsweise http://groupware.example.com/rpc.php. Beim Nutzer trägt man die Daten ein, mit denen man sich auch an der Groupware anmeldet.
Nun wechselt man mittels des Buttons “Sync” wieder zurück in die vorherige Übersicht. Da die Notes leider nicht abgeglichen werden können, kann man dort den Haken rausmachen. Für Contacts, Calendar und Tasks muss man noch ein wenig einstellen. Das Setting “Remote Name” unter “Advanced” muss verändert werden:
- Contacts: ./sifcontacts
- Calendar: ./sifcalendar
- Tasks: ./siftasks
Hier noch die Bilder von den korrekten Einstellungen:
Über den Scheduler kann man sich nun seine Daten in regelmäßigen Zeitabständen syncronisieren lassen, was ich recht praktisch finde :) Die Verschlüsselungsfunktion habe ich nicht näher angesehen, da ich die Daten sowieso per SSL versende :)
Im Laufe der Installation sind einige Probleme aufgetreten, die ich hier noch schnell erläutere:
Leider ist hält Funambol während dem kompletten Abgleich meiner Kontakte anscheinend die gleiche PHP-Datei offen und “hält nicht mal zwischendrin an”. Das Problem ist nun das mod_fcgid in den folgenden Fehler läuft:
| |
Die Behebung dieses Fehler ist nicht sofort erkennbar, das Anheben des Wertes default_socket_timeout in der php.ini half nicht weiter. Auf meiner Suche nach dieser Fehlermeldung stieß ich auf ein fremdsprachiges Blog, welches dankbarerweise die Lösung des Fehlers fett markiert hatte. Der IPCCommTimeout von mod_fcgid musste auf einen höheren Wert eingestellt werden.
Leider hat das erhöhen dieses Wertes bei meinem mod_fcgid gar nichts ausgelöst, der Fehler bliebt genau der gleiche. Wie ein Blogeintrag auf jay.vox.com beschreibt, scheint es daran zu liegen, dass mod_fcgid mit der Direktive nur arbeitet, wenn diese im Vhost-Block definiert wurde.
Ich bin zunächst einen anderen Weg gegangen, da ich den obenstehenden Blogeintrag erst später entdeckt habe. Mittlerweile habe ich die Direktive in den Vhost-Eintrag gepackt, was den Fehler behoben hat. Wen es interessiert, kann ja den folgenden Absatz lesen :)
Bitte die folgende Anleitung nur nachmachen, wenn man weiss, was man tut! Ich übernehme keine Haftung! Ein Blick in den Quellcode von mod_fcgid ergab in der Datei fcgid_conf.c folgende Zeilen:
| |
Jetzt war mir auch klar, wie mod_fcgid auf den Wert 40 kam. Leider führte um eine manuelle Kompilierung kein Weg, wenn man den Fehler beheben wollte. Dank Gentoo war das ganz einfach. Man gehe in /usr/portage/distfiles und entpacke die Datei:
| |
Anschließend wechselt man in das neu entpackte Verzeichnis mod_fcgid.2.2 und ändert die Datei fcgid_conf.c entsprechend den eigenen Vorstellungen (ich habe den IPCCommTimeout mal auf 120 gestellt). Wieder zurück in /usr/portage/distfiles packt man das Verzeichnis wieder (ich rate dazu, zuvor das alte Archiv zu verschieben):
| |
Da jetzt die Dateigröße anders ist, wird portage meckern, was man einfach umgehen kann:
| |
Anschließend ein beherztes emerge -av mod_fcgid und die Sache ist installiert :)
Ein Fehler, den ich mittels der Debug-Funktion des Funambol-Connectors herausgefunden habe, war dass, in einer Datei phpgwapi/inc/horde/Horde/RPC/syncml.php in der Zeile 44 die Variable $_debugDir auf einen Speicherort gesetzt war, wo der Server nicht zugreifen durfte. Wenn man diese auf das gleiche TMP-Verzeichnis wie eGroupware gelegt hat, lief SyncML problemlos. Wenn man diese gar nicht setzt, werden auch keine Debug-Logs geschrieben.