DecaTec

Programmieren, Fotografie, Home-Server und einiges mehr

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

ownCloud Logo

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:

Update-Historie
  • Update 31.05.2016:
    • Gateway-Host angepasst, so dass nun nicht mehr die nginx-Default-Seite angezeigt wird, wenn auf die Haupt-URL zugegriffen wird (owncloud9tutorial.goip.de, ohne /owncloud).
    • Hinweis auf die Log-Dateien hinzugefügt – im Fehlerfall geben diese Logs meist einen Hinweis darauf, wo der Fehler liegt.
  • Update 07.06.2016:
    • Anpassung virtueller Host für ownCloud, damit der PHP-Handler die richtige IP des Remote-Hosts kennt. Diese Anpassung war notwendig, um den Einsatz von Fail2ban zu ermöglichen.
  • Update 11.07.2016:
    • Hinweis für open_basedir (PHP-Konfiguration) hinzugefügt: Hier müssen alle Verzeichnisse aufgelistet werden, auf die ownCloud später Zugriff haben soll.
  • Update 13.07.2016:
    • Hinweis hinzugefügt, wenn die Verzeichnisse sites-available/sites-enabled nicht vorhanden sind, oder nginx keine virtuelle Hosts auf diesen Verzeichnissen lädt.
  • Update 01.08.2016:
    • Es gab vermehrt Hinweise, dass die Verzeichnisse sites-available/sites-enabled für die virtuellen Hosts nicht vorhanden sind. Nach der Installation der aktuellen Programm-Versionen auf einem frisch installierten System nutzt nginx zur Verwaltung der Hosts tatsächlich das Verzeichnis /etc/nginx/conf.d. Die Beschreibung wurde dahingehend angepasst.
  • Update 04.08.2016:
    • Verbesserungen beim Rewrite von HTTP auf HTTPS (zuvor gab es Probleme beim Erneuern des Let’s Encrypt Zertifikats).
  • Update 02.09.2016:
    • Vereinfachte Generierung der SSL-Zertifikate, da Let’s Encrypt in den Paketquellen von Ubuntu 16.04 enthalten ist. Ein manuelles Clonen mittels git ist nicht mehr nötig.
  • Update 03.09.2016:
    • Änderung an den Konfiguration der elliptischen Kurven für ECDHE ciphers in der nginx-Konfiguration (im Gateway-Host). Hier wurde bisher ssl_ecdh_curve secp521r1; empfohlen, allerdings kommt es hier seit Chrome 53 zu Fehlern (ERR_SSL_OBSOLETE_CIPHER). Um dieses Problem lösen ist es notwendig, auf ssl_ecdh_curve secp384r1; auszuweichen.
  • Update 20.09.2016:
    • listen-Direktive der virtuellen Hosts für Let’s Encrypt und ownCloud angepasst, so dass diese nur noch auf lokale Anfragen reagieren (z.B. listen 127.0.0.1:82;). Dadurch wird verhindert, dass ein Zugriff über das lokale Netzwerk möglich ist, ohne den Gateway-Host zu passieren.
  • Update 24.09.2016:
    • Hinweis für die Installation von nginx auf einem Raspberry Pi hinzugefügt.
  • Update 16.11.2016:
  • Update 06.01.2017:
    • Hinweis auf Konfiguration MariaDB in Datei mariadb.cnf
  • Update 18.03.2017:
    • Hinweis auf ownCloud Vulerability Scanner/Nextcloud Security Scan hinzugefügt

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:

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:

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:

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.

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.

Hinweis für Raspberry Pi Benutzer

Die nachfolgenden Schritte sind für Benutzer eines Raspberry Pi nicht notwendig. In den offiziellen Paketquellen von nginx ist kein Paket für die ARM-Architektur vorhanden, die für einen Raspberry Pi benötigt wird. Daher wird hier empfohlen, auf die nginx-Version zurück zu greifen, die in den Paketquellen von Raspbian enthalten ist. Hier reichen zur Installation des Webservers folgende Befehle:

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:

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

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).

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:

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

Nginx läuft auf dem Server

Nginx läuft auf dem Server

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):

Dann werden die Paketquellen hinzugefügt:

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).

Nun kann die Datenbank installiert werden:

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:

Root-Passwort für MariaDB vergeben

Root-Passwort für MariaDB vergeben

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:

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:

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:

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:

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:

Hier fügen wir nun folgenden Inhalt ein:

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:

Dieser Host ist dabei sehr einfach aufgebaut:

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:

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).
Menü zum Aktivieren der erweiterten Ansicht der FritzBox

Menü zum Aktivieren der erweiterten Ansicht der FritzBox

  • 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
Portfreigabe in der FritzBox einrichten

Portfreigabe in der FritzBox einrichten

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

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

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:

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:

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:

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.

Die hinzugefügten Abschnitte sind markiert:

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:

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

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.

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:

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:

  • 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:

  • 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:

 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:

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.

Absichern der MariaDB-Installation

Absichern der MariaDB-Installation

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

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

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:

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.

Download-Link für ownCloud

Download-Link für ownCloud

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:

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

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:

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:

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.

ownCloud Setup

ownCloud Setup

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.

Warnungen im Admin-Bereich der ownCloud

Warnungen im Admin-Bereich der ownCloud

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:

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

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:

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:

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:

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:

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:

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.

Umstellung von AJAX auf Cron

Umstellung von AJAX auf Cron

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+:

SSL-Test der ownCloud-Installation

SSL-Test der ownCloud-Installation

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:

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

Links

, , , , , , , , , , ,

Kommentare: 550

  • Tobias sagt:

    Hi,
    Ich bin gerade bei der einrichtung von OC und wollte mal schauen ob ich noch Zugriff auf meine nginx Webseite habe (/var/www/index.html). Ich bekomme jedoch die Meldung „403 Forbidden“ obwohl ich mit chown index.html dem User www-data zugewiesen habe. Hier ist ein Ausschnitt meine config datei(/etc/nginx/conf.d/dyris.cc.conf): https://pastebin.com/Dm5TEBbg und im error.log steht: access forbidden by rule, client: x.x.x.135, server: mydomain.at, request: „GET / HTTP/1.1“, host: „mydomain.at“. Da ich erst vor kurzem angefangen habe mich mit einem eigenen Server zu befassen habe ich nich viel Ahnung von nginx. Ich denke es stimmt etwas nicht mit einem von den location Einträgen aber eine google such hat mich nicht wirklich weitergebracht.

    Danke,
    Tobias

    • Jan sagt:

      Hallo Tobias,

      folgender location-Block ist dafür verantwortlich, dass der Zugriff auf das Root-Verzeichnis unterbunden wird:
      location = / {
      # Disable access to the web root, otherwise nginx will show the default site here.
      deny all;
      }

      Wenn du neben der Cloud-Anwendung eine weitere Website unter der Root-Domain hosten willst, dann musst du dafür sorgen, dass hier eine korrekte Weiterleitung stattfindet. Also beispielsweise:
      location = / {
      root /var/www;
      // ...
      }

      Was in diesem location-Block genau aufgeführt werden muss, hängt von der jeweiligen Web-Anwendung ab. Auf jeden fall darf hier kein deny all; stehen. Als guten Ausgangspunkt zum Rumprobieren kannst du auch erst einmal diesen location-Block komplett löschen oder auskommentieren. Nicht vergessen: nginx muss anschließend neu gestartet werden (service nginx restart), damit die Änderungen übernommen werden.

      Gruß,
      Jan

  • Sven sagt:

    Hallo Zusammen,

    erst einmal rießen dank an die tolle Anleitung muss echt sagen, ist bei weitem die beste die ich in dieser Konfiguration und hinsichtlich der Erklärung der Einstellungen und Vorgehensweise gefunden hab, großes Lob an dich.

    Allerdings habe ich zwei Probleme.

    Einerseits erscheint im Adminbereich die Fehlermeldung

    Der „X-Frame-Options“-HTTP-Header ist nicht so konfiguriert, dass er „SAMEORIGIN“ entspricht. Dies ist ein potentielles Sicherheitsrisiko und es wird empfohlen, diese Einstellung zu ändern.

    Andererseits scheint der Server nicht aus dem Internet erreichbar zu sein, mit der Nextcloud App allerdings schon, auch scan.nextcloud.com gibt eine Fehlermeldung aus, wonach keine Installation gefunden wurde.

    Anleitung wurde Schritt für Schritt befolgt und bereits zweimal frisch aufgesetzt um konfigurationsfehler auszuschließen, selbe Fehler.

    Log nginx

    access forbidden by rule, client: 127.0.0.1, server: 127.0.0.1, request: „GET /nextcloud/data/.ocdata?t=1501234945906 HTTP/1.0“, host: „xxxxx.ddns.net“

    Nextcloud ist anscheinend kein log vorhanden unter

    /var/owncloud_data/nextcloud.log

    Erstellt wurde das ganze auf dem Pine64 mit Armbian als Distro.

    Auf eine Antwort freue ich mich

    Im Voraus vielen Dank.

    Mit freundlichen Grüßen

    Sven

    • Jan sagt:

      Hallo Sven,

      erst einmal vielen Dank für das Lob!
      Zu deinen Problemen: Die „X-Frame-Options“ werden eigentlich im Gateway-Host gesetzt: add_header X-Frame-Options "SAMEORIGIN";.
      Die anderen Probleme sind etwas komisch: Das Logfile wird erst angelegt, wenn der erste Log-Eintrag erzeugt wird. Allerdings sollte hier eigentlich immer was zu finden sein. Auch dass die Cloud nicht aus dem Internet erreichbar ist, ist etwas seltsam. Zum Analysieren des Problems bräuchte ich ein paar mehr Infos: Schick mir doch bitte mal sämtliche vHost-Configs, das komplette nginx error.log und ein evtl. vorhandenes Nextcloud-Log per Mail zu. Dann schaue ich mir das Problem mal genauer an.

      Gruß,
      Jan

      • Bernd sagt:

        Hallo,
        gibt es zum dem Fehler:

        Der „X-Frame-Options“-HTTP-Header ist nicht so konfiguriert, dass er „SAMEORIGIN“ entspricht. Dies ist ein potentielles Sicherheitsrisiko und es wird empfohlen, diese Einstellung zu ändern

        schon eine abstellende Maßnahme, ich würde mich wahnsinnig darüber freuen 🙂

        Vielen Dank
        Gruß Bernd

        • Jan sagt:

          Hi Bernd,

          meine Vermutung ist folgende: Wenn die „X-Frame-Options“ mehrfach gesetzt werden (also z.B. einmal mit add_header X-Frame-Options „SAMEORIGIN“; im Gateway-Host und einmal mit proxy_set_header X-Frame-Options „SAMEORIGIN“; im ownCloud/Nextcloud-vHost), dann kann es u.U. zu dieser Meldung kommen. Versuch doch mal, ein Setzen des X-Frame-Options zu entfernen (einfach auskommentieren und nginx neu starten). Vielleicht führt das ja zum Erfolg.

          Gruß,
          Jan

  • Lorenzo sagt:

    Moin,

    aktuell bin ich bei der Neuinstallation auf einem weiteren System nach deiner Anleitung, leider scheitere ich schon bei der NGINX installation mit folgender Fehlermeldung:

    ———————————————————————-
    Entpacken von nginx (1.13.3-1~xenial) …
    dpkg: Fehler beim Bearbeiten des Archivs /var/cache/apt/archives/nginx_1.13.3-1~xenial_amd64.deb (–unpack):
    Versuch, »/etc/nginx/uwsgi_params« zu überschreiben, welches auch in Paket nginx-common 1.10.3-0ubuntu0.16.04.2 ist
    dpkg-deb: Fehler: Unterprozess einfügen wurde durch Signal (Datenübergabe unterbrochen (broken pipe)) getötet
    Fehler traten auf beim Bearbeiten von:
    /var/cache/apt/archives/nginx_1.13.3-1~xenial_amd64.deb
    E: Sub-process /usr/bin/dpkg returned an error code (1)

    Hast du dazu ggf. Ideen?

    • Lorenzo sagt:

      Okay, eine komplette Neuinstallation von ubuntu hat geholfen, nun steck ich an dem Punkt der Owncloud installation fest, ich bekomm nur einen Fehler 502 Bad Gateway… ich überprüfe die Virtual Hosts gerade schon das xte mal…

      • Jan sagt:

        Hi Lorenzo,

        hier hilft wohl nur ein Blick in das error.log von nginx. Hier sollte auf jeden Fall ein Hinweis zu finden sein, was hier schief läuft.
        Evtl. wurde auch schon ein ownCloud-Logfile angelegt, vielleicht findet sich hier auch noch ein Hinweis.

        Gruß,
        Jan

        • Lorenzo sagt:

          Welchen Errorlog meinst du denn genau? Dann kann ich den gerne nachher von Zuhause mal posten.

          • Jan sagt:

            Hi,

            ich meine die Datei /var/log/nginx/error.log. Vielleicht ist es besser, wenn du mir die komplette Datei per Mail schickst, da hier meist sehr viel drin steht.

            Gruß,
            Jan

          • Lorenzo sagt:

            Woher bekomm ich denn deine Mailadresse?

            Andernfalls hier mal der Log, der ist IMHO sehr übersichtlich:

            2017/08/08 06:55:38 [error] 1486#1486: *1307 access forbidden by rule, client: 60.191.38.77, server: MEINE URL, request: „GET / HTTP/1.1“, host: „91.47.113.205:443“
            2017/08/08 06:55:40 [error] 1486#1486: *1308 access forbidden by rule, client: 60.191.38.77, server: MEINE URL, request: „GET / HTTP/1.1“, host: „91.47.113.205:443“
            2017/08/08 11:55:23 [warn] 1486#1486: no resolver defined to resolve ocsp.int-x3.letsencrypt.org while requesting certificate status, responder: ocsp.int-x3.letsencrypt.org, certificate: „/etc/letsencryp$
            2017/08/08 11:55:25 [error] 1486#1486: *1315 access forbidden by rule, client: 184.105.247.196, server:MEINE URL, request: „GET / HTTP/1.1“, host: „46.90.12.189“
            2017/08/08 18:44:09 [warn] 1486#1486: no resolver defined to resolve ocsp.int-x3.letsencrypt.org while requesting certificate status, responder: ocsp.int-x3.letsencrypt.org, certificate: „/etc/letsencryp$
            2017/08/08 19:06:53 [warn] 12269#12269: no resolver defined to resolve ocsp.int-x3.letsencrypt.org while requesting certificate status, responder: ocsp.int-x3.letsencrypt.org, certificate: „/etc/letsencr$
            2017/08/08 19:06:53 [crit] 12269#12269: *4 connect() to unix:/run/php/php7.0-fpm.sock failed (13: Permission denied) while connecting to upstream, client: 127.0.0.1, server: 127.0.0.1, request: „GET /own$
            2017/08/08 19:06:53 [error] 12269#12269: *1 open() „/etc/nginx/html/favicon.ico“ failed (2: No such file or directory), client: 46.90.12.189, server: MEINE URL, request: „GET /favicon.ico HTTP/2.0“, host:$

            habe mein URL mal ersetzt

          • Jan sagt:

            Hi Lorenzo,

            „access forbidden by rule“ sagt aus, dass du wohl in den generellen location-Block (location = / {…}) reinläufst. Hier wird mit dem deny all angegeben, dass der Zugriff hierauf nicht gestattet sein soll. Deine Cloud-URL sollte folgendermaßen aussehen, damit der Zugriff klappt: https://meine.domain.de/owncloud (bzw. https://meine.domain.de/nextcloud).

            Gruß,
            Jan

          • Lorenzo sagt:

            So siehtse auch aus, https://meineurl.eu/owncloud

            und es spuckt dann bad gateway 502 aus =/

            Angepasst habe ich ja eig. nur die beiden config dateien für die virtuellen hosts, soll ich da noch einmal schauen?!

          • Lorenzo sagt:

            Hallo Jan, hast du noch weitere Ideen? Alternativ setz ich einfach neu auf und Versuch es von vorne 😀

          • Jan sagt:

            Hi Lorenzo,

            ich habe dir eine Mail geschickt. Hat dir das nicht weiter geholfen?

            Gruß,
            Jan

          • Lorenzo sagt:

            Moin Jan,
            ist im Spamordner gelandet 😉 Ich Antworte dir nachher von Zuhause mal ;9

            Grüße

    • Jan sagt:

      Hi,

      auch wenn sich das Problem nun schon erledigt hat: Dieser Fehler kann wohl kommen, wenn man nginx aus dem Standard-Ubuntu-Repository installiert hat und zu einem späteren Zeitpunkt das nginx-Repository in die apt-Sources hinzugefügt hat (siehe hier). Man sollte wohl prinzipiell bei dem Repo bleiben, von dem man nginx ursprünglich installiert hat.

      Gruß,
      Jan

  • cjay sagt:

    Hi Jan,
    super Anleitung bisher.
    Ich komme bei dem Punkt nicht weiter, beim Anlegen des Admin Accounts für die OwnCloud im Browser über dem Feld Administrator-Konto anlegen erscheint folgender Fehler: Error while trying to create admin user: An exception occurred while executing ‚ALTER TABLE oc_calendarsubscriptions CHANGE ‚lastmodified‘ lastmodified INT UNSIGNED DEFAULT NULL NOT NULL‘:SQLSTATE[42000]: Syntax error or access violation: 1067 Invalid default value for ‚lastmodified‘
    ich komme leider durch google auch nicht weiter, da ich jetzt nicht so affin in SQL bin. :-/
    Wäre super wenn du mir helfen könntest oder andere.
    Vielen Dank

    • Jan sagt:

      Hi cjay,

      diesen Fehler konnte ich bislang noch nicht beobachten. Welche OC Version versuchst du hier zu installieren?
      Hast du eine neue (leere) Datenbank für OC vor dem eigentlichen Setup angelegt (also genau so wie im Tutorial beschrieben)?
      Ansonsten würde ich hier zunächst einmal im ownCloud-Forum nachfragen, hier sollte die am ehesten geholfen werden können.

      Gruß,
      Jan

      • cjay sagt:

        Hi,
        danke für die schnelle Antwort ich nutze die aktuellste Version 10.0.3
        Ja ich habe natürlich die Anleitung so befolgt wie beschrieben auch nochmal die Datenbank gedropt und neu angelegt immer die selbe Fehlermeldung.
        Danke trotzdem.

1 5 6 7

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.