DecaTec

Home-Server | Linux | Nextcloud | Raspberry Pi | Programmierung | Fotografie

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

ownCloud Logo

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

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

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

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

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

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

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

Zielsetzung und Aufwand

Folgende Ziele sollen mit diesem Artikel erreicht werden:

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

Folgende Programmversionen kommen dabei zum Einsatz.

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

Zeitaufwand: ca. 3 Stunden

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

Warum die Kombination mit nginx und MariaDB Sinn macht

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

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

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

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

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

Voraussetzungen

Betriebssystem/Hardware

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

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

Zugriff per SSH

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

DynDNS

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

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

Arbeiten mit Root-Rechten

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

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:

Nginx läuft auf dem Server

Nginx läuft auf dem Server

MariaDB installieren

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

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

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:

Root-Passwort für MariaDB vergeben

Root-Passwort für MariaDB vergeben

PHP installieren

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

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

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

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

Menü zum Aktivieren der erweiterten Ansicht der FritzBox

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

Portfreigabe in der FritzBox einrichten

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

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

Erzeugung eines SSL-Zertifikats mittels Let’s Encrypt

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

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

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.

Absichern der MariaDB-Installation

Absichern der MariaDB-Installation

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.

Download-Link für ownCloud

Download-Link für ownCloud

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

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.

ownCloud Setup

ownCloud Setup

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

Warnungen im Admin-Bereich

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

Warnungen im Admin-Bereich der ownCloud

Warnungen im Admin-Bereich der ownCloud

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

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

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

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

Anpassung der ownCloud-Konfiguration

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

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.

Umstellung von AJAX auf Cron

Umstellung von AJAX auf Cron

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

Weitere Konfiguration der ownCloud

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

Überprüfung der Sicherheit

Qualys SSL Labs

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

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

SSL-Test der ownCloud-Installation

SSL-Test der ownCloud-Installation

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

ownCloud Vulerability Scanner/Nextcloud Security Scan

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

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

Zugriff auf die ownCloud über das lokale Netzwerk

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

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

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

# 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

, , , , , , , , , , ,

