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

14. Mai 2016 / Home-Server / 591 Kommentare

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:
- Hinweis zum Hosten weiterer Web-Anwendungen auf der hier gezeigten Konfiguration hinzugefügt: Zweite Web-Anwendung neben ownCloud/Nextcloud einrichten (am Beispiel WordPress)
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:

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.

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:

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

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

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.

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:

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

Links

591 Kommentare zu „ownCloud 9 auf Ubuntu Server 16.04 LTS mit nginx, MariaDB, PHP 7 und Let’s Encrypt“

Florian
12. Juli 2016 um 18:14 Uhr

Hallo nochmals,
soweit hat jetzt alles funktioniert. Ich hätte jetzt allerdings eine erweiterte Frage betreffend nginx und hoffe ihr könnt mir da weiterhelfen.
Ich möchte noch eine weitere Webanwendung tt-rss (tinytinyrss) mit niginx hinzufügen.
Wie gehe ich hier am besten vor?
Muss ich ein weiteres File z.B. /etc/nginx/sites-available/owncloud9tutorial.goip.de_ttrss anlegen ODER das bestehende /etc/nginx/sites-available/owncloud9tutorial.goip.de_owncloud erweitern?

Eigentlich soll alles gleich sein nur die Location soll auf /var/www/tt-rss gehen.

Muss ich dazu für ein eigenes File ein listen 83 machen? Möchte das natürlich wie bei owncloud via https verschlüsselt aufrufen und auch die letsencrypt Zertifikate verwenden.

Danke vorab,
Lg Florian

Antworten
1. Jan
  13. Juli 2016 um 8:20 Uhr
  
  Hallo Florian,
  
  prinzipiell sind beide Varianten möglich. Allerdings empfehle ich aus Gründen der Übersichtlichkeit eine Trennung der virtuellen Hosts pro Webanwendung.
  In deinem Fall würde ich eine eigene Config für ttrss anlegen. Dieser virtuelle Host läuft dann (wie schon bei ownCloud) auf der IP 127.0.0.1 aber einen anderem Port (z.B. 83). In diese Config kommen dann alle Anweisungen, die du für ttrss brauchst.
  Damit das ganze nicht nur lokal aufgerufen werden kann, muss noch der Gateway-Host erweitert werden. Dies funktioniert analog zum Redirect für ownCloud – nur, dass das Verzeichnis nicht owncloud, sondern z.B. ttrss heißt:
  location ^~ /ttrss { proxy_pass http://127.0.0.1:83; proxy_redirect off; }
  Evtl. brauchst du hier für den proxy_pass noch weitere Parameter (wie bei ownCloud auch). Das hängt dann von der Webanwendung ab. Sorry, ich habe keinerlei Erfahrungen mit ttrss, daher kann ich dir hier keine konkrete Konfiguration geben. Aber mit ein bisschen Rumprobieren bekommt man das sicher schnell hin.
  
  Gruß,
  Jan
  
  Antworten
  1. Florian
    13. Juli 2016 um 10:19 Uhr
    
    Hallo Jan,
    
    sehe ich das richtig?
    
    Die Datei owncloud9tutorial.goip.de erweitere ich um
    location ^~ /tt-rss {
    proxy_pass http://127.0.0.1:83;
    proxy_redirect off;
    }
    
    dann lege ich eine neue Datei owncloud9tutorial.goip.de_tt-rss mit folgenden Inhalt an.
    
    upstream php-handler {
    server unix:/run/php/php7.0-fpm.sock;
    }
    
    server {
    listen 83;
    server_name 127.0.0.1;
    disable_symlinks off;
    }
    
    würde das mal stimmen wenn wir die Paramter für proxy_pass weglassen die die Webanwendung event. braucht?
    
    Antworten
    1. Jan
      13. Juli 2016 um 10:28 Uhr
      
      Hi Florian,
      
      ja, im Prinzip genau richtig.
      Wenn du mehrere PHP-Anwendungen laufen lässt, kannst du den upstream-handler auch in den Gateway-Host „hochziehen“.
      Falls es noch hakt, kannst du mir gerne auch eine E-Mail schicken – das hat ja nicht direkt was mit ownCloud zu tun :-)
      
      Gruß,
      Jan
      
      Antworten
    2. Marcus
      13. Juli 2016 um 13:46 Uhr
      
      Sofern du denselben upstream nutzen möchtest, wirst du an dieser Stelle eine Fehlermeldung erhalten, weil es den php-handler bereits gibt. Den Block kannst du dementsprechend weglassen. In größeren Umgebungen wird geraten, einen neuen upstream zu erstellen und einen neuen php-fpm Pool, damit sich die Anwendungen nicht „über den Weg laufen“.
      
      Einen root benötigt dein neuer Server dennoch, wo deine Installation liegt. Genau wie fastcgi_pass php-handler für die php-Dateien.
      
      Antworten
Nixda
13. Juli 2016 um 14:41 Uhr

Hallo,

ich würde die Cloud gerne nach dem Tutorial installieren, aber ich kann die Nginx configuration nicht durchführen, da dieser die nötigen pfade nicht findet.
wird das evtl noch nachgepflegt?
würde mich sehr darüber freuen.

LG NIXDA

Antworten
1. Jan
  13. Juli 2016 um 16:22 Uhr
  
  Hallo Nixda,
  
  ich denke mal du meinst die Pfade sites-enabled/available. Wenn diese nicht vorhanden sind, oder nginx dort angelegte virtuelle Hosts nicht lädt, dann wirf doch mal einen Blick in die Datei /etc/nginx/nginx.conf (Abschnitt Virtual Host Configs). Hier sind die Verzeichnisse angegeben, die nginx bei Start nach virtuellen Hosts durchsucht.
  
  Ich habe hierzu auch extra noch einen Hinweis im Artikel hinzugefügt.
  
  Gruß,
  Jan
  
  Antworten
Nixda
13. Juli 2016 um 17:22 Uhr

Hallo,

die konfiguration bleibt also gleich, ich muss also nur die Verzeichnisse anpassen?
Oder versteh ich das falsch?

LG NIXDA

Antworten
1. Jan
  13. Juli 2016 um 17:30 Uhr
  
  Hi,
  
  ja, an der Config selbst (also dem Datei-Inhalt) ändert sich nichts. Es sei denn, Verzeichnisse, die in der Config angegeben werden, lauten anders (z.B. der Pfad zu den Zertifikats-Dateien). Solche Probleme kann man allerdings mit dem Befehl nginx -t recht leicht herausfinden (hier werden die virtuellen Hosts lediglich getestet und nicht wirklich geladen).
  
  Gruß,
  Jan
  
  Antworten
Ondrej
15. Juli 2016 um 0:02 Uhr

Hammer guide, nur habe ich statt ownCloud benutzt der letzte fork Nextcloud – mehr OpenSource für die Kummunität… danke sehr, alles funktioniert einfach super.

Antworten
RaveKev
15. Juli 2016 um 9:38 Uhr

Danke für das super Tutorial!
Was müsste ich machen, wenn ich owncloud.meinetolleseite.goip.de als Adresse hätte, da ich auch gitlab.meinetolleseite.goip.de und jenkins.meinetolleseite.goip.de haben möchte.

Kann ich ein letsencrypt-Zertifikat für meinetolleseite.goip.de erstellen, oder muss ich das für jede subdomain extra machen?

Wie konfiguriere ich nginx dafür? Bis jetzt habe ich immer nur mit VHosts gearbeitet, aber noch nie mit dem ReverseProxy dazwischen.

Danke schön!

Antworten
1. Jan
  15. Juli 2016 um 10:10 Uhr
  
  Hallo RaveKev,
  
  Let’s Encrypt unterstützt (noch) keine Wildcard-Zertifikate. Hier ist es also notwendig, für jede Subdomain ein eigenes Zertifikat zu erzeugen. Diese Zertifikate werden dann in die jeweiligen virtuellen Hosts eingebunden. Hier muss dann jeweils der server_name und die Subdomain übereinstimmen, auf die das Zertifikat ausgestellt wurde.
  
  Einen Reverse-Proxy bzw. Gateway-Host wirst du dafür dann aber nicht brauchen. Ich verwende dieses Konstrukt nur, damit ich mehrere Webdienste auf einer Subdomain laufen lassen kann (z.B. meinetolleseite.de/owncloud und meinetolleseite.de/nextcloud). Der Gateway-Host leitet in diesem Fall auf „Verzeichnisebene“ weiter (also alles, was nach dem ‚/‘ kommt).
  Wenn du eine Trennung auf Basis mehrerer Subdomains erreichen willst, dann brauchst du einfach nur für jede Subdomain einen eigenen virtuellen Host.
  
  Allerdings könnte dir hier der DynDNS-Anbieter oder der Router einen Strich durch die Rechnung machen: Zunächst weiß ich nicht, ob man eine Domain wie sub2.sub1.goip.de registrieren kann. Wenn dies klappen sollte, muss aber auch sichergestellt sein, dass all diese DynDNS-Adressen am Router eingerichtet werden können. An der FritzBox kann ich beispielsweise immer nur eine DynDNS-Adresse einrichten.
  
  Melde dich doch bitte noch einmal, wenn du das so hinbekommen solltest. Würde mich sehr interessieren.
  
  Gruß,
  Jan
  
  Antworten
  1. RaveKev
    16. Juli 2016 um 13:20 Uhr
    
    Danke für die äußerst schnelle Antwort!
    Habe überlesen, dass du keine Subdomains sondern Pfade verwendest.
    
    Aber jetzt klappt das super. Vielen Dank.
    
    Habe mehrere Tutorials gemixt gehabt.
    
    -Kevin
    
    Antworten
smu
25. Juli 2016 um 16:20 Uhr

Hallo!

Habe nginx soweit installiert.

Probleme gibt es, sobald ich in „/etc/nginx/nginx.conf“ die Zeile „server_tokens off“ einfüge, um die Versionsnummer zu verstecken – dann lässt sich nginx mit „service nginx restart“ nicht mehr neu starten.
Es kommt die Fehlermeldung:
„Job for nginx.service failed because the control process exited with error code. See „systemctl status nginx.service“ and „journalctl -xe“ for details.

Ein weiteres Problem ist, dass sich in „/etc/nginx/“ weder der Ordner „sites-available“, noch „sites-enabled“ und demnach auch keine Datei „default“ befindet!

Benutze die Desktop-Version 16.04 LTS von Ubuntu und nicht die Server-Version.

Antworten
1. Jan
  26. Juli 2016 um 9:19 Uhr
  
  Hallo,
  
  wenn sich nginx nicht mehr starten lässt, dann versuch mal ein nginx -t in der Kommandozeile: Dann testet nginx die Config-Dateien nur und sagt dir ziemlich genau, wo der Fehler liegt.
  Ist mir am Anfang auch häufig passiert, hier hatte ich meistens irgendwo ein Semikolon vergessen.
  
  Wenn die Ordner sites-available/sites-enabled fehlen, dann erwartet nginx die Dateien vermutlich an einem anderen Ort. Ist im Artikel unter Konfiguration des Servers > Konfiguration nginx (Teil 1) > Virtuelle Hosts und Konfigurations-Dateien von nginx beschrieben. Die Configs werden dann vermutlich unter /etc/nginx/conf.d gesucht.
  
  Gruß,
  Jan
  
  Antworten
Stefan
25. Juli 2016 um 21:07 Uhr

Bekomme nach Eingabe von E-Mail-Adresse und Domain diese Fehlermeldung :( :

Failed authorization procedure. smuenz.dnshome.de (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to http://smuenz.dnshome.de/.well-known/acme-challenge/m5ucqpmCeKBtiIJYoCjMCBSybB9-GyeDMMUBKY0bqmQ

IMPORTANT NOTES:
– The following errors were reported by the server:

Domain: smuenz.dnshome.de
Type: connection
Detail: Could not connect to
http://smuenz.dnshome.de/.well-known/acme-challenge/m5ucqpmCeKBtiIJYoCjMCBSybB9-GyeDMMUBKY0bqmQ

To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you’re using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.

Antworten
1. Jan
  26. Juli 2016 um 9:25 Uhr
  
  Hallo Stefan,
  
  wie schon häufiger geschrieben wird hier sehr wahrscheinlich etwas an der Verzeichnis-Struktur und/oder der Weiterleitung auf den (lokalen) LE-Host nicht passen. Ein Blick in das Error-Log von nginx (/var/log/nginx/error.log) sollte weitere Hinweise liefern, wenn du eine beliebige (txt-)Datei unter http://smuenz.dnshome.de/.well-known/acme-challenge/ platzierst und versuchst, diese mit dem Browser zu öffnen.
  
  Gruß,
  Jan
  
  Antworten
  1. Wilhelm
    26. Juli 2016 um 17:07 Uhr
    
    Ich habe da so eine Vermutung:
    
    In der Datei
    
    /etc/nginx/sites-enabled/smuenz.dnshome.de
    
    ist die automatische Weiterleitung
    
    # Enforce HTTPS
    return 301 https://$server_addr$request_uri;
    
    auszukommentieren, dann klappts auch mit einer Erneuerung des Zertitifikates.
    
    Gruß,
    Wilhelm
    
    Antworten
Stefan
26. Juli 2016 um 17:46 Uhr

Bei mir kommt leider immer diese Fehlermeldung:

Failed authorization procedure. smuenz.dnshome.de (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to http://smuenz.dnshome.de/.well-known/acme-challenge/nHVVEi1sfuEcKUATTaN5C1UpLaTsKHjEixTy0ORKpaw

Antworten
Ruebe
27. Juli 2016 um 12:00 Uhr

Caldav/Carddav-Problem durch nginx-Konfiguration

Vielen Dank für das hervorragende Tutorial. Ich habe damit die Installation (fast) problemlos hinbekommen.

Einen Hinweis habe ich zum Umgang mit caldav/carddav in der nginx-Konfiguration: In der owncloud-Server-Konfiguration befinden sich in /etc/nginx/sites-enabled/owncloud9tutorial.goip.de_owncloud die Zeilen

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

Diese benötigt man grundsätzlich, um dav-clients, die keine explizite Pfadkonfiguration zum dav-Server erlauben, über einen Redirect auf die Sprünge zu helfen. Das ist insbesondere wg. eines Bugs für die Contacts/Calendar-Apps unter Mac OS X wichtig. Die beiden Statements sind direkt aus der Beispielkonfiguration von Owncloud übernommen

https://doc.owncloud.org/server/9.0/admin_manual/installation/nginx_owncloud_9x.html

In der konkreten Konfiguration des Tutorials klappt der Redirect allerdings nicht, weil hier Owncloud als 127.0.0.1:82 hinter einem Reverse Proxy liegt. die o.g. beiden Statements müssen aber im nach außen zeigenden Server gelten. Darum gehören die Zeilen direkt in /etc/nginx/sites-enabled/owncloud9tutorial.goip.de.

Antworten
1. Jan
  27. Juli 2016 um 13:13 Uhr
  
  Hallo Ruebe,
  
  danke für den Hinweis, ich werde dem mal nachgehen.
  Verstehe ich das richtig, dass es mit der aktuellen Konfiguration Probleme mit CardDAV/CalDAV unter Mac OS X gibt? Das kann ich nicht nachvollziehen, da ich keinen Mac nutze.
  
  Gruß,
  Jan
  
  Antworten
  1. Ruebe
    27. Juli 2016 um 22:33 Uhr
    
    Ja, ist genau so.
    
    https://github.com/owncloudarchive/contacts/issues/1058
    
    Mit der angegebenen Config klappte es bei mir für z.B. Android und iOS, aber nicht für den Mac – das ging dann erst nach der o.g. Verschiebung
    
    Antworten
Daniel
27. Juli 2016 um 12:55 Uhr

Hi, danke für den Guide, leider hänge ich jedoch auch an den „sites-Available“. Diese Ordner gibt es bei mir nicht.
In meiner nginx.conf steht leider auch nix über Abschnitt Virtual Host Configs oder so drin. Hier mal die nginx.conf:

GNU nano 2.5.3 Datei: nginx.conf

user nginx;
worker_processes 1;

error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

events {
worker_connections 1024;
}

http {
include /etc/nginx/mime.types;
default_type application/octet-stream;

log_format main ‚$remote_addr – $remote_user [$time_local] „$request“ ‚
‚$status $body_bytes_sent „$http_referer“ ‚
‚“$http_user_agent“ „$http_x_forwarded_for“‚;

access_log /var/log/nginx/access.log main;

sendfile on;
#tcp_nopush on;

keepalive_timeout 65;

#gzip on;

include /etc/nginx/conf.d/*.conf;
}

Wäre super wenn du mir kurz auf die Sprünge helfen könntest.
Danke

Antworten
1. Jan
  27. Juli 2016 um 13:10 Uhr
  
  Hi Daniel,
  
  das hier ist die entscheidende Zeile:
  include /etc/nginx/conf.d/*.conf;
  
  Im Klartext bedeutet dies, dass alle *.conf Dateien im Verzeichnis /etc/nginx/conf.d geladen werden. Sprich, hier kommen deine virtuellen Hosts hin. Wenn du einen Host deaktivieren möchtest, musst du nur die Dateiendung abändern und nginx neu starten (z.B. meineseite.conf -> meineseite.conf_disabled). Beim (Re-)Aktivieren dann genau anders herum.
  
  Gruß,
  Jan
  
  Antworten
Daniel
27. Juli 2016 um 14:09 Uhr

hab ich hinbekommen – Danke. Allerdings krieg ich jetzt beim Schritt “ https://meineip/owncloud “ über Browser aufrufen ein „Bad Gateway 502“
Irgendwo steh ich da auf dem Schlauch.

Antworten
1. Jan
  27. Juli 2016 um 14:30 Uhr
  
  Hi,
  
  dann schau bitte mal ins Error-Log von nginx (/var/log/nginx/error.log). Vielleicht passt was mit den Verzeichnisstrukturen und/oder der Weiterleitung nicht.
  
  Gruß,
  Jan
  
  Antworten
  1. Daniel
    27. Juli 2016 um 16:10 Uhr
    
    2016/07/27 15:25:23 [error] 5525#5525: *1 open() „/usr/share/nginx/html/favicon.ico“ failed (2: No s$
    2016/07/27 15:25:23 [error] 5525#5525: *1 open() „/usr/share/nginx/html/favicon.ico“ failed (2: No s$
    2016/07/27 16:08:56 [crit] 18727#18727: *2 connect() to unix:/var/run/php7.0-fpm.sock failed (2: No $
    2016/07/27 16:08:56 [error] 18727#18727: *2 open() „/var/www/favicon.ico“ failed (2: No such file or$
    2016/07/27 16:08:56 [error] 18727#18727: *2 open() „/var/www/favicon.ico“ failed (2: No such file or$
    
    Antworten
    1. Jan
      28. Juli 2016 um 10:42 Uhr
      
      Hallo Daniel,
      
      das mit dem favicon ist erst einmal halb so wild. Aber anscheinend kann der Socket für PHP7 vom Server nicht angesprochen werden. Schau doch dazu bitte mal in die Datei /etc/php/7.0/fpm/pool.d/www.conf: Hier muss ein Eintrag für den Socket hinterlegt sein (listen = /run/php/php7.0-fpm.sock). Wenn hier z.B. listen = 127.0.0.1:9000 steht, dann läuft die Kommunikation nicht über einen Socket (was zu empfehlen ist), sondern über IP:Port. In diesem Fall einfach die Zeile auskommentieren und eine neue (mit Socket) angeben und anschließend PHP neu starten.
      
      Gruß,
      Jan
      
      Antworten
Stefan
28. Juli 2016 um 10:31 Uhr

Hallo!

Danke für die Tipps, Jan.
Hab die Zertifikate jetzt selbst erstellt.

Bekomme jetzt eine Bad Gateway 502-Warnung, wenn ich auf meinedomain.de/owncloud gehe.

Antworten
1. Jan
  28. Juli 2016 um 10:34 Uhr
  
  Hallo Stefan,
  
  auch hier wieder bitte ins nginx Error-Log gucken. Hier müsste zumindest ein Hinweis auf den Fehler zu finden sein.
  
  Gruß,
  Jan
  
  Antworten
  1. Stefan
    28. Juli 2016 um 11:47 Uhr
    
    2016/07/28 02:21:34 [error] 4396#4396: *2 directory index of „/var/www/owncloud/“ is forbidden, client: 88.69.31.184, server: smuenz.dnshome.de, request: „GET /owncloud/ HTTP/1.1“, host: „smuenz.dnshome.de“
    2016/07/28 02:21:34 [crit] 4396#4396: *2 connect() to unix:/var/run/php5-fpm.sock failed (2: No such file or directory) while connecting to upstream, client: 88.69.31.184, server: smuenz.dnshome.de, request: „GET /owncloud/ HTTP/1.1“, upstream: „fastcgi://unix:/var/run/php5-fpm.sock:“, host: „smuenz.dnshome.de“
    2016/07/28 02:32:21 [crit] 4438#4438: *1 connect() to unix:/var/run/php5-fpm.sock failed (2: No such file or directory) while connecting to upstream, client: 88.69.31.184, server: smuenz.dnshome.de, request: „GET /owncloud/ HTTP/1.1“, upstream: „fastcgi://unix:/var/run/php5-fpm.sock:“, host: „smuenz.dnshome.de“
    
    Antworten
    1. Jan
      28. Juli 2016 um 13:00 Uhr
      
      Hi,
      
      auch hier bitte, wie in einem Kommentar weiter oben beschrieben, die PHP-Konfiguration in der Datei /etc/php/7.0/fpm/pool.d/www.conf checken.
      
      Gruß,
      Jan
      
      Antworten
      1. Stefan
        28. Juli 2016 um 13:59 Uhr
        
        Ist gecheckt – steht aber „listen = /run/php/php7.0-fpm.sock“ drin :(
      2. Stefan
        28. Juli 2016 um 19:46 Uhr
        
        Komisch, dass in dem Error-Logfile was von PHP5 drin steht, ich aber PHP7 installiert habe!
Jens
30. Juli 2016 um 11:01 Uhr

Hallo Jan !

Erst einmal vielen Dank für tolle Tutorial – auch mir als totalen Noob ist es gelungen, meine ownCloud erfolgreich in Betrieb zu nehmen !

Ich würde jetzt gerne zusätzlich eine eigene kleine Anwendung „test“ laufen lassen und habe hierzu einen zusätzlichen Eintrag /test in der owncloud9tutorial.goip.de vorgenommen – analog zu /owncloud.

Eine zusätzliche owncloud9tutorial.goip.de_test habe ich auch erstellt und der Zugriff auf „normale“ html-Dateien funktioniert auch, allerdings wird php nicht ausgeführt, sondern die entsprechende Datei zum Download angeboten.

Ich vermute, meine Pfade/Verweise zum PHP stimmen nicht – allerdings komme ich hier nicht weiter. Kannst Du mir bei diesem Problem helfen ?

Vielen Dank und viele Grüße,

JENS!

zusätzlicher Eintrag in der owncloud9tutorial.goip.de :

location ^~ /test {
# 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‘ ownclo$
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:84;
proxy_redirect off;

owncloud9tutorial.goip.de_test :

######

server {
listen 84;
server_name 127.0.0.1;

error_page 405 =200 $uri;

location ^~ /test {
index index.html;
try_files $uri $uri/ /index.html;
root /var/www/;
}

location ~ ^/test/\.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$
# All the PHP parameters have to be set in one fastcgi_param. When using more ‚fastcgi_param P$
fastcgi_param PHP_VALUE „open_basedir=/var/www:/tmp/:/var/www/test:/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;
}

}

Antworten
1. Jan
  30. Juli 2016 um 13:14 Uhr
  
  Hallo Jens,
  
  danke für das Lob!
  
  Um zwei (oder mehr) PHP-Anwendungen laufen zu lassen, kannst du den entsprechenden Upstream-Handler in den Gateway-Host hochziehen und aus der ownCloud-Konfiguration entfernen:
  upstream php-handler { server unix:/run/php/php7.0-fpm.sock; }
  
  Gruß,
  Jan
  
  Antworten
  1. Jens
    30. Juli 2016 um 17:46 Uhr
    
    Hallo Jan !
    
    Ich habe den Upstream-Handler in die owncloud9tutorial.goip.de verschoben, aber leider brachte das keine Änderung.
    
    Ich habe dann ein wenig mit den locations experimentiert und mit folgender Änderung in der owncloud9tutorial.goip.de_test hat es dann funktioniert :
    
    location ~ ^/test/\.php$ { #### ALT
    
    location ~ \.php$ { #### NEU
    
    Vielen Dank für Deine Hilfe und viele Grüße,
    
    JENS!
    
    Antworten
    1. Ingo
      5. September 2016 um 15:43 Uhr
      
      Hallo
      Ich habe die info.php datei im Verzeichnis /var/www/test angelegt mit volgenen Inhalt
      
      Und das was Jens ergänzt bzw. geändert hat habe ich vorgenommen.
      Wenn ich jetzt die owncloud9tutorial.goip.de/test/info.php aufrufe im Webbrowser, wir mir nur die Datei zum Downloaden angeboten mit dem Inhalt den ich da reingeschrieben habe.
      Kann mir eine sagen was ich noch ändern muss?
      
      Bis dann
      Ingp
      
      Antworten
      1. Jan
        6. September 2016 um 7:01 Uhr
        
        Hallo Ingo,
        
        um PHP auch außerhalb des ownCloud-Verzeichnisses nutzen zu können, muss der PHP-Handler (upstream php-handler) zunächst einmal in den Gateway-Host verschoben werden, damit dieser „global“ verfügbar ist.
        Wenn er nun die test/info.php herunterladen will, ist dies ein sicheres Anzeichen, dass der PHP-Handler nicht greift. Dann fügst du (ebenfalls im Gateway-Host) einen allgemeinen PHP-Handler hinzu (und zwar vor der Zeile location ^~ /owncloud {):
        location ~ \.php$ { include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param HTTPS on; fastcgi_pass php-handler; }
        
        Wenn das immer noch nichts bringt, versuch doch mal, den allgemeinen PHP-Handler nach dem Block mit dem ownCloud-Redirect einzufügen.
        
        Gruß,
        Jan
      2. Ingo
        6. September 2016 um 14:25 Uhr
        
        Hallo Jan,
        
        Das mit den allgemeinen PHP-Handler funktioniert aber nur wen man im Virtuellen Host im Server Block nach root /var/www/; einfügt.
        
        Oder im Gateway-Host wen man ihm mit bei location ^~ /test/ einfügt.
        
        Nur habe ich noch eine Frage.
        Warum muss ich noch hinter location ^~ /test/ ein slash machen damit wen ich owncloud9tutorial.goip.de/test aufrufe die index.html Seite angezeigt wird, mache ich das nicht kommt der Fehler: Netzwerk-Zeitüberschreitung.
        
        Außer ich mach das slash hinter der Adresse.
        
        Bis dann
        Ingo
      3. Jan
        6. September 2016 um 15:31 Uhr
        
        Hallo Ingo,
        
        das mit dem Slash liegt am Algorithmus, wie nginx Anfragen interpretiert und entscheidet, welcher location-Block zuständig ist. Auf dieser Seite findest du dazu eine Menge Infos.
        
        Der allgemeine PHP-Handler würde vermutlich mit dieser Definition auch gehen:
        location ~* \.php$ { try_files $uri =404; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param HTTPS on; fastcgi_pass php-handler; }
        
        Hier werden einfach alle Requests, die durch keinen anderen location-Block abgefangen werden und auf *.php enden, an diesen Handler weiter geleitet.
        Wichtig ist dabei dann allerdings das try_files $uri =404;, wenn dies weggelassen wird, stellt dies u.U. ein Sicherheitsrisiko dar (siehe hier).
        
        Gruß,
        Jan
Marc
4. August 2016 um 16:56 Uhr

Hallo Jan,

erstmal danke für die Tolle Anleitung. Ich als totaler Linux Neuling kam Problemlos damit zurecht. Allerdings funktioniert bei mir owncloud nicht so wirklich. Ich kam bereits so weit, dass ich Benutzernamen, Kennwort, Speicherpfad und Datenbankinformationen eingeben konnte, allerdings kommt danach bei mir nur noch folgende Seite welche ich nicht verstehe:

<?php
/**
* @author JÃ¶rn Friedrich Dreyer
* @author Lukas Reschke
* @author Morris Jobke
* @author Robin Appelman
* @author Thomas MÃ¼ller
* @author Vincent Petry
*
* @copyright Copyright (c) 2016, ownCloud, Inc.
* @license AGPL-3.0
*
* This code is free software: you can redistribute it and/or modify
* it under the terms of the GNU Affero General Public License, version 3,
* as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU Affero General Public License for more details.
*
* You should have received a copy of the GNU Affero General Public License, version 3,
* along with this program. If not, see
*
*/

// Show warning if a PHP version below 5.4.0 is used, this has to happen here
// because base.php will already use 5.4 syntax.
if (version_compare(PHP_VERSION, ‚5.4.0‘) === -1) {
echo ‚This version of ownCloud requires at least PHP 5.4.0‘;
echo ‚You are currently running ‚ . PHP_VERSION . ‚. Please update your PHP version.‘;
return;
}

try {

require_once ‚lib/base.php‘;

OC::handleRequest();

} catch(\OC\ServiceUnavailableException $ex) {
\OC::$server->getLogger()->logException($ex, [‚app‘ => ‚index‘]);

//show the user a detailed error page
OC_Response::setStatus(OC_Response::STATUS_SERVICE_UNAVAILABLE);
OC_Template::printExceptionErrorPage($ex);
} catch (\OC\HintException $ex) {
OC_Response::setStatus(OC_Response::STATUS_SERVICE_UNAVAILABLE);
OC_Template::printErrorPage($ex->getMessage(), $ex->getHint());
} catch (Exception $ex) {
\OC::$server->getLogger()->logException($ex, [‚app‘ => ‚index‘]);

//show the user a detailed error page
OC_Response::setStatus(OC_Response::STATUS_INTERNAL_SERVER_ERROR);
OC_Template::printExceptionErrorPage($ex);
} catch (Error $ex) {
\OC::$server->getLogger()->logException($ex, [‚app‘ => ‚index‘]);
OC_Response::setStatus(OC_Response::STATUS_INTERNAL_SERVER_ERROR);
OC_Template::printExceptionErrorPage($ex);
}

Könntest du mir da helfen?? Habe ich irgendwas vergessen bzw falsch gemacht oder lässt sich daraus nichts erkennen?

Grüße,
Marc

Antworten
1. Marc
  4. August 2016 um 23:19 Uhr
  
  Hey, kurzes Update
  
  Habe einfach nochmal alle Schritte was Konfiguration von PHP und nginx angeht durchgeführt und plötzlich klappt es. :D
  
  Allerdings würde ich gerne noch meinen Ordner in welchem die Dateien gelagert werden auf eine Externe NTFS Platte Lagern. Nur OC verlangt nach verschieben des Ordners, eintragen in die Configs und vergeben der Rechte verlante OC immer nach einer leeren .ocloud Datei im Root Verzeichnis wenn ich mich nicht Irre – habe es aber nicht mehr wirklich im Kopf jetzt.
  
  Hättest du da einen Tipp für mich wie ich das ganze zum laufen bekomme? Die Platte ist bereits per fstab unter /media/ gemountet.
  
  Grüße,
  Marc
  
  Antworten
  1. Jan
    5. August 2016 um 6:35 Uhr
    
    Hallo Marc,
    
    danke für die Rückmeldung!
    Dein erstes Problem lag vermutlich da dran, dass PHP nicht richtig eingebunden war, hier wurde die PHP-Datei von ownCloud „im Klartext“ ausgeliefert, sprich: wurde nicht von PHP bearbeitet.
    
    Zum Datenverzeichnis auf der externen Festplatte: Hier wurden vermutlich die versteckten Dateien (mit ‚.‘ am Anfang) nicht mit verschoben. Ist ein wenig kompliziert, das mit dem mv Befehl hinzubekommen, daher verwende einfach ein cp (kopieren) und anschließend ein rm (löschen):
    cp -rf /var/owncloud_data /media/hdd/owncloud_data rm -rf /var/owncloud_data
    Bitte vor dem Löschen kontrollieren, ob auch die .-Dateien kopiert wurden:
    cd /media/hdd/owncloud_data ls -a
    
    Gruß,
    Jan
    
    Antworten
    1. Heinz
      19. August 2016 um 21:31 Uhr
      
      Hallo Jan,
      
      ich hab auch eine Frage zu dem Thema.
      
      Ich habe eine Windows Freigabe via fstab eingebunden und habe die user/group dabei zu www-data gegeben.
      nun bekomme ich eine Fehlermeldung
      
      Das Erstellen des „data“-Verzeichnisses ist nicht möglich (/mnt/DATEN)
      
      Dies kann normalerweise repariert werden, indem dem Webserver Schreibzugriff auf das Wurzelverzeichnis gegeben wird.
      
      Kannst du mir eventuell helfen?
      Danke
      VG Heinz
      
      Antworten
      1. Jan
        20. August 2016 um 11:38 Uhr
        
        Hallo Heinz,
        
        zum Setzen der Berechtigungen hast du vermutlich folgenden Befehl genutzt:
        chown -R www-data:www-data /mnt/DATEN
        Dieses Verzeichnis muss dann ebenfalls in der PHP-Variablen für open_basedir mit angegeben werden, sonst kann PHP darauf nicht zugreifen (CLI, als auch FPM – hier gibt es zwei unterschiedliche Configs).
        
        Wenn das alles nicht klappt, dann könnte es auch sein, dass du von Linux aus keine Berechtigungen auf dem NTFS-Dateisystem setzen kannst. In dem Fall wirst du die Netzwerk-Freigabe in der Cloud nicht ohne weiteres nutzen können.
        
        Gruß,
        Jan
Reinhard
6. August 2016 um 16:38 Uhr

Hallo Jan,

danke erstmal für die prima Anleitung!

Leider hätte ich auch noch ein „502 Bad Gateway“ in Angebot. Die http://www.conf von PHP7 habe ich schon überprüft, das error.log von nginx sagt:

2016/08/06 16:34:59 [crit] 3397#3397: *39 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 /owncloud HTTP/1.0“, upstream: „fastcgi://unix:/run/php/php7.0-fpm.sock:“, host: „192.168.123.40“

An welcher Berechtigung muss hier noch etwas angepasst werden?

Gruß,
Reinhard

Antworten
1. Jan
  8. August 2016 um 7:18 Uhr
  Hallo Reinhard,
  
  hier scheint etwas an den Zugriffsrechten nicht zu passen. Kontrollier doch bitte mal folgendes:
  - Nutzer, mit dem der Webserver läuft (/etc/nginx/nginx.conf -> user)
  - Nutzer, mit dem PHP läuft (/etc/php/7.0/fpm/pool.d/www.conf -> user bzw. group)
  In beiden Fällen muss dies www-data sein. Nach einer Änderung muss der Webserver und/oder der PHP-Service neu gestartet werden.
  
  Gruß,
  Jan
  
  Antworten
  1. Hallo
    27. August 2016 um 11:12 Uhr
    
    Hallo,
    
    ich ahbe genau das glecihe Problem…
    wie habt ihr es denn gelöst?
    ein einfaches chown -R www-data:www-data /etc/nginx/nginx.conf
    oder chown -R www-data:www-data /etc/php/7.0/fpm/pool.d/www.conf
    hat nicht geholfen :(
    
    Dankeschön
    
    Antworten
    1. Jan
      27. August 2016 um 12:05 Uhr
      
      Hallo,
      
      das dürfte nichts mit den Zugriffsrechten auf Datei-Ebene zu tun haben.
      
      Nutzer, mit dem der Webserver läuft (/etc/nginx/nginx.conf -> user)
      
      Nutzer, mit dem PHP läuft (/etc/php/7.0/fpm/pool.d/www.conf -> user bzw. group)
      
      Hiermit meinte ich die Inhalte der jeweiligen Dateien. Diese also beispielsweise mit nano öffnen und nach den entsprechenden Inhalten suchen.
      
      Gruß,
      Jan
      
      Antworten
Major
11. August 2016 um 19:02 Uhr

Lief auch mit Nextcloud 9.0.50, wobei ich sorgsam überall owncloud durch nextcloud ersetzt habe.

Allerdings war hat nginx in *meinem* Fall mit meinen paar Usern keinen messbaren Performance-Schub gegenüber dem Apachen 2.4 gebracht, aber die Konfiguration ist damit dann doch deutlich einfacher, gerade bei Letsencrypt.

Deshalb werde ich wieder auf die VM mit der Apache-Installation zurück fallen. Spart mir das zusätzliche Lernen der nginx-Konfiguration

Antworten
1. Jan
  12. August 2016 um 9:13 Uhr
  
  Hallo,
  
  ja, in den meisten Fällen dürfte man im Vergleich zu Apache keinen Unterschied bzgl. der Performance merken. Das wird erst eine Rolle bei sehr vielen (gleichzeitig angemeldeten) Usern und/oder schwachbrüstiger Hardware (RasPi, etc.) spielen.
  Wenn du mit Apache besser zurecht kommst, dann würde ich auch dabei bleiben.
  
  Gruß,
  Jan
  
  Antworten
M. Jor
12. August 2016 um 10:00 Uhr

Sehr gutes tutorial, hat fast auf Anhieb funktioniert, Danke.

Auch das Proxy-Prinzip ist schön, weil es so etwas an das Apache-Konzept der Modularität herankommt.

Ich habe nur dadurch ein anderes Problem:

Bei mir ist die Owncloud unter http://www.beispiel.de/owncloud erreichbar.

Funktioniert prächtig, das LE-Zertifikat ist ja für http://www.beispiel.de ausgestellt. Aber: http://www.beispiel.de ohne /nextcloud erzeugt jetzt einen „403 forbidden“.
Ich habe da noch nicht ganz verstanden, wohin der Reverse-Proxy ohne nachgestellter URI veweist, also für die location / ohne $request_uri

Ich hätte gerne einen virtuellen Host dafür, aber die location / verweist ja schon auf einen 301 redirect und

return 301 https://$server_addr$request_uri;

läuft ins Leere.

Vorgestellt hatte ich mir das eigentlich wieder als virtuellen Host, der in der Location auf /var/www/www/ verweist, um die Daten dort wieder getrennt zu haben.

Antworten
1. Jan
  12. August 2016 um 10:33 Uhr
  
  Hi,
  
  ja, dieses Verhalten ist soweit auch logisch, wenn du die Configs so aus dem Tutorial übernommen hast:
  http://beispiel.de (also /-Location) wird auf https://beispiel.de weitergeleitet. Im HTTPS-Server-Block steht dann ein
  location = / { deny all; }
  Dies sorgt für den 403-Fehler.
  
  Wenn du nun im Root-Verzeichnis von https://beispiel.de eine andere Website laufen lassen möchtest, dann musst du genau hier ansetzen: Am besten einen separaten virtuellen Host einrichten und dann mittels proxy_pass an diesen weiterleiten (alles im /-location-Block des HTTPS-Server-Blocks, wo jetzt das deny all; steht).
  Wie der zusätzliche vHost aufgebaut sein muss, hängt natürlich von der jeweiligen Webanwendung ab.
  
  Gruß,
  Jan
  
  Antworten
Hans
23. August 2016 um 14:03 Uhr

Hallo,

ich habe mein Let´s Encrypt Zertifikat über

sudo -H ./letsencrypt-auto certonly -a webroot –webroot-path=/var/www/letsencrypt –rsa-key-size 4096

erneuert. Allerdings beim Aufruf von Owncloud wird angezeigt, dass das Zertifikat abgelaufen sei.
Du hast ja im Tutorial ergänzt:

Update 04.08.2016:

Verbesserungen beim Rewrite von HTTP auf HTTPS (zuvor gab es Probleme beim Erneuern des Let’s Encrypt Zertifikats).

Was hast Du genau geändert?

Gruß Hans

Antworten
1. Jan
  24. August 2016 um 6:41 Uhr
  
  Hallo Hans,
  
  geändert habe ich lediglich den Server-Block für HTTP im Gateway-Host:
  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; } }
  
  Aber wenn Let’s Encrypt keine Fehlermeldung gebracht hat, dann müsste die Erzeugung der neuen Zertifikate eigentlich geklappt haben. Liegen diese im Verzeichnis /etc/letsencrypt/live/?
  
  Gruß,
  Jan
  
  Antworten
  1. Hans
    24. August 2016 um 21:09 Uhr
    
    Hallo Jan,
    
    die Zertifikate liegen im Verzeichnis
    
    etc/letsencrypt/live/owncloud9tutorial.goip.de
    
    Die 4 Dateien sind auch von dem Datum, an dem ich das Zertifikat erneuert habe.
    
    lrwxrwxrwx 1 root root 41 Aug 19 18:38 cert.pem -> ../../archive/owncloud9tutorial.goip.de/cert2.pem
    lrwxrwxrwx 1 root root 42 Aug 19 18:38 chain.pem -> ../../archive/owncloud9tutorial.goip.de/chain2.pem
    lrwxrwxrwx 1 root root 46 Aug 19 18:38 fullchain.pem -> ../../archive/owncloud9tutorial.goip.de/fullchain2.pem
    lrwxrwxrwx 1 root root 44 Aug 19 18:38 privkey.pem -> ../../archive/owncloud9tutorial.goip.de/privkey2.pem
    
    Ich habe nun noch Deine Änderungen an dem Server Block vorgenommen und den Server neu gestartet. Jetzt scheint es zu funktionieren. Der Neustart war wohl notwendig.
    
    Antworten
    1. Jan
      26. August 2016 um 19:57 Uhr
      
      Hallo Hans,
      
      ja, ein Neustart (des Servers und/oder der Dienste) kann oftmals Wunder bewirken. ;)
      
      Gruß,
      Jan
      
      Antworten
Philipp
2. September 2016 um 16:59 Uhr

Hallo Jan!

Erstmal vielen Dank für die wirklich tolle Anleitung, sie ist echt verständlich und nachvollziehbar!
Es hat alles bisher super funktioniert, nur habe ich heute Chrome auf Version 53 geupdated und nun kommt eine SSL Fehlermeldung:
„This site can’t provide a secure connection“
…
„ERR_SSL_OBSOLETE_CIPHER“
…
„Unsupported protocol
The client and server don’t support a common SSL protocol version or cipher suite.“
Hab kurz nachgelesen und gesehen dass es irgendwas mit DHE zu tun hat, aber ich bin da leider mit der Materie zu wenig vertraut.

Hast du vielleicht eine Idee was man da nun anders machen muss?

LG,
Philipp

Antworten
1. Jan
  3. September 2016 um 9:13 Uhr
  
  Hi Philipp,
  
  danke für das Lob und für diesen wichtigen Hinweis. Mir wäre das vermutlich nicht so schnell aufgefallen, da ich Chrome nur selten nutze.
  Ich habe ein wenig recherchiert und es liegt an den elliptischen Kurven für ECDHE chipers (Variable ssl_ecdh_curve im Gateway-Host). In Chrome 53 wurde wohl die Unterstützung von secp521r1 gestrichen. Hier muss man auf secp384r1 ausweichen, damit die Website mit Chrome wieder angezeigt werden kann.
  Im Rahmen dessen habe ich auch gleich die Empfehlung für die ssl_ciphers angepasst, hier kann nun ssl_ciphers ‚AES256+EECDH:AES256+EDH:!aNULL‘; verwendet werden (höhere Sicherheit, allerdings gab es hier zuvor Probleme mit Chrome).
  
  Den Artikel habe ich dementsprechend angepasst.
  
  Gruß,
  Jan
  
  Antworten
  1. Ingo
    4. September 2016 um 20:58 Uhr
    
    Hallo Jan,
    
    Diese Einstellung funktionieren aber nicht mit dem Firefox, da kommt es dann zu Fehler Meldungen.
    
    Bis dann
    Ingo
    
    Antworten
    1. Jan
      5. September 2016 um 7:11 Uhr
      
      Hi,
      
      stimmt, da hast du recht. Ein Browser zickt wohl immer rum. ;)
      Habe die ssl_ciphers wieder auf den ursprünglichen Wert gesetzt. Die einzige Änderung für das Problem mit Chrome 53 ist ssl_ecdh_curve secp384r1;.
      Nun funktioniert es mit Chrome, Firefox, IE und Edge.
      
      Gruß,
      Jan
      
      Antworten
  2. Philipp
    9. September 2016 um 17:07 Uhr
    
    Hey Jan,
    vielen Dank für deine rasche Antwort, es hat super geklappt!
    
    Ich hab jetzt noch ein anderes seltsames Problem unabhängig von dem Vorherigen:
    Ich habe mit deiner Anleitung einen Nginx Proxy für mein Domoticz Home Automation eingerichtet. Hat bis vor Kurzem auch alles super funktioniert. Allerdings bekomme ich beim starten von Nginx immer ein „502 Bad Request“ im Browser und im Log ein „upstream prematurely closed from 127.0.0.1:8080“. Wenn ich allerdings die nginx-debug statt der normalen nginx binary starte, dann funktioniert alles ganz normal… (Obwohl beide auf die selben configs zugreifen?)
    Weißt du vielleicht Rat?
    
    LG,
    Philipp
    
    Antworten
    1. Jan
      9. September 2016 um 18:38 Uhr
      
      Hallo Philipp,
      
      eine direkte Erklärung dafür habe ich nicht.
      Aber werf doch mal einen Blick in das Error-Log von nginx (/var/log/nginx/error.log) nachdem du einen solchen 502er Fehler bekommen hast. Hier sollte zumindest ein Hinweis zu finden sein, was schief gelaufen ist.
      
      Gruß,
      Jan
      
      Antworten
thomas
7. September 2016 um 21:12 Uhr

Hallo Jan,
das ist wirklich ein großartiger Artikel. Den ich auf einem Pi2 mit Raspian (und ein wenig Vorerfahrung) nachvollziehen konnte. Die einzigen Abweichungen ergeben sich, wie erwartet beim Punkt ARM vs x86. Aber an sonsten eine Freude zu lesen.

Ich habe noch eine kurze Frage: Ich habe den Proxy wie beschrieben konfiguriert. Manchmal, z.B. nach der Abmeldung springt die URL von https nach http zurück (z.B. nach http://localip/owncloud/login), da diese nicht-verschlüsselte Verbindung nicht zulässig ist, ist damit die Webseite nicht mehr verfügbar. Die Nginx config ist bis auf die DNS Einträge und IPs identisch zu Deiner. Die OC config ist unveränderter Standard.
Der Betrieb läuft bis auf diesen Fehler normal.

Hast Du eine Idee, wo ich mal nachschauen kann?

Vielen Dank

Thomas

Antworten
1. Jan
  8. September 2016 um 6:50 Uhr
  
  Hallo Thomas und danke für das Lob!
  
  Also dass das Protokoll wieder auf HTTP zurück springt, ist mir noch nicht untergekommen.
  Du könntest mal folgendes ausprobieren: Den Redirect auf HTTPS ziehst du aus dem Block location / {…} eine Ebene nach oben, so dass dieser direkt im server-Block zu finden ist. Vielleicht bekommst du das damit in den Griff.
  
  Gruß,
  Jan
  
  Antworten
Thomas
8. September 2016 um 19:17 Uhr

Hallo Jan,

hab ich ausprobiert – führt zum gleichen Ergebnis. Hast Du noch andere Ideen?

Viele Grüße

Thomas

Antworten
1. Thomas
  12. September 2016 um 14:38 Uhr
  
  Hallo Jan, liebe Leser,
  
  ich habe den Fehler gefunden.
  
  Der Eintrag:
  
  ‚overwriteprotocol‘ => ‚https‘
  
  innerhalb der config.php der Owncloud-Instanz behebt das Problem.
  
  Vielen Dank Jan für Deine Hilfe
  
  Thomas
  
  Antworten
Major
14. September 2016 um 19:53 Uhr

Hat schon jemand auf Nextcloud 10 aktualisiert ?

Bisher habe ich das drei Mal versucht, und es hat jedes Mal NICHT geklappt.
Automatisch geht das sowieso nicht, also habe ich das manuell gemacht.
Leider jedes Mal ohne Erfolg. Bosher läuft nur die 9.0.53 stabil.

Es scheint sich aber um einen Fehler in der Nextcloud-Installation zu handeln, denn die nginx-Config als reverse proxy läuft und eine einzelne phpinfo()- index.php läuft auch. Die NC-index.php liefert aber leider nur eine tote weiße Seite, ohne Anmeldemöglichkeit.

Ich bin diversen Hinweisen wie fastcgi-param umstellen nachgegangen, aber es läuft einfach nicht.

Antworten
1. Jan
  14. September 2016 um 20:11 Uhr
  
  Hi,
  
  was sagen die Logs?
  Vielleicht muss man hier nachbessern.
  
  Gruß,
  Jan
  
  Antworten
  1. Major
    9. Oktober 2016 um 13:55 Uhr
    
    Hat sich mit NC 10.0.1 einfach so erledigt. Das Update war problemlos.
    
    1. NC in den Wartungsmodus versetzt
    2. NGINX beendet
    3. Altes Verzeichnis umbenannt
    4. NC 10.0.1 heruntergeladen, entpackt und auf „alten“ Pfad kopiert
    5. Benutzerrechte angepasst
    6. NGINX starten
    7. Wartungsmodus aus
    8. über das Webinterface den Update-Prozess gestartet.
    
    Läuft.
    
    Antworten
Michael
16. September 2016 um 16:24 Uhr

Hallo super Anleitung habe das ganze mit Nextcloud 10 am laufen.
Habe nur ein Problem mit dem Upload Size von mehr als 10 GB

im Admin Beckend von Nextcloud kann ich z.B. 15 GB einstellen und es wird auch in den zwei Dateien .htaccess und .user.ini abgespeichert,
nach dem ich den zwei Dateien die berechtigung chown -R www-data:www-data gesetzt habe.
Aktualisiert man das Backend stehen wieder 10 GB drin.

In der Virtuellen Host Datei habe ich die Einträge auf 16 GB angepasst
ich kann auch per Browser Firefox ohne problem 10 GB hochladen aber nicht mehr.
Über den Windows client von Nextcloud gehen auch 15 GB und mehr

ich vermute das hat was mit der Anzeige im Adminbeckend zu tun. Bin mir nicht ganz sicher aber ich meine gesehen zu haben,
wenn ein Apcheserver läuft
bleibt die Einstellung der angegebenen speichergrösse im AdminsBackend auch stehen

kann mir jemand weiterhelfen
beste Grüße,
Michi

Antworten
1. Jan
  16. September 2016 um 17:03 Uhr
  
  Hallo Michael,
  
  mit der Anpassung der max. Upload-Größe in der Admin-UI hatte ich auch schon einige Probleme. Das hat mit nginx leider noch nie so richtig funktioniert.
  Unter Apache wird der Wert einfach in die .htaccess eingetragen, jedoch ist diese Datei für nginx belanglos. Hier steuert man das hauptsächlich über den virtuellen Host.
  
  Da du nun über den Desktop-Client Dateien größer 10 GB hochladen kannst, scheint das ja schonmal prinzipiell zu funktionieren. Warum das mit Firefox nicht klappt ist allerdings merkwürdig. Hast du hier auch schonmal andere Browser ausprobiert?
  
  Spontan würde ich hier auf einen Timeout tippen. Evtl. musst du dazu die Timeout-Werte im vHost auch noch erhöhen. Was sagen die Logs, wenn ein Upload abbricht?
  
  Gruß,
  Jan
  
  Antworten
  1. Michael
    19. September 2016 um 11:02 Uhr
    
    Hallo Jan,
    
    in den Log steht leider nichts drin ich habe es auch mit dem Google Chrom versucht es fängt erst gar nicht an zum uploaden das war beim Firefox auch so es erscheint sofort die Meldung im oberen Bereich des Browsers wenn man die Datei grösser 10 GB anklickt
    Meldung!
    Fehler beim Hochladen der Datei „test12GB.dat“: Die Gesamt-Größe 12 GB überschreitet die Upload-Begrenzung 10 GB
    
    ich vermute doch das das was mit den 10 GB in der Admin UI zu tun hat
    
    Antworten
    1. Jan
      20. September 2016 um 6:49 Uhr
      
      Hallo Michael,
      
      also wenn du folgende Variablen gesetzt hast, wüsste ich nicht, warum ein größerer Upload nicht funktionieren sollte:
      
      Gateway-Host (location ^~ /owncloud {…): client_max_body_size, proxy_connect_timeout, proxy_send_timeout, proxy_read_timeout, send_timeout
      
      vHost ownCloud (location ^~ /owncloud {…): client_max_body_size
      
      vHost ownCloud (location ~ ^/owncloud/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|ocs-provider/.+|core/templates/40[34])\.php(?:$|/) {…): fastcgi_read_timeout, fastcgi_send_timeout, fastcgi_connect_timeout
      
      vHost OwnCloud (fastcgi_param PHP_VALUE …): upload_max_filesize, post_max_size, max_execution_time
      
      Mit den ganzen Timeout-Werten muss man evtl. ein wenig rumprobieren. Diese sollten im Vergleich zum Tutorial allerdings generell erhöht werden, um größere Uploads zuzulassen.
      
      Hier habe ich auch noch einen Artikel über große Uploads mit ownCloud auf nginx gefunden. Ist zwar schon etwas älter, aber dennoch vielleicht ganz hilfreich.
      
      Gruß,
      Jan
      
      Antworten
Nik
17. September 2016 um 1:13 Uhr

Super Anleitung! Hilft einen schnell einen sicheren OC-Server zu erstellen.

Hätte da ne Frage. Ich nutze das Addon external Storage, wenn ich jetzt einen Ordner einstelle und diesen das aufrufen möchte, werde ich immer wieder ins Hauptverzeichnis des Benutzer geleitet. Habe noch einen anderen OC-Server aber mit Version 8.1, da läuft es ohne Probleme.

PS. basedir habe ich nicht gesetzt gehabt.

Antworten
1. Jan
  17. September 2016 um 9:09 Uhr
  
  Hallo Nik,
  
  hast du die Verzeichnisrechte gesetzt (chown -R www-data /mein/Verzeichnis)?
  Falls ja, was sagen die Logs (ownCloud/nginx) beim Zugriff auf dieses Verzeichnis?
  
  Gruß,
  Jan
  
  Antworten
  1. Nik
    17. September 2016 um 13:01 Uhr
    
    Rechte hab ich gesetzt, dennoch das selbe Problem.
    
    Mein OC-Log gibt diese Fehler aus:
    
    realpath(): open_basedir restriction in effect. File(/media/G3Station) is not within the allowed path(s): (/var/www:/tmp/:/var/owncloud_data:/dev/urandom) at /var/www/owncloud/lib/private/Files/Storage/Local.php#56
    
    is_dir(): open_basedir restriction in effect. File(/media/G3Station/) is not within the allowed path(s): (/var/www:/tmp/:/var/owncloud_data:/dev/urandom) at /var/www/owncloud/lib/private/Files/Storage/Local.php#118
    
    open_basedir ist mit ; ausgeklammert in der php.ini. Weißt vllt voran es liegen könnte?
    
    Antworten
    1. Jan
      18. September 2016 um 12:09 Uhr
      
      Hi Nik,
      
      ist open_basedir in beiden phh.ini auskommentiert (/etc/php/7.0/fpm/php.ini und /etc/php/7.0/cli/php.ini)? Irgendwo muss ja open_basedir gesetzt sein, ansonsten würde ownCloud ja keine fehlende Verzeichnis-Berechtigung anzeigen.
      
      Gruß,
      Jan
      
      Antworten
      1. Nik
        18. September 2016 um 12:54 Uhr
        
        Hi Jan,
        
        ist bei beiden ini`s ausgeklammert. Gibt es sonst noch eine Möglichkeit?
        
        Gruß
      2. Jan
        18. September 2016 um 17:38 Uhr
        
        Hi Nik,
        
        ansonsten fällt mir nur noch das fastcgi_param PHP_VALUE.. im ownCloud-vHost ein. Wüsste sonst nicht, wo noch ein open_basedir definiert werden könnte…
        
        Gruß,
        Jan
      3. Ingo
        18. September 2016 um 17:29 Uhr
        
        Hallo
        
        Ich hatte auch ein Problem mit open_basedir. Hast du auch das Verzeichnis mit im Virtuellen Host von ownCloud bei „fastcgi_param PHP_VALUE „open_basedir=/var/www:/tmp/:/var/owncloud_data:“ angegeben und du musst auch www-data die Zugriffsrechte geben für das Verzeichnis. Und alles neustarten oder ein reboot machen.
        Das hatte ich bei mir Vergessen.
        
        Bis dann
        Ingo
      4. Nik
        18. September 2016 um 19:52 Uhr
        
        Hi Jan,
        
        hast Recht, genau da war es :).
        
        Danke
Markus
17. September 2016 um 15:09 Uhr

Hallo Jan,
super Anleitung. Konnte soweit alles umsetzen und bin gerade am testen.

Dabei bin ich auf ein seltsamen problem gestoßen, zu dem ich nichts über google bzw. in den owncloud Foren finden konnte.

Und zwar über den Link den man in der Passwort Reset Mail erhält, sollte man ja ein neues angeben können. Dieses wird aber nicht angenommen. Man gibt es ein er lädt kurz, zeigt wieder die PAssworteingabe ein und es passiert nichts weiter. Probiert man dann sich mit dem neuen kennwort einzuloggen klappt es nicht. Mit dem alten jedoch schon. Wenn ich es im User bzw.. Admin Backend ändere wird die Änderung angenommen.

Der User hat keine Admin oder Gruppenadmin Rechte.

In der owncloud Log wird dazu leider nichts geloggt, obwohl ich höchste Stufe aktiviert habe. Auch in der nginx und mysql Log steht meiner Meinung nichts brauchbares.

Hast du noch eine Idee oder hast du dies schonmal getestet? Danke im voraus.

Grüße,
Markus

Antworten
1. Jan
  18. September 2016 um 11:57 Uhr
  
  Hallo Markus,
  
  wenn ein Passwort nicht zurück gesetzt werden kann, ist natürlich problematisch.
  Ich habe das Ganze mal ausprobiert und bei mir klappt das. Wenn das Verschlüsselungs-Modul aktiviert wurde, erscheint hier eine deutliche Warnung, dass das Wiederherstellungs-Passwort für die Verschlüsselung für den entsprechenden User gesetzt sein sollte. Ansonsten kommt man danach nicht mehr an die eigenen Daten heran. Wenn dies allerdings gesetzt ist, kann das Passwort über die Passwort-Reset-Funktion geändert werden und dies ist für nächste Anmeldung dann auch gültig.
  
  Also ich kann diesen Fehler nicht nachvollziehen. Ich würde an deiner Stelle mal im ownCloud-Forum nachfragen…
  
  Gruß,
  Jan
  
  Antworten
  1. Markus
    19. September 2016 um 12:12 Uhr
    
    Hallo Jan,
    
    das Verschlüsselungsmodul ist jetzt als nächstes dran. Bin ja gespannt ob es auf anhieb klappt.
    
    Das Problem mit dem Passwort Reset konnte ich übrigends lösen.
    
    In der config.php musste ich noch die Zeile:
    
    ‚overwriteprotocol‘ => ‚https‘,
    
    einfügen.
    
    Damit kam in der E-Mail der Link auch mit https anstelle von http. Er hat zwar auch davor den Zugriff mit https über den http Link erlaubt aber wohl nicht richtig „angenommen“, aber wie schon oben geschrieben keinen Fehler gebracht.
    
    Grüße,
    Markus
    
    Antworten
    1. Jan
      20. September 2016 um 6:56 Uhr
      
      Hallo Markus,
      
      danke für die Rückmeldung und den Tipp. Vielleicht ja auch für andere ganz hilfreich.
      
      Zum Thema Verschlüsselung: Ich würde dieses Modul nur aktivieren, wenn du externen Speicher (Google, Dropbox, FTP, etc.) nutzt. Wenn du die Daten rein auf einem lokalen Laufwerk speicherst, hast du damit keine Vorteile: Die Verschlüsselung bringt hier keine zusätzliche Sicherheit, da ein Admin immer an diese Dateien rankommen kann. Nebenbei werden die Dateien hier größer und belegen mehr Speicherplatz.
      Nur auf externem Speicher macht dies Sinn, da man so effektiv unterbinden kann, dass diese externen Dienste irgendwie auf die Dateien direkt zugreifen können, da der Schlüssel lokal bei dir in der Cloud gespeichert ist.
      
      Gruß,
      Jan
      
      Antworten

Zielsetzung und Aufwand

Warum die Kombination mit nginx und MariaDB Sinn macht

Voraussetzungen

Betriebssystem/Hardware

Zugriff per SSH

DynDNS

Arbeiten mit Root-Rechten

Updates einspielen

Statische IP-Adresse zuweisen

Programm-Installation

nginx installieren

MariaDB installieren

PHP installieren

Konfiguration des Servers

Konfiguration nginx (Teil 1)

Virtuelle Hosts und Konfigurations-Dateien von nginx

Sinnvolle Aufteilung in mehrere virtuelle Hosts

Allgemeine nginx-Konfiguration anpassen

Default-Seite deaktivieren

Vorbereitung der Verzeichnisstruktur

Anlegen des „Gateway-Hosts“

Anlegen des Hosts für Let’s Encrypt

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

SSL-Zertifikat mit Let’s Encrypt erzeugen

Port-Forwarding einrichten

Erzeugung eines SSL-Zertifikats mittels Let’s Encrypt

Erweiterte Sicherheit: Diffie-Hellman-Parameter

Zugriffsberechtigungen für Zertifikat-Dateien setzen

Erneuerung der Zertifikate nach 90 Tagen

Konfiguration nginx (Teil 2)

Gateway-Host für ownCloud vorbereiten

Virtuellen Host für ownCloud anlegen

Konfiguration PHP

Konfiguration MariaDB

Einrichtung ownCloud

Download

Anlegen der ownCloud-Datenbak

ownCloud-Setup

Warnungen im Admin-Bereich

Anpassung der ownCloud-Konfiguration

Zugriffsrechte anpassen

ownCloud Cronjob einrichten

Weitere Konfiguration der ownCloud

Überprüfung der Sicherheit

Qualys SSL Labs

ownCloud Vulerability Scanner/Nextcloud Security Scan

Zugriff auf die ownCloud über das lokale Netzwerk

Falls es doch einmal hakt…

Download Checkliste

Meine Daten gehören mir!

Weiterführende Artikel

Links

Ähnliche Artikel:

591 Kommentare zu „ownCloud 9 auf Ubuntu Server 16.04 LTS mit nginx, MariaDB, PHP 7 und Let’s Encrypt“

Kommentar verfassen Kommentieren abbrechen