Hostsharing Wiki - Benutzerbeiträge [de]

RadicaleCalDAVServer

2017-02-11T20:48:54Z

Ita00:

= Radicale CalDAV Server =

[http://de.wikipedia.org/wiki/CalDAV CalDAV] ist eine Erweiterung des WebDAV- (und damit des HTTP-) Protokolls, um Kalenderdaten (Termine und Aufgaben) auf einem Server zu speichern.

Apple nutzt diese Protokoll für seine Clients (iCal-Anwendung und Kalender-App auf dem iPhone) und bietet einen entsprechenden Server an. Dadurch gewinnt CalDAV zunehmende Bedeutung.

Wenn man freie Software einsetzen will, bieten sich folgende Anwendungen an:
* Das [http://www.mozilla.org/projects/calendar/lightning/ Lightning-Plugin] für Thunderbird (unter Linux und Windows)
* [https://f-droid.org/repository/browse/?fdid=org.gege.caldavsyncadapter CalDAV Sync Adapter] als Android-App zur Synchronisation des Kalenders
* Der [http://caldavsynchronizer.org/ CaldavSynchronizer] für Outlook

In diesem Artikel wird die Installation eines CalDAV-Server in einem normalen Hostsharing-Paket beschrieben, als leichtgewichtigen Server nutze ich den [http://radicale.org/ Radicale CalDAV Server]. Der Server kann mit Hilfe von Passenger betrieben werden.

In dieser Installationsanleitung wird die Installation für HTTP und HTTPS (Verzeichnisse "app-ssl" und "htdocs-ssl") parallel vorgenommen. Ihr solltet darauf achten, den CalDAV- / Card-Server im produktiven
Betrieb immer nur über HTTPS (also mit SSL-/TLS_Verschlüsselung) anzusprechen. Schliesslich werden Passworte und personenbezogene Daten übertragen!

== Installation ==

=== Vorbereitung ===

Ich lege mit HSAdmin einen User ''xyz00-cal'' an und schalte eine Domain ''cal.example.org'' auf.

=== Download und Entpacken des Paketes ===

* Radicale Download: [http://radicale.org/download/], die aktuelle Version beim Schreiben des Artikel: 0.9

als User ''xyz00-cal'':

<pre>
wget http://pypi.python.org/packages/source/R/Radicale/Radicale-0.9.tar.gz
tar xzf Radicale-0.9.tar.gz
</pre>

=== Installation des Python Eggs ===

Die Eggs sollen jeweils im Verzeichnis des aktuellen Users installiert werden. Der Aufruf des Setup-Skripts dazu:

<pre>
cd ~/Radicale-0.9
python setup.py install --user
</pre>

Danach sollten sich im Unterverzeichnis ~/.local/ die entsprechenden Python-Skripte finden:

<pre>
ls -l ~/.local/bin/ ~/.local/lib/python2.7/site-packages/
</pre>

<pre>
/home/pacs/xyz00/users/cal/.local/bin/:
total 4
-rwxr-xr-x 1 xyz00-cal xyz00 1001 Dec 28 12:04 radicale

/home/pacs/xyz00/users/cal/.local/lib/python2.6/site-packages/:
total 12
-rw-r--r-- 1 xyz00-cal xyz00 1797 Dec 28 12:04 Radicale-0.9.egg-info
drwxr-xr-x 3 xyz00-cal xyz00 4096 Dec 28 12:04 radicale
</pre>

=== Passenger Konfiguration ===

Wir wechseln in das Domain-Verzeichnis ''~/doms/cal.example.org/''.
Dorthin legen wir die folgende Datei an:

''~/doms/cal.example.org/app/passenger_wsgi.py'' und
''~/doms/cal.example.org/app-ssl/passenger_wsgi.py''

<pre>
#!/usr/bin/env python

import radicale

radicale.log.start()
application = radicale.Application()
</pre>

''~/doms/cal.example.org/htdocs/.htaccess'' und
''~/doms/cal.example.org/htdocs-ssl/.htaccess''

<pre>
AuthType Basic
AuthName "Radicale Calendar Server"
require valid-user
AuthUserFile /home/pacs/xyz00/users/cal/.htpasswd
</pre>

Es fehlt noch das Anlegen der ''~/.htpasswd''-Datei mit den verschlüsselten Passworten der User.
Dazu rufen wir (für die User ''hans'' und ''franz'') folgendes Kommando auf (''htpasswd -c'' erzeugt die Datei):

<pre>
htpasswd -c ~/.htpasswd hans
htpasswd ~/.htpasswd franz
...
</pre>

An dieser Stelle sollte ein Aufruf von ''https://cal.example.org'' im Browser nach Eingabe des Passwortes für ''hans'' oder ''franz'' die folgende Seite liefern: ''Radicale works!''

=== Radicale Konfiguration ===

Zuletzt bleibt noch die Erstellung einer Konfigurationsdatei für den Radicale-Server.
Ein Template für die Datei findet Ihr in ''~/Radicale-0.9/config''.

Hier der Inhalt meiner ''~/.config/radicale/config'':

<pre>
# Config file for Radicale - A simple calendar server
# Place it into ~/.config/radicale/config (user)

[server]
base_prefix = /
can_skip_base_prefix = False
dns_lookup = False

[encoding]
request = utf-8
stock = utf-8

[auth]
type = None

[rights]
type = None

[storage]
type = filesystem
custom_handler =
filesystem_folder = ~/.config/radicale/collections

[logging]
config = ~/.config/radicale/logging
debug = False
full_environment = False
</pre>

Hier der Inhalt meiner ''~/.config/radicale/logging'':

<pre>
[loggers]
keys = root

[handlers]
keys = file

[formatters]
keys = full

[logger_root]
level = INFO
handlers = file

[handler_file]
class = FileHandler
args = ('/home/pacs/xyz00/users/cal/var/radicale.log',)
formatter = full

[formatter_full]
format = %(asctime)s - %(levelname)s: %(message)s
</pre>

== Nutzung der Kalender ==

=== Zugriffsrechte ===

Zu diesem Zeitpunkt können die User ''hans'' und ''franz'' jeweils auf alle Kalender zugreifen. In einer größeren Organisation ist das sicher nicht ausreichend.

Im der oben beschriebenen Konfiguration überlässt man die Zugriffskontrolle am besten dem Apache-Webserver. Das kann man einfach über die bereits vorhandene ''.htaccess''-Datei regeln:

<pre>
AuthType Basic
AuthName "Radicale Calendar Server"
AuthUserFile /home/pacs/xyz00/users/cal/.htpasswd
<FilesMatch "^hans">
require user hans
</FilesMatch>
<FilesMatch "^franz">
require user franz
</FilesMatch>
<FilesMatch "^team">
require valid-user
</FilesMatch>
</pre>

So können beide User jeweils eigene Kalender anlegen, z.B:
* /hans/privat
* /hans/aufgaben
* /franz/kalender

Unter dem Pseudouser ''team'' können gemeinsame Kalender verwaltet werden:
* /team/meetings
* /team/seminarraum

Mit einer zusätzlichen Datei ''.htgroups'' kann man auch komplexere Szenarien implementieren.

=== Client Konfiguration ===

Ich selbst verwende das Lightning-Plugin zu Thunderbird und aCal als Android-App.

==== Lightning ====

Hier kann man jeden einzelnen Kalender mit seiner vollständigen URL abonnieren.

Über die Funktion "Create Calendar":
# "On the Network"
# "CalDAV" mit "Location": ''https://cal.example.org/franz/privat''
# Namen vergeben und Farbe wählen
# ggf. noch User und Passwort angeben
# das war's

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:CalDAV]]
[[Kategorie:Passenger]]

Diskussion:RadicaleCalDAVServer

2017-02-11T20:43:52Z

Ita00: /* Fehler in Beispiel-Config? */

== Beschwerdeführer droht mit Blacklisting der Anleitung ==

Die Installationsanleitung ist einwandfrei, aber suboptimal.

Wir wurden heute von einem Dritten (Ticket #2015081110000178) darüber in Kenntis gesetzt unter Androhung der Aufnahme in eine Blacklist von Anleitungen, die Nutzer unsichere Konfigurationen empfehlen.

=== Orientierung an den best practices ===

Grundsätzlich ist die Anleitung nicht falsch. Im vorderen Teil ist sie leider unnötig kompliziert. Die Empfehlung - den best practices für Python folgend - lautet eigentlich:

<pre>
# Basiordner anlegen
$ mkdir radicale
# und absichern
$ chmod 700 radicale
# Virtuelle Python-Umgebung (im Userspace) erzeugen
$ virtualenv radicale/virtualenv
# und dort Radicale installieren
$ radicale/virtualenv/bin/pip install Radicale
# Ordnerstrukturen erzeugen
$ mkdir radicale/application/etc radicale/application/log radicale/application/data
</pre>

Man erhält so eine klare Trennung zwischen der Installation der Software nebst Abhängigkeiten und den Anwendungsdaten. Entsprechend verteilt man dann die Konfigurations-, Daten- und Log-Dateien auf die jeweiligen Unterordner.

Möchte man an Stelle des Filesystem-Backends ein Datenbank-Backend nutzen, so sind die passenden Python-Bibliotheken in das virtualenv zu installieren. Alternativ kann man die systemweit installierten Bibliotheken nutzer (site-package beim virtualenv aktivieren); dies enspricht jedoch nicht den best pratices.

Der WSGI-Starter sieht dann so aus (Pfad zum Python im virtualenv):
<pre>
#!/......./virtualenv/bin/python

import radicale

radicale.log.start()
application = radicale.Application()
</pre>

=== TLS oder Nicht-TLS - beides ist möglich ===

Wenn man nun noch konsequent auf die Ordner app-ssl und htdocs-ssl setzt, nutzt man die TLS-Terminierung des Apache, der von Hostsharing auf dem aktuellen Stand gehalten wird und auch unser Beschwerdeführer sollte zufrieden sein.

Im Übrigen gilt es als best practice, die TLS-Terminierung nicht der Anwendung, sondern einem reverse proxy zu überlassen. Konkret erhöht dies sogar die Sicherheit, weil Hostsharing die allfälligen Sicherheitsprobleme mit OpenSSL im Blick behält und passend reagiert statt dieses Problem auf den Endnutzer abzuwälzen.

Hostsharing befürwortet und unterstützt den Einsatz von TLS, erzwingt ihn aber nicht. Der besseren Lesbarkeit halber wiederholen wir auch nicht bei jeder Erwähnung einer Installationsoption eine Belehrung über die Risiken der Wahl.

=== Grundsätzliches ===

Der maßgebliche Autor dieser Anleitung ist Java-Experte und ihm ist sicherlich nicht vorzuwerfen, dass ihm "virtualenv" nicht geläufig ist. Die etwas umständlichere Installationsvariante birgt keine Sicherheitsrisiken. Zudem setzt der Autor implizit voraus, dass unseren Nutzern der Unterschied zwischen den ssl- und nicht-ssl-Konfigurationoptionen bekannt ist. Dies - genauer die Beschreibung der Ordner und der SSL/TLS-Terminierung - geht unter anderem aus der maßgeblichen Endandwender-Dokumentation hervor.

--[[Benutzer:Web|Web]] ([[Benutzer Diskussion:Web|Diskussion]]) 21:26, 11. Aug. 2015 (CEST)

=== Fehler in Beispiel-Config? ===
Kann es sein, dass da ein paar "/" fehlen?
z.B. schreibt
filesystem_folder = ~/.config/radicale/collections
dann alle einträge in eine datei, was nicht gut endet.

mit ~/.config/radicale/collections gibts unterordner per user

--[[Benutzer:Ita00|Ita00]] ([[Benutzer Diskussion:Ita00|Diskussion]]) 21:43, 11. Feb. 2017 (CET)

Diskussion:RadicaleCalDAVServer

2017-02-11T20:43:22Z

Ita00: /* Fehler in Beispiel-Config? */

== Beschwerdeführer droht mit Blacklisting der Anleitung ==

Die Installationsanleitung ist einwandfrei, aber suboptimal.

Wir wurden heute von einem Dritten (Ticket #2015081110000178) darüber in Kenntis gesetzt unter Androhung der Aufnahme in eine Blacklist von Anleitungen, die Nutzer unsichere Konfigurationen empfehlen.

=== Orientierung an den best practices ===

Grundsätzlich ist die Anleitung nicht falsch. Im vorderen Teil ist sie leider unnötig kompliziert. Die Empfehlung - den best practices für Python folgend - lautet eigentlich:

<pre>
# Basiordner anlegen
$ mkdir radicale
# und absichern
$ chmod 700 radicale
# Virtuelle Python-Umgebung (im Userspace) erzeugen
$ virtualenv radicale/virtualenv
# und dort Radicale installieren
$ radicale/virtualenv/bin/pip install Radicale
# Ordnerstrukturen erzeugen
$ mkdir radicale/application/etc radicale/application/log radicale/application/data
</pre>

Man erhält so eine klare Trennung zwischen der Installation der Software nebst Abhängigkeiten und den Anwendungsdaten. Entsprechend verteilt man dann die Konfigurations-, Daten- und Log-Dateien auf die jeweiligen Unterordner.

Möchte man an Stelle des Filesystem-Backends ein Datenbank-Backend nutzen, so sind die passenden Python-Bibliotheken in das virtualenv zu installieren. Alternativ kann man die systemweit installierten Bibliotheken nutzer (site-package beim virtualenv aktivieren); dies enspricht jedoch nicht den best pratices.

Der WSGI-Starter sieht dann so aus (Pfad zum Python im virtualenv):
<pre>
#!/......./virtualenv/bin/python

import radicale

radicale.log.start()
application = radicale.Application()
</pre>

=== TLS oder Nicht-TLS - beides ist möglich ===

Wenn man nun noch konsequent auf die Ordner app-ssl und htdocs-ssl setzt, nutzt man die TLS-Terminierung des Apache, der von Hostsharing auf dem aktuellen Stand gehalten wird und auch unser Beschwerdeführer sollte zufrieden sein.

Im Übrigen gilt es als best practice, die TLS-Terminierung nicht der Anwendung, sondern einem reverse proxy zu überlassen. Konkret erhöht dies sogar die Sicherheit, weil Hostsharing die allfälligen Sicherheitsprobleme mit OpenSSL im Blick behält und passend reagiert statt dieses Problem auf den Endnutzer abzuwälzen.

Hostsharing befürwortet und unterstützt den Einsatz von TLS, erzwingt ihn aber nicht. Der besseren Lesbarkeit halber wiederholen wir auch nicht bei jeder Erwähnung einer Installationsoption eine Belehrung über die Risiken der Wahl.

=== Grundsätzliches ===

Der maßgebliche Autor dieser Anleitung ist Java-Experte und ihm ist sicherlich nicht vorzuwerfen, dass ihm "virtualenv" nicht geläufig ist. Die etwas umständlichere Installationsvariante birgt keine Sicherheitsrisiken. Zudem setzt der Autor implizit voraus, dass unseren Nutzern der Unterschied zwischen den ssl- und nicht-ssl-Konfigurationoptionen bekannt ist. Dies - genauer die Beschreibung der Ordner und der SSL/TLS-Terminierung - geht unter anderem aus der maßgeblichen Endandwender-Dokumentation hervor.

--[[Benutzer:Web|Web]] ([[Benutzer Diskussion:Web|Diskussion]]) 21:26, 11. Aug. 2015 (CEST)

=== Fehler in Beispiel-Config? ===
Kann es sein, dass da ein paar "/" fehlen?
z.B. schreibt
filesystem_folder = ~/.config/radicale/collections
dann alle einträge in eine datei, was nicht gut endet.
~/.config/radicale/collections gibts unterordner per user

--[[Benutzer:Ita00|Ita00]] ([[Benutzer Diskussion:Ita00|Diskussion]]) 21:43, 11. Feb. 2017 (CET)

Diskussion:RadicaleCalDAVServer

2017-02-11T20:43:07Z

Ita00: /* Fehler in Beispiel-Config? */

== Beschwerdeführer droht mit Blacklisting der Anleitung ==

Die Installationsanleitung ist einwandfrei, aber suboptimal.

Wir wurden heute von einem Dritten (Ticket #2015081110000178) darüber in Kenntis gesetzt unter Androhung der Aufnahme in eine Blacklist von Anleitungen, die Nutzer unsichere Konfigurationen empfehlen.

=== Orientierung an den best practices ===

Grundsätzlich ist die Anleitung nicht falsch. Im vorderen Teil ist sie leider unnötig kompliziert. Die Empfehlung - den best practices für Python folgend - lautet eigentlich:

<pre>
# Basiordner anlegen
$ mkdir radicale
# und absichern
$ chmod 700 radicale
# Virtuelle Python-Umgebung (im Userspace) erzeugen
$ virtualenv radicale/virtualenv
# und dort Radicale installieren
$ radicale/virtualenv/bin/pip install Radicale
# Ordnerstrukturen erzeugen
$ mkdir radicale/application/etc radicale/application/log radicale/application/data
</pre>

Man erhält so eine klare Trennung zwischen der Installation der Software nebst Abhängigkeiten und den Anwendungsdaten. Entsprechend verteilt man dann die Konfigurations-, Daten- und Log-Dateien auf die jeweiligen Unterordner.

Möchte man an Stelle des Filesystem-Backends ein Datenbank-Backend nutzen, so sind die passenden Python-Bibliotheken in das virtualenv zu installieren. Alternativ kann man die systemweit installierten Bibliotheken nutzer (site-package beim virtualenv aktivieren); dies enspricht jedoch nicht den best pratices.

Der WSGI-Starter sieht dann so aus (Pfad zum Python im virtualenv):
<pre>
#!/......./virtualenv/bin/python

import radicale

radicale.log.start()
application = radicale.Application()
</pre>

=== TLS oder Nicht-TLS - beides ist möglich ===

Wenn man nun noch konsequent auf die Ordner app-ssl und htdocs-ssl setzt, nutzt man die TLS-Terminierung des Apache, der von Hostsharing auf dem aktuellen Stand gehalten wird und auch unser Beschwerdeführer sollte zufrieden sein.

Im Übrigen gilt es als best practice, die TLS-Terminierung nicht der Anwendung, sondern einem reverse proxy zu überlassen. Konkret erhöht dies sogar die Sicherheit, weil Hostsharing die allfälligen Sicherheitsprobleme mit OpenSSL im Blick behält und passend reagiert statt dieses Problem auf den Endnutzer abzuwälzen.

Hostsharing befürwortet und unterstützt den Einsatz von TLS, erzwingt ihn aber nicht. Der besseren Lesbarkeit halber wiederholen wir auch nicht bei jeder Erwähnung einer Installationsoption eine Belehrung über die Risiken der Wahl.

=== Grundsätzliches ===

Der maßgebliche Autor dieser Anleitung ist Java-Experte und ihm ist sicherlich nicht vorzuwerfen, dass ihm "virtualenv" nicht geläufig ist. Die etwas umständlichere Installationsvariante birgt keine Sicherheitsrisiken. Zudem setzt der Autor implizit voraus, dass unseren Nutzern der Unterschied zwischen den ssl- und nicht-ssl-Konfigurationoptionen bekannt ist. Dies - genauer die Beschreibung der Ordner und der SSL/TLS-Terminierung - geht unter anderem aus der maßgeblichen Endandwender-Dokumentation hervor.

--[[Benutzer:Web|Web]] ([[Benutzer Diskussion:Web|Diskussion]]) 21:26, 11. Aug. 2015 (CEST)

=== Fehler in Beispiel-Config? ===
Kann es sein, dass da ein paar "/" fehlen?
z.B. schreibt
filesystem_folder = ~/.config/radicale/collections
dann alle einträge in eine datei, was nicht gut endet.
~/.config/radicale/collections gibts unterordner per user
--[[Benutzer:Ita00|Ita00]] ([[Benutzer Diskussion:Ita00|Diskussion]]) 21:43, 11. Feb. 2017 (CET)

Diskussion:RadicaleCalDAVServer

2017-02-11T20:42:48Z

Ita00:

== Beschwerdeführer droht mit Blacklisting der Anleitung ==

Die Installationsanleitung ist einwandfrei, aber suboptimal.

Wir wurden heute von einem Dritten (Ticket #2015081110000178) darüber in Kenntis gesetzt unter Androhung der Aufnahme in eine Blacklist von Anleitungen, die Nutzer unsichere Konfigurationen empfehlen.

=== Orientierung an den best practices ===

Grundsätzlich ist die Anleitung nicht falsch. Im vorderen Teil ist sie leider unnötig kompliziert. Die Empfehlung - den best practices für Python folgend - lautet eigentlich:

<pre>
# Basiordner anlegen
$ mkdir radicale
# und absichern
$ chmod 700 radicale
# Virtuelle Python-Umgebung (im Userspace) erzeugen
$ virtualenv radicale/virtualenv
# und dort Radicale installieren
$ radicale/virtualenv/bin/pip install Radicale
# Ordnerstrukturen erzeugen
$ mkdir radicale/application/etc radicale/application/log radicale/application/data
</pre>

Man erhält so eine klare Trennung zwischen der Installation der Software nebst Abhängigkeiten und den Anwendungsdaten. Entsprechend verteilt man dann die Konfigurations-, Daten- und Log-Dateien auf die jeweiligen Unterordner.

Möchte man an Stelle des Filesystem-Backends ein Datenbank-Backend nutzen, so sind die passenden Python-Bibliotheken in das virtualenv zu installieren. Alternativ kann man die systemweit installierten Bibliotheken nutzer (site-package beim virtualenv aktivieren); dies enspricht jedoch nicht den best pratices.

Der WSGI-Starter sieht dann so aus (Pfad zum Python im virtualenv):
<pre>
#!/......./virtualenv/bin/python

import radicale

radicale.log.start()
application = radicale.Application()
</pre>

=== TLS oder Nicht-TLS - beides ist möglich ===

Wenn man nun noch konsequent auf die Ordner app-ssl und htdocs-ssl setzt, nutzt man die TLS-Terminierung des Apache, der von Hostsharing auf dem aktuellen Stand gehalten wird und auch unser Beschwerdeführer sollte zufrieden sein.

Im Übrigen gilt es als best practice, die TLS-Terminierung nicht der Anwendung, sondern einem reverse proxy zu überlassen. Konkret erhöht dies sogar die Sicherheit, weil Hostsharing die allfälligen Sicherheitsprobleme mit OpenSSL im Blick behält und passend reagiert statt dieses Problem auf den Endnutzer abzuwälzen.

Hostsharing befürwortet und unterstützt den Einsatz von TLS, erzwingt ihn aber nicht. Der besseren Lesbarkeit halber wiederholen wir auch nicht bei jeder Erwähnung einer Installationsoption eine Belehrung über die Risiken der Wahl.

=== Grundsätzliches ===

Der maßgebliche Autor dieser Anleitung ist Java-Experte und ihm ist sicherlich nicht vorzuwerfen, dass ihm "virtualenv" nicht geläufig ist. Die etwas umständlichere Installationsvariante birgt keine Sicherheitsrisiken. Zudem setzt der Autor implizit voraus, dass unseren Nutzern der Unterschied zwischen den ssl- und nicht-ssl-Konfigurationoptionen bekannt ist. Dies - genauer die Beschreibung der Ordner und der SSL/TLS-Terminierung - geht unter anderem aus der maßgeblichen Endandwender-Dokumentation hervor.

--[[Benutzer:Web|Web]] ([[Benutzer Diskussion:Web|Diskussion]]) 21:26, 11. Aug. 2015 (CEST)

=== Fehler in Beispiel-Config? ===
Kann es sein, dass da ein paar "/" fehlen?
z.B. schreibt
filesystem_folder = ~/.config/radicale/collections
dann alle einträge in eine datei, was nicht gut endet.
~/.config/radicale/collections gibts unterordner per user