Kommentare: 591

  • Andi K sagt:

    Hallo Jan,
    ich habe nextcloud nun doch auf einem Pi 3 unter debian jessie installiert anstatt auf der Synology Box.

    Leider meckert er am Ende immer beim Einrichten im Webbrowser:
    „das datenverzeichnis /share/nextcloud_data“ kann nicht erstellt oder es kann darin nicht geschrieben werden“

    Der Data-Ordner für die nexcloud soll auf einer HDD liegen.
    Diese ist dauerhaft unter /share gemountet.
    fstab sagt:

    # USB-Platte
    UUID=xxxxx-xxxx-xxxx-xxxx-xxxxxxx /share ext4 defaults 0 0

    Die Rechte für den Ordner sind ebenfalls auf www-data deklariert:
    drw——- 2 www-data www-data 4096 Dec 16 22:02 nextcloud_data

    in den beiden php.inis steht:
    open_basedir =/var/www/:/tmp/:/share/nextcloud_data

    den eintrag in my.cnf binlog_format = MIXED musste ich manuell setzen.

    hast du eine idee?

    grüße

    • Jan sagt:

      Hallo Andi,

      sorry, ich war die letzten Tage offline, daher antworte ich erst jetzt.
      Sieht eigentlich alles gut aus. Kommen irgendwelche Fehlermeldungen, wenn du die Rechte für /share setzen willst? Dazu mal mit Verbose-Switch aufrufen: chown -Rv www-data:www-data /var/owncloud_data/

      Gruß,
      Jan

  • Ruschi sagt:

    Ich versuche nextcloud in openmediavault umzusetzen.

    Es scheitert an:

    nginx: [emerg] invalid parameter „http2“ in /etc/nginx/conf.d/meinedomain.net.conf:22
    nginx: configuration file /etc/nginx/nginx.conf test failed

    Problem ist: nginx-Version ist die 1.6.5 also asbach-

    • Jan sagt:

      Hallo Ruschi,

      ganz genau, die nginx Version ist ziemlich alt. HTTP 2 wird erst seit 1.9.5 unterstützt. Das ist aber auch kein Problem, lass das „http2“ in der Config einfach weg.

      Gruß,
      Jan

      • Ruschi sagt:

        Ich konnte auf Version 1.9.x updaten.
        So langsam verstehe ich es..

        mit php habe ich noch so meinen Klemmer..

        Wie sieht eigentlich dann ein virtueller host für weitere „Anwendungen“ aus. z.B. einfach nur die Weboberfläche von verschiedenen Diensten auf dem Server? Webgui , TVserver etc.?

        • Jan sagt:

          Hallo Ruschi,

          was funktioniert denn nicht mit PHP bei dir?
          Habe einen weiteren Blog-Artikel geschrieben wie man eine weitere Web-Anwendung neben ownCloud/Nextcloud installiert: Zweite Web-Anwendung neben ownCloud/Nextcloud einrichten (am Beispiel WordPress)
          Hier habe ich einfach mal WordPress als Beispiel-Applikation hergenommen. Das Vorgehen ist allerdings auch auf andere Anwendungen übertragbar. Trotzdem (wie du am Artikel sehen kannst), erfordern andere Webanwendungen u.U. andere Einstellungen/spezielle Vorgehensweisen. Hier gibt es leider nicht das eine Patent-Rezept.

          Gruß,
          Jan

          • Ruschi sagt:

            Ich habe gestern dein Tutorial bis zum Ende durchgeführt..
            Danach konnte ich nicht mehr auf die webgui von meinem server zugreifen.
            Ist ja auch logisch da ja kein virtueller Host für den Zugriff auf (in diesem Fall port 100 vorliegt).

            Ich schaue mir deine 2. Anleitung gerne an. Top Job den du da machst.

            Mein Setup ist eh etwas anders..

            OMV, Mysql, nextcloud 9,

          • Jan sagt:

            Hallo Ruschi,

            dein Setup dürfte keinen großen Unterschied machen: MariaDB bietet die gleiche Schnittstelle wie MySQL. OMV basiert auf Debian. Auch wenn ich damit keinerlei Erfahrungen habe, wird es hier auch keine Überraschungen geben (solange du ganz normal aufs Terminal zugreifen kannst).
            Ich wünsche schon mal einen guten Rutsch!

            Gruß,
            Jan

  • Victor Seitz sagt:

    Hi Jan!

    Ich habe mit deiner Anleitung jetzt erfolgreich ownCloud 8 von meinem alten System auf meinen neuen Server umgezogen und danach Schrittweise zuerst auf nextcloud 9 geupgradet, und dann weiter auf 10 und jetzt 11. Deine Anleitung funktioniert also auch mit nextcloud 11 :-) (fast, siehe unten :D)

    Ich habe aber zwei kleine Fragen:

    1. ich würde gerne die Möglichkeit in die host-conf mit aufnehmen, statt nur über domain.de auch über http://www.domain.de die owncloud zu erreichen, was muss ich dazu an den host-conf-Dateien machen?

    2. Der calDAV/cardDAV Zugriff von iOS oder macOS funktioniert nicht. Da nginx-error.log zeigt auch warum: er versucht die remote.php über diesen Pfad zu erreichen: /var/www/nextcloud/index.php/domain.de/owncloud/remote.php … das kann natürlich nicht klappen, ich weiss aber nicht weiter wo diese „Verlinkung“ entsteht.

    Weil es vermutlich Teil des Problems ist: damit ich nicht domain.de/owncloud aufrufen muss leite ich über den Host Gateway von domain.de direkt auf /var/www/nextcloud um (im Laufe des Upgrade-Prozess war ich gezwungen das Verzeichnis von owncloud in nextcloud um zu benennen)

  • Matthias Thieroff sagt:

    Hallo Jan,

    vielen Dank für das spitzenmäßige Tutorial! Das beste, was ich bislang gefunden habe und nach dem Lesen bin ich mir sicher, dass ich die Installation ohne Probleme hinbekommen werde :)

    Vielen Dank für die Mühe und Ausführlichkeit, beste Grüße,
    Matthias

  • Dirk sagt:

    Danke für das Tutorial.

    Bis auf eine Kleinigkeit bei der Konfiguration von MariaDB, hat alles geklappt.

    • Jan sagt:

      Hallo Dirk,

      wo hat es bei der Konfiguration von MariaDB gehakt? Kann ich hier vielleicht etwas am Tutorial verbessern?

      Gruß,
      Jan

      • Dirk sagt:

        Wenn ich die ‚/etc/mysql/my.cnf‘ öffne, dann steht da nur ‚!includedir /etc/mysql/conf.d/‘.
        Die Datei die man editieren muss ist dann ‚/etc/mysql/conf.d/mariadb.cnf‘.

        Es könnte sein dass ich ne andere Version von MariaDB habe, als du im Tutorial.

  • Dirk E. sagt:

    Hallo Jan.

    Mittlerweile ist mein Owncloud produktiv.
    Den Upload habe ich auf 4GB begrenzt. Das funktioniert auch.
    Lade ich jedoch Dateien herunter, funktioniert das bei großen Dateien nicht.
    Aktuell soll eine.mov Datei per Link zur Verfügung gestellt werden (ca. 1,8GB)
    Nach ca. 200 Sekunden oder knapp der Hälte der Datei bekommt man einen Abbruch :(.
    Im error.log des nginx steht dann z.B.:
    2017/01/05 11:38:47 [warn] 1711#1711: *1 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/1/00/0000000001 while reading upstream, client: xxx.xxx.xxx.xxx, server: mein-server, request: „GET /owncloud/core/vendor/moment/min/moment-with-locales.js?v=8bec7821aeba9a370b3a6e8883fd18bd HTTP/2.0“, upstream: „http://127.0.0.1:82/owncloud/core/vendor/moment/min/moment-with-locales.js?v=8bec7821aeba9a370b3a6e8883fd18bd“, host: „mein-server“
    2017/01/05 11:38:47 [warn] 1711#1711: *1 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/2/00/0000000002 while reading upstream, client: xxx.xxx.xxx.xxx, server: mein-server, request: „GET /owncloud/core/vendor/jquery/dist/jquery.min.js?v=8bec7821aeba9a370b3a6e8883fd18bd HTTP/2.0“, upstream: „http://127.0.0.1:82/owncloud/core/vendor/jquery/dist/jquery.min.js?v=8bec7821aeba9a370b3a6e8883fd18bd“, host: „mein-server“
    2017/01/05 11:38:47 [warn] 1711#1711: *1 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/3/00/0000000003 while reading upstream, client: xxx.xxx.xxx.xxx, server: mein-server, request: „GET /owncloud/core/vendor/jquery-ui/ui/jquery-ui.custom.js?v=8bec7821aeba9a370b3a6e8883fd18bd HTTP/2.0“, upstream: „http://127.0.0.1:82/owncloud/core/vendor/jquery-ui/ui/jquery-ui.custom.js?v=8bec7821aeba9a370b3a6e8883fd18bd“, host: „mein-server“
    2017/01/05 11:38:47 [warn] 1711#1711: *1 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/4/00/0000000004 while reading upstream, client: xxx.xxx.xxx.xxx, server: mein-server, request: „GET /owncloud/core/vendor/underscore/underscore.js?v=8bec7821aeba9a370b3a6e8883fd18bd HTTP/2.0“, upstream: „http://127.0.0.1:82/owncloud/core/vendor/underscore/underscore.js?v=8bec7821aeba9a370b3a6e8883fd18bd“, host: „mein-server“
    2017/01/05 11:38:47 [warn] 1711#1711: *1 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/5/00/0000000005 while reading upstream, client: xxx.xxx.xxx.xxx, server: mein-server, request: „GET /owncloud/core/vendor/handlebars/handlebars.js?v=8bec7821aeba9a370b3a6e8883fd18bd HTTP/2.0“, upstream: „http://127.0.0.1:82/owncloud/core/vendor/handlebars/handlebars.js?v=8bec7821aeba9a370b3a6e8883fd18bd“, host: „mein-server“
    2017/01/05 11:38:47 [warn] 1711#1711: *1 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/6/00/0000000006 while reading upstream, client: xxx.xxx.xxx.xxx, server: mein-server, request: „GET /owncloud/core/vendor/backbone/backbone.js?v=8bec7821aeba9a370b3a6e8883fd18bd HTTP/2.0“, upstream: „http://127.0.0.1:82/owncloud/core/vendor/backbone/backbone.js?v=8bec7821aeba9a370b3a6e8883fd18bd“, host: „mein-server“
    2017/01/05 11:38:47 [warn] 1711#1711: *1 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/7/00/0000000007 while reading upstream, client: xxx.xxx.xxx.xxx, server: mein-server, request: „GET /owncloud/core/js/js.js?v=8bec7821aeba9a370b3a6e8883fd18bd HTTP/2.0“, upstream: „http://127.0.0.1:82/owncloud/core/js/js.js?v=8bec7821aeba9a370b3a6e8883fd18bd“, host: „mein-server“
    2017/01/05 11:38:47 [warn] 1711#1711: *1 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/8/00/0000000008 while reading upstream, client: xxx.xxx.xxx.xxx, server: mein-server, request: „GET /owncloud/apps/gallery/js/vendor/bigshot/bigshot-compressed.js?v=8bec7821aeba9a370b3a6e8883fd18bd HTTP/2.0“, upstream: „http://127.0.0.1:82/owncloud/apps/gallery/js/vendor/bigshot/bigshot-compressed.js?v=8bec7821aeba9a370b3a6e8883fd18bd“, host: „mein-server“
    2017/01/05 11:38:47 [warn] 1711#1711: *1 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/9/00/0000000009 while reading upstream, client: xxx.xxx.xxx.xxx, server: mein-server, request: „GET /owncloud/apps/files/js/jquery.fileupload.js?v=8bec7821aeba9a370b3a6e8883fd18bd HTTP/2.0“, upstream: „http://127.0.0.1:82/owncloud/apps/files/js/jquery.fileupload.js?v=8bec7821aeba9a370b3a6e8883fd18bd“, host: „mein-server“
    2017/01/05 11:38:47 [warn] 1711#1711: *1 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/0/01/0000000010 while reading upstream, client: xxx.xxx.xxx.xxx, server: mein-server, request: „GET /owncloud/apps/files/js/filelist.js?v=8bec7821aeba9a370b3a6e8883fd18bd HTTP/2.0“, upstream: „http://127.0.0.1:82/owncloud/apps/files/js/filelist.js?v=8bec7821aeba9a370b3a6e8883fd18bd“, host: „mein-server“
    2017/01/05 11:38:53 [warn] 1711#1711: *1 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/1/01/0000000011 while reading upstream, client: xxx.xxx.xxx.xxx, server: mein-server, request: „GET /owncloud/s/fZoVbPlyKsp3YTr/download HTTP/2.0“, upstream: „http://127.0.0.1:82/owncloud/s/fZoVbPlyKsp3YTr/download“, host: „mein-server“
    2017/01/05 11:38:56 [warn] 1713#1713: *225 an upstream response is buffered to a temporary file /var/cache/nginx/fastcgi_temp/2/01/0000000012 while reading upstream, client: 127.0.0.1, server: 127.0.0.1, request: „GET /owncloud/s/fZoVbPlyKsp3YTr/download HTTP/1.0“, upstream: „fastcgi://unix:/run/php/php7.0-fpm.sock:“, host: „mein-server“

    Bei Google habe ich bislang keine Lösung gefunden, die funktioniert.
    Hier noch mal ein paar Dateien:

    Die .user.ini :
    upload_max_filesize=4G
    post_max_size=4G
    memory_limit=1024M
    mbstring.func_overload=0
    always_populate_raw_post_data=-1
    default_charset=’UTF-8′
    output_buffering=0

    ========

    .htaccess :

    SetEnvIfNoCase ^Authorization$ „(.+)“ XAUTHORIZATION=$1
    RequestHeader set XAuthorization %{XAUTHORIZATION}e env=XAUTHORIZATION

    SetEnvIfNoCase Authorization „(.+)“ HTTP_AUTHORIZATION=$1

    # Add security and privacy related headers
    Header set X-Content-Type-Options „nosniff“
    Header set X-XSS-Protection „1; mode=block“
    Header set X-Robots-Tag „none“
    Header set X-Frame-Options „SAMEORIGIN“
    Header set X-Download-Options „noopen“
    Header set X-Permitted-Cross-Domain-Policies „none“
    SetEnv modHeadersAvailable true

    # Add cache control for CSS and JS files

    Header set Cache-Control „max-age=7200, public“

    php_value upload_max_filesize 4G
    php_value post_max_size 4G
    php_value memory_limit 1024M
    php_value mbstring.func_overload 0
    php_value always_populate_raw_post_data -1
    php_value default_charset ‚UTF-8‘
    php_value output_buffering 0

    SetEnv htaccessWorking true

    php_value upload_max_filesize 4G
    php_value post_max_size 4G
    php_value memory_limit 1024M
    php_value mbstring.func_overload 0
    php_value default_charset ‚UTF-8‘
    php_value output_buffering 0

    SetEnv htaccessWorking true

    RewriteEngine on
    RewriteRule .* – [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
    RewriteRule ^\.well-known/host-meta /public.php?service=host-meta [QSA,L]
    RewriteRule ^\.well-known/host-meta\.json /public.php?service=host-meta-json [QSA,L]
    RewriteRule ^\.well-known/carddav /remote.php/dav/ [R=301,L]
    RewriteRule ^\.well-known/caldav /remote.php/dav/ [R=301,L]
    RewriteRule ^remote/(.*) remote.php [QSA,L]
    RewriteRule ^(?:build|tests|config|lib|3rdparty|templates)/.* – [R=404,L]
    RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/.*
    RewriteRule ^(?:\.|autotest|occ|issue|indie|db_|console).* – [R=404,L]

    AddType image/svg+xml svg svgz
    AddEncoding gzip svgz

    DirectoryIndex index.php index.html

    AddDefaultCharset utf-8
    Options -Indexes

    ModPagespeed Off

    #### DO NOT CHANGE ANYTHING ABOVE THIS LINE ####

    ErrorDocument 403 /owncloud/core/templates/403.php
    ErrorDocument 404 /owncloud/core/templates/404.php

    =======

    server {
    listen 80 default_server;
    server_name mein-server 10.x.x.x;

    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 mein-server 10.x.x.x;

    #
    # Configure SSL
    #
    ssl on;

    # Certificates used
    ssl_certificate /etc/nginx/ssl/bundle.crt;
    ssl_certificate_key /etc/nginx/ssl/server.key;
    # ssl_certificate_key /etc/letsencrypt/live/owncloud9tutorial.goip.de/privkey.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 = 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 off;
    ssl_stapling_verify off;
    # ssl_trusted_certificate /etc/nginx/ssl/bundle.pem;
    # ssl_stapling on;
    # ssl_stapling_verify on;
    # ssl_trusted_certificate /etc/nginx/ssl/bundle.pem;
    # 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 4G;
    # 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 6000;
    proxy_send_timeout 6000;
    proxy_read_timeout 6000;
    send_timeout 6000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_pass http://127.0.0.1:82;
    proxy_redirect off;
    }
    }

    =======

    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 4G;
    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 6000;
    fastcgi_send_timeout 6000;
    fastcgi_connect_timeout 6000;

    # 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 = 4G
    post_max_size = 4G
    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;
    }
    }
    }

    =====

    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/ssl;
    }
    }

    =====
    aus der fpm/php.ini:

    output_buffering = Off
    open_basedir = /var/www/:/tmp/:/var/owncloud_data:/dev/urandom:
    cgi.fix_pathinfo= 0
    file_uploads = On
    ;upload_tmp_dir =
    upload_max_filesize = 4G
    post_max_size = 4G

    Die php.ini unter cli sieht genauso aus.

    Hast Du eine Idee, wo der Fehler liegen könnte?
    Die Seiten, die ich gedfunden habe, zielen alle auf die Parameter upload_max_filesize und post_max_size. Gibt noch weitere Dateien, in denen man Einstellungen kontrollieren kann?

    Vielen dank im voraus für Deine Antwort.

    LG

    Dirk E.

    max_file_uploads = 20

    • Jan sagt:

      Hallo Dirk,

      also die .htaccess wird bei der Konfiguration bei nginx gar nicht verwendet (ist nur wichtig für Apache), hier muss also nichts angepasst werden.
      Die nginx error.log gibt hier leider auch keinen Hinweis.

      Ich würde nun zunächst einmal die timeout-Werte erhöhen (im Gateway-Host, im ownCloud-Host und evtl. auch die max_execution_time von PHP). Vielleicht ist das ja schon die Lösung.

      Gruß,
      Jan

      • Dirk E. sagt:

        Hallo Jan.
        Herzlichen Dank für Deine Antwort.

        Diese Werte sind bereits erhöht gewesen:
        fastcgi_read_timeout 6000;
        fastcgi_send_timeout 6000;
        fastcgi_connect_timeout 6000;

        max_execution_time = 3600

        proxy_connect_timeout 6000;
        proxy_send_timeout 6000;
        proxy_read_timeout 6000;
        send_timeout 6000;

        Heute hab ich mal mit unterschiedlich großen Dateien getestet. Dateien mit 3GB lassen sich ohne Probleme hochladen. Beim herunterladen ist bei 1GB Schluss.

        In der nginx.conf habe ich keepalive_timeout von 600 auf 6000 gesetzt. Das werde ich nächste Woche testen.

        Schönes Wochenende :)

        Dirk

      • Dirk E. sagt:

        Hallo Jan.
        Das erhöhen von keepalive_timeout hat nichts gebracht.
        Auch wenn es nichts direkt damit zu tun hat habe den Memory_limit auf 2048 hochgesetzt.
        Auf meinem Rechner habe den Owncloud-Client installiert. Das hakt zwar auch, hat aber meine Testdatei heruntergeladen. Bei einem 1,8GB Video gab es auch einen Abbruch.
        Momentan habe ich keine Idee mehr, wo ich noch suchen kann :(.

        LG

        Dirk E.

        • Jan sagt:

          Hi Dirk,

          sorry, aber da bin ich momentan ebenso ratlos wie du.
          Kannst du vielleicht eine zeitliche Komponente erkennen? Beispielsweise: 1,8 GB werden immer in der gleichen Zeit herunter geladen und der Download bricht nach einer gewissen Zeitspanne ab (und nicht nach einem gewissen Download-Volumen). Man könnte z.B. mal versuchen, die Bandbreite im OC-Client künstlich zu verringern (diese Option gibt es ja). Ist dann auch noch bei 1,8 GB die „magische Grenze“ erreicht?

          Gruß,
          Jan

          • Dirk E. sagt:

            Hallo Jan.

            Die Bandbreite habe ich im Owncloud-Client auf 1024 kBit/s reduziert.
            Auch hier wird die Übertragung erst einmal abgebrochen (nach 1.054.372 Bytes)
            Im Gegensatz zu Browser, wird der Download hier aber fortgesetzt (Gutes Features!).
            Der Download wurde erfolgreich beendet. Das hängt meiner Meinung nach an der Größe der Datei und ist nicht von Timeouts abhängig.
            Hätte eine Umstellung von Nginx auf Apache2 Aussicht auf Erfolg?
            Was meinst Du dazu?

            LG

            Dirk E.

          • Jan sagt:

            Hi Dirk,

            nein, der Umstieg auf Apache würde hier vermutlich auch nichts bringen. Das muss (in der Theorie zumindest) auch mit nginx funktionieren.

            Gruß,
            Jan

  • Tobias sagt:

    Hallo Jan,

    ich würde gerne anhand der Anleitung nicht Owncloud, sondern direkt Nextcloud installieren. Ist das möglich, sofern man die Befehle und Einträge in den conf und php-Dateien entsprechend auf „nextcloud“ ändert. Oder bestehen da sonst irgendwelche signifikante Unterschiede?

    Vielen Dank schon im Voruas,
    Tobi

    • Jan sagt:

      Hallo Tobi,

      nein, die Nextcloud-Installation läuft hier analog zu ownCloud ab. Laut den Kommentaren hier im Blog haben das auch schon viele Leute ohne Probleme hinbekommen.

      Gruß,
      Jan

      • Tobias sagt:

        Hallo Jan,

        die Installation hat soweit wunderbar geklappt. Mit ein paar Problemen bei der Benutzung bin ich nun jedoch konfrontiert. Und zwar kann ich weder im Webinterface noch über WebDav Ordner, geschweige denn ganze Ordnerstrukturen hochladen, sondern lediglich einzelne Dateien. Das macht es natürlich nicht sehr praktisch. Außerdem kann ich mit manchen Apps (z.B. Documents auf iOS) nicht per Webdav zugreifen – das ist jedoch zunächst weniger wichtig.
        Ansonsten bekomme ich immer einen Fehler angezeigt, wenn ich einen in Nextcloud erstellten Kalender in einem anderen Programm importieren möchte (getestet mit iCal, Outlook 2010, Google).
        Hast du eine Idee woran das liegen könnte?

        Viele Grüße,
        Tobi

        • Jan sagt:

          Hallo Tobias,

          also ganze Ordner sollten auch per WebDAV hochgeladen werden können. In der Web-Oberfläche geht das allerdings nur über Drag & Drop (wenn man den Button nutzt, kann man tatsächlich nur einzelne Dateien hochladen).

          Was meinst du mit „einen in Nextcloud erstellten Kalender in einem anderen Programm importieren“? Lädst du einen Kalender vorher als ics-Datei herunter und importierst diese Datei dann in andere Programme?
          Wenn du Kalender synchronisieren möchtest, dann musst du über die CalDAV-Adresse gehen. Wie dies z.B. unter Outlook funktioniert (mit dem Add-In CalDAVSynchronizer), ist im Artikel ownCloud unter Windows 10 optimal nutzen beschrieben.

          Gruß,
          Jan

          • Tobias sagt:

            Hallo Jan,

            nach ausgiebigen Tests auf verschiedenen Systemen (Mac, WIndows) sieht’s nun folgendermaßen aus: Ich kann über das Webinterface alles hochladen. Wenn ich jedoch per WebDav den Zugriff einrichte scheint die Verbindung hergestellt zu sein, aber wenn ich Ordner oder Dateien hochladen möchte, bekomme ich immer einen Fehler angezeigt:
            – Windows: zuerst kommt die Meldung, dass die Dateien bereits vorhanden wären –> im Ziel ersetzen angeklickt: Die Quelldatei oder vom Quelldatenträger kann nicht gelesen werden.
            – Mac: Der Finder konnte den Vorgang nicht abschließen, da einige Dateien in „Dateiname…..“ nicht gelesen oder geschrieben werden können. (Fehler -36)

            Dabei werden Ordner und Dateien zwar angelegt, aber immer nur mit 0 Byte.

            Ich weiß nicht welchen Port WebDav verwenden, aber anhand der Anleitung werden ja nur die Ports 80 und 443 an Nextcloud weiter geleitet. Kann es damit zu tun haben?
            Ich hatte dasselbe Problem beim syncen der Kalender mit dem Mac. Dort musste ich beim anlegen des CalDav Kontos den Port 443 erzwingen, damit die Verbindung geklappt hat.

            Ich bin etwas ratlos, hast du eine Idee?

            Viele Grüße,
            Tobias

          • Jan sagt:

            Hi Tobias,

            wie verbindest du dich auf Windows/Mac per WebDAV auf den Server? Bei Windows würde ich hier zunächst versuchen, den Port explizit mitzugeben (z.B. https://meinserver.de:443/owncloud). Sollte eigentlich nicht notwendig sein, das HTTPS automatisch über Port 443 geht, aber man weiß ja nie…

            Gruß,
            Jan

          • Tobias sagt:

            Hi Jan,

            ich verbinde mich am Mac mit Cmd+K (Server verbinden) und gebe dort die WebDav Adresse ein.
            Unter Windows gehe ich über Netzlaufwerk verbinden mit der WebDav-Adresse.
            Habe beides nochmal mit dem Port explizit auf :443 getestet – hat nichts gebracht.
            Hast du sonst noch eine Idee?
            Dann bin ich schon wieder auf ne Kleinigkeit gestoßen als ich über das Webinterface als admin ein Update machen wollte. Das hat er mir direkt abgebrochen mit der Meldung ich hätte nicht die Rechte. Muss man das Update hier „händisch“ machen?

            Viele Grüße,
            Tobias

          • Jan sagt:

            Hallo Tobias,

            die Verbindung sollte auf diese Weise eigentlich klappen. Siehst du nach dem Verbinden mit dem Explorer/Finder und der erscheinenden Fehlermeldungen etwas in der Log-Datei von nginx und oder Nextcloud? Hier müsste zumindest ein Hinweis zu finden sein.

            Wie man ownCloud/Nextcloud Updates richtig durchführt, wenn man nach diesem Tutorial installiert hat, habe ich bereits in einem anderen Blog-Beitrag erklärt. Wenn die entsprechenden Rechte beim Update fehlen, dann wurde vermutlich ein chown –R www-data:www-data /var/www/owncloud vor dem Anstoßen des Updates vergessen.
            Trotzdem würde ich immer den „komplett manuellen“ Weg empfehlen (über den OCC-Befehl, nicht über die Admin-UI). Meiner Erfahrung nach handelt man sich hier die wenigsten Probleme ein.

            Gruß,
            Jan

    • Marcus sagt:

      Hallo Tobis,
      habe nach Jan´s Anleitung einen Nextcloud 11 vor eineinhalb Wochen installiert, hat super geklappt.

  • Marcus sagt:

    Hallo Jan,
    ich würde gerne über das Gatway meinen Plex-Server SSL verschlüsselt ansprechen, dieser wäre aber auf einem anderen Rechner / IP, ist dies möglich? Kenne mich mit nginx noch nicht so aus. Wie könnte so eine Konfig aussehen? Hab schon ein paar sachen gelesen, aber alle gehen von einem Apache aus.
    Gruß
    Marcus

    • Jan sagt:

      Hallo Marcus,

      ja, das sollte klappen: Du nutzt einfach deine Cloud-Maschine mit dem darauf befindlichen Zertifikat.
      Schon wie bei der Weiterleitung Gateway-Host -> Cloud nutzt du nun eine andere Weiterleitung, um auf deinen Plex-Server zu kommen. Ob das proxy_pass nun an einen anderen vHost weiterleitet, oder an eine andere Maschine/Webserver, spielt dabei keine Rolle. Der Plex-Server sollte sich dann verhalten wie eine weitere Webanwendung.

      Gruß,
      Jan

  • Friedrich sagt:

    Hallöchen.
    ich komme leider nicht weiter.
    Mein Client ist nur über einen Port ansprechbar. ( Virtuelle Umgebung, auf der läuft Linux, und darauf die Owncloud). Damit schlüssle ich z.B. den port

    meinedomain.dyndns.org:1200 auf.
    Da soll die Owncloud erreichbar sein.

    Wenn ich jedoch über „letsencrypt“ gehe, erhalte ich die Meldung das mein Host / Client von Encrypt, nicht erreichbar wäre.

    das passiert bei folgendem Befehl:
    letsencrypt certonly –webroot -w /var/www/letsencrypt -d meinedomain.dyndns.org –rsa-key-size 4096

    Hier erhalte ich: „Host nicht erreichbar“ (bzw. „client antwortet nicht“ )
    somit wird auch kein Key erstellt, bzw. : gar nichts erstellt.

    meine Mailadresse haben die Knaben, das ist aber auch alles.

    Ein paar Fragen zum Toturial:
    Du verweist für eigene Keys auf das alte Toturial, es geht für mich nicht klar hervor, wo nun „letsencrypt“ anfängt, und wo es aufhört.
    ich hätte lieber einen eigenen Key, Letsencrypt ist nicht zuletzt eine Vertrauensfrage sondern auch zu aufwändig den aller Nase lang erneuern / ändern zu müssen.

    Dann sehe ich gar nicht klar, wann ich nun was in welcher Datei eintragen muß, wenn es um einen eigenen Key geht :(
    Bei den Letsencrypt kann man zwar „folgen“, aber sobald es mit dem fernconnect oder sonstigem, ein Problem gibt – steht man dann da :(

    Außerdem:
    Es wäre schön wenn man das „Menu“ von Letsencrypt im Terminal erklärt bekäme, das man Hotkeys verwenden soll, geht nicht sofort hervor
    habe mich mit der Maus zu tode geklickt, Return hat auch nichts gebracht, bis ich kapiert habe – das ich da ALT+O und dann Alt+A drücken soll
    hätte ich nicht noch alte Dos Zeiten in Erinnerung – wäre ich da nicht mehr weitergekommen.

    PS: freue mich über Antwort.
    Wie gebe ich denn die Domain nun richtig an, damit er auch meinen Server hinter meinem Port erreicht, denn über meinedomain.dyndns.org

    sind mehrere Rechner erreichbar, nicht nur die Cloud. Daher MUSS sie hinter einem Port liegen.

    • Jan sagt:

      Hallo Friedrich,

      soweit ich weiß, funktioniert Let’s Encrypt nur mit den Ports 80/443. Wenn der Webserver auf einem anderen Port läuft, muss dieser auf jeden Fall temporär (während der Zertrifikat-Erzeugung) auf Port 80 laufen. Wenn das Zertifikat dann erst einmal generiert ist, kann der Server dann auch auf einem anderen Port laufen. Ist echt keine praktische Lösung (besonders, weil die Zertifikate ja von Zeit zu Zeit erneuert werden müssen).
      Aber (mitunter) aus diesem Grund verfolge ich hier das Prinzip des Gateway-Hosts (einziger Host/Maschine, der auf Port 80/443 lauscht). Dieser leitet gewisse Anfragen an andere vHost. Die Weiterleitung muss dabei nicht zwingend an andere vHosts auf der gleichen Maschine gehen (wie im Tutorial gezeigt), dies können auch andere Maschinen im Netzwerk sein, auf den eben auch ein Webserver läuft. Auf diese Weise solltest du das „Port-Problem“ auch in den Griff bekommen.

      Mit „eigene Keys“ meinst du sicher ein selbst signiertes Zertifikat. Die Anleitung ist im alten Tutorial zu finden: Abschnitt Konfiguration des Servers > SSL-Zertifikat. Einfach den Teil SSL-Zertifikat generieren (Let’s Encrypt) überspringen und dann erst bei Selbst signiertes Zertifikat erstellen weiter machen.

      Ich frage mich nur, welches Menü du bei Let’s Encrypt meinst. Der Aufruf erfolgt ja über die Kommandozeile und anschließend wird prinzipiell nur noch die Mail-Adresse abgefragt. Oder hast du im Terminal einfach letsencrypt aufgerufen?

      Gruß,
      Jan

      • Friedrich sagt:

        Hallo Jan.
        Vielen Dank für Deine Antwort.

        Ich habe nun eigene SSL benutzt, aber ich bin mir in einem unklar, in der Setting, vom Key. Ich habe da die certificat.cfi (hieß die glaube) angegeben, das geht aus deinem altem Toturial nicht klar hervor.

        da gibt es diese Stelle, wo du dich auf encrpt beziehst.
        dort schreibst du unten drunter. „für eigene Verschlüsslung bitte das hier eingeben“ okay

        aber später einmal, trägst Du den Key noch mal ein ( ich müßte erst auf die VM und den alten link kopieren, finde den gerade hier au fdem System nicht ) und da hast du keine Alternative drin, sondern nur die Encrypt Variante.

        die Encrypt finde ich wie gesagt nicht so prall, wegen der Erneuerung. Ein schlüssel ist ein Schlüssel, der macht ja nichts anderes als zu verschlüsseln *hm* (zumindest meinem verständnis nach) das ist so sinnfrei wie die Erinnerung „ändere dein Passwort alle 3 Monate“ wenn s keiner weiß, vergisst du es höchstens selber dadurch…

        Mein problem ist nun:
        ich kann die Claud vom internem netz her aufrufen. das Ding hängt an „DSL“

        aber mein problem ist:
        ich kann von außen zwar manchmal aufrufen (nicht immer) aber ich kriege nur den Login Screen.
        Gebe ich meine Nutzerdaten / passwort ein, bekomme ich „Netzwerkfehler Zeitüberschreitung“ :(

        das ist echt ärgerlich, ich habe so viele Stunden in dem Versuhc ne Owncloud sicher zum laufen zu bekommen, da könnte ich wahnsinnig werden :(

        Alternativ habe ich noch auf die von Tech and Me gesetzt, aber die wirft mir aus das meine „herkunftsdomain“ nicht zu den Trusted Domains gehört, und kein Mensch weiß wo die config.php dafür ist, und was da rein muss – weil s eben wieder – nur ein ablaufendes Script war, nicht wie hier ein Toturial wo man einigermaßen Durchblick bekommt was man tut.

        PS: das Toturial ist HAMMERGUT!!!!!!
        aber es sind eben noch einige Probleme übrig :(

  • Friedrich sagt:

    PS:
    im Zweifelsfall kann ich Dir anonymisiert ja den PHP Code hier mal posten.

    das ganze wird über Port aufgerufen

    z.B. https://meinedomain.dyndns.org/owncloud:700

    zum Loginscreen komme ich, anschließend erhalte ich „timeout, Netzwerk Zeitüberschreitung“

    dabei sollte ich sagen:
    das ist DSL der langsamsten Sorte, leider.
    gehe ich über das „interne“ Netz aber die Außendomain
    (d.h. selbe domain, aber von einem internem Rechner, dem dann wohl der interne virtuelle schneller antwortet)

    … funzt es prima, HTTPS ist dann auch verfügbar.

    • Jan sagt:

      Hallo Friedrich,

      wenn du ein selbst signiertes Zertifikat verwendest, lautet der Befehl zu Erzeugen wie folgt:
      openssl req -new -x509 -days 365 -nodes -out /etc/nginx/ssl/certificate.crt -keyout /etc/nginx/ssl/certificate.key
      Daraus werden zwei Dateien generiert:

      • /etc/nginx/ssl/certificate.crt: Die (öffentliche) Zertifikat-Datei
      • /etc/nginx/ssl/certificate.key: Der private Teil des Zertifikats

      Diese Dateien werden dann folgendermaßen in nginx eingebunden:
      ssl_certificate /etc/nginx/ssl/certificate.crt;
      ssl_certificate_key /etc/nginx/ssl/certificate.key;

      Let’s Encrpyt Zertifikate müssen erneuert werden, das erscheint zunächst lästig. Diese Aufgabe kann man allerdings auch per Cron automatisieren, dann muss man dies nie mehr manuell machen. Tipps, wie dies realisiert werden kann, findest du hier.

      Gruß,
      Jan

      • Friedrich sagt:

        Ja, das hatte ich ja so eingebunden, d.h. das steht da auch so drin (siehe mein Posting )
        ich hatte ja den Code noch mal angehangen hier, in anonymisierter Form.

        Bin so langsam ein bisschen (arg) überfragt :(

        am SSL kann es nicht liegen, das nimmt er ja an, aber wenn ich z.B. über Außendomain komme, dann leitet er mich sofort zur internen weiter.

        Beispiel:
        meinedomain.dyndns.de

        wird dann zu
        192.111.111.111 (beispiel halt)

        das komische ist:
        ich komme vom Browser aus (manchmal, nicht immer) bis zum Loginscreen, da scheint alles normal.

        logge ich mich jedoch ein (Nutzername / Passwort)
        kommt: „Netzwerk Zeitüberschreitung, die Seite antwortet nicht“

        und Ende.
        Weiter als bis zum Login, bin ich noch nie gekommen :(
        im Internem System wiederum, ändert er das

        da komme ich zum Login ( über Dyndns) und danach steht dann oben im Browser die lokale IP, und alles läuft.

        HTTPS steht da auch da.

        • Friedrich sagt:

          Der Status sagt dann:

          „verbinden mit meinedomain.dyndns.info“

          und nichts geht mehr.

          Kann das irgendwie daran liegen, das ich über einen Port freischalte ?
          d.h. das meine domain eben ist

          meinedomain.dyndns.info/owncloud/:3333 ?
          und der Server über normal Dyndns zurückantwortet, und der Port außer Acht fällt oder so was ?

          weil die Port s selbst, d.h. 443 und 80
          sind auf die IP des LInux Servers durchgeschleift / getiggert

          hm

          • Jan sagt:

            Hi Friedrich,

            ja, alle Ports, über die etwas aus dem Internet erreichbar sein soll, müssen auch im Router freigeschaltet und an die IP der Cloud-Maschine weitergeleitet werden.
            Daher auch das Konstrukt mit dem Gateway-Host, hier müssen immer nur die Ports 80 und 443 geöffnet werden.

            Gruß,
            Jan

  • Friedrich sagt:

    ja, aber sonst hast Du auch keine Idee woran es liegen kann ?
    Also das der Server sich nicht weiter meldet als bis zum login ?

  • Friedrich sagt:

    Naja dann ist ja von den Ports usw., alles richtig.

    mir bleibt nur noch eine Idee: den Rechner direkt routen, ohne einen Sonderport.

    das kann ich nächste Woche tun.

    wenn das auch nicht geht, funktioniert es nicht :(

    • Jan sagt:

      Hallo Friedrich,

      ja, jeder Traffic Internet -> internes Netzwerk muss über Port 80/443 laufen, dann sollte das Ganze auch funktionieren.
      Ich habe dir übrigens eine E-Mail mit weiteren Infos geschickt…

      Gruß,
      Jan

      • Friedrich sagt:

        Hallo Jan

        du hat Antwort.
        und VIELEN DANK für Deine Mühe.
        ich hoffe wir finden den Fehler gemeinsam, ich bin ehrlich am
        verzweifeln :(

  • Adrian K. sagt:

    Hallo,

    erst ein mal vielen Dank für das fantastische Tutorial.

    Hier noch eine Frage, zu der ich bis lang noch keine Antwort finden konnte:

    Die URL’s egal ob owncloud, wordpress, etc. funktionieren nur mit einem endenden Slash /
    Wird dieser nicht mit eingegeben, erhält man eine Fehlerseite und wird auf folgende URL weiter geleitet:
    https://website.tld:84/wordpress/

    Kennt jemand das Problem und hat einen Tipp für mich?

    PS: Ich habe Roundcube ebenfalls erfolgreich integriert und werde hier
    meine Konfiguration noch zur Verfügung stellen.

    • Jan sagt:

      Hallo Adrian,

      vielen Dank für das Lob.
      Das mit dem Slash sollte eigentlich nicht so sein. Hier ist vermutlich irgendwo in den nginx-vHosts ein ‚/‘ Zuviel angegeben. Im Fehlerfall sollte die die nginx error.log einen Hinweis darauf geben, auf welchen Pfad die Anfrage ursprünglich gehen sollte.

      Gruß,
      Jan

  • Joey sagt:

    Diese Anleitung ist sehr gut. Ich habe sie schon mehrfach verwendet.
    Vielen Dank für deine Mühe und die sehr gute Dokumentation.

    Allerdings wollte ich jetzt auch das teilen (Federation Server) testen und scheitere.

    Meine Konstellation:

    2 Server (mit selbst signiertem Zertifikat) im lokalen Netz hinter einem Proxy.

    Die Verbindung ins Internet klappt. Die Zertifikate sind untereinander bekannt, in Nextcloud (vorher auch schon bei Owncloud) als vertrauenswürdige Server hinterlegt, wget und curl funktionieren.
    Allerdings bleiben diese Server immer gelb.
    Ich kann Dateien für einen Nutzer auf dem anderen Server freigeben, E-Mail wird verschickt. Will ich dann den Link akzeptieren, kommt die Meldung: „Failed to perform action.Verbindung zum Server verloren.“

    Funktioniert diese Konfiguration nicht wegen des reverse Proxy?

    • Jan sagt:

      Hi Joey,

      der Reverse-Proxy sollte eigentlich nicht das Problem darstellen, da sich dieser ja transparent gegenüber Cloud und Client verhält.
      Kannst du mal einen Blick ins Nextcloud-Log und auch in das error.log von nginx werfen (auf beiden Servern)? Kommen hier beim Federation-Sharing irgendwelche Fehler oder Warnungen?

      Gruß,
      Jan

      • Joey sagt:

        Hi Jan,

        danke, natürlich richtig die Log-Dateien zu durchforsten:
        error.log von nginx ist leer, aber in der nextcloud.log sind alle 15 Minuten (cron.php?) je 3 Meldungen zur App „federation“ (hier stark gekürzt):

        1. cURL error 28: Operation timed out after 3000 milliseconds with 0 bytes received
        2. und 3.: cURL error 56: Proxy CONNECT aborted due to timeout

        sudo -u www-data curl -v https://ip_anderer_server/nextcloud funktioniert aber.

        Das Timeout-Verhalten hatte ich auch schon beim Eintragen der vertrauenswürdigen Server: erst timeout, aber bei der Wiederholung klappt es dann.
        Brauchst du die Log-Zeilen komplett?

        Vielen Dank für deine Mühe

        • Jan sagt:

          Hi Joey,

          wenn der Fehler alle 15 Minuten in den Logs aufschlägt, dann hängt dies sicher mit Cron zusammen. Mich wundert nur, dass die Verbindung nach 3000ms einen Timeout produziert – das sind nur 3 Sekunden und erscheint mir etwas kurz.
          Schau doch mal in der php.ini (CLI), ob hier irgendwelche (zu kurzen) Timeout-Values gesetzt werden (z.B. max_execution_time). Evtl. findet sich auch ein Hinweis in den PHP-Logs.
          Um sicher zu gehen, dass dies etwas mit Cron zu tun hat, könntest du testweise mal von „Cron“ auf „AJAX“ umstellen. Hier wird eine andere PHP-Config herangezogen (phi.ini für FPM, bzw. fastcgi_param PHP_VALUE… im nginx vHost).

          Vielleicht können wir das Problem dadurch etwas eingrenzen.

          Gruß,
          Jan

          • Joey sagt:

            Hi Jan,

            wenn ich cron abschalte, werden die Einträge in nextcloud.log nicht mehr geschrieben.
            In Administration habe ich auf AJAX umgeschaltet, aber dadurch kommen keine neuen Einträge in die nextcloud.log.
            in den beiden php.ini (FPM und CLI) ist die max_execution_time = 30. (Ubuntu 16.04 LTS frisch installiert).
            php7.0-fpm.log enthält nur die Start-Info (2 Tage alt)
            fastcgi_param habe ich 1:1 aus deinem Tutorial übernommen.

            Damit die Fehlermeldung „Kein Internetzugriff“ in der Administration verschwindet, habe ich in der config.php von Nextcloud proxy => ‚192.168.10.1:8080‘, gesetzt.
            Diese habe ich jetzt auskommentiert. Das brachte auch keinen Erfolg.
            allerdings habe ich die Log-Dateien jetzt in einer besser lesbaren Form gefunden (das raw-Format in der nextcloud.log ist unübersichtlich).

            Damit wird mir wieder einiges klarer:
            Diese Meldung sit auf Server1:

            GuzzleHttp\Exception\ClientException: Client error response [url] https://192.168.1.20/nextcloud/ocs/v2.php/apps/federation/api/v1/request-shared-secret?format=json [status code] 400 [reason phrase] Bad request

            Dast ist die Anfrage von Server2, die abgewiesen wird. Das wiederholt sich, wobei die url mal mit Namen, mal mit Adresse geschrieben wird.

            Proxy ist jetzt abgeschaltet, weil ich nicht gefunden habe, ob man in config.php Proxy-Ausnahmen (als ENV no_proxy) setzen kann.

            Warum wird die Anfrage abgewiesen?

            Danke Jost

          • Jan sagt:

            Hi Joey,

            also wenn die Umstellung auf AJAX auch nichts bringt, dann kannst du das vermutlich auf Cron zurück stellen. max_execution_time für PHP (CLI) sollte laut PHP-Doku auf 0 stehen. Könntest du ja auch mal versuchen.

            Die Fehlermeldung scheint allerdings der eigentliche Grund zu sein, warum die Sache noch nicht klappt. Hier wird die Web-API der Federation-App genutzt. Ein HTTP 400 (Bad Request) sagt eigentlich aus, dass der Request irgendwelche Fehler enthält (z.B. im Request-Content/JSON). Am Client (wo der 400er ausgegeben wird) wirst du zu dem Fehler keine weiteren Infos mehr bekommen, allerdings sollte am Server noch irgendwo die Information zu finden sein, was genau zum 400er geführt hat.
            Da ich keine Ahnung habe, wie die Web-API programmiert wurde oder wie die Schnittstelle genau aussieht, könte ich hier auch nur raten. Vielleicht kommst du schneller ans Ziel, wenn du auf GitHub mal einen Issue erfasst. Hier sollte dir auf jeden Fall geholfen werden können.

            Gruß,
            Jan

  • Philipp sagt:

    Super Tutorial!!!
    Hab es hier auch problemlos zum laufen bekommen.

    Zum Schluss ist mir dann doch ein Fehler passiert.
    Ich habe statt dem owncloud_db_user den root user eingetragen, mit dem entsprechend passwort.

    Lässt sich das rückgängig machen bzw. der Einrichtungs-Assistent neustarten und die Datenbank Einstellungen neu eintragen.
    Muss dann auch die Datenbank bereinig werden . . . . bloß wie!?!?!?

    Danke schon mal im voraus…..

    Wie gesagt sehr gutes Tutorial ;)

    • Jan sagt:

      Hi Philipp,

      wenn der owncloud_db_user die entsprechenden Rechte bereits hat (grant all privileges…), dann kann man dies sehr leicht ändern. Dazu einfach nur die ownCloud-Config öffnen (nano /var/www/owncloud/config/config.php) und hier den entsprechenden Nutzer nebst Passwort eintragen:
      'dbuser' => 'owncloud_db_user',
      'dbpassword' => 'MeinPasswort',

      Anpassungen an der Datenbank sollten nicht notwendig sein.

      Gruß,
      Jan

      • Philipp sagt:

        Vielen Danke, das ging ja einfacher als gedacht ;)

        Nun steht das Passwort aber unverschlüsselt in der config, lässt sich dies ändern bzw. ist dies evtl. ein Sicherheitsrisiko!?

        Eine frage hätte ich noch…. derzeit wird Owncloud mit „meinedomain/owncloud“ aufgerufen, lässt es sich ohne großen Aufwand bewerkstelligen, Owncloud direkt über die Domain Eingabe zu erreichen.

        Danke schon mal ;)

        Gruß

        • Jan sagt:

          Hi Philipp,

          das DB-Passwort steht immer unverschlüsselt in der config.php. An diese Datei kommt aber niemand direkt heran. Darüber hinaus ist durch die Angabe von „@localhost“ beim DB-Benutzer sicher gestellt, dass der Login immer nur lokal (und nicht remote) stattfinden kann. Daher ist das kein Sicherheitsrisiko.

          Um die Cloud direkt über das Root-Verzeichnis zu erreichen, ist nur eine kleine Änderung notwendig (siehe markierte Zeile, den Rest in diesem Block entweder auskommentieren oder löschen):
          location = / {
          rewrite ^ /owncloud;
          }

          Gruß,
          Jan

  • Bernd sagt:

    Hallo,

    ich habe Nextcloud 11 nach einer Anleitung installiert, es funktioniert soweit auch alles, nur habe ihc Probleme mit der Serverinfo:

    Diese zeigt mir z.B. den Verfügbaren Speicher nicht an und gibt mir folgenden Fehler im Log aus:

    Error PHP file_get_contents(/proc/meminfo): failed to open stream: Operation not permitted at /var/www/nextcloud/apps/serverinfo/lib/SystemStatistics.php#71

    Error PHP file_get_contents(): open_basedir restriction in effect. File(/proc/meminfo) is not within the allowed path(s): (/var/www:/tmp/:/var/nextcloud_data:/dev/urandom) at /var/www/nextcloud/apps/serverinfo/lib/SystemStatistics.php#71

    Ich würde mich wahnsinnig über Hilfe freuen.

    Vielen lieben Dank

    Gruß Bernd

  • Mark sagt:

    Hallo Jan,
    auch von mir vielen Dank für das super Tutorial. Die ersten 90 Tage Nutzung sind nun rum und ich habe versucht mein Zertifikat zu aktualisieren.
    1. Versuch:
    letsencrypt renew
    2. Versuch:
    letsencrypt certonly –webroot -w /var/www/letsencrypt -d MEINE.ADRESSE.net –rsa-key-size 4096
    In beiden Fällen bekomme ich folgende Fehlermeldung:
    Failed authorization procedure. MEINE.ADRESSE.net (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to MEINE.ADRESSE.net

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

    Domain: MEINE.ADRESSE.net
    Type: connection
    Detail: Could not connect to MEINE.ADRESSE.net

    Ich habe versucht das erzwungene HTTPS zweitweilig abzuschalten indem ich folgendes in der MEINE.ADRESSE.net.config gelöscht habe:

    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;
    }
    Das hat nicht wirklich funktioniert. Offensichtlich durchschaue ich das noch nicht in Gänze.
    Für einen Tipp wäre ich sehr dankbar.
    Viele Grüße
    Mark

    • Jan sagt:

      Hallo Mark,

      eigentlich sollte das funktionieren – zumindest bekomme ich beim Erneuern der Zertifikate keine Fehlermeldung.
      Durch diesen Block wird HTTPS für LE nicht erzwungen:
      location ^~ /.well-known/acme-challenge {
      proxy_pass http://127.0.0.1:81;
      proxy_redirect off;
      }

      Dieser muss vor dem redirect auf HTTPS (location / {…) stehen.
      Wird zwar nicht die Lösung sein (wenn man sich die Fehlermeldung ansieht), aber hast du den LE-Aufruf mit Admin-Rechten (sudo) aufgerufen?
      Ansonsten findest du vermutlich im Error-Log von nginx die genaue URL, auf die LE zugreifen will (die aber nicht gefunden wird). Hier müsste man untersuchen, warum die Weiterleitung ins Leere führt.

      Gruß,
      Jan

      • Mark sagt:

        Hallo Jan,
        danke für die schnelle Antwort! Ja, ich führe das Ganze mit root-Rechten aus (vorher sudo -i). Im Errorlog vom nginx steht folgendes:
        2017/02/07 13:02:55 [warn] 12196#12196: no resolver defined to resolve ocsp.int-x3.letsencrypt.org while requesting certificate status, responder: ocsp.int-x3.letsencrypt.org, certificate: „/etc/letsencrypt/live/MEINE.ADRESSE.net/fullchain.pem“
        Mich wundert, dass hier fullchain.pem und nicht chain.pem angegeben ist. Ich habe nun mal testweise versucht, ssl_stapling auszuschalten. DAs hat allerdings auch nichts gebracht. – Der Fehler bleibt der gleiche, ich bekomme nun aber keine neuen Einträge mehr in der error.log vom nginx (auch nicht nach erneutem Einschalten)
        Ich kann auch in keiner *.conf Datei einen eingetragenen Resolver finden. Muss der nicht irgendwo stehen? Bin nach wie vor etwas ratlos.
        Gruß
        Mark

        • Jan sagt:

          Hi Mark,

          Einen resolver kannst du einfach in die (SSL-)Server-Config des Gateway-Hosts eintragen (z.B. nach ssl_trusted_certificate …):
          resolver <IP-des-Nameservers>;
          Dabei ist diese IP meistens die IP deines Routers.

          Allerdings glaube ich nicht, dass dieser Fehler verantwortlich für das Scheitern der LE-Erneuerung ist. Wenn du eine einfache txt-Datei im Verzeichnis anlegst, das von LE zur Verifikation herangezogen wird (z.B. /var/www/letsencrypt), kannst du dann per Browser auf diese Datei zugreifen (per HTTP)? Wenn das funktioniert, sollte auch die Erneuerung des Zertifikats keine Probleme bereiten.

          Gruß,
          Jan

          • Mark sagt:

            Hi Jan,

            du hast leider recht – der eingetragene Resolver löst das Problem nicht. Ich kann per HTTP gar nicht mehr zugreifen, weil ich offensichtlich nicht in der Lage bin das HTTPS-Redirect zurückzunehmen. Was muss ich hierfür genau tun? Wie sieht dann der Zugriff per Browser auf die Textdatei aus?

            Danke und Gruß
            Mark

          • Mark sagt:

            Hallo noch mal,
            nun hat es geklappt. Habe das Zertifikat folgendermaßen neu installiert:
            1. stoppen nginx
            2. letsencrypt certonly –standalone -d MEINE.ADRESSE.net
            3. starten nginx
            Schönen Gruß
            Mark

          • Jan sagt:

            Hi Mark,

            komisch, dass es anscheinend nur mit dem Stoppen von nginx funktioniert. Aber gut, du konntest das Zertifikat erneuern, das ist erst einmal das Wichtigste.

            Gruß,
            Jan

          • Mark sagt:

            …danach ging übrigens dann auch
            letsencrypt certonly –webroot -w /var/www/letsencrypt -d MEINE.ADRESSE.net –rsa-key-size 4096
            wieder.

          • Jan sagt:

            Hi,

            noch komischer, anscheinend hat sich hier irgend etwas verhakt. Nun sollte es auch einfach mit einem renew funktionieren.

            Gruß,
            Jan

    • benb sagt:

      Hi,
      ich habe exakt das gleiche Problem. Das interessante ist, dass ich in der Vergangenheit bereits einmal mein Zertifikat erneuert hatte. Jetzt laufe ich auf den selben Fehler, nur dass deine Lösungsansätze leider nicht bei mir funktioniert haben. Im Forum von letsencrypt habe ich eine detaillierte Beschreibung abgegeben:
      https://community.letsencrypt.org/t/failed-authorization-procedure-colony47-de/27517
      Für Tipps wäre ich sehr dankbar!

      • Jan sagt:

        Hi,

        außer, dass bei deiner Config auf Port 81 gelauscht wird, fällt mir nichts weiter auf (muss Port 80 sein). Spiel mal ein wenig mit den Anweisungen root/location rum und teste das mal einfach mit einer Text-Datei an der Stelle, an der du erwarten würdest, dass sie abgerufen werden kann. Dann Zugriff per Browser: Wenn das klappt, sollte auch die Zertifikat-Erneuerung funktionieren.
        Weil du erwähnst, dass die Erneuerung schon einmal funktioniert hat: Was hat sich in der Zwischenzeit geändert (Configs, Updates, etc.)?

        Gruß,
        Jan

        • Ben sagt:

          Hallo, danke für deinen Kommentar. Ich habe die Lösung gefunden: Mein Server nimmt nach der Beispielkonfiguration ersteinmal alle Anfragen auf Port 80 an und definiert dort mit dem Befehl root /var/www; den Ort wo bei Files liegen. Danach wird alles auf Port 443 weiter geleitet, damit es nun https ist. Hier gibt es einen neuen Server Block. Diesem fehlte jetzt der Eintrag root /var/www;. Nachdem ich ihn eingefügt habe, klappt wieder alles wunderbar (wundert mich, warum es beim ersten Mal funktioniert hat und sonst hier niemand das Problem hat). Eventuell liegt es aber auch an meinen zahlreichen Experimenten, die ich mit nginx durchgeführt habe um zu verstehen wie es funktioniert.

          Zu deiner Frage, das mit dem Port 81 geht in Ordnung, weil ich intern alle letsencrypt Anfragen an Port 81 umleite. Das kommt glaube ich auch aus der Anleitung.

          • Jan sagt:

            Hi Ben,

            Danke für die Rückmeldung.
            War wohl der „klassische“ Fehler: Eine Kleinigkeit vergessen/geändert und schon funktioniert irgend etwas nicht mehr. Ist wirklich tückisch.
            Aber gut, wenn nun alles funktioniert, sollte die Erneuerung auch zukünftig klappen.

            Gruß,
            Jan

  • Joe sagt:

    Top Dokumentation!! Hat super funktioniert, sehr sehr gut gemacht!!

    Eine Frage hätte ich noch:
    ich möchte, dass der Server unter https://ADRESSE und nicht über https://ADRESSE/owncloud erreichbar ist.

    An welchen Stellen muss ich dann Änderungen ausführen?

    • Jan sagt:

      Hey Joe,

      wenn du die Cloud nur über die Domain (ohne Pfad) aufrufen willst, dann kannst du eigentlich auch auf den Gateway-Host verzichten und direkt einen einzigen vHost für ownCloud verwenden: siehe ownCloud-Dokumentation (ownCloud in the webroot of nginx).

      Wenn du deine Cloud jetzt schon nach dem Tutorial aufgebaut hast, dann ist das auch nicht weiter wild: Einfach im location-Block „/“ im Gateway-Host (in der HTTPS-Server-Definition) eine Weiterleitung einrichten (wo bei dir jetzt vermutlich noch deny all; steht):
      location = / {
      rewrite ^ /owncloud;
      }

      Gruß,
      Jan

  • Mark sagt:

    Hallo Jan,

    erstmal Danke für Deine Top Seite….

    Ich habe mich durchgehangelt und es klappt – fast perfekt :-)

    Folgende Frage:

    Ich rufe meine Seite (von außen) über http://meindydns.de/owncloud auf – dann kommt wie gewünscht meine Anmeldeseite.
    Aber….
    In der URL-Leiste steht: https://192.168.1.1/ownlcoud und das Zertifikat wird – zurecht – angemeckert, da es ja auf meindydns.de lautet.

    Kannst Du mir sagen wo mein Fehler liegt?

    Danke

    Mark

    • Jan sagt:

      Hi Mark,

      stell doch mal folgendes in der Gatewa-Config ein (das erste return ist auskommentiert, das zweite aktiv):
      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;
      }

      Dann sollte er auf jeden Fall immer auf die DynDNS-Adresse gehen. Nachteil: Ein Zugriff über die lokale IP ist damit nicht mehr möglich. In den meisten Fällen wird dieser allerdings auch nicht benötigt, da es ansonsten beim lokalen Zugriff immer zu Warnungen wegen des Zertifikats kommt.
      Aber vielleicht taugt die Lösung in deinem Fall ja.

      Gruß,
      Jan

      • Mark sagt:

        Hallo,

        leider keine Änderung (trotz reboot).

        Unter unter Chrome:

        Forbidden

        You don’t have permission to access /owncloud on this server.
        Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.

        • Mark sagt:

          Meine Conf sieht so aus:

          server {
          listen 80 default_server;
          server_name meindyndns.de 192.168.100.66;

          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 meindyndns.de 192.168.100.66;

          #
          # Configure SSL
          #
          ssl on;

          # Certificates used
          ssl_certificate /etc/letsencrypt/live/meindyndns.de/fullchain.pem;
          ssl_certificate_key /etc/letsencrypt/live/meindyndns.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 = 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/meindyndns.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;
          }
          }

          • Jan sagt:

            Hi,

            die Config sieht soweit gut aus. Wird in Chrome noch etwas anderes angezeigt? Hier werden ja sämtliche Requests/Responses in der Konsole aufgeführt.
            Wundert mich nur, dass ein „Forbidden“ kommt, wenn du auf /owncloud zugreifen willst.
            Hast du den vHost für ownCloud 1:1 übernommen? Stimmen die Verzeichnisrechte auf dem Server?

            Gruß,
            Jan

          • Mark sagt:

            hier die conf:

            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;
            }
            }
            }

            habe mich an Deine Anleitung gehalten – hoffe dass ich keinen Fehler habe..

          • Mark sagt:

            403 Forbidden kommt in jeden Browser…

          • Jan sagt:

            Hi,

            auch der OC-Host sieht soweit gut aus. Läuft hier vielleicht sowas wie ufw oder so? Wenn nicht, kannst du mir ja mal eine Mail schicken mit der genauen URL deiner Cloud, dann kann ich da mal mit Chrome drauf gucken. Vielleicht fällt mir ja noch was auf.

            Gruß,
            Jan

          • Mark sagt:

            was meinst du mir ufw?

  • Jan sagt:

    Hi,

    wenn dir ufw nichts sagt, dann ist es auch nicht aktiviert. ;-)

    Gruß,
    Jan

  • Bernd sagt:

    Hallo,

    die Nextcloud rennt wie wild.
    Ich musste aber heute ein Backup heruinterladen und hatte mit folgendem Fehler zu kämpfen:

    Uncaught Error: Access to undeclared static property: OC\Files\Filesystem::$normalizedPathCache in /var/www/nextcloud/lib/private/Files/Filesystem.php:806 Stack trace: #0 /var/www/nextcloud/lib/private/Files/View.php(2018): OC\Files\Filesystem::normalizePath(‚/XXXX/files/Ha…‘) #1 /var/www/nextcloud/lib/private/Files/View.php(1156): OC\Files\View->unlockFile(‚/Handy Backup/B…‘, 1) #2 [internal function]: OC\Files\View->OC\Files\{closure}() #3 /var/www/nextcloud/3rdparty/icewind/streams/src/CallbackWrapper.php(109): call_user_func(Object(Closure)) #4 [internal function]: Icewind\Streams\CallbackWrapper->stream_close() #5 {main} thrown at /var/www/nextcloud/lib/private/Files/Filesystem.php#806

    Dieser Fehler kommt zustande wenn ich die Dateien über das Webfrontend laden möchte, oder aber auch wenn ich den Desktop Client nutze.

    an was kann das liegen? bzw. wie kann ich das abstellen :)

    Vielen lieben Dank Gruß Bernd

    • Jan sagt:

      Hi Bernd,

      was heißt in diesem Fall „ein Backup herunterladen“? Ein Backup, welches in der Cloud abgelegt wurde einfach nur über das Web-UI herunter laden? Oder ein Backup der Cloud selbst?
      Mit dem Fehler kann ich leider nichts anfangen. Ist auf jeden Fall etwas Nextcloud-internes.
      Wenn der Fehler weiterhin bestehen bleibt, würde ich mal einen Issue bei GitHub aufmachen. Die Entwickler können da sicher besser weiter helfen.

      Gruß,
      Jan

      • Bernd sagt:

        Hallo Jan,

        genu ein Backup das ich in der Cloud abgelegt habe.
        Das Funktioniert spitze, biss ca die Hälfte geladen wurde, dann wird einfach die Verbindung zum Server unterbrochen.
        Das Backup ist 24 GB Groß

        Gruß Bernd

        • Jan sagt:

          Hi,

          OK, das Backup ist ziemlich groß. Läuft er hier evtl. in irgendwelche Beschränkungen bzgl. Request-Größen rein? Findest du dazu etwas in den nginx Logs?

          Gruß,
          Jan

          • Bernd sagt:

            nein die Logs sind sauber :(
            ich hab die Installation unter ESXi erneut durchgeführt, und die Dateien ungezippt duch den Sync-Client hochgeladen.
            Trotzdem Procct das ein oder andre mal der Fehler auf.

            Gruß Bernd

          • Jan sagt:

            Hi Bernd,

            du hast also die alte Cloud durch eine neue ersetzt und die Dateien aus der alten Installation in die neue Cloud überführt? Haben sich die Versionen (NC alt/neu) unterschieden?

            Wie gesagt, ich würde an deiner Stelle mal einen Issue auf GitHub erfassen, da hier ein interner Fehler in der File-App geworfen wird. Ich befürchte hier nämlich, dass man diesen Fehler nicht „von außen“, d.h. mit administrativen Handgriffen lösen kann.

            Gruß,
            Jan

  • Stefan sagt:

    Hallo, klasse Zusammenstellung, auch für Anfänger wie für mich.

    Beim letzten Punkt,

    find /var/www/owncloud/ -type f -print0 | xargs -0 chmod 0640
    find /var/www/owncloud/ -type d -print0 | xargs -0 chmod 0750

    erhalte ich Operation not permitted für sämtlich Dateien.

    Fail2ban funktioniert auch.

    Vielen Dank

    • Jan sagt:

      Hi Stefan,

      führst du die Befehle auch mit root-Rechten aus (vorher noch ein sudo -s absetzen)?
      Wenn das auch nicht klappt, dann vielleicht mal chmod im Verbose-Mode ausführen. Also z.B. find /var/www/owncloud/ -type f -print0 | xargs -0 chmod -v 0640. Hier sollte dann eine genauere Fehlermeldung angezeigt werden.

      Gruß,
      Jan

  • Martin sagt:

    Hi there,

    ich bin begeistert. es klappt wunderbar.

    Vielen Dank

  • Christoph Ostermayer sagt:

    Fehler bei Php7-Installation: Das Paket heißt (jetzt) statt php-apcu > php7.0-apcu

    Danke für die grandiose Anleitung!

    • Jan sagt:

      Hi Christoph,

      also auf meiner Maschine kann das Paket php7.0-apcu nicht gefunden werden (apt-get install php7.0-apcu). Hier heißt es nach wie vor php-apcu. Welche Ubuntu-Version verwendest du genau?

      Gruß,
      Jan

  • Wolfram sagt:

    Danke für die Anleitung – funktioniert wunderbar!

    Gibt es noch eine Anleitung für den Umzug der eigenen Webseite(n) auf den Homeserver (http,css,js,php)?

    Die erste Seite läuft zwar schon einwandfrei, für einen Nicht-Webadmin ist die Frage, ob alle Sicherheitsnotwendigen Dinge erledigt wurden nicht ohne Hilfe beantwortbar. Danke für die Hilfe!
    Gruß
    Wolfram

    • Jan sagt:

      Hallo Wolfram,

      diese Frage ist leider nicht pauschal zu beantworten. Ich habe in einem weiteren Artikel beschrieben, wie man neben ownCloud/Nextcloud eine weitere Web-Anwendung installieren kann. Der Artikel zeigt recht deutlich, dass es hier und da immer mal wieder Fallsticke gibt, welche aber von der Web-Anwendung ausgehen.
      Ein Patent-Rezept gibt es hier leider nicht.

      Gruß,
      Jan

1 3 4 5 6 7

Schreibe einen Kommentar

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