ownCloud 9 auf Ubuntu Server 16.04 LTS mit nginx, MariaDB, PHP 7 und Let’s Encrypt

ownCloud erfreut sich als „Selfmade-Cloud“ nach wie vor großer Beliebtheit. Mit der persönlichen Cloud erhält man von überall aus Zugriff auf seine Dateien, Kontakte und Kalender, ohne sich jedoch von Cloud-Anbietern wie Google, Microsoft oder Dropbox abhängig zu machen.

Dieser Artikel zeigt nun die Installation und Konfiguration von ownCloud 9 auf Ubuntu Server 16.04 LTS mit nginx, MariaDB, PHP 7 und Let’s Encrypt.

Zu diesem Thema gibt es bereits einen älteren Beitrag: ownCloud auf Ubuntu Server mit nginx, MariaDB und PHP. Dieser war recht erfolgreich und zeigte, dass das Interesse an dieser Konfiguration gegeben ist. Allerdings steht die Zeit in der IT-Welt ja nicht still, so dass sich mittlerweile einiges geändert hat:

• Mit Ubuntu 16.04 LTS („Xenial Xerus“) wurde die nächste Version des Betriebssystems mit verlängertem Support-Zeitraum veröffentlicht.
• ownCloud unterstützt neuerdings PHP 7 (ab ownCloud 8.2), was deutliche Performance-Verbesserungen mit sich bringt.
• Mit ownCloud 9 ist die nächste große Version der Cloud-Software erschienen.
• Let’s Encrypt (Zertifizierungsstelle für kostenlose SSL-Zertifikate) hat die Beta-Phase verlassen.

Hier haben sich somit viele Faktoren geändert, so dass ich mich dazu entschlossen habe, den alten Artikel nicht zu aktualisieren, sondern einen komplett neuen Beitrag zu verfassen.

Wenn sich zukünftig Änderungen am Vorgehen ergeben, wird der Artikel aktualisiert:

Zielsetzung und Aufwand

Folgende Ziele sollen mit diesem Artikel erreicht werden:

• Installation/Konfiguration von ownCloud 9 unter Linux (Ubuntu Server 16.04 LTS) mit nginx (Webserver), MariaDB (Datenbank) und PHP 7.
• Erhöhte Sicherheit (PHP-Konfiguration, SSL, ownCloud-Konfiguration laut ownCloud Server Administration Manual).
• Verschlüsselte Verbindung (SSL/HTTPS mit Let’s Encrypt Zertifikat) zur ownCloud über das lokale Netzwerk und über das Internet (DynDNS).
• ownCloud soll in einem Unterverzeichnis des Webservers liegen, d.h. nicht über meinedomain.de, sondern über meinedomain.de/owncloud erreichbar sein. Dies macht es möglich, dass mehrere Webseiten über die gleiche Domain gehostet werden können.
• Im Administrator-Bereich der ownCloud sollen keine Warnungen/Fehler bzgl. Sicherheit und Konfiguration angezeigt werden.

Folgende Programmversionen kommen dabei zum Einsatz.

• Ubuntu Server 16.04.1 LTS („Xenial Xerus“)
• nginx 1.11.3
• MariaDB 10.1.17
• PHP 7
• ownCloud 9.0.2

Zeitaufwand: ca. 3 Stunden

Wichtig: Alle gezeigten Schritte sind auf die o.g. Zielsetzung ausgerichtet und sollten daher genau befolgt werden. Wenn man nur ein kleines Detail übersieht (oder leicht anders macht), kann es im weiteren Verlauf zu Fehlern führen.
Falls es mal klemmen sollte: Bevor das Rätselraten losgeht, wo es nun genau hakt, sollte man auf jeden Fall zunächst einen Blick in die Logs werfen (im Verzeichnis /var/log/). Besonders das nginx Error-Log bringt einen meist auf die richtige Fährte.

Warum die Kombination mit nginx und MariaDB Sinn macht

An dieser Stelle vielleicht erst einmal ein paar Worte, warum ich mich für diese Kombination entschieden habe und welche Vorteile sich hierdurch ergeben:

Der Begriff „LAMP-Stack“ dürfte dem einen oder anderen gebräuchlich sein. Dabei handelt es sich quasi um die Standard-Umgebung, wenn es darum geht, dynamische Webseiten zu hosten: Linux, Apache, MySQL und PHP.

Natürlich kann ownCloud auf einem solchen LAMP-Stack betrieben werden: Bei der Installation der offiziellen ownCloud-Pakete bringen diese automatisch Apache, MySQL und PHP mit, sofern noch nicht auf dem System vorhanden.

Warum zeigt der Artikel nun die Installation mit einem anderen Webserver und einem anderen Datenbank-System? Die Kombination Linux, nginx, MariaDB/MySQL und PHP wird dabei auch als LEMP-Stack bezeichnet.
Gerade der Einsatz von nginx als Webserver und MariaDB als DB-System bieten dabei einige Vorteile:

• nginx arbeitet ressourcenschonender als Apache: Dies hängt zum großen Teil damit zusammen, wie die Webserver Verbindungen zu den Clients abarbeiten. Während Apache pro Verbindung neue Prozesse bzw. Threads erstellt, was bei vielen gleichzeitigen Connections sehr speicherintensiv ist, arbeitet nginx mit einem Thread-Pool. Dies ist eine feste, konfigurierbare Anzahl an Threads, die die Verbindungen asynchron abarbeiten.
  Somit ist nginx klar im Vorteil, wenn viele Verbindungen gleichzeitig abzuarbeiten sind, oder auch, wenn nur begrenzte Hardware-Ressourcen zur Verfügung stehen (z.B. auf einem Raspberry Pi).
• MariaDB ging ursprünglich aus einem Fork von MySQL hervor. Dabei ist MariaDB bis heute binärkompatibel zu MySQL, d.h. ist ein 1:1-Ersatz für MySQL (sog. drop-in replacement) und alle von MySQL bekannten Befehle/Tools funktionieren damit auch mit MariaDB. Die Entscheidung, ob man nun MariaDB oder MySQL als Datenbank für ownCloud verwendet, ist daher zunächst eher nebensächlich.
  Jedoch haben Ende 2012 etliche Linux-Distributionen MySQL durch MariaDB als Standard-Datenbanksystem ersetzt. MariaDB macht momentan einen sehr zukunftssicheren Eindruck, daher fiel die Wahl bei diesem Artikel auf MariaDB. Wer dennoch gerne MySQL einsetzen möchte, kann dies auch gerne tun. Die Schritte zur Einrichtung von ownCloud sind im Grunde genommen dieselben.

Voraussetzungen

Betriebssystem/Hardware

Der Artikel beschreibt die Einrichtung von ownCloud auf einem neu installiertem Ubuntu Server 16.04 LTS („Xenial Xerus“). Für einen eigenen Home-Server bietet sich v.a. auf die Verwendung einer LTS-Version (Long Term Support) von Ubuntu an, da diese Versionen einer verlängerten Support-Zeitraum haben. Daher können LTS-Versionen über einen langen Zeitraum betrieben werden, ohne dass die Notwendigkeit besteht, jedes Distributions-Update durchzuführen.
Generell ist die eingesetzte Linux-Distribution allerdings unerheblich. Die Installation von ownCloud und den benötigten Komponenten funktioniert auf anderen Distributionen (z.B. Debian) nahezu identisch.

Auch die verwendete Server-Hardware ist nicht weiter entscheidend. Alle Schritte des Artikels können auch angewendet werden, wenn beispielsweise ein Raspberry Pi (Affiliate-Link) mit Raspbian als Betriebssystem oder ein Intel NUC (Affiliate-Link) mit Debian zum Einsatz kommt.
Es ist ebenso möglich, eine virtuelle Linux-Maschine (VM) für ein ownCloud-Projekt zu verwenden. Wie man Ubuntu Server mittels Hyper-V auf einem Windows-Rechner installiert und optimal einrichtet, zeigt der Artikel Ubuntu Server als Hyper-V Gastsystem installieren und optimal einrichten. Besonders reizvoll ist diese Vorgehensweise, da mit einer virtuellen Maschine „Prüfpukte“ definiert werden können. Dies sind Snapshots der VM, die den Zustand der Maschine speichern. Falls bei der Installation/Einrichtung etwas schieflaufen sollte, kann man in wenigen Sekunden das System wieder auf einen früheren Zeitpunkt zurück setzen. Darüber hinaus kann die automatische Sicherung einer (Hyper-V)-VM leicht in eine bestehende Backup-Strategie mit eingebunden werden. Dies macht Client-seitige Backups (fast) überflüssig.

Zugriff per SSH

