ICal-Server
Aus Macwrench
Dieser Artikel ist als besonders ausbaufähig gekennzeichnet worden. |
||
Im Rahmen der Mac OS 10.5 Preview in der Keynote zur WWDC 2006 am 07. August 2006 wurde eine Multiuser-Fähigkeit von iCal vorgestellt. Diese wird mit Hilfe des "Darwin Calendar Server" realisiert (auch als iCal-Server bezeichnet), und basiert auf dem OpenSource Projekt "Collaboration" (dem Darwin Calendar Server). Der Server wird wohl zum Lieferumfang der Server-Version von Mac OS X Leopard gehören, zur in der Client-Version ist dann voraussichtlich lediglich iCal 3.0 als Client-Anwendung zum Calendar-Server enthalten.
Da derzeit nur sehr wenig Dokumentation zum iCal-Server existiert, wie das gute Stück zu Übersetzen und zum Laufen zu bewegen ist, wird dieser Artikel in nächster Zeit wohl eher an eine Bastelstube erinnern als an eine vollständige Anleitung/HowTo ... ;-) Vielmehr ist dieser Artikel im Moment die (chronologische) Dokumentation der Versuche, den Server auch unter Mac OS 10.4 zum Laufen zu bringen. Wenn es denn soweit ist, wird der Artikel bereinigt und in eine HowTo umfunktioniert ...
Eine Einschränkung ergibt sich bereits durch iCal, das in der aktuellen Version 2.03 keine Unterstützung für CalDAV mitbringt und daher für diesen Zweck hier noch nicht zu gebrauchen ist (siehe unten)
Inhaltsverzeichnis |
Funktionsumfang
Im derzeitigen Status handelt es sich wohl in erster Linie um einen CalDAV[1] Server, wobei weitere Groupwarefunktionen jedoch denkbar wären. Mehr Infos dazu gibts auf www.macosforge.org, die Quellen stehen dort unter der Apache 2.0 Lizenz zum Download bereit.
Alleine schon der Artikel über die Konfiguration von "Apple Teams" (siehe unten im Abschnitt "Konfiguration der Clients"), der im Moment nur die vage Beschreibung eines webbasierten Kalenders beinhaltet, bietet wohl einigen Webseiten genügend Stoff für neue Gerüchte ...
Im Folgenden Abschnitt starte ich den Versuch, die aktuellen Quellen des Calendar-Servers (SVN-trunk build) zum Laufen zu bewegen. Infolgedessen ist natürlich offen, was dabei herauskommt - für Hinweise und Tipps bin ich immer dankbar!
Vorbereitungen
Vor der Übersetzung der eigentlichen Quellen und der Installation des Servers sind noch diverse Vorbereitungen zu treffen:
Bezug der Quellen
Die Quellen können entweder via WebDAV oder SVN (Subversion) bezogen werden:
svn checkout http://svn.macosforge.org/repository/collaboration/CalendarServer/trunk CalendarServer
Weitere Informationen über SVN Clients und den Bezug via WebDAV sind hier verfügbar.
Sie umfassen dabei neben einem Xcode Projekt auch eine bereits lauffähige (übersetzte) Fassung des caldavd (Server-Daemon), etwas Dokumentation (im Wesentlichen das Datenmodell, eine manpage und diverse RFCs) sowie die Python-Sourcen von "twistedcaldav".
Tipp: Es empfiehlt sich, die Quellen des Servers in einem weiteren Verzeichnis (z.B. "temp" oder etwas ähnlich kreatives) zu deponieren, da im weiteren Verlauf noch einige Python-Pakete nachinstalliert werden müssen. Diese landen dann im selben Verzeichnis wie das der Server-Quellen. Ergo ist imho die Sache so etwas übersichtlicher ...
Python 2.4 Installation
Da
caldavd offensichlich in Python geschrieben ist, wird zuallererst das Python Framework in der Version 2.4 benötigt. Da Mac OS 10.4 nur die Version 2.3 beiliegt, muss dies zuerst nachinstalliert werden.
Den Mac OS Installer gibt es als Universal Binary auf python.org, nach erfolgter Installation sollte sich das Framework an folgender Stelle wiederfinden:
/Library/Frameworks/Python.framework/2.4/
Die GUI Applikationen landen im Verzeichnis
/Applications/MacPython 2.4/
und die Kommandozeilentools im Verzeichnis
/usr/local/bin
Mehr Informationen zu Python auf dem Mac gibt es unter pythonmac.org und hier. Noch eine kleine Info am Rande: das mit Mac OS X mitgelieferte Python-Framework befindet sich im Verzeichnis
/System/Library/Frameworks/Python.framework/2.3
Außerdem muss noch - falls das Verzeichnis /usr/local/bin nicht als Standardpfad definiert wurde - ein Symlink auf die Kommandozeilentools python2.4 und pythonw2.4 gesetzt werden, die sich in folgendem Verzeichnis befinden:
/usr/bin/local
Das erfolgt durch Eingabe der folgenden Kommandos im Terminal:
sudo ln -s /usr/local/bin/python /usr/bin/python2.4 sudo ln -s /usr/local/bin/pythonw /usr/bin/pythonw2.4
Dasselbe gillt übrigens auch für die Subversion-Tools svn und svnversion.
Zope Interface Installation
Offensichtlich wird (wie sich in einem weiteren Versuch herausgestellt hat) das Zope Interface benötigt, das unter der folgenden Adresse bezogen werden kann:
http://zope.org/Products/ZopeInterface/
In meinem Fall kam die Version 3.1.0c1 zum Einsatz, übersetzt und installiert wird sie (nach dem Entpacken des Archivs) durch die Eingabe der folgenden Kommandos im Terminal:
python2.4 setup.py build sudo python2.4 setup.py install
Überstzen des Server-Quellcodes
Eigentlich ist der folgende Abschnitt als erster entstanden, als ich aus lauter Neugier erst einmal das Skript run im Hauptverzeichnis des CalendarServers aufgerufen habe. Damit das Skript durchläuft, waren einige Hürden zu überwinden, was sich im Nachinein aber als nützlich herausgestellt hat da das Skript z.B. alle notwendigen Pakete automatisch herunterlädt.
Es gibt also sicherlich elegantere Wege, die Quellen zu übersetzen aber für meinen Teil hat es funktioniert.
Übersetzen der Quellen
Die Quellen des Servers - das Paket heißt "twistedcaldav" - erfolg analog zum Zope Interface durch Eingabe der folgenden Kommandos im Terminal:
python2.4 setup.py build sudo python2.4 setup.py install
Übersetzen der Python-Pakete
Eines vorweg: die Tools svn und svnversion (der Kommandozeilenclient für das Versionsierungssystem Subversion, mit dem auch der Calendar Server heruntergeladen wurde) muss dazu im Standardpfad - z.B. in /usr/bin liegen, sonst bricht der nachfolgend beschriebene Vorgang ab!
Zuallererst habe ich aus lauter Neugier (sic!) einmal das Skript run im Hauptverzeichnis des CalendarServer aufgerufen. Daraufhin wird das vom Server benötigte Zope Interface geladen und übersetzt. Dasselbe erfolgt mit den Paketen
- PyXML (XML-Unterstützung für Python)
- PyOpenSSL (SSL-Unterstützung für Python)
- PyKerberos (Kerberos-Unterstützung für Python)
- PyOpenDirectory
- xattr
- Twisted
- python-dateutil (Version 1.0)
- vobject
- pysqlite (Version 2.2.2)
Ein kleiner Hinweis: Auch wenn das Skript hier das Zope-Interface herunterlädt und übersetzt, erscheind am Ende eine Fehlermeldung über das Fehlen desselbigen. Der weiter oben beschriebene Abschnitt zur manuellen Installation ist daher notwendig! Dazu aber später mehr ...
Der Vorgang brach allerdings bereits bei der Übersetzung von PyKerberos mit der folgenden Fehlermeldung ab:
In file included from /System/Library/Frameworks/Python.framework/Headers/Python.h:48,
from src/kerberos.c:22:
/System/Library/Frameworks/Python.framework/Headers/pyport.h:554:2: error:
#error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)."
src/kerberos.c: In function 'authGSSClientClean':
src/kerberos.c:79: warning: implicit declaration of function 'PyCObject_SetVoidPtr'
src/kerberos.c: In function 'authGSSClientClean':
src/kerberos.c:79: warning: implicit declaration of function 'PyCObject_SetVoidPtr'
lipo: can't open input file: /var/tmp//ccn8DPLJ.out (No such file or directory)
error: command 'gcc' failed with exit status 1
make: *** [PyKerberos] Error 1
Wie es ausschaut, wird der Fehler im PyKerberos Paket erzeugt, und zwar in der Datei
src/kerberos.c
in Zeile 22; dort wird Python.h aus dem Python-Framework eingebunden. Die wiederum bindet die Datei pyport.h ein. Scheinbar ist irgendwo im System oder in der gcc/glibc-Konfiguration eine Variable namens LONG_BIT nicht richtig definiert worden. Die Datei
/System/Library/Frameworks/Python.framework/Headers/pyport.h
gibt den Fehler lediglich aus:
#if LONG_BIT != 8 * SIZEOF_LONG /* 04-Oct-2000 LONG_BIT is apparently (mis)defined as 64 on some recent * 32-bit platforms using gcc. We try to catch that here at compile-time * rather than waiting for integer multiplication to trigger bogus * overflows. */ #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." #endif
Als Abhilfe habe ich in der Datei pyport.h ein paar Zeilen weiter oberhalb (544-546) die Anweisungen
#ifndef LONG_BIT #endif
auskommentiert, so dass da nur noch stand:
//#ifndef LONG_BIT #define LONG_BIT (8 * SIZEOF_LONG) //#endif
Es ist gut möglich, das dieser Fehler auf 64Bit Systemen (G5, Core2Duo) nicht auftaucht (schließe ich zumindest aus dem Kommentar in pyport.h), meine Versuche hier beziehen sich auf ein iBook G4 (also 32Bit PPC). Nach dem Übersetzungsvorgang sollte man diese Änderung jedoch wieder rückgängig machen. Vielleicht finde ich auch noch die Stelle in der gcc- oder glibc-Konfiguration, die den Fehler verursacht ...
Dann ging es (zumindest bei mir) allerdings weiter mit Fehlermeldungen ... schätze dass man vorher auch die diversen Patches, die beim CalendarServer mitgeliefert wurden, anwenden sollte (habe ich aus Neugier und Faulheit nicht gemacht). Außerdem ist wohl noch weiteres an Vorarbeit zu leisten, was der folgenden Fehlermeldung zu entnehmen ist:
... Repository File does not exist: conf/repository-dev.xml SSL Private Key File does not exist: /etc/certificates/Default.key
Als Quick-and-Dirty Abhilfe habe ich dann in den .plist Dateien im conf/ Verzeichnis des CalendarServer die Einstellungen für SSL auf "no" gesetzt und einfach eine Kopie von repository.xml namens repository-dev.xml angelegt.
Danach lief es zwar durch; am Schluß kamen jedoch diverse Fehlermeldungen über nicht vorhandene Python-Pakete. Wie sich herausgestellt hat, übersetzt das Skript die Pakete nur und installiert sie nicht. Na toll!
Anm. d. Red.: Jetzt bin ich an dem am Anfang des Abschnitts beschriebenen Punkt, dass es sicherlich elegantere Lösungen gibt. Aber so haben wir jetzt wenigstens alle notwendigen Pakete auf der Platte rumfahren und können sie manuell installieren.
An dieser Stelle wurde mir dann auch klar, woher die Fehlermeldung mit dem fehlenden Zope-Interface kam ... Das befindet sich übrigens auch unter den durch das run-Skript heruntergeladenen Paketen, die nicht installiert wurden ...
Also müssen die ganzen Pakete, die bei diesem Vorgang durch das Skript run heruntergeladen wurden, manuell installiert werden. Also die Pakete wie z.B. PyXML, PyKerberos, PyOpenDirectory, PyOpenSSL, Twisted und wie sie alle heißen. Das erfolgt analog zum Zope-Interface durch Eingabe der folgenden Kommandos im jeweiligen Verzeichnis des Paketes:
python2.4 setup.py build sudo python2.4 setup.py install
Jetzt sollte der Vorgang durchlaufen.
Testweises Starten
Nun lief das Skript run durch und quittierte den Start des Servers mit der folgenden Ausgabe:
hagbard$ sh run
2006/08/09 10:41 CEST [-] Log opened.
2006/08/09 10:41 CEST [-] twistd 2.3.0+r17097 (/Library/Frameworks/Python.framework/Versions/2.4/
Resources/Python.app/Contents/MacOS/Python 2.4.3) starting up
2006/08/09 10:41 CEST [-] reactor class: <class 'twisted.internet.selectreactor.SelectReactor'>
2006/08/09 10:41 CEST [-] Loading /tmp/caldavK6r1RD...
2006/08/09 10:41 CEST [-] Document root is: twistedcaldav/test/data/
2006/08/09 10:41 CEST [-] Repository configuration is: conf/repository-dev.xml
2006/08/09 10:41 CEST [-] Initializing index /Users/hagbard/Desktop/iCal-Server/CalendarServer/
twistedcaldav/test/data/principals/users/.db.sqlite
2006/08/09 10:41 CEST [-] Initializing index /Users/hagbard/Desktop/iCal-Server/CalendarServer/
twistedcaldav/test/data/principals/groups/.db.sqlite
2006/08/09 10:41 CEST [-] Initializing index /Users/hagbard/Desktop/iCal-Server/CalendarServer/
twistedcaldav/test/data/principals/resources/.db.sqlite
2006/08/09 10:41 CEST [-] Starting http server
2006/08/09 10:41 CEST [-] Loaded.
2006/08/09 10:41 CEST [-] twisted.web2.channel.http.HTTPFactory starting on 8008
2006/08/09 10:41 CEST [-] Starting factory <twisted.web2.channel.http.HTTPFactory instance at 0x16961c0>
Ergo sollte auf Port 8008 ein http-Server lauschen, wie der Zeile
... 2006/08/09 10:41 CEST [-] twisted.web2.channel.http.HTTPFactory starting on 8008 ...
der obigen Ausgabe zu entnehmen ist. Und so isses auch (zumindest bei mir) ... wie sich im Terminal mit hilfe des Tools
netstat leicht ermitteln ließ, nachdem ich mit dem Browser draufzugegriffen habe:
netstat -ln | grep 8008 tcp4 0 0 127.0.0.1.61317 127.0.0.1.8008 CLOSE_WAITBeendet werden muss er unschönerweise mit Hilfe eines beherzten Drucks auf
| + | C |
2006/08/09 11:13 CEST [-] Received SIGINT, shutting down. 2006/08/09 11:13 CEST [-] (Port 8008 Closed) 2006/08/09 11:13 CEST [-] Stopping factory <twisted.web2.channel.http.HTTPFactory instance at 0x16961c0> 2006/08/09 11:13 CEST [-] Main loop terminated. 2006/08/09 11:13 CEST [-] Server Shut Down.
Starten im Hintergrund
Durch Aufruf des Skriptes run mit der Option -s
sh ./run -s
wird der Server im Hintergrund gestartet und gibt keine Meldungen auf dem Terminal aus (so schreibt es der QuickStart Guide auf der Projektseite). Hat bei mir aber leider nicht funktioniert ... :-(
Zugang über den Browser
Über die Adresse
http://127.0.0.1:8008
gelangt man zum Web-Interface des Servers, das im Moment nichts anderes als ein Verzeichnislisting des Demo-Users "admin" ausgibt.
Die Zugangsdaten für den Demo-User sind übrigens:
username: admin password: admin
So, nun mach ich mal Pause ...
Wer Lust und Zeit hat, kann gerne seine/ihre Erfahrungen hier ebenfalls kundtun - am Besten auf der Diskussionsseite dieses Artikels.
... more to come ...
Installation des Servers
Damit der Server über den launchd-Service mit Hilfe des Skriptes
caldavd automatisch gestartet werden kann, muss er noch ordnungsgemäß installiert werden - im bisherigen Verlauf erfolgte der Start ja immer aus dem Source-Verzeichnis heraus.
... more to come ...
Konfiguration
Konfiguration des Servers
... more to come ...
Konfiguration der Clients
Im Moment werden die folgenden Clients unterstützt:
- Apple's iCal (allerdings erst ab Version 3, die in MacOS X 10.5 enthalten ist/sein wird. Ältere Versionen unterstützen noch kein CalDAV)
- Apple's Teams (Whatever that may be, anscheinend ein webbasierter Kalender)
- OSAF's Chandler
- OSAF's Scooby
- Mozilla's Sunbird
- Mozilla's Lightning
weitere Informationen zu deren Konfiguration sind auf der Projektseite verfügbar.
In Ermangelung einer Leopard Developer-Preview lief mein Test also mit Mozilla Sunbird ab, der hier heruntergeladen werden kann. Allerdings gibt mir der Eintrag "CalDAV support remains extremely basic" in den Release Notes zur Version 0.3 alpha2 zu denken ...
CalDAV Clients
HIer eine kleine Übersicht verbreiteter E-Mail und PIM-Programme mit ihren Möglichkeiten als CalDAV Client:
| Name | CalDAV | Webseite | Bemerkungen | Lizenz |
|---|---|---|---|---|
| Apple iCal | Apple, Wikipedia | Ab Version 3, enthalten in Mac OS 10.5 (Leopard) | CS, kommerziell (Teil von Mac OS X) | |
| Apple iPhone OS Kalender | Apple, Wikipedia | Ab Version 3.0 | CS, kommerziell (Teil von iPhone OS) | |
| Mozilla Sunbird | mozilla.org, Wikipedia | CalDAV Unterstützung (noch) sehr rudimentär. Mozilla Lightning als Thunderbird Plug-In nutzt dieselbe Codebasis. | OSS | |
| Kmail | ? | kde.org, Wikipedia | Mail-Client der Desktop-Umgebung KDE | OSS |
| Novell Evolution | Novell, Wikipedia | OSS | ||
| Microsoft Entourage | Microsoft, Wikipedia | anscheinend nur in Verbindung mit einem Microsoft Exchange Server, kann das jemand mal verifizieren? | CS, kommerziell | |
| Microsoft Outlook | Microsoft, Wikipedia | Das Open Outlook Connector Project arbeitet an einer CalDAV Unterstützung für Outlook. Ob diese MAPI Erweiterungen dann auch mit Entourage funktionieren, kann ich nicht beantworten. | CS, kommerziell | |
| Lotus Notes | IBM, Wikipedia | CS, kommerziell |
Legende:
- CS = Closed Source Software
- OSS = Open Source Software
- Weitere Informationen unter http://ietf.osafoundation.org/caldav/
Weitere Informationen
caldavd
-
Manpage zu caldavd
- Collaboration Projektwebseite auf www.macosforge.org
CalDAV
- Wikipedia-Artikel zu CalDAV: en, de
- caldav.org - CaöDAV Homepage
- CalConnect - The Calendaring and Scheduling Consortium (Apple ist seit dem 8.8.06 Mitglied in diesem Konsortium)
- Open Calendar Sharing and Scheduling with CalDAV
- ↑ CalDAV ist eine Erweiterung von WebDAV zur Bereitstellung und serverseitigen Verwaltung von Kalendern und Terminen.
Verfasser: hagbard





