Debian 7 proposait la version 3.2 de calendarserver mais rien dans Debian 8 ! Il est toujours possible d’utiliser une de celles fournies par le projet. J’ai essayé les versions 6 et 7 mais sans avoir trop cherché pourquoi, je n’arrive même pas à lancer le setup. Je suis donc parti sur la version 5.3. Il faut tout d’abord récupérer la branche avec svn :
~$ mkdir CalendarServer
~$ cd CalendarServer
~/CalendarServer $ svn checkout https://svn.calendarserver.org/repository/calendarserver/CalendarServer/tags/release/CalendarServer-5.3
Il vaut mieux le faire dans un répertoire de travail parce que la phase de setup va récupérer les dépendances nécessaires au même niveau.
Première chose à faire donc, le setup :
~$ cd CalendarServer/CalendarServer-5.3
~/CalendarServer/CalendarServer-5.3$ ./run -s
EDIT: En puisant dans mes souvenirs, je me rends compte qu’il faut également modifier support/build.sh pour que le script ne télécharge pas toute la distribution de postgresql - téléchargement qui soit dit en passant ne fonctionne pas. A la ligne 916, il faut modifier type -P postgres par type -P psql.
Ça peut être assez long puisque l’outil va télécharger et compiler (dans ..) tout ce dont calendarserver a besoin et qui ne se trouve pas déjà sur la machine.
Un des prérequis importants, c’est la base postgresql. J’utilise autopostgresqlbackup, il n’y a donc qu’à créer la base et importer le dump :
# su - postgres
$ createuser caldav
[...]
$ createdb -O caldav caldav
$ gzip -dc /tmp/caldav_2016-02-03_06h25m.mercredi.sql.gz | psql caldav
Il faut ensuite copier conf/caldavd-test.plist en caldav-dev.plist, modifier les entrées relatives à la base et on peut lancer bin/calendarserver_upgrade qui va modifier le schéma de la base.
Si on utilise un annuaire openldap, il est important de faire un export de la base avec slapcat et de restaurer avec slapadd parce que calendarserver utilise l’identifiant unique (entryUUID chez openldap, défini à la clé guidAttr dans caldavad.plist) des entrées de l’annuaire pour faire le lien avec les données de la base. Il ne faut donc pas utiliser ldapsearch et ldapadd puisque ces derniers ne vont pas conserver cet identifiant.
Il semble que l’authentification digest n’est pas gérée avec un annuaire ldap tierce partie, il faut donc la désactiver et utiliser l’authentification de type http basic en clair ; il est donc important d’utiliser TLS.
<key>Digest</key>
<dict>
<key>Enabled</key>
<false/>
</dict>
Il faut également désactiver le service XML de recherche d’emplacements.
On peut procéder à une installation système ou dans un répertoire personnel. Dans le premier cas, ça sera installé dans /usr/local avec la commande run -i /. On lance alors /usr/local/bin/caldavd qui va chercher son fichier de configuration dans /etc/caldavd/caldavd.plist.
Avec un serveur mandataire inverse nginx, il faut pointer sur le port SSL de calendarserver si on utilise une connexion chiffrée, sinon ça ne marche pas :
proxy_pass https://127.0.0.1:8443;
Il n’y a plus qu’à configurer les clients. Avec Calendar.app sous El Capitan et iOS 9.2.1, a priori ça fonctionne tout seul mais le nom du calendrier peut changer et s’appeller calendar-vevent, dans thunderbird, il faut donc utiliser l’url /calendars/users/utilisateur/calendar-vevent.