Ein eigener Kalenderserver

Termine zwischen mehreren Geräten synchron zu halten kann nervig sein, vor allem wenn man auf Google & Co verzichten möchte. Eine Lösung: ein eigener Caldav Server.

Im Folgenden soll mein Setup mit davical beschrieben werden, schon auch als Dokumentation.

  1. DAVical installieren
  2. Datenbank einrichten
  3. Apache einrichten
  4. DAVical einrichten
  5. nützliche Quellen

 

1. davical installieren

Davical ist zwar Bestandteil der debian-Distribution, mit der auch unser Server läuft, allerdings entwickelt sich davical recht schnell und benötigt das eine oder andere Programm in einer neueren Version als es in den debian-Repository verfügbar ist. Ein eigenes Davical-Repository ermöglich eine einfache und problemlose Installation. Dieses binden wir zunächst ein indem wir der Datei /etc/apt/sources.list die Zeile

deb http://debian.mcmillan.net.nz/debian squeeze awm

hinzufügen und den dazugehörigen Schlüssel importieren

apt-key advanced --keyserver pgp.net.nz --recv-keys \
 F6E0FA5CF0307507BB23A512EAFCFEBF8FEB8EBF

Nun können wir davical ganz bequem installieren:

aptitude install davical

2. Datenbank einrichten

Außerdem braucht davial noch php, apache und postgresql, was ggf. noch zu installieren ist.

Damit davical auf die Datenbank zugreifen kann, legen wir zwei Benutzer an davical_app und davical_dba. Da wir nicht jedem Programm den Zugriff auf Kalender und Adressbücher erlauben wollen, verpassen wir den Benutzern je ein Passwort. Das tun wir als Benutzer postgres, da root das NICHT darf.

su postgres
psql
CREATE USER davical_app WITH PASSWORD 'davical_app_pw';
CREATE USER davical_dba WITH PASSWORD 'davical_dba_pw';
\q
exit>

Leider funktioniert die Installation nur ohne Passwort, weshalb wir die Benutzer zunächst auch ohne Passwort in die Datenbank lassen (müssen), daher vertrauen wir ihnen und legen sie in der /etc/postgresql/8.x/main/pg_hba.conf ab:

local   davical    davical_app     trust
local   davical    davical_dba     trust

und laden die postgresql-Konfiguarion neu:

/etc/init.d/postgresql reload

Wiederum als Benutzer postgres legen wir die Datenbank an:

su postgres -c /usr/share/davical/dba/create-database.sh

3. Apache einrichten

Davical bringt ein Webinterface zur Konfiguration von Benutzern und Gruppen mitbringt, legen wir nun noch einen Apache-Vhost an (mit unserem SSL-Zertifikat):

<VirtualHost *:443 >
 DocumentRoot /usr/share/davical/htdocs/
 DirectoryIndex index.php index.html
 ServerName cbjck.de
 ServerAlias davical.cbjck.de
 Alias /images/ /usr/share/davical/htdocs/images/
 <Directory /usr/share/davical/htdocs/>
  AllowOverride None
  Order allow,deny
  Allow from all
 </Directory>
 AcceptPathInfo On
 php_value include_path /usr/share/awl/inc
 php_value magic_quotes_gpc 0
 php_value register_globals 0
 php_value error_reporting "E_ALL & ~E_NOTICE"
 php_value default_charset "utf-8
 SSLEngine on
 SSLCertificateFile    /etc/ssl/certs/cert.pem
 SSLCertificateKeyFile /etc/ssl/private/key.pem
</VirtualHost>

Nach einem Neuladen der Apache-Konfiguration sollte die Weboberfläche erreichbar sein. Man erreicht die Weboberfläche nun allerdings ausschließlich unter https://davical.cbjck.de, vergisst man das “s” geht’s ins Nirwana. Das ist unschön und so basteln wir uns eine Umleitung, wie z.B. hier beschrieben mit einem zweiten vhost in der /etc/apache2/sites-avaiable/davical:

<VirtualHost *:80>
 ServerName cbjck.de
 ServerAlias calendar.cbjck.de
 # Das folgende erzwingt SSL
 RewriteEngine On
 RewriteCond %{HTTPS} off
 RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</VirtualHost>

Nochmal neuladen und dann klappt das:

/etc/init.d/apache2 reload

4. Davical einrichten

Nun steht noch die Konfiguration von davical selbst in der Datei /etc/davical/calendar.cbjck.de-conf.php:

<?php
$c->domain_name = "calendar.cbjck.de";
$c->sysabbr     = 'davical';
$c->admin_email = 'admin@cbjck.de';
$c->system_name = "cbjcks calDAV/cardDAV-Server";
$c->enable_row_linking = true;
$c->pg_connect[] = 'dbname=davical user=davical_app \
 password=davical_app_pw';

$c->enable_auto_schedule="false";
$c->override_dav_header = '1, 2, 3, access-control, \
 calendar-access, calendar-schedule, extended-mkcol, \
 calendar-proxy, bind';

Die letzten beiden Zeilen beheben ein Problem mit der Einladung zu Terminen in Apples iCal 4 (s. z.B. hier). Nun müssen wir den beiden Davical-Datenbankbenutzer unser Vertrauen wieder entsziehen und auf Passwort-Authentifizierung umstellen (in /etc/postgresql/8.x/main/pg_hba.conf):

local   davical    davical_app     password
local   davical    davical_dba     password

und die postgresql-Konfiguration neuladen.

/etc/init.d/postgresql reload

Anschließend sollte wir uns im Webfrontend als ‘admin’ mit dem bei der Datenbankeinrichtung erzeugten Passwort einloggen können.

Im Webfrontend richten wir nun die benötigten Benutzer unter “Benutzer Funktionen”->”Principal anlegen” ein und können uns nun mit dem Kalender-Client unserer Wahl (Apple iCal, Evolution, Kontact, Thunderbird Lightning, …) verbinden und loslegen.

5. Nützliche Quellen:

TrackBack URL

1 Kommentar »

flattr this!
  • Facebook
  • Google Bookmarks
Pingback
von: meine private Wolke – Zwischenstand - cbjck.de
17.05.2012 01:10

[...] Vereinfachung ergebn. Ursprünglich hatte ich geplant, den vorhandenen aber bisher ungenutzten Kalenderserver (davical) zu verwenden. Mittlerweile hat sich das Project ownCloud aber rapide weiterentwickelt und [...]

Hinterlasse einen Kommentar