Nach der Installation des Betriebssystems ist lässt man einen Server üblicherweise „headless“ laufen, d.h. ohne Monitor, Maus und Tastatur. Der Zugriff erfolgt dann normalerweise aus der Ferne per SSH (z.B. mit PuTTY). Eine genauere Beschreibung hierzu findet man ebenfalls im Artikel Ubuntu Server als Hyper-V Gastsystem installieren und optimal einrichten.

DynDNS

Damit der Zugriff auf die eigene Cloud später nicht nur auf das lokale Netzwerk begrenzt ist, sondern auch über das Internet möglich ist, sollte der Router per DynDNS zu erreichen sein. Ohne DynDNS ändert sich in den meisten Fällen die (externe) IP des Routers nach einer Zwangstrennung (in der Regel alle 24 Stunden), wodurch ein Zugriff sehr erschwert wird. Dazu kann ein beliebiger DynDNS-Dienst genutzt werden.

Aus eigener Erfahrung kann ich hier den kostenlosen DynDNS-Dienst GoIP empfehlen. Im Artikel verwende ich daher beispielhaft die DynDNS-Adresse owncloud9tutorial.goip.de.
Sehr zuverlässig ist auch der Webhoster All-inkl.com: Ab dem Webhosting-Paket „PrivatPlus“ ist ebenfalls ein DynDNS-Dienst enthalten, mit dem ich noch nie Probleme (Downtime, etc.) hatte.

Arbeiten mit Root-Rechten

Ein letzter Hinweis, bevor es endlich losgehen kann: Für die Konfiguration und Einrichtung von ownCloud und aller benötigter Programme, ist es meist erforderlich, mit Root-Rechten zu arbeiten. Damit nicht vor jedem Befehl ein sudo eingegeben werden muss, arbeite ich bei der Einrichtung des Rechners mit dauerhaften Root-Rechten. Diese erlangt man über den Befehl:

sudo -s

Am Ende sollte man sich dann mit exit wieder abmelden. Ein dauerhaftes Arbeiten mit Root-Rechten ist aus Gründen der Sicherheit nicht empfohlen.

Genug der Vorrede, nun geht es endlich los…

Updates einspielen

Zunächst bringen wir das System auf den aktuellsten Stand:

apt-get update && apt-get upgrade && apt-get dist-upgrade 
reboot

Dieser Befehl aktualisiert die Paket-Liste, installiert verfügbare Updates und spielt auch die Updates ein, die neue Pakete oder deren Abhängigkeiten mitbringen.

Statische IP-Adresse zuweisen

Mit einem frisch installierten Linux bekommt der Rechner in den meisten Fällen durch den Router eine dynamische IP per DHCP. Da sich diese IP bei jedem Neustart des Rechners ändern kann, ist dies für einen Server nicht gerade optimal. Daher wird zunächst eine statische IP-Adresse zugewiesen. Dazu muss folgende Konfigurations-Datei bearbeitet werden:

nano /etc/network/interfaces

Hier sind alle Netzwerkkarten aufgelistet. eth0 ist dabei die primäre Netzwerkkarte. Hier passen wird den Eintrag entsprechend an. In diesem Beispiel gehe ich davon aus, dass der verwendete Router die IP 192.168.178.1 hat und der Linux-Rechner die statische IP 192.168.178.20 haben soll. Diese Einstellungen müssen im konkreten Fall an die eigene Netzwerk-Infrastuktur angepasst werden.

auto eth0
iface eth0 inet static
address 192.168.178.20
netmask 255.255.255.0
network 192.168.178.0
broadcast 192.168.178.255
gateway 192.168.178.1
dns-nameservers 192.168.178.1

Nach einem Neustart des Rechners ist dieser fortan immer unter der IP 192.168.178.20 zu erreichen.

Hinweis: Durch diese Änderung ist es oftmals nicht mehr möglich, den Rechner mit seinem Rechnernamen im Netzwerk anzusprechen (v.a. beim SSH-Zugriff per PuTTY). Hier sollte ab jetzt auch immer die angegebene IP-Adresse verwendet werden, die sich ja auch nicht mehr ändert.

Programm-Installation

Vor der ownCloud-Installation benötigen wir nun zunächst einmal den Webserver (nginx), MariaDB und PHP.

nginx installieren

In den Paketquellen von Ubuntu 16.04 ist nginx 1.10.0 enthalten, also eine recht aktuelle Version. Um dennoch unabhängig von den Ubuntu-Paketquellen zu sein, empfehle ich, das offizielle nginx-Repository in die Paketquellen mit aufzunehmen. Allerdings ist es auch kein Problem, diesen Schritt zu überspringen und die jeweilige nginx-Version zu verwenden, die in den Ubuntu-Paketquellen enthalten ist. Letzten Endes ist dies Geschmackssache.

apt-get update 
apt-get install nginx

Um später keine Warnungen bei der Installation des Webservers angezeigt zu bekommen, muss der Schlüssel des nginx-Repositories im System bekannt gemacht werden:

wget -O - http://nginx.org/keys/nginx_signing.key | apt-key add -

Anschließend werden die Paketquellen in die sources.list hinzugefügt:

nano /etc/apt/sources.list

Dazu wird am Ende dieser Datei folgender Inhalt eingefügt. Wenn eine andere Distribution/Version zum Einsatz kommt, müssen diese Zeilen angepasst werden (siehe nginx: Linux packages).

# Nginx (Mainline)
deb http://nginx.org/packages/mainline/ubuntu/ xenial nginx
deb-src http://nginx.org/packages/mainline/ubuntu/ xenial nginx

Hinweis: Diese Zeilen sorgen dafür, dass die Mainline-Version von nginx genutzt wird. Die Mainline stellt den aktuellen Entwicklungszweig dar und gilt als stabil. Es gibt darüber hinaus noch den Stable-Entwicklungszweig. Dieser ist ein Fork aus dem Mainline-Entwicklungszweig, der aber nicht unbedingt stabiler ist als die Mainline (siehe nginx-Blogbeitrag). Ein anderer Beitrag aus dem nginx-Blog  empfiehlt explizit die Verwendung des Mainline-Zweigs.

Nach dem Hinzufügen der Paketquellen folgt die eigentliche Installation von nginx:

apt-get update 
apt-get install nginx

Die Installation des Webservers kann getestet werden, indem man die IP des Rechners im Browser aufruft:

MariaDB installieren

Bei der Installation von MariaDB verhält es sich ähnlich wie schon bei nginx zuvor: Man kann die Version nehmen, die in den Paketquellen von Ubuntu enthalten ist (10.0), oder man fügt für größere Flexibilität das MariaDB-Repository manuell den Paketquellen hinzu. Auf diese Weise kann man die neuste Version von MariaDB installieren (10.1).
Die MariaDB-Homepage liefert dazu ein praktisches Repository Configuration Tool. Hier die notwendigen Schritte:

Zunächst fügen wir den Key-Server für MariaDB hinzu (sonst gibt es im weiteren Verlauf u.U. Warnungen):

apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8

Dann werden die Paketquellen hinzugefügt:

nano /etc/apt/sources.list

Folgende Zeilen fügen wir am Ende der Datei hinzu. Auch hier muss bei einer anderen Distribution/Version etwas anderes angegeben werden (siehe Repository Configuration Tool weiter oben).

# MariaDB 10.1 repository list
# http://mariadb.org/mariadb/repositories/
deb [arch=amd64,i386] http://ftp.hosteurope.de/mirror/mariadb.org/repo/10.1/ubuntu xenial main
deb-src http://ftp.hosteurope.de/mirror/mariadb.org/repo/10.1/ubuntu xenial main

Nun kann die Datenbank installiert werden:

apt-get update 
apt-get install mariadb-server

Im Rahmen der Installation wird auch gleich ein Root-Passwort für den Datenbank-Zugriff festgelegt. Aus Sicherheitsgründen sollte man diesen Schritt nicht überspringen und ein ausreichend sicheres Passwort angeben:

PHP installieren

Nun fehlt nur noch die Installation von PHP. Wir nehmen hier die neuste Version von PHP (PHP 7), da diese praktischerweise in den Paketquellen von Ubuntu 16.04 enthalten ist und im Vergleich zu PHP 5 (ja, die Vorgängerversion von PHP 7 war tatsächlich PHP 5) deutliche Performance-Vorteile mit sich bringt.

Die ownCloud-Dokumentation liefert einen Hinweis auf die benötigten Pakete. Aktuell werden noch die Pakete für PHP 5 gelistet, diese sind prinzipiell aber auch für PHP 7 verfügbar. Einige dieser Pakete werden nur benötigt, wenn spezielle Features von ownCloud zum Einsatz kommen sollen.

Es können durchaus noch mehr Pakete notwendig sein, wenn spezielle Features von ownCloud zum Einsatz kommen sollen, aber für den Anfang reicht die Installation folgender Pakete:

apt-get update 
apt-get install php7.0-fpm php7.0-gd php7.0-mysql php7.0-curl php7.0-xml php7.0-zip php7.0-intl php7.0-mcrypt php7.0-mbstring php7.0-bz2 php-apcu

Wenn später weitere Pakete benötigt werden, können diese jederzeit nachinstalliert werden.

Konfiguration des Servers

Nachdem nun alle benötigten Programm-Pakete installiert sind, müssen diese vor der Installation von ownCloud noch konfiguriert werden.

Konfiguration nginx (Teil 1)

Die meiste Arbeit macht dabei die Konfiguration des Webservers. Ich habe mich bemüht, diesen Abschnitt relativ kompakt zu halten, jedoch ist die nginx-Konfiguration leider etwas komplexerer Natur. Hier macht es durchaus Sinn, sich mit der Funktionsweise von nginx auseinander zu setzen. Gerade wenn es im weiteren Verlauf etwas hakt, ist es nur von Vorteil, wenn man sich ein wenig mit der Materie auskennt.

Virtuelle Hosts und Konfigurations-Dateien von nginx

Mit nginx können (ähnlich wie bei Apache) virtuelle Hosts definiert werden. Ein virtueller Host stellt dabei eine separate Konfiguration für eine Website/Webdienst/Webanwendung dar. Dabei spielen folgende Dateien und Verzeichnisse eine entscheidende Rolle:

• /etc/nginx/nginx.conf: Globale Konfigurations-Datei von nginx. Hier werden die globalen Einstellungen definiert.
• /etc/nginx/conf.d: In diesem Verzeichnis werden die virtuellen Hosts gespeichert. Pro Host wird dazu eine Datei mit der Endung *.conf angelegt. Alle Dateien mit einer anderen Dateiendung werden dabei ignoriert (dies kann genutzt werden, um virtuelle Hosts gezielt an- und abzuschalten).

Dabei arbeiten all diese Konfigurations-Dateien zusammen: Die globale Konfiguration vererbt alle Einstellungen an die Konfigurationen der aktiven virtuellen Hosts. Ein virtueller Host kann dabei eine geerbte Einstellung jederzeit überschreiben.

Sinnvolle Aufteilung in mehrere virtuelle Hosts

Warum sollte man nun mehrere virtuelle Hosts verwenden? Reicht hier nicht ein virtueller Host aus?

In diesem Artikel geht es hauptsächlich um die Einrichtung von ownCloud. Hierfür würde prinzipiell ein einzelner virtueller Host vollkommen ausreichen. Dennoch sollte ein Webserver so flexibel sein, dass auch mehrere Webanwendungen über den gleichen Server gehostet werden können. So könnte beispielsweise später der Wunsch aufkommen, neben ownCloud auch noch einen kleinen WordPress-Blog auf der gleichen Maschine zu betreiben.

Um diese Flexibilität zu erreichen, gibt es nun verschiedene Ansätze:

• Ein einzelner virtueller Host: Hierbei werden alle Webseiten über den gleichen virtuellen Host konfiguriert. Auf den ersten Blick ist dies vermutlich die einfachste Lösung, jedoch wird die Konfigurations-Datei hierbei schnell unübersichtlich und es steigt das Risiko, dass man sich durch einen kleinen Fehler in der Konfiguration alle gehosteten Webanwendungen lahmlegt.
• Ein virtueller Host pro Webanwendung: Hierbei werden die Konfigurationen pro Webseite/Webanwendung strikt getrennt. Damit ist so gut wie ausgeschlossen, dass Änderungen an einem virtuellen Host die jeweils andere Webanwendung beeinflussen kann. Daher ist dieser Ansatz deutlich flexibler und weniger fehleranfällig.
  Dennoch gibt es hierbei ein Problem: Ein virtueller Host wird durch einen Server-Namen (die URL) und einen Port definiert. Die Kombination aus Name und Port muss sich dabei von allen anderen virtuellen Hosts unterscheiden. In unserem Fall wird aber immer die gleiche URL (die DynDNS-Adresse) verwendet, da die meisten Router keine Möglichkeit bieten, sich zeitgleich über mehrere DynDNS-Adressen anzumelden. Daher müssen sich hier gezwungenermaßen die Ports der Webanwendungen unterscheiden. Dies ist aber eher unkomfortabel, da zum einen mehrere Ports in der Firewall des Routers geöffnet werden müssen (Sicherheitsrisiko), zum anderen müssen alle Clients die richtigen Ports verwenden (in jeder URL-Eingabe muss der konkrete Port spezifiziert werden). Dies macht diese Lösung nicht sehr benutzerfreundlich und ich rate eher davon ab.
• Mehrere virtuelle Hosts + Reverse-Proxy: Es gibt allerdings auch einen weiteren Ansatz, mit dem man die Flexibilität von getrennten virtuellen Hosts und gleichzeitig nicht die oben genannten Nachteile hat. Dabei dient ein zentraler virtueller Host als Gateway (mit der DynDNS-Adresse und den Standard-Ports 80 und 443). Dieser „Gateway-Host“ bedient sich nun den Reverse-Proxy-Fähigkeiten von nginx, um eine Anfrage eines Clients gezielt an weitere virtuelle Hosts weiter zu leiten. Die Hosts der einzelnen Webanwendungen laufen mit dem gleichen Server-Namen (die lokale IP) und auf getrennten Ports. Da dies aber alles lokal auf dem Webserver geschieht, müssen keine weiteren Ports nach außen hin geöffnet werden. Der zentrale Anlaufpunkt für alle Clients ist dabei immer der Gateway-Host, der die Anfragen dann zielgerichtet an andere virtuelle Hosts (oder sogar andere Webanwendungen) weiterleitet.

Die letzte Lösung ist mit Abstand die flexibelste, aber leider auch die komplizierteste. Dennoch habe ich mich dazu entschieden, diesen Ansatz im weiteren Verlauf des Artikels zu verfolgen.

Als praxistaugliches Beispiel soll hier neben ownCloud auch ein virtueller Host speziell für die Erzeugung eines Let’s Encrypt Zertifikats genutzt werden (mehr Informationen zu Let’s Encrypt folgen später). Durch ein konkretes Beispiel sollte das Vorgehen dabei leicht verständlich sein.

Wenn neben ownCloud auch weitere Web-Anwendungen gehostet werden sollen:
Let’s Encrypt ist natürlich keine „echte“ Web-Applikation im eigentlichen Sinne, daher ist das hier gezeigte Beispiel evtl. nicht wirklich repräsentativ. Daher habe ich in einem weiteren Artikel (der auf diesem Tutorial aufbaut) die Einrichtung einer weiteren Web-Anwendung am Beispiel von WordPress durchgespielt und meine Erfahrungen geschildert: Zweite Web-Anwendung neben ownCloud/Nextcloud einrichten (am Beispiel WordPress). Dabei gilt es einiges zu beachten, aber der Beitrag sollte auf jeden Fall einen Anhaltspunkt liefern, auch wenn es sich bei der Anwendung nicht um WordPress handeln sollte.

Leider können nicht einfach alle Konfigurations-Dateien bzw. virtuelle Hosts auf einmal erstellt werden, da zunächst die Erzeugung eines SSL-Zertifikats notwendig ist, um mit den folgenden Schritten fortzufahren. Daher werden sämtliche Konfigurationen des Webservers sukzessive vorgenommen (Reihenfolge ist wichtig!).

Hinweis: Wer kein Let’s Encrypt Zertifikat verwenden möchte, kann auch ein selbst signiertes Zertifikat erzeugen und verwenden. Was dafür zu tun ist, ist im alten Artikel über ownCloud auf Ubuntu Server erklärt (Abschnitt Selbst signiertes Zertifikat erstellen). Man sollte sich nur darüber im Klaren sein, dass ein selbst signiertes Zertifikat auch Nachteile mit sich bringt (z.B. Warnungen in Browsern).
Wenn sein selbst signiertes Zertifikat zum Einsatz kommt, können hier alle Schritte übersprungen werden, die mit der Generierung und Einbindung des Let’s Encrypt Zertifikats zusammenhängen.

Allgemeine nginx-Konfiguration anpassen

Zunächst werfen wir einen Blick auf die globale nginx-Konfiguration:

nano /etc/nginx/nginx.conf

Hier sollten eigentlich keine Anpassungen notwendig sein, da die Standard-Werte in den meisten Fällen bereits passen. Die wichtigsten Einstellungen sind dabei:

• user: Gibt den Benutzer an, unter dem der Webserver läuft. Dies sollte der User www-data sein.
• worker_processes: Gibt die Anzahl der Threads an, die zum Abarbeiten der Verbindungen genutzt werden. Wird hier auto angegeben, wird pro CPU-Kern ein Thread angelegt. Dies ist in den meisten Fällen auch die richtige Einstellung.
• server_tokens: Durch die Angabe off wird verhindert, dass nginx (z.B. auf Fehlerseiten) Versions-Informationen präsentiert. Aus Sicherheitsgründen sollte man dies ausstellen. Dies ist die einzige Variable, die man hier manuell hinzufügen muss (server_tokens off; im HTTP-Block dieser Datei).

Default-Seite deaktivieren

nginx ist nach der Installation so konfiguriert, dass eine sog. Default-Seite aktiv ist. Diese sieht man beim Aufruf mit dem Browser (siehe oben). Da diese Default-Seite nur dazu gedacht ist, die initiale nginx-Installation zu testen, kann diese deaktiviert werden.

Dazu benennt man einfach die Datei /etc/nginx/conf.d/default.conf um:

mv /etc/nginx/conf.d/default.conf /etc/nginx/conf.d/default.conf_disabled

Durch das Ändern der Dateiendung wird dieser virtuelle Host nicht mehr geladen, jedoch geht die Standard-Konfiguration dadurch auch nicht verloren (man könnte diese Datei auch einfach löschen).

Vorbereitung der Verzeichnisstruktur

Zunächst werden die Verzeichnisse für Let’s Encrypt und ownCloud angelegt. Die Besitzrechte sollten dabei beim Webserver-User (www-data) liegen:

mkdir -p /var/www/letsencrypt
mkdir -p /var/www/owncloud
mkdir -p /var/owncloud_data
chown -R www-data:www-data /var/www
chown -R www-data:www-data /var/owncloud_data

Anlegen des „Gateway-Hosts“

Nun gilt es zunächst einmal den virtuellen Host für den Gateway anzulegen. Dieser nimmt zunächst nur die Verbindungen von Clients entgegen und leitet diese an weitere virtuelle Hosts weiter, die dann quasi die Arbeit erledigen.

Zum jetzigen Zeitpunkt soll zunächst nur einmal die Weiterleitung an einen Let’s Encrypt Host stattfinden.

Dazu legen wir im ersten Schritt den Gateway-Host an. Der Name der Datei ist erst einmal unwichtig, ich benenne diese einfach wie die (Haupt-)Domain:

nano /etc/nginx/conf.d/owncloud9tutorial.goip.de.conf

Hier fügen wir nun folgenden Inhalt ein:

server {
	listen 80 default_server;
	server_name owncloud9tutorial.goip.de 192.168.178.20;

	root /var/www;
	
	location ^~ /.well-known/acme-challenge {
		proxy_pass http://127.0.0.1:81;
		proxy_redirect off;
	}		
}

Dieser virtuelle Host lauscht somit zunächst nur einmal auf Port 80 (HTTP) und hört auf die DynDNS-URL bzw. die lokale IP des Servers. Der einzige location-Block wird später für die Erzeugung des SSL-Zertifikats benötigt und leitet die Anfrage auf einen anderen virtuellen Host weiter (proxy_pass).

Anlegen des Hosts für Let’s Encrypt

Der nächste Schritt besteht nun darin, den virtuellen Host für Let’s Encrypt anzulegen. „Spezialisierte“ Hosts kennzeichne ich mit einem zusätzlichen Unterstrich und dem Namen des Dienstes:

nano /etc/nginx/conf.d/owncloud9tutorial.goip.de_letsencrypt.conf

Dieser Host ist dabei sehr einfach aufgebaut:

server {
	listen 127.0.0.1:81;
	server_name 127.0.0.1;	
	
	location ^~ /.well-known/acme-challenge {
		default_type text/plain;
		root /var/www/letsencrypt;
	}
}

Gelauscht wird auf 127.0.0.1:81. Hier könnte man auch einen anderen beliebigen Port verwenden, dieser muss nur mit dem Port des proxy_pass des Gateway-Hosts übereinstimmen. Dadurch, dass auf der Loopback-Adresse 127.0.0.1 gelauscht wird und mit dem entsprechenden server_name sorgt man dafür, dass dieser virtuelle Host nur auf dem lokalen Rechner aufgerufen werden kann. Dadurch wird es unmöglich, diesen Host direkt anzusprechen, d.h. ohne vorher den Gateway-Host passiert zu haben.

Nach einem Neustart von nginx sind wir nun bereit, das SSL-Zertifikat erzeugen zu lassen:

service nginx restart

SSL-Zertifikat mit Let’s Encrypt erzeugen

Die Konfiguration des Webservers ist nun soweit abgeschlossen, dass zunächst das SSL-Zertifikat generiert werden kann

Port-Forwarding einrichten

Hierfür ist es wichtig, dass der Server auch aus dem Internet aus erreichbar ist. Hierfür muss ein Port-Forwarding für die Ports 80 (HTTP) und 443 (HTTPS) im Router konfiguriert werden, ansonsten ist die VM nur im lokalen Netzwerk erreichbar.

Das Einrichten von Port-Forwarding unterscheidet sich von Router zu Router. Das hier gezeigte Vorgehen bezieht sich auf eine FritzBox:

• Die Erweiterte Ansicht muss aktiv sein (Menü rechts neben den MyFritz! Einstellungen).

• Unter Internet > Freigaben öffnen wir den Reiter Portfreigaben.
• Hier klickt man auf den Button Neue Portfreigabe.
• Portfreigabe aktiv für: Andere Anwendungen.
• Bezeichnung: beliebig (z.B. HTTP).
• Protokoll: TCP
• von Port/bis Port: 80
• an Computer: Name der VM (in diesem Fall UbuntuServerTest) oder IP-Adresse (192.168.178.20)
• an Port: 80

Das gleiche muss noch einmal für Port 443 (HTTPS) wiederholt werden, da ansonsten der verschlüsselte Zugriff per HTTPS nicht möglich ist. Bitte zwei einzelne Portfreigaben einrichten und nicht eine einzige mit Freigabe-Ports 80 bis 443: hier würde man unnötigerweise zu viele Ports öffnen.

Darüber hinaus muss auch DynDNS auf dem Router eingerichtet werden. Das Vorgehen dazu ist abhängig vom verwendeten Router und auch vom DynDNS-Anbieter. Wie man DynDNS mit GoIP auf verschiedenen Routern einrichtet, ist detailliert auf der GoIP-Hilfeseite erklärt.

Erzeugung eines SSL-Zertifikats mittels Let’s Encrypt

Eine gute Anleitung zum Erzeugen von Let’s Encrypt Zertifikate auf verschiedenen Betriebssystemen und Webservern findet man auf der Certbot-Homepage.

Bei Ubuntu 16.04 ist Let’s Encrypt bereits in den Paketquellen enthalten, daher entfällt das manuelle Clonen des Repositories mittels git. Zur Installation reicht ein

apt-get install letsencrypt

Die eigentliche Erzeugung der Zertifikate wird mit folgendem Befehl angestoßen:

letsencrypt certonly --webroot -w /var/www/letsencrypt -d owncloud9tutorial.goip.de --rsa-key-size 4096

Hier wird zunächst nach einer E-Mail-Adresse gefragt. Diese dient in erster Linie dazu, Benachrichtigungen zu bald ablaufenden Zertifikaten zu versenden (Let’s Encrypt Zertifikate sind nur 90 Tage lang gültig, daher müssen diese nach einer gewissen Zeit erneuert werden). Hier sollte man also eine gültige Mail-Adresse angeben.

Nach dem Bestätigen der Nutzungsbedingungen erfolgt die Generierung des Zertifikats automatisch und ohne weiteres Zutun des Benutzers.

Das Programm sollte nun eine Erfolgsmeldung ausgeben, daraufhin findet man die Zertifikate im Verzeichnis /etc/letsencrypt/live/owncloud9tutorial.goip.de:

• cert.pem: Das öffentliche Zertifikat in Reinform
• chain.pem: Öffentliches Zertifikat aus der sog. Keychain
• fullchain.pem: entspricht cert.pem + chain.pem
• privkey.pem: Privates Zertifikat

Erweiterte Sicherheit: Diffie-Hellman-Parameter

Mit einem SSL-Zertifikat hat man bereits einen großen Schritt für eine verschlüsselte Verbindung zur eigenen ownCloud getan. Um die Sicherheit jedoch noch weiter zu erhöhen, empfiehlt es sich, sog. Diffie-Hellman-Parameter zu generieren. Dieses Thema ist reichlich komplex, sorgt aber einfach ausgedrückt für einen sicheren Schlüsselaustausch beim Verbindungsaufbau.

Die Generierung der Parameter ist dagegen recht einfach und erfolgt über folgenden Befehl:

mkdir -p /etc/nginx/ssl 
openssl dhparam -out /etc/nginx/ssl/dhparams.pem 2048

Zugriffsberechtigungen für Zertifikat-Dateien setzen

Damit nicht jeder Benutzer freien Zugriff auf die Zertifikat-Dateien hat, sollten hier die Zugriffsberechtigungen eingeschränkt werden, so dass nur noch der Besitzer der Dateien Lese- bzw. Schreibrecht hat:

chmod 600 /etc/letsencrypt/live/owncloud9tutorial.goip.de/fullchain.pem
chmod 600 /etc/letsencrypt/live/owncloud9tutorial.goip.de/privkey.pem
chmod 600 /etc/letsencrypt/live/owncloud9tutorial.goip.de/chain.pem
chmod 600 /etc/letsencrypt/live/owncloud9tutorial.goip.de/cert.pem
chmod 600 /etc/nginx/ssl/dhparams.pem

Erneuerung der Zertifikate nach 90 Tagen

Wie bereits erwähnt, sind die Let’s Encrypt Zertifikate nur 90 Tage lang gültig. Für den Webserver-Betreiber bedeutet dies, dass die Zertifikate spätestens alle 90 Tage erneuert werden müssen. Wenn ein Zertifikat in einigen Tagen ungültig werden wird, erhält man auch automatisch eine E-Mail von Let’s Encrypt, die einen an die Erneuerung des Zertifikats erinnert.

Dann reicht einfach ein erneuter Aufruf von Let’s Encrypt:

letsencrypt certonly --webroot -w /var/www/letsencrypt -d owncloud9tutorial.goip.de --rsa-key-size 4096

Alle weiteren Schritte (Diffie-Hellman-Parameter erzeugen, Verzeichnisrechte anpassen) sind dann nicht mehr notwendig, da lediglich die eigentlichen Zertifikat-Dateien ausgetauscht werden.

Konfiguration nginx (Teil 2)

Mit dem vorliegenden Zertifikat kann nun die Konfiguration von nginx abgeschlossen werden.

Gateway-Host für ownCloud vorbereiten

Dazu wird der „Gateway-Host“ für ownCloud erweitert. Generell sollten alle Verbindungen zu unserem Webserver verschlüsselt über HTTPS ablaufen, nicht nur die Kommunikation zur ownCloud. Daher enthält der Gateway sämtliche Einstellungen zu verschlüsselten Verbindungen.

nano /etc/nginx/conf.d/owncloud9tutorial.goip.de.conf

Die hinzugefügten Abschnitte sind markiert:

server {
	listen 80 default_server;
	server_name owncloud9tutorial.goip.de 192.168.178.20;

	root /var/www;
	
	location ^~ /.well-known/acme-challenge {
		proxy_pass http://127.0.0.1:81;
		proxy_redirect off;
	}

	location / {
	        # Enforce HTTPS
	        return 301 https://$server_addr$request_uri;

                # Use this if you always want to redirect to the DynDNS address (no local access).
	        #return 301 https://$server_name$request_uri;
        }		
}

server {
	listen 443 ssl http2;
	server_name owncloud9tutorial.goip.de 192.168.178.20;
  
	#
	# Configure SSL
	#
	ssl on;
  
	# Certificates used
	ssl_certificate /etc/letsencrypt/live/owncloud9tutorial.goip.de/fullchain.pem;
	ssl_certificate_key /etc/letsencrypt/live/owncloud9tutorial.goip.de/privkey.pem;
  
	# Not using TLSv1 will break:
	#	Android <= 4.4.40
	#	IE <= 10
	#	IE mobile <=10
	# Removing TLSv1.1 breaks nothing else!
	ssl_protocols TLSv1.2;
  
	# 100 % Security
        # Low Compatibility 
        # No Android 2 
        # No Java 
        # No IE < 11 (XP) 
        # No Firefox
        # Robust Forward Secrecy 
        #ssl_ciphers 'AES256+EECDH:AES256+EDH:!aNULL';
	
        # These are the recommended cipher suites from: https://wiki.mozilla.org/Security/Server_Side_TLS
        ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK';
  
        # Nginx for Modern Browsers (uncomment this when the other ssl_ciphers won't work for you)
        # Grade A (A+ with HSTS at >= 6 Months) 
        # 90 % Security 
        # Medium Compatibility 
        # No Java 6 (No DH parameters > 1024 bits) 
        # No IE on XP 
        # Robust Forward Secrecy 
        #ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK';  
  
        # Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
        ssl_dhparam /etc/nginx/ssl/dhparams.pem;
  
        # Specifies a curve for ECDHE ciphers. 
        # Remarks: This won't work on Chrome 53 (ERR_SSL_OBSOLETE_CIPHER)
        #ssl_ecdh_curve secp521r1;
  
        # Slightly lower security, but will work on
        # - Chrome 53
        # - Windows phones before 8.1 Update 1 
        ssl_ecdh_curve secp384r1; 
	
        # Server should determine the ciphers, not the client
	ssl_prefer_server_ciphers on;
  
	# OCSP Stapling
	# fetch OCSP records from URL in ssl_certificate and cache them
	ssl_stapling on;
	ssl_stapling_verify on;
	ssl_trusted_certificate /etc/letsencrypt/live/owncloud9tutorial.goip.de/fullchain.pem;
  
	# SSL session handling
	ssl_session_timeout 24h;
	ssl_session_cache shared:SSL:50m;
	ssl_session_tickets off;

	#
	# Add headers to serve security related headers
	#
  
	# HSTS (ngx_http_headers_module is required)
	# In order to be recoginzed by SSL test, there must be an index.hmtl in the server's root
	add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
	add_header X-Content-Type-Options nosniff;
	# Usually this should be "DENY", but when hosting sites using frames, it has to be "SAMEORIGIN"
	add_header X-Frame-Options "SAMEORIGIN";
	add_header X-XSS-Protection "1; mode=block";
	add_header X-Robots-Tag none;
	add_header X-Download-Options noopen;
	add_header X-Permitted-Cross-Domain-Policies none;

        location = / {
                # Disable access to the web root, otherwise nginx will show the default site here.
                deny all;
         }
  
	location ^~ /owncloud {
                # Set max. size of a request (important for uploads to ownCloud)
                client_max_body_size 1G;
		# Besides the timeout values have to be raised in nginx' owncloud config, these values have to be raised for the proxy as well
		proxy_connect_timeout 300;
		proxy_send_timeout 300;
		proxy_read_timeout 300;
		send_timeout 300;
	        proxy_set_header Host $host;
		proxy_set_header X-Real-IP $remote_addr;
		proxy_pass http://127.0.0.1:82;
		proxy_redirect off;
	}
}

Virtuellen Host für ownCloud anlegen

Nachdem der Gateway-Host für ownCloud vorbereitet wurde, ist es nun an der Zeit einen speziellen virtuellen Host für ownCloud anzulegen:

nano /etc/nginx/conf.d/owncloud9tutorial.goip.de_owncloud.conf

Der komplette Inhalt dieser Datei sieht dann folgendermaßen aus:

upstream php-handler {
    server unix:/run/php/php7.0-fpm.sock;
}

server {
    listen 127.0.0.1:82;
    server_name 127.0.0.1;

    # Add headers to serve security related headers
    # Use 'proxy_set_header' (not 'add_header') as the headers have to be passed through a proxy.
    proxy_set_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
    proxy_set_header X-Content-Type-Options nosniff;
    proxy_set_header X-Frame-Options "SAMEORIGIN";
    proxy_set_header X-XSS-Protection "1; mode=block";
    proxy_set_header X-Robots-Tag none;
    proxy_set_header X-Download-Options noopen;
    proxy_set_header X-Permitted-Cross-Domain-Policies none;

    # Path to the root of your installation
    root /var/www/;

    location = /robots.txt {
        allow all;
        log_not_found off;
        access_log off;
    }

    # The following 2 rules are only needed for the user_webfinger app.
    # Uncomment it if you're planning to use this app.
    #rewrite ^/.well-known/host-meta /owncloud/public.php?service=host-meta last;
    #rewrite ^/.well-known/host-meta.json /owncloud/public.php?service=host-meta-json last;

    location = /.well-known/carddav { return 301 $scheme://$host/owncloud/remote.php/dav; }
    location = /.well-known/caldav { return 301 $scheme://$host/owncloud/remote.php/dav; }

    location /.well-known/acme-challenge { }

    location ^~ /owncloud {

        # set max upload size
        client_max_body_size 1G;
        fastcgi_buffers 64 4K;

        # Disable gzip to avoid the removal of the ETag header
        gzip off;

        # Uncomment if your server is build with the ngx_pagespeed module
        # This module is currently not supported.
        #pagespeed off;

        error_page 403 /owncloud/core/templates/403.php;
        error_page 404 /owncloud/core/templates/404.php;

        location /owncloud {
            rewrite ^ /owncloud/index.php$uri;
        }

        location ~ ^/owncloud/(?:build|tests|config|lib|3rdparty|templates|data)/ {
            deny all;
        }

        location ~ ^/owncloud/(?:\.|autotest|occ|issue|indie|db_|console) {
            deny all;
        }

        location ~ ^/owncloud/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|ocs-provider/.+|core/templates/40[34])\.php(?:$|/) {
            include fastcgi_params;
            fastcgi_split_path_info ^(.+\.php)(/.+)$;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_param PATH_INFO $fastcgi_path_info;

	    # Important: disable HTTPS, otherwise no log in will be possible!
            #fastcgi_param HTTPS on;

            fastcgi_param modHeadersAvailable true; #Avoid sending the security headers twice
            fastcgi_param front_controller_active true;
            fastcgi_pass php-handler;
            fastcgi_intercept_errors on;

            # Raise timeout values.
	    # This is especially important when the ownCloud setup runs into timeouts (504 gateway errors)
	    fastcgi_read_timeout 300;
	    fastcgi_send_timeout 300;
	    fastcgi_connect_timeout 300;
	    
            # Pass PHP variables directly to PHP.
            # This is usually done in the php.ini. For more flexibility, these variables are configured in the nginx config.
	    # All the PHP parameters have to be set in one fastcgi_param. When using more 'fastcgi_param PHP_VALUE' directives, the last one will override all the others.
            fastcgi_param PHP_VALUE "open_basedir=/var/www:/tmp/:/var/owncloud_data:/dev/urandom
						upload_max_filesize = 1G
						post_max_size = 1G
						max_execution_time = 3600";
            
            # Make sure that the real IP of the remote host is passed to PHP.
            fastcgi_param REMOTE_ADDR $http_x_real_ip;
        }

        location ~ ^/owncloud/(?:updater|ocs-provider)(?:$|/) {
            try_files $uri/ =404;
            index index.php;
        }

        # Adding the cache control header for js and css files
        # Make sure it is BELOW the PHP block
        location ~* \.(?:css|js)$ {
            try_files $uri /owncloud/index.php$uri$is_args$args;
            proxy_set_header Cache-Control "public, max-age=7200";
            # Add headers to serve security related headers
            # Again use 'proxy_set_header' (not 'add_header') as the headers have to be passed through a proxy.
            proxy_set_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
            proxy_set_header X-Content-Type-Options nosniff;
            proxy_set_header X-Frame-Options "SAMEORIGIN";
            proxy_set_header X-XSS-Protection "1; mode=block";
            proxy_set_header X-Robots-Tag none;
            proxy_set_header X-Download-Options noopen;
            proxy_set_header X-Permitted-Cross-Domain-Policies none;
            # Optional: Don't log access to assets
            access_log off;
        }

        location ~* \.(?:svg|gif|png|html|ttf|woff|ico|jpg|jpeg)$ {
            try_files $uri /owncloud/index.php$uri$is_args$args;
            # Optional: Don't log access to other assets
            access_log off;
        }
    }
}

Noch ein paar Erläuterungen zu dieser Konfiguration:

• Es wird hier kein HTTPS-Server definiert. Trotzdem läuft die Verbindung verschlüsselt über HTTPS, da der Gateway-Host für die Verschlüsselung sorgt.
• Gelauscht wird wieder über die Loopback-Adresse (127.0.0.1:82). Zusammen mit dem entsprechenden server_name ist wiederum sicher gestellt, dass keine direkte Verbindung zu diesem virtuellen Host aufgebaut werden kann (ohne den Gateway-Host zu passieren).
• Die proxy_set_header Anweisungen sind für die erhöhte Sicherheit notwendig. Ohne diese Einträge werden später Warnungen im Admin-Bereich von ownCloud angezeigt. In vielen Tutorials werden diese Header per add_header angegeben. In unserem Fall funktioniert dies nicht, da die Zugriffe über einen Proxy (Gateway-Host) ablaufen. Daher werden die Header mittels proxy_set_header angegeben.
• Der PHP-Handler (der in diesem Fall nur für ownCloud zuständig ist) beinhaltet neben den Anweisungen, die für ownCloud wichtig sind, auch noch weitere Parameter, die die Variablen in der php.ini überschreiben (fastcgi_param PHP_VALUE). Dabei darf nur eine fastcgi_param PHP_VALUE Anweisung existieren, da sich diese ansonsten gegenseitig überschreiben. Wenn mehrere Parameter an PHP übergeben werden sollen (wie hier der Fall), müssen diese einfach durch einen Zeilenumbruch getrennt werden.

Nun sollte der Webserver neu gestartet werden, damit die neue Konfiguration auch geladen wird. Der zuvor aufgeführte Befehl testet diese Konfiguration zunächst. Falls irgendetwas nicht stimmen sollte (z.B. auf Grund eines Tippfehlers), wird dies hier angezeigt.

nginx -t
service nginx restart

Konfiguration PHP

Mit der Konfiguration von nginx ist nun der dickste Brocken geschafft! Bevor es nun zur eigentlichen Installation von ownCloud geht, müssen noch PHP und die Datenbank MariaDB konfiguriert werden.

PHP wird dabei über FPM (FastCGI Process Manager) betrieben. Dabei handelt es sich im eine (performante) Möglichkeit der Kommunikation zwischen Webserver und PHP. FPM definiert dabei einen Pool an Threads, die auf das Abarbeiten von Anfragen bereitgehalten werden. Der Pool wird mittels folgender Datei konfiguriert:

nano /etc/php/7.0/fpm/pool.d/www.conf

Hier sucht man nach dem Eintrag Pass environment variables like LD_LIBRARY_PATH. ALL $VARIABLES are taken from the current environment. Hier sind die Kommentare (Semikolon) bei allen Einträgen zu entfernen, die mit env beginnen. Ohne diese Änderung wird ownCloud später eine Warnung im Admin-Bereich anzeigen, dass keine Umgebungs-Variablen definiert sind.

Neben der Pool-Konfiguration gibt es die globale PHP-Konfiguration in der php.ini. Sämtliche hier vorgenommen Änderungen wirken sich auf alle PHP-Anwendungen gleichermaßen aus. Da der Server u.U. verschiedene (PHP-)Webanwendungen hostet, belassen wir große Teile der globalen Konfiguration bei den Standard-Werten. Anpassungen, die für bestimmte Webanwendungen gelten sollen, werden über die Konfigurationen der virtuellen Hosts an PHP weitergegeben (siehe fastcgi_param PHP_VALUE im virtuellen Host von ownCloud).

Daher werden an dieser Stelle nur zwei Variablen geändert, die für erhöhte Sicherheit sorgen:

nano /etc/php/7.0/fpm/php.ini

• cgi.fix_pathinfo = 0: Sorgt für eine sichere Interpretation von Pfadangaben.
• open_basedir = /var/www/:/tmp/:/var/owncloud_data: Schränkt den Zugriff von PHP auf das Webroot- und das temporäre Verzeichnis, sowie das Datenverzeichnis von ownCloud ein. Dadurch kann PHP auf sonst keine Dateien des Systems zugreifen oder diese verändern.
  Wichtig: Hier müssen alle Verzeichnisse aufgeführt werden, auf die ownCloud später Zugriff haben soll.

Neben FPM kann PHP auch über die Kommandozeile aufgerufen werden. Dies wird später für ownCloud-Cron-Jobs benötigt. Daher muss neben der FPM-Konfiguration auch die CLI-Konfiguration angepasst werden, da diese Parameter nicht über einen virtuellen Host definiert werden können:

nano /etc/php/7.0/cli/php.ini

• cgi.fix_pathinfo = 0: siehe oben
• open_basedir = /var/www/:/tmp/:/var/owncloud_data: Schränkt die oben erwähnt den Zugriff von PHP ein. Zusätzlich wird hier das Datenverzeichnis von ownCloud mit angegeben, da dies außerhalb des Webroots liegt.
  Wichtig: Hier müssen ebenso alle Verzeichnisse angegeben werden, auf die ownCloud später Zugriff haben soll.

Mit einem Neustart von PHP werden die Änderungen übernommen:

service php7.0-fpm restart

 Konfiguration MariaDB

Nun fehlt nur noch die Konfiguration der Datenbank. Diese ist nach der Installation noch nicht auf maximale Sicherheit getrimmt, was man aber mit folgendem Befehl nachholen kann:

mysql_secure_installation

Da das Root-Passwort schon während der Installation vergeben wurde, muss dies nicht geändert werden. Alle anderen Fragen sollte man mit Ja (y) beantworten.

Für ownCloud muss ebenfalls die Datenbank-Konfiguration angepasst werden:

nano /etc/mysql/my.cnf

Im Abschnitt [mysqld] muss hier folgender Eintrag zu finden sein, ansonsten wird das ownCloud-Setup später auf Fehler laufen:

binlog_format = MIXED

Falls der oben genannte Abschnitt nicht in der Datei my.cnf enthalten ist, findet man diesen für gewöhnlich in einer anderen Konfigurations-Datei: /etc/mysql/conf.d/mariadb.cnf.

Nun fehlt nur noch ein Neustart, dann ist die Konfiguration von MariaDB abgeschlossen:

service mysql restart

Einrichtung ownCloud

Bis hierher war es nun ein ganzes Stück Arbeit, aber nun können wir mit der Einrichtung und Konfiguration von ownCloud beginnen.

Download

Im ersten Schritt benötigen wir die aktuellste Version von ownCloud als gepacktes Archiv. Dazu ruft man am besten die Download-Seite auf der ownCloud-Homepage auf, hier findet man immer die neuste Version. Hier werden Links zu den Archiven als .tar.bz2 und .zip angeboten. Fährt man mit der Maus über einen Link, wird unten im Browser der direkte Download-Link eingeblendet.

Nun kann man (wieder auf der Linux-VM) das entsprechende Archiv herunterladen und entpacken. Anschließend wird die nicht mehr benötigte Archiv-Datei wieder gelöscht:

wget https://download.owncloud.org/community/owncloud-9.0.2.tar.bz2 
tar -xjf owncloud-9.0.2.tar.bz2 -C /var/www 
rm owncloud-9.0.2.tar.bz2

Nach diesem Schritt ist es wichtig, noch einmal die Dateiberechtigungen explizit zu setzen, da das ownCloud-Setup ansonsten später fehlschlägt:

chown -R www-data:www-data /var/www/owncloud 
chown -R www-data:www-data /var/owncloud_data

Anlegen der ownCloud-Datenbak

Bevor nun das Setup der ownCloud im Browser aufgerufen werden kann, muss noch die Datenbank angelegt werden, die ownCloud nutzen soll. Dies wird am besten in der MariaDB-Kommandozeile erledigt, die mit (DB-)Root-Rechten aufgerufen wird. Das Passwort ist dabei das beim Setup von MariaDB vergebene Passwort:

mysql -u root -p

Nun wird neben der Datenbank gleich noch ein eigener DB-Benutzer für ownCloud angelegt. Die Angabe localhost sorgt dafür, dass der Zugriff auf diese Datenbank auf den lokalen Rechner begrenzt wird. Auch hier sollte man wieder ein sicheres Passwort wählen. Man beachte das Semikolon am Ende jeder Zeile:

create database owncloud_db;
create user owncloud_db_user@localhost identified by 'MeInPasSw0rT';
grant all privileges on owncloud_db.* to owncloud_db_user@localhost;
flush privileges;
exit;

ownCloud-Setup

Nun folgt der Aufruf des ownCloud Setups über den Browser. Dazu wird einfach die Adresse https://owncloud9tutorial.goip.de/owncloud aufgerufen.

Falls an dieser Stelle fehlende Abhängigkeiten entdeckt werden, liefert das Setup einen Hinweis auf die noch fehlenden Pakete. Hier muss man zunächst die fehlenden Pakete nachinstallieren.

Im Zuge der Ersteinrichtung wird ein Administrator-Konto angelegt. Der Benutzername ist dabei frei wählbar. Auch hier sollte man wieder Wert auf ein sicheres Passwort legen, da die ownCloud ja „öffentlich“ über das Internet erreichbar ist. Weitere Punkte bei der ersten Einrichtung sind das ownCloud-Datenverzeichnis (/var/owncloud_data) und die Zugangsdaten für die zuvor angelegte Datenbank. Mit einem Klick auf Installation abschließen wird die Einrichtung nach einem kurzen Moment abgeschlossen.

Hinweis: Besonders auf langsamen Rechnern dauert der Vorgang nach einem Klick auf Installation abschließen mitunter recht lange. Dies führt manchmal zu einem Timeout (504 Gateway Timeout). nginx kappt in diesem Fall die Verbindung zum Client (Browser), das Setup wird aber weiterhin ausgeführt. Dann hilft es, ein paar Minuten warten und die ownCloud-URL nochmals aufrufen. Wenn hier die Login-Maske erscheint, wurde das Setup erfolgreich abgeschlossen. Trotzdem sollte man sich in diesem Fall überlegen, die Timeout-Werte (im virtuellen Host für ownCloud) zu erhöhen.

Warnungen im Admin-Bereich

Nach der Installation ist die ownCloud prinzipiell einsatzbereit. Als erstes sollte man einen Blick in den Admin-Bereich werfen: Benutzername (rechts oben) > Administration. Mit dem Aufruf dieser Seite führt ownCloud ein paar Checks durch und gibt ggf. Warnungen aus, wenn irgendetwas an der Konfiguration oder den Zugriffsrechten nicht passt.

In unserem konkreten Fall sollte hier nur eine Warnung zu sehen sein:

Es wurde kein PHP Memory Cache konfiguriert. Konfiguriere zur Erhöhung der Leistungsfähigkeit, soweit verfügbar, einen Memory Cache. Weitere Informationen finden Sie in unserer Dokumentation.

Diese Meldung ist dabei kein Fehler an sich, sondern nur ein Hinweis darauf, dass die Performance der Cloud u.U. verbessert werden kann. Ein Memory Cache sorgt in diesem Fall dafür, dass die PHP-Anweisungen nicht bei jedem Aufruf aufs Neue interpretiert werden müssen, sondern gecached werden. Wenn nur wenige Benutzer die ownCloud (parallel) nutzen, kann man diese Warnung auch getrost ignorieren – hier würde ein Memory Cache nur einen minimalen Effekt haben.

Hinweis: Falls hier weitere Warnungen oder Fehler angezeigt werden, sollten die Schritte zur Einrichtung der ownCloud nochmals kontrolliert werden. Wenn alle Schritte befolgt worden sind, erscheint nur dieser eine Hinweis! Die ownCloud-Dokumentation bietet eine Liste an möglichen Fehlern und wie man diese beseitigen kann.

Anpassung der ownCloud-Konfiguration

Um diese Warnung zu beseitigen, muss die Konfigurations-Datei von ownCloud bearbeitet werden:

nano /var/www/owncloud/config/config.php

Der Memory Cache wird nun einfach durch das Hinzufügen folgender Zeile (ganz am Ende) aktiviert:

'memcache.local' => '\OC\Memcache\APCu',

Wenn man später über über das lokale Netzwerk auf die Cloud zugreifen will, sollte man hier gleich noch die lokale IP als Trusted Domain mit aufnehmen:

array (
	0 => 'owncloud9tutorial.goip.de',
	1 => '192.168.178.20',
),

Ich empfehle darüber hinaus noch die Umstellung der Zeitzone für die Log-Datei. Dadurch fällt es leichter, den Zeitpunkt von auftretenden Fehlern zu bestimmen:

'logtimezone' => 'Europe/Berlin',

Mit einem erneuten Aufruf des Admin-Bereichs sollte die zuvor angezeigte Warnung nun verschwunden sein.

Eine komplette Übersicht aller verfügbaren Parameter in der config.php findet man in der ownCloud-Dokumentation.

Zugriffsrechte anpassen

Nach der Installation von ownCloud sollten die Datei-/Verzeichnis-Berechtigungen aus Sicherheitsgründen noch einmal explizit gesetzt werden. Dies geschieht durch folgende Befehle:

find /var/www/owncloud/ -type f -print0 | xargs -0 chmod 0640
find /var/www/owncloud/ -type d -print0 | xargs -0 chmod 0750
chown -R root:www-data /var/www/owncloud/
chown -R www-data:www-data /var/www/owncloud/apps/
chown -R www-data:www-data /var/www/owncloud/config/
chown -R www-data:www-data /var/www/owncloud/themes/
chown -R www-data:www-data /var/owncloud_data/
chown root:www-data /var/www/owncloud/.htaccess
chown root:www-data /var/owncloud_data/.htaccess
chmod 0644 /var/www/owncloud/.htaccess
chmod 0644 /var/owncloud_data/.htaccess

Dabei kann es sein, dass die Datei /var/owncloud_data/.htaccess nicht existiert und eine entsprechende Fehlermeldung ausgegeben wird. Diese Warnung kann allerdings ignoriert werden, da die .htaccess-Dateien nur für Apache relevant sind.

ownCloud Cronjob einrichten

Standardmäßig werden Hintergrundaufgaben, die in regelmäßigen Abständen erledigt werden müssen, von ownCloud über AJAX ausgeführt. Dies funktioniert prinzipiell ganz gut, hat aber zwei Nachteile: Zum einen wird ein Hintergrund-Job nur dann ausgeführt, wenn ein Benutzer angemeldet ist und eine Seite geladen wird. Wenn nun über längere Zeit kein Benutzer aktiv ist, wird der Hintergrund-Job einfach nicht mehr ausgeführt. Zum anderen ist diese Art der Job-Ausführung weniger performant.

Man kann diese Hintergrundaufgaben allerdings auch per Cron erledigen lassen: Hier wird in regelmäßigen Abständen ein Hintergrund-Dienst gestartet, der dann alle zu erledigenden Hintergrund-Jobs abarbeitet. Das Umstellen auf Cron empfiehlt sich dabei besonders beim Einsatz auf einem Raspberry Pi oder ähnlicher schwacher Hardware, ist aber nicht zwingend erforderlich.

Um die Hintergrundaufgaben durch einen Cronjob erledigen zu lassen, muss zunächst ein neuer Job für den Webserver-Benutzer angelegt werden:

crontab -u www-data -e

Wenn das System nachfragt, wie wir die Datei bearbeiten möchten, wählt man am besten den bekannten Editor nano. Folgendes wird nun am Ende der Datei eingefügt:

*/15 * * * * php -f /var/www/owncloud/cron.php > /dev/null 2>&1

Dies sorgt dafür, dass die Hintergrundarbeiten alle 15 Minuten ausgeführt werden.

Damit diese Aktivitäten nun nicht doppelt (per AJAX und per Cron) ausgeführt werden, muss man noch im Admin-Bereich von ownCloud unter dem Punkt Cron die Einstellung AJAX auf Cron ändern.

Ob der Cron-Job nun ordnungsgemäß ausgeführt wird, kann man an der Anzeige Letzte Cron-Jon-Ausführung erkennen: Immer nach 15 Minuten sollte die Anzeige wieder zurück gesetzt werden (gerade eben).

Weitere Konfiguration der ownCloud

Damit ist die Einrichtung der ownCloud abgeschlossen. Alle weiteren Schritte zur Konfiguration (z.B. die serverseitige Verschlüsselung) hängt vom individuellen Einsatzzweck ab. Dazu verweise ich hier auf das offizielle Administrations-Handbuch von ownCloud.

Überprüfung der Sicherheit

Qualys SSL Labs

Nachdem wir gesteigerten Wert auf die Sicherheit der ownCloud gelegt haben, sollte man zumindest die SSL-Sicherheit (Verschlüsselung) überprüfen. Ich verwende dazu immer den SSL Server Test von Qualys SSL Labs.

Mit der gezeigten Konfiguration erreicht man eine sehr gute Wertung von A+:

Falls an dieser Stelle eine niedrigere Einstufung erfolgt und/oder Warnungen ausgegeben werden, sollte die SSL-Konfiguration nochmals überprüft werden (Erzeugung und Einbindung der Zertifikate, Verwendung von sicherheitsrelevanten Headern in den virtuellen Hosts).

ownCloud Vulerability Scanner/Nextcloud Security Scan

Neben dem Überprüfen der (SSL-)Sicherheit, gibt es noch ein Tool von ownCloud, mit dem die Cloud-Installation auf eventuelle Verwundbarkeiten geprüft werden kann: Den ownCloud Vulnerability Scanner. Nach dem Check werden evtl. vorhandene Schwachstellen gezeigt.

Etwas umfangreicher arbeitet der Nextcloud Security Scan. Dieses Tool ist zwar spezielle für Nextcloud gedacht, man kann allerdings auch ownCloud-Instanzen damit überprüfen. Hier sollte man auf jeden Fall ein „A-Rating“ erzielen können. Der einzige Punkt, der unter „Hardenings“ als verbesserungswürdig gekennzeichnet wird, ist „__Host-Prefix“. Dies hat allerdings damit zu tun, dass wir unsere Cloud über ein Unterverzeichnis des Webservers ansprechen und stellt kein Sicherheitsrisiko dar.

Zugriff auf die ownCloud über das lokale Netzwerk

Die eigene Cloud ist soweit eingerichtet und wartet nun auf Input. Gerade beim Upload von größeren Dateien kann es sinnvoll sein, dass man diese über das lokale Netzwerk überträgt – also nicht über die DynDNS-Adresse der Cloud, da hier sämtlicher Traffic über das Internet geleitet wird, was definitiv länger dauert als die Übertragung über das lokale Netzwerk.

Dazu greift man einfach über die IP-Adresse auf die ownCloud zu (https://192.168.178.20/owncloud) und nicht über die DynDNS-Adresse (https://owncloud9tutorial.goip.de/owncloud). In diesem Fall bekommt man eine Warnung im Browser angezeigt, da das SSL-Zertifikat ja auch die DynDNS-Domain und nicht auf die lokale IP ausgestellt wurde. Diese Warnung kann man getrost ignorieren, da die übertragenen Daten ja das lokale Netzwerk nicht verlassen und daher nicht unbedingt verschlüsselt werden müssen.

Sollte der lokale Zugriff nicht funktionieren (häufigster Fehler ist dabei, dass nach der Anmeldung automatisch auf die DynDNS-Adresse weitergeleitet wird), dann sollte noch einmal der Gateway-Host kontrolliert werden (/etc/nginx/conf.d/owncloud9tutorial.goip.de). Hier ist folgender Eintrag wichtig:

# Enforce HTTPS
return 301 https://$server_addr$request_uri;

# Use this if you always want to redirect to the DynDNS address (no local access).
#return 301 https://$server_name$request_uri;

Wenn der zweite Redirect verwendet wird (hier auskommentiert), wird immer auf die DynDNS-Adresse weitergeleitet.

Ebenfalls muss die lokale IP als Trusted Domain in der config.php von ownCloud angegeben werden (siehe Abschnitt Anpassung der ownCloud-Konfiguration).

Falls es doch einmal hakt…

Am Ende noch ein wichtiger Hinweis: Die Einrichtung und Konfiguration der ownCloud ist nicht trivial. Wenn nur ein kleines Detail übersehen oder vergessen wurde, hat dies meist zur Folge, dass der Zugriff auf die ownCloud nicht wie erwartet funktioniert.

In diesem Fall liefern die Log-Dateien von nginx bzw. ownCloud aber meist einen Hinweis darauf, wo der Fehler liegen könnte. Im Fehlerfall sollte man daher immer zunächst einmal einen Blick in die Logs werfen:

• /var/log/nginx/error.log: Fehler-Log von nginx.
• /var/owncloud_data/owncloud.log: ownCloud-Log, auch einzusehen in der Admin-Oberfläche der Cloud.

Download Checkliste

Da zur Installation und Einrichtung von ownCloud durchaus viele Schritte erforderlich sind, gibt es hier die Zusammenfassung als Checkliste als PDF. Dieses Dokument verzichtet bewusst auf weitere Erklärungen, sondern listet lediglich die verwendeten Befehle und Eingaben hintereinander auf.

Download Checkliste

Meine Daten gehören mir!

Nun ist es an der Zeit, sich einfach mal in dem Gewissen zurückzulehnen, dass man ab sofort die Hoheit über die eigenen Daten behält.

Ich muss zugeben, dass der Artikel recht umfangreich geworden ist. Ich musste selbst viel rumtüfteln, damit ownCloud optimal und mit erhöhter Sicherheit läuft. Aber vielleicht hilft das Tutorial dem einen oder anderen, seine eigenen ownCloud aufzusetzen und dabei nicht so viel Zeit mit Suchen und Rumprobieren zu verschwenden.

Falls es dennoch Unklarheiten oder Verbesserungsvorschläge gibt, hinterlasst mir doch einfach einen Kommentar. Ich versuche euch dann soweit wie möglich weiter zu helfen.

Weiterführende Artikel

• Ubuntu Server als Hyper-V Gastsystem installieren und optimal einrichten
• ownCloud Updates richtig durchführen
• ownCloud unter Windows 10 optimal nutzen
• HTTPS für alle: SSL-Zertifikate mit Let’s Encrypt und nginx
• ownCloud mit Fail2ban absichern
• Zweite Web-Anwendung neben ownCloud/Nextcloud einrichten (am Beispiel WordPress)

Links

• Offizielle ownCloud Homepage (englisch)
• Offizielle nginx Homepage (englisch)
• nginx Wiki mit Anleitungen und Beispielen (englisch)
• Offizielle MariaDB Homepage (englisch)
• Offizielle PHP Homepage (englisch)
• ownCloud Server Administration Manual (englisch)
• Offizielle Let’s Encrypt Homepage (englisch)
• Certbot-Homepage (englisch)
• ownCloud Vulnerability Scanner
• Nextcloud Security Scan

Ähnliche Artikel:

ownCloud auf Ubuntu Server mit nginx, MariaDB und PHP Nextcloud auf Ubuntu Server mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban Nextcloud auf Ubuntu Server 20.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban