In diesem dritten und vorerst letzten Teil wird auf die Anbindung von stationären und mobilen Clients eingegangen. Dabei kommen vorerst iOS und Mozilla Thunderbird zum Einsatz. Der fiktive ownCloud Server ist dabei unter der URL https://owncloud.dahlen.org/ mit dem Benutzer cloudmaster zu erreichen.

Client-Geräte und -Software

Die Nutzungsmöglichkeiten von ownCloud via iPhone oder anderen mobilen Geräten sind vielfältig. Neben einem Zugriff über die entsprechende ownCloud App können Kontakte und Kalenderdaten über das CardDAV resp. CalDAV Protokoll verwaltet werden, welches von iOS direkt unterstützt wird.

Geräte mit Apples iOS

Die entsprechenden Assistenten zur Einrichung in iOS sind recht straight-forward, benötigen aber etwas Vorarbeit auf der Server-Seite. Zur automatischen Erkennung der Möglichkeiten fragt iOS zunächst die Pfade

• /.well-known/carddav bzw.
• /.well-known/caldav ab.

Diese existieren in ownCloud nicht, ihre Funktionalität allerdings sehr wohl, nur an anderer Stelle. Am einfachsten ist es jetzt, die Anfragen per HTTP Redirect umzuleiten. Dazu wird die Konfiguration unter /etc/lighttpd/lighttpd.conf um einen Eintrag ergänzt, z.B. ab Zeile 22:

url.access-deny = ( „~“, „.inc“ )
url.redirect = (
„^/.well-known/carddav$“ => „/remote.php/carddav/“,
„^/.well-known/caldav$“ => „/remote.php/caldav/“
)

Außerdem ist es wichtig, daß man den eigenen Kalender in ownCloud über den Browser mindestens 1x aufruft. Erst dann werden die notwendigen Strukturen in ownClouds CalDAV-Server eingerichtet.

Dann kann die Anbindung via iPhone beginnen. Die Assistenten befinden sich in Einstellungen – Mail, Kontakte, Kalender – Account hinzufügen …. Aus der Liste der Möglichen Anbieter (iCloud, Exchange usw.) wählt man den letzten Punkt (Andere):

Die Dialoge für CardDAV und CalDAV sind im Wesentlichen identisch. Durch unsere Vorbereitung reicht es, den Namen des Server (owncloud.dahlen.org, ohne https://), den Benutzernamen und das Paßwort einzutragen. Alles andere wird bei Wahl von Weiter oben rechts automatisch ermittelt.

Und das war es dann auch schon. Der neue Kalender taucht in der Kalender-App auf und nimmt Termine entgegen. Die Enrichtung eines Kontakt-Accounts geschieht völlig analog und wird hier nicht weiter beschrieben.

Mozilla Thunderbird mit Lightning Add-On

Mozillas Mail-Client Thunderbird wird durch das Kalender-AddOn Lightning in die Richtung eines Personal Information Assistents, wie z.B. Outlook gerückt. Als Vertreter der Open Source Idee war zu erwarten, daß eine Anbindung an offene Standards möglich ist.

Zumindest für den Kalender gilt das auch. Nach der Installation von Lightning und dem Neustart von Thunderbird wird über das Menü Datei – Neu – Kalender der Assistent für einen neuen Kalender gestartet. Zunächst entscheidet man sich für einen Kalender im Netzwerk.

Im folgenden Dialog wählt man das Kalender-Format, was hier CalDAV ist. Der Dialog erwartet auch die Adresse, unter welcher der Kalender erreichbar ist. An dieser Stelle ist es leider nicht ausreichend einfach nur die URL des ownCloud-Servers anzugeben. Vielmehr wird hier die vollständige URL zum persönlichen Kalender erwartet.

Diese URL kann in ownCloud ausgelesen werden. Dazu wählt man in der Web-Oberfläche von ownCloud den Kalender und klickt dann oben rechts auf das Kalender-Symbol. Ein weiterer Klick auf das Weltkugel-Symbol offenbart dann den CalDAV-Link.

Gemäß den Beispieldaten in diesem Artikel lautet die CalDAV-Adresse meines Default-Kalenders
https://owncloud.dahlen.org/remote.php/caldav/principals/cloudmaster/defaultcalendar. Diese trägt man in den offenen Dialog ein und bestätigt mit Weiter.

Im nächsten Dialog-Schritt hat man noch die Möglichkeit die Darstellung des Kalendars zu personalisieren und eine E-Mail-Adresse zuzuordnen. Außerdem werden in einem Popup die Anmeldedaten abgefragt.

Schließlich kommt es zum letzten Schritt des Dialogs, in welchem man einfach nur auf Fertigstellen klickt. Das war’s.

Damit hat mein Protokoll zur Einrichtung des eigenen, abgesicherten ownCloud-Servers auf dem Raspberry PI und die Anbindung an Clients sein vorläufiges Ende erreicht. Es ist nicht ausgeschlossen, daß Ergänzungen für weiter Clients wie Android oder Outlook folgen.

Ich hoffe, daß meine Ausführungen dem ein oder anderem zur Hilfe reichen und freue mich auf Feedback.

Der Beitrag Die eigene Cloud auf dem Raspberry PI (Teil 3: Anbindung von Clients) erschien zuerst auf dahlen.org.

Dazu wurde die Web-Server-Software lighttpd installiert und die Kommunikation via Transport Layer Security (TLS) abgesichert. Mein (fiktiver) Web-Server ist nun ausschließlich unter https://owncloud.dahlen.org/ erreichbar.

Installation von ownCloud

Wegen der begrenzten Ressourcen des Raspberry PI wurde nicht auf das ownCloud-Paket der Distribution (Raspian) zurückgegriffen, da hier eine Abhängigkeit zum Apache 2 http-Server besteht. Dennoch kann das Gros der notwendigen Software aus den Paketquellen der Distribution genommen werden, z.B. PHP5 mit seinen Modulen:
$ sudo apt-get install php5-gd php5-curl php5-sqlite php5-cgi

PHP5

Nach der Installation von PHP5 sind bei Bedarf zwei Einstellungen anzupassen, welche Auswirkung auf den gleichen Aspekt haben: Die maximale Größe für Uploads nach ownCloud. Es handelt sich um folgende Parameter, die sich in der Datei /etc/php5/cgi/php.ini befinden:

• upload_max_filesize
• post_max_size

Ich habe beide Werte auf 16M gesetzt. In erster Linie möchte ich ownCloud für Kalender- und Kontaktdaten nutzen, aber mit 16MB sind auch mal ein Bild oder ein größeres Dokument drin.

Vor dem Beginn der eigentlichen Installation von ownCloud muß PHP5 noch via FastCGI angebunden werden. Dazu ist auch ein Neustart des Web-Servers notwendig:
$ sudo lighttpd-enable-mod fastcgi-php
$ sudo service lighttpd force-reload

ownCloud

Jetzt kann das ownCloud-Setup-Skript direkt vom Anbieter gezogen werden. Abgelegt wird es im Document-Root des Web-Servers /var/www/:
$ sudo wget -O /var/www/setup-owncloud.php \
https://download.owncloud.com/download/community/setup-owncloud.php

Außerdem sind noch Berechtigungen anzupassen, damit ownCloud Daten nachladen und installieren kann:
$ sudo chown www-data:www-data /var/www /var/www/setup-owncloud.php

Schließlich wird das Skript im Browser aufgerufen, gemäß Beispiel lautet die URL zum Setup https://owncloud.dahlen.org/setup-owncloud.php.

Es erscheint der Begrüßungsbildschirm der Installation. Dieser kann ohne Änderungen per Next bestätigt werden.
Der Startbildschirm der OwnCloud Installation

Im folgenden Dialog kann man das Zielverzeichnis der Installation auswählen, relativ zum Document Root. Auch hier reicht ein Klick auf Next, auch wenn man mit owncloud nicht einverstanden ist (dazu später mehr):

Im Hintergrund lädt ownCloud nun die aktuelle Version vom ownCloud-Server und entpackt sie im vorhin gewählten Zielverzeichnis. Je nach Internet-Anbindung kann dieser Schritt etwas dauern. Sein Abschluß wird durch den dritten Dialog berichtet, den man wieder über Next bestätigt.

Schließlich wird nach den Anmeldedaten des ersten Benutzers gefragt. Dieser wird automatisch zum Administrator. Nachdem man Benutzernamen und Passwort eingetragen hat, kann die Installation über die entsprechende Schaltfläche abgeschlossen werden.

Im letzten Dialog war ein roter Textabschnitt zu sehen. Sinngemäß wird dadrin darauf hingewiesen, daß alle Daten, die man ownCloud anvertraut ohne jede Zugangskontrolle abrufbar sind. Darum wird lighttpd (und damit ownCloud) jetzt erstmal runtergefahren:
$ sudo service lighttpd stop

Nun zu Ursache und Beseitigung der Warnung: ownCloud speichert die meisten seiner Daten in einem Unterverzeichnis namens data. Dieses Verzeichnis wird in der Regel über eine Datei namens .htaccess vor direkten Zugriffen aus dem Internet geschützt. Nur indirekt, über die ownCloud-Software und das dort integrierte Rechtemanagement soll der Zugriff erfolgen.

lighttpd bietet aber keine Unterstützung für die Anweisungen in der .htaccess-Datei, darum besteht auch kein Zugriffsschutz. Zwar bietet auch lighttpd ähnliche Mechanismen, aber ich wähle einen anderen Weg.

Als erstes ersetze ich /var/www/owncloud durch /var/www, weil ich keine weitere Anwendung auf dem Raspberry PI laufen lassen werde.
$ sudo mv /var/www /var/www.off
$ sudo mv /var/www.off/owncloud /var/www
$ sudo rm -r /var/www.off

Dann verschiebe ich das data-Verzeichnis aus dem Bereich des Webservers.
$ sudo mkdir -p /srv/owncloud
$ sudo chown www-data:www-data /srv/owncloud
$ sudo mv /var/www/data /srv/owncloud

Den neuen Ort des data-Verzeichnisses müssen wir ownCloud bekannt machen, dazu wird der alte Wert in der Konfigurationsdatei /var/www/config/config.php geändert.

Aus
'datadirectory' => '/var/www/owncloud/data',
wird also
'datadirectory' => '/srv/owncloud/data',

Zeit lighttpd (und damit owncloud) neu zu starten.
$ sudo service lighttpd start

Damit ist die Installation von ownCloud abgeschlossen. Sie steht (nur lt. meinem Beispiel) jetzt direkt unter https://owncloud.dahlen.org/ zur Verfügung.

Im nächsten Teil gehe ich auf die Anbindung von Kontakten und Kalender via iOS und anderen Clients ein.

Der Beitrag Die eigene Cloud auf dem Raspberry PI (Teil 2: ownCloud Installation) erschien zuerst auf dahlen.org.

Jetzt habe ich auch endlich eine Verwendung für die Himbeere 3,1415 gefunden: Meine eigene, kleine Cloud – mein Wölkchen also.

Motivation

Zunächst möchte ich noch meine Zielsetzung schärfen: Trotz der Auswahl von ownCloud als Server-Software geht es mir primär nicht um die Einrichtung einer Dateiablage oder ähnlichem. Vielmehr steht der weltweite Zugriff auf Kontakte und Kalenderdaten via Browser oder mobilem Endgerät im Vordergrund. Die dafür notwendigen Protokolle CalDAV und CardDAV sind in ownCloud integriert und die Installation der ownCloud-Software ist um ein Vielfaches einfacher als der dedizierten Varianten (z.B. DaviCAL).

Zwar kann man alle Leistungen kostenlos bei Google bekommen, doch liegen die persönlichen Daten dann eben bei Google. Natürlich muß das nicht zwangsläufig zu Mißbrauch führen (Don’t be evil, sagt Google). Aber ab und an wird Google sicherlich mal einen Blick auf die Daten werden, um die Benutzererfahrung zu verbessern. Anders wären Dienste wie Google Now gar nicht möglich.

Hard- und Software-Basis

Meine Beschreibung orientiert sich dabei an den Möglichkeiten eines Raspberry Pi, Modell B, 256MB Variante. Als Betriebssystem kommt die Debian Wheezy basierte Raspbian-Distribution zum Einsatz. Wegen der begrenzten Ressourcen wird nicht auf das ownCloud-Paket der Distribution zurückgegriffen, da hier eine Abhängigkeit zum Apache 2 http-Server besteht. Stattdessen wird auf LigHTTPd zurückgegriffen:
$ sudo apt-get install lighttpd

Damit ist der Webserver bereits installiert und liefert sein Platzhalter-Seite über HTTP aus. Allerdings handelt es sich um eine unverschlüsselte Verbindung. Die später notwendigen Anmelde-, meine Kontakt- und Kalenderdaten sollen so nicht verschickt werden. Vielmehr muß eine Absicherung über TLS, besser bekannt als SSL.

Absicherung der Kommunikation

Ich will erreichen, daß die Kommunikation mit den Clients (iPhone, Browser, etc.) verschlüsselt abläuft. Dazu würde theoretisch ein einfaches, selbst-signiertes Zertifikat reichen. Allerdings würden dann unbedarfte Anwender mit Dialogen konfrontiert werden, in denen Begriffe wie Gefahr, Sicherheitshinweis und nicht empfohlen vorkommen.

Der Grund ist, daß ein selbst-signiertes Zertifikat zwar für den Aufbau einer verschlüsselten Verbindung ausreicht, aber die Identität des Servers nicht bestätigt. Dies geht nur über eine Zertifikatskette, welche ausschließlich aus dem Client bekannten Certification Authorities (CA) besteht. Das heißt: Eine dem Client bekannte und als vertrauenswürdig eingestufte CA hat die Validität meines Server-Zertifikats mit ihrer Signatur bestätigt.

In meiner Beschreibung verwende ich als Hostnamen owncloud.dahlen.org und einen Benutzer namens cloudmaster. Weder die Domäne, noch der Benutzer existieren in der Realität.

Leider verlangen die im Browser vorinstallierten CAs teilweise horrende Gebühren für ihre Signatur. Doch es gibt kostenlose Ausnahmen, welche für meinen Anwendungsfall auch völlig ausreichend sind. Eine davon ist die Firma StartSSL.

Wichtig: Für die Erstellung eines durch StartSSL-signierten Zertifikats wird die eigene Domäne benötigt (wie dahlen.org). Ohne diese Domäne bleibt euch nur die Möglichkeit eines selbst-signierten Zertifikats. Auch muß der ownCloud-Host über einen Fully Qualified Domain Name (FQDN) erreichbar sein, also über einen Namen wie owncloud.dahlen.org.

Das erforderliche Software (OpenSSL) sollte bereits bei der Installation von Raspian mitgekommen sein, ansonsten schadet eine erneuter Versuch auch nicht.
$ sudo apt-get install openssl

Schlüssel und Zertifikate

Zunächst erstellt man einen privaten Schlüssel, mit welchem das spätere Server-Zertifikat abgesichert ist. Auf die Möglichkeit, diesen private key mit einem weiteren Kennwort abzusichern wird bewußt verzichtet:
$ openssl genrsa -out server.key 2048

Dann erstellt man einen Certificate Signing Request (CSR), eigentlich ist das der öffentliche Teil des privaten Schlüssels, welcher zur Signatur bei der CA eingereicht wird (oder eben selbst signiert wird):
$ openssl req -new -key server.key -out server.csr

Die gestellten Fragen sind gemäß der eigenen Umgebung anzugeben. Wichtig dabei: Das Feld Common Name (CN) muß den Namen und die Domäne (Fully Qualified Domain Name, FQDN) des eigenen ownCloud-Servers beinhalten. Der vollständige Dialog kann also wie folgt aussehen:

Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Nordrhein-Westfalen
Locality Name (eg, city) []:Toenisvorst
Organization Name (eg, company) [Internet Widgits Pty Ltd]:dahlen.org
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:owncloud.dahlen.org
Email Address []:cloudmaster@dahlen.org

Der erzeugte CSR wird jetzt bei StartSSL zur Signatur eingereicht. Diesen Prozeß muß ich glücklicherweise nicht beschreiben, denn das haben die Kollegen auf heise Security bereits getan. Im Ergebnis wird das signierte Zertifikat angezeigt, welches man kopiert und eine Datei namens server.crt speichert. Es ist dabei enorm wichtig, daß der Inhalt der Datei nicht durch Umbrüche oder ähnliches verändert wird.

Drei Dateien befinden sich nun im aktuellen Verzeichnis:

• server.key – der private Schüssel zum Zertifikat
• server.csr – der öffentliche, unsignierte Schlüssel
• server.crt – das öffentliche, signierte und damit „zertifizierte“ Schlüssel

Der CSR wird nicht mehr benötigt und kann gelöscht werden. Eine weitere Datei muss noch besorgt werden, um die Kette der Zertifikat-Signaturen zu schliessen: Das Intermediate Certificate von StartSSL. Diese lässt sich direkt abrufen:
$ wget -O ca.pem http://www.startssl.com/certs/sub.class1.server.ca.pem

Damit ist die Zertifikatskette geschlossen und die Gültigkeit des eigenen Server-Zertifikats kann überprüft werden:
$ openssl verify -CAfile ca.pem server.crt
Erwartetes Ergebnis:

server.crt: OK

Als letzten Schritt der Zertifikat-Vorbereitung müssen jetzt noch der private Schlüssel und das Zertifikat in eine Datei überführt werden.
$ cat server.key server.crt > server.pem

Installation in lighttpd

Nun ist es Zeit, die generierten Teile der SSL-Infrastruktur dem Webserver bekannt zu machen:
$ sudo cp server.pem /etc/lighttpd/
$ sudo cp ca.pem /etc/lighttpd/

Außerdem muß die Konfiguration unter /etc/lighttpd/lighttpd.conf angepasst werden. Die Änderungen beginnen mit der Änderung der Port-Nummer (ca. ab Zeile 15). Aus
server.port = 80
wird
server.port = 443
ssl.engine = "enable"
ssl.pemfile = "/etc/lighttpd/server.pem"
ssl.ca-file = "/etc/lighttpd/ca.pem"

Letztendlich wird damit der Zugriff über einfaches, unverschlüsseltes HTTP abgeschaltet. Durch einen Neustart wird dies aktiviert:
$ sudo service lighttpd restart

Danach ist der Dienst nur noch über HTTPS auf Port 443 zu erreichen, also https://owncloud.dahlen.org/.

Im nächsten Teil beschreibe ich, wie jetzt ownCloud ins Spiel kommt.

Der Beitrag Die eigene Cloud auf dem Raspberry PI (Teil 1: lighttpd und SSL) erschien zuerst auf dahlen.org.