ICal-Server


Aus Macwrench

Wechseln zu: Navigation, Suche
  Ausbaufaehig.png

Dieser Artikel ist als besonders ausbaufähig gekennzeichnet worden.

Du kannst dem macwrench Team helfen, diese zu kurzen Artikel zu erweitern. Hinweise über besonders ausbaufähige Teile des Artikels sind evtl. auf der Diskussionsseite hinterlegt.
Ausbaufähige Artikel werden in der Kategorie "Ausbaufähig" gesammelt, weitere Informationen zu der Verwendung von Berwerungsbausteinen sind im entsprechenden Hilfeartikel verfügbar.

 
ICal Server.png
Diese Funktion oder Software benötigt Mac OS X in der Version 10.5 (oder neuer)

Terminal.png Baustelle.png

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 Manpage.png 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 Manpage.png 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_WAIT
Beendet werden muss er unschönerweise mit Hilfe eines beherzten Drucks auf
+ C
in dem Terminal, in dem der Server gestartet wurde. Das quittiert er dann durch die folgenden Ausgabe:
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 Manpage.png 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
YES.png
Apple, Wikipedia Ab Version 3, enthalten in Mac OS 10.5 (Leopard) CS, kommerziell (Teil von Mac OS X)
Apple iPhone OS Kalender
YES.png
Apple, Wikipedia Ab Version 3.0 CS, kommerziell (Teil von iPhone OS)
Mozilla Sunbird
YES.png
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
YES.png
Novell, Wikipedia OSS
Microsoft Entourage
NOPE.png
Microsoft, Wikipedia anscheinend nur in Verbindung mit einem Microsoft Exchange Server, kann das jemand mal verifizieren? CS, kommerziell
Microsoft Outlook
NOPE.png
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
NOPE.png
IBM, Wikipedia CS, kommerziell

Legende:

CS = Closed Source Software
OSS = Open Source Software
Weitere Informationen unter http://ietf.osafoundation.org/caldav/

Weitere Informationen

caldavd

CalDAV


  1. CalDAV ist eine Erweiterung von WebDAV zur Bereitstellung und serverseitigen Verwaltung von Kalendern und Terminen.

Verfasser: hagbard

Persönliche Werkzeuge