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

  • Bernd sagt:

    DANKE!!! genau richtig zum Urlaub! :)
    Wieder einmal klasse geworden!

    Gruß Bernd

  • Bernd sagt:

    ui und schon die erste Frage :) wenn ich Let´s encrypt nicht nutzen möchte, wass muss ich dann weglassen? denn der Server soll nur lokal laufen und ein selbstsigniertes Zertifikat sollte reichen.

    Gruß Bernd

    • Jan sagt:

      Hallo Bernd!

      Klar, das Let’s Encrypt Zertifikat ist nur optional, es kann genau so gut ein selbst signiertes Zertifikat zum Einsatz kommen. Wie das dann gemacht wird, ist noch im alten Artikel (Abschnitt Selbst signiertes Zertifikat erstellen) erklärt. Ich habe auch noch einen kleinen Hinweis darauf in diesem Artikel hier hinzugefügt.
      Dennoch ist die Generierung eines Zertifikats über LE mittlerweile recht einfach geworden und funktioniert sehr zuverlässig. Darüber hinaus hast du mit einem selbst signierten Zertifikat immer Probleme (z.B. Warnungen in Browsern, Windows Phones weigern sich komplett, die Zertifikate zu akzeptieren (wenn diese nicht manuell nachinstalliert werden), etc.). Daher würde ich immer den Weg über Let’s Encrypt gehen.

      Gruß,
      Jan

  • Bernd sagt:

    Hallo,

    so ich bin komplett durch Server läuft!!!!
    Sehr geil!
    eine Kleinigkeit ist mir aufgefallen:

    Da ist ein O zuviel drin :)
    chown -R www-data:www-data /var/oowncloud_data

    Der Server läuft sehr performant, ich werde ihn jetzt mal auf Herz und Nieren testen!!

    eines wäre aber noch klasse,
    wie kann ich den Server vom lokalen Netzt aus erreichen, denn er routet mich immer wieder über´s inet (ist aktuell auch verständlich)

    aber ich müsste die Cloud, wenn sie live geht, mit vielen Daten füttern, und dass wird dann ja ewig dauern :(

    gibt es eine Möglichkeit das ich mit eingabe der IP im browser eben auch auf die Cloud komme, ohne redirect?

    Gruß Bernd

    • Jan sagt:

      Hi Bernd,

      Arg, einen Tippfehler haut man immer in die Befehls-Auflistung rein. Danke für den Hinweis, habe ich ausgebessert.

      Wenn du den Server nur über das lokale Netzwerk ansprechen willst, dann nimm nicht die URL (owncloud9tutorial.goip.de/owncloud), sondern die IP-Adresse (192.168.178.20/owncloud). Dadurch, dass wir im Gateway-Host von nginx neben der URL auch die IP angegeben haben, reagiert auch der Gateway-Host auf die Anfrage.
      Es kann sein, dass du eine Zertifikat-Warnung angezeigt bekommst, die kannst du aber getrost ignorieren. ownCloud wird auch meckern, da du nicht über die erwartete URL auf die Cloud zugreifst. Praktischerweise zeigt diese Fehler-Seite auch gleich eine Schaltfläche, mit der du die IP zu den sog. Trusted Domains hinzufügen kannst.
      Jetzt sollte der ganze Traffic nur über das lokale Netzwerk ablaufen.

      Gruß,
      Jan

  • Bernd sagt:

    Hallo,
    Das klappt leider nicht, ich habe das schon versucht, aber sobaold ich die lokale ip eingebe routet er mich auf die inetaddresse.
    Sobald ich das portforwarding ausschalte, ist auch keine verbindung zum server mehr möglich, auch von lokaler seite nicht.

    Gruß Bernd

  • Bernd sagt:

    Ah Kommando zurück :)
    also es läuft, mann muss lokal lediglich die volle Add eingeben also inkl https:XXXXXXXXXX:443 dann läuft es man bekommt halt den von dir Beschriebenen Zertifikatsfehler.
    Danke für die Info.

    Gruß Bernd

  • Bernd sagt:

    Gibt es bei dir auf der HP eigentlich die Möglichkeit für ein donate?

    Gruß Bernd

  • Chris sagt:

    Hallo,
    diese Anleitung kam auch bei mir zur richtigen Zeit und hat mir wirklich sehr geholfen!
    Vielen Dank dafür!

    Da mein Aufbau ein andere ist, hänge ich leider noch an einem Punkt mit Nginx. Und zwar habe ich deine Anleitung in zwei VMs nachgebaut. Einmal ohne DB/Owncloud, einmal komplett.
    Jetzt möchte ich die erste VM lediglich als Reserved Proxy nutzen. Die zweite als Webserver.

    Die Proxy VM läuft und ich habe schon erfolgreich SSL Verbindungen zu z.b. meiner Gitlab VM. Also git.domain.de wird über Proxy VM zu GitlabVM durchgereicht. Passt.

    Aber ich bekomme ich nicht hin auf die zweite neue Webserver VM zu verweisen. Auf dieser laufen statische Seiten sowie z.b. owncloud / dokuwiki. Diese möchte ich teils über seperate subdomains, teils als Pfadangabe (domain.de/statisch) ansprechen.
    Mein größer Erfolg war das mein Browser die Owncloud index.php heruntergeladen hat :(

    Hast du zu dieser Thematik einen Tipp? Ich komme da einfach nicht weiter.

    Gruß
    Chris

    • Jan sagt:

      Hallo Chris,

      die Sache wird zunehmend komplexer, wenn zusätzlich noch eine Aufteilung zwischen mehreren VMs stattfindet. Wenn hier Fehler auftreten, sollte man aber in jedem Fall einen Blick in die nginx-Logs werfen (/var/log/nginx/error.log). Hier findet man häufig einen Hinweis auf den Fehler (und v.a. die Info, auf welcher VM der Fehler auftritt).

      Wenn dein Browser allerdings die index.php heruntergeladen hat, sieht mir das aber fast so aus, als ob die PHP-Dateien nicht durch den PHP-Interpreter gejagt werden, sondern vom Webserver „einfach so“ ausgeliefert werden, so dass ein Browser dann einfach den Download startet.

      Wenn es doch noch an einer anderen Stelle hakt, kannst du dich auch gern bei mir per E-Mail melden. Dein Konfiguration ist schon sehr speziell… ;-)

      Gruß,
      Jan

  • Hans sagt:

    Hallo,

    ein super Tutorial. Wollte dies in dieser Konfiguration schon lange machen.

    Ich komme leider nur bis zur ownCloud-Setup. Dann erhalte ich immer folgenden Fehler:

    Failed to connect to database: An exception occured in driver: SQLSTATE[HY000][1045] Acess denied for user ‚owncloud_db_user’@’localhost'(usind password: YES)

    Ich habe inzwischen auch den User mehrfach gedropped und wieder created, aber keine Wirkung.

    Weiterhin wird mir die Setup Seite auf Englisch angezeigt.

    Irgendeine Idee insbesondere zum ersten Problem?

    Gruß
    Hans

    • Hans sagt:

      Hallo,

      habe den Server neu gestartet. Dann hat es geklappt.

      Allerdings bleibt die ownCloud weite auf Englisch. Muss ich noch was installieren?

      Gruß
      Hans

      • Jan sagt:

        Hallo Hans,

        vielleicht hilft dir der Vorschlag von Bernd ja schon.
        Falls nicht, würde ich es direkt über die config.php probieren. Hier gibt es eine Variable default_language: Hier würde ich einfach mal de eintragen.
        Läuft dein Betriebssystem eigentlich auf Englisch?

        Gruß,
        Jan

        • Hans sagt:

          Hallo Jan,
          mein Betriebssystem ist Ubuntu Server 16.04 LTS. Ich habe es runtergeladen und dort alle Auswahlmöglichkeiten auf deutsch gesetzt. Kann ich irgendwo noch mehr einstellen?

          Gruß
          Hans

  • Bernd sagt:

    man kann die sprache in owncloud direkt für jeden User umstellen unter dem reiter „persöhnlich“

    Gruß Bernd

    • Hans sagt:

      Hallo Bernd,

      die Umstellung auf deutsch hat funktioniert. Ich habe auch noch in der config.php die default language auf De_de gesetzt. Und es funktioniert.

      Ich habe noch eine Frage. Bei der Vergabe des owncloud_db_users habe ich leider ein einfaches Passwort gewählt und möchte dies nun ändern.

      Ich habe über

      mysql -u root -p

      SET PASSWORD FOR ‚owncloud_db_user’@’localhost‘ = PASSWORD(’newpassword‘);

      das Passwort versucht zu ändern. Quittiert wird mir der Befehl mit

      Query OK, 0 rows affected (0.00 sec)

      Nun habe ich in

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

      die Zeile

      ‚dbpassword‘ => ‚altes Passwort‘,

      auf

      ‚dbpassword‘ => ’newpassword‘,

      geändert.

      Dann kann ich leider die owncloud nicht aufrufen. Ein Server Fehler kommt.

      Muss ich den Server, die owncloud oder sonstiges neu starten? Sonst eine Idee?

      Gruß
      Hans

      P.S. Müsste man den Server noch absichern, z.B. mit fail2ban? Vielleicht ein weiteres Tutorial?

      • Jan sagt:

        Hallo Hans,

        was besagt der Fehler, wenn du die ownCloud nun aufrufen willst?

        Ein Neustart, zumindest vom MariaDB könnte helfen (service mysql restart).
        Ich würde evtl. nach dem Ändern des Passworts nochmal ein
        grant all privileges on owncloud_db.* to owncloud_db_user@localhost IDENTIFIED BY 'newpassword';
        flush privileges;

        hinterherschieben.

        Wenn alles nichts hilft, User noch einmal löschen und neu anlegen.

        Gruß,
        Jan

        • Hans sagt:

          Hallo Jan,

          folgende Befehle haben dann funktioniert:

          mysql -u root -p

          SET PASSWORD FOR ‚owncloud_db_user’@’localhost‘ = PASSWORD(’newpassword‘);

          grant all privileges on owncloud_db.* to owncloud_db_user@localhost IDENTIFIED BY ’newpassword‘;

          flush privileges;

          quit

          Dann ein:

          service mysql restart

          In

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

          die Zeile

          ‚dbpassword‘ => ‚altes Passwort‘,

          auf

          ‚dbpassword‘ => ’newpassword‘,

          Vielen Dank für die Hilfe.

          Eine Frage habe ich noch: Ist die Installation von fail2ban bei diesem Einsatzzweck sinnvoll?

          Viele Grüße
          Hans

          • Jan sagt:

            Hallo Hans!

            fail2ban erachte ich hier schon für sinnvoll, da die ownCloud ja direkt über das Internet erreichbar ist. Zwar muss man Usernamen und Passwort eingeben, allerdings ist dieser Login nicht weiter geschützt (z.B. wie bei der FritzBox, hier muss man nach einer falschen Eingabe der Login-Daten immer länger warten). Die ownCloud wäre (in der Theorie zumindest) anfällig für Brute Force Angriffe.

            Ich denke ich werde zu diesem Thema auch mal einen kurzen Artikel in Angriff nehmen.

            Gruß,
            Jan

          • Jan sagt:

            So, habe nun Fail2ban mit meiner ownCloud-Konfiguration getestet. Es war ein kleiner Umweg notwendig, damit der virtuelle Host für ownCloud (bzw. der entsprechende PHP-Handler) die „richtige“ IP-Adresse mitbekommt.
            Habe daraus einen Artikel gemacht: ownCloud mit Fail2ban absichern. Hoffe, das hilft weiter.

            Gruß,
            Jan

  • ThoSchl sagt:

    Super Artikel!!! Wirklich fantastisch! Ganz großes Lob! Zwei Kleinigkeiten sind mir aufgefallen:

    1.) in der Beispiel Konfiguration /etc/nginx/sites-available/owncloud9tutorial.goip.de_owncloud fehlt in der Zeile max_execution_time = 3600 das „=“-Zeichen. Ich hatte deshalb Fehler im Error-Log von Nginx (/var/log/nginx/error.log) „FastCGI sent in stderr: „Passing INI directive through FastCGI: empty value for key ‚max_execution_time 3600′“ while reading response header from upstream“

    2.) Ich hatte Schwierigkeiten mit dem Fileupload. Fehlermeldung „client intended to send too large body:“. Ich habe das Problem damit gelöst, dass ich in /etc/nginx/nginx.conf im Konfigurationsbereich http { } den Eintrag client_max_body_size 1G; gesetzt habe. Offenbar gab es da einen Problem, das dieser Parameter nicht for /var/owncoud_data zu greifen scheint?

    Gruß und 1000 Dank
    Thoschl

    • Jan sagt:

      Hallo ThoSchl,

      danke für das Lob!

      Zu 1: Habe den Code-Block angepasst. Danke für den Hinweis.
      Zu 2: Das client_max_body_size muss überall mit angegeben werden, wo der Upload mit „durch läuft“. Im konkreten Fall heißt das, dass diese Anweisung sowohl im proxy_pass (Gateway-Host), als auch im virtuellen Host für ownCloud mit angegeben werden muss. Du kannst es natürlich auch eine (server-Block im Gateway-Host) oder zwei Ebenen höher (hhtp-Block in der globalen nginx-Konfiguration) angeben. Das wird dann nach unten weiter gereicht.

      Gruß,
      Jan

  • neo sagt:

    Hallo Jan,

    Ich habe dein Tutorial 1:1 nachgemacht, einfach mit der Domain cloud.meindomain.ch statt auf owncloud9tutorial.goip.de. Wenn ich im Browser über meine cloud.meinedomain.ch/owncloud aufrufen will funktioniert es nicht, kommt immer die Meldung: ERR_CONNECTION_CLOSED, wget sagt:
    Unable to establish SSL connection

    Aus dem selben Netzwerk mit dem Aufruf: https://192.168.0.153/owncloud/index.php funktioniert es.

    Ich dachte mir, es liegt weil der Router meine Anfragen nicht sauber vom Inet an die VM gibt, aber im AccessLog sowie im Browser Entwicklertools, sehe ich den 301 http Stutus vom Nginx von http Aufruf. Aber danach kommt die oben erwähnte Meldung.

    Hier meine zwei Server Blöcke (nur Beginn, sonst kann muss man ausser die Certpafade ja nix anpassen) cloud.meinedomain.ch
    server {
    listen 80 default_server;
    server_name cloud.meinedomain.ch 192.168.0.153;

    server {
    listen 443 ssl http2;
    server_name cloud.meinedomain.ch 192.168.0.153;
    ….

    Hier noch der Server Block cloud.meinedomain.ch_owncloud

    server {
    listen 82;
    server_name 127.0.0.1;

    Habe hier auch schon statt nur 127.0.0.1; auch zusätzlich noch cloud.meinedomain.ch 192.168.0.153 eingetragen. Ging aber auch nicht.

    Der Aufruf im Browser wäre ja http://cloud.meinedomain.ch/owncloud oder das selbe mit https.

    Irgendwas mit dem https Server vermute ich, aber ich habe keine Idee mehr. Wäre um jede Hilfe dankbar.

    Gruss Neo

    • Neo sagt:

      Problem nach 4 Tagen gerade heute gefunden. Mein Router sein OpenVPN läuft ja auf 443, daher hat der immer die Connection an sich gerissen.
      Ich habe nun den owncloud Server auf Port 8443 gelegt. Dazu müssen folgende Konfigs angepasst werden

      /etc/nginx/sites-enabled/owncloud9tutorial.goip.de
      Im ersten server Block:

      return 301 https://$server_name:8443$request_uri;

      Im zweiter server Block:

      server {
      listen 8443 ssl http2;

      location ^~ /owncloud {
      proxy_set_header Host $host:8443;

      Für über paranoya Leute wie mich. Kann man noch die lokale Firewall aktivieren.
      In meinem Fall muss noch der Port 8443 aufgenommen werden in das nginx profile:
      File öffnen
      sudo nano /etc/ufw/applications.d/nginx

      im Block „Nginx Full“

      Zeile ports=80,443/tcp mit ports=80,443,8443/tcp ersetzten. Wenn die kein Webserver auf 443 sonst läuft, kann man auch ports=80,8443/tcp eintragen.

      Vorheriges editiertes Firewall Profil laden:
      ufw allow „Nginx Full“

      Solltet ihr mit SSH eingeloggt sein, oder wollt dies noch können, nicht vergessen das Profil „OpenSSH“ ebenfalls zu laden, vor der FW Aktivierung

      Nun die Firewall aktivieren:
      ufw enable

      So läuft nun meine Owncloud auf port 8443

      Gruss Neo

      • Jan sagt:

        Hallo Neo,

        gut, dass es bei dir nun mit einem alternativen Port funktioniert.
        Danke für die genaue Anleitung, vielleicht hilft diese anderen Leuten, die ähnliche Probleme haben.

        Gruß,
        Jan

  • Kirdan sagt:

    Irgendwie will er nicht so, wie er es soll. Hat sich was bei den Verzeichnisstruktur bei nginx was geändert ?
    Es gibt nach der Installation bei Nginx und MariaDB kein /etc/nginx/sites-available/ und /etc/nginx/sites-enabled/ Verzeichnis, ein var/www/ ist nicht vorhanden, rm /etc/nginx/sites-enabled/default gibt es nicht -Seite wird aber angezeigt. Selbst das Anlegen der fehlenden Verzeichnisse bringt nichts :-(
    Die Default Seite wird aber angezeigt. Danke für einen Tipp.

    • Jan sagt:

      Hallo Kirdan,

      unter Ubuntu 16.04 haben sich tatsächlich die Verzeichnisstrukturen von nginx geändert. Früher (siehe alter Artikel) waren die virtuellen Hosts unter /etc/nginx/conf.d/ zu finden. Vermutlich befindet sich hier auch der default Host bei dir.
      Vermutlich wurde diese Verzeichnisstruktur deshalb geändert, da die Vorgehensweise mit den sites-available/sites-enabled sehr dem Konzept von Apache ähnelt.

      Dass das Verzeichnis /var/www nach einer neuen Installation nicht vorhanden ist, ist soweit normal. Dieses muss man in diesem Fall selbst anlegen.

      Gruß,
      Jan

      • Kirdan sagt:

        Danke für deine Antwort. OK, dann werde ich noch mal ran setzen (dachte immer, da haste wieder einen Schritt ausgelasenn ;-) ), denn die obrigen Kommentare sagen ja was anderes, das dies so klappt :-(
        Vielleicht sollte man diesen HowTo so anpassen, das man schreibt, mit welcher Versionsnummer dies durchgeführt worden ist.
        Mal sehen, wo es steckt, wenn ich die Informationen habe werde ich diese hier posten.

        • Jan sagt:

          Hallo Kirdan,

          ziemlich weit oben im Artikel stehen die verwendeten Programmversionen, mit den dieser Artikel entstanden ist.

          • Ubuntu Server 16.04 LTS („Xenial Xerus“)
          • nginx 1.10.0
          • MariaDB 10.1.13
          • PHP 7
          • ownCloud 9.0.2

          Trotzdem würde mich auch interessieren, warum die eigentlichen Verzeichnisse bei dir nicht vorhanden sind…

          Gruß,
          Jan

      • Kirdan sagt:

        Sorry, hast du ja :-(

        olgende Programmversionen kommen dabei zum Einsatz.

        Ubuntu Server 16.04 LTS („Xenial Xerus“)
        nginx 1.10.0
        MariaDB 10.1.13
        PHP 7
        ownCloud 9.0.2

        • Kirdan sagt:

          Ja, warst etwas schneller beim Antworten. Habe es auch gefunden beim nochmaligen durchlesen.

          • Kirdan sagt:

            Also es ist definitiv so, das sich die Verzeichnisstruktur von nginx 1.11.0 geändert hat. Wenn man mit der hier bschriebenen Version vorgeht, hat man keine Probleme.

  • Bernhard sagt:

    Hallo Jan,

    erstmal will ich mich für dieses super Tutorial bedanken! Du hast mir damit die fehlende Motivation gegeben, meinen Server endlich mal online zu bringen! :) Für mich hat das Tutorial ohne Probleme funktioniert und der Server läuft einwandfrei!

    Jedoch habe ich ein Problem mit dem Cronjob, da sich dieser nicht selbst ausführt. Du hast geschrieben, dass man folgendes unter „crontab -u www-data -e“ am Ende hinzufügen soll: „*/15 * * * * php -f /var/www/owncloud/cron.php > /dev/null 2>&1“. Das habe ich natürlich gemacht, jedoch funktioniert das nicht. Außerdem habe ich gesehen das in der Dokumentation für ownCloud 9.0 der Teil mit „> /dev/null 2>&1“ fehlt und hab es deswegen auch schon ohne dem probiert (also */15 * * * * php -f /var/www/owncloud/cron.php), leider ohne Erfolg! Ich habe auch schon ein bisschen gegooglet, aber leider ohne Erfolg! Woran könnte dieses Problem liegen? Das Tutorial habe ich 1:1 abgearbeitet.

    Desweiteren hatte ich dann auch noch ein komisches Verhalten des ownCloud Clients für Windows 10. Dieser hat nur alle (ca.) 24 Minuten ein paar MB synchronisiert und größere Daten (über 1GB) einfach ignoriert. Anscheinend hat das heute schon funktioniert, jedoch geht jetzt nach einem Neustart des Clients gar nichts mehr! Woran könnte dies liegen?

    Als letztes ist mir noch etwas bezüglich WebDAV aufgefallen -> mit einem Passwort welches Sonderzeichen und Umlaute verwendet, konnte ich mich nicht verbinden, nur mit einem ohne Sonderzeichen und Umlaute

    • Bernhard sagt:

      ach, vielleicht bin ich doch nicht 1:1 nach dem Tutorial vorgegangen.. ich habe nämlich statt /var/owncloud_data einen anderen Pfad gewählt, damit die Daten auf der anderen Festplatte sind (media/data/owncloud_data) :) Habe das gerade überprüft ob diese Einträge alle gepasst haben – habe tatsächlich 1 Eintrag vergessen – jedoch hat sich an meine Problemen nichts geändert :(

      mfg
      Bernhard

    • Bernhard sagt:

      ah, da ist mir nochwas eingefallen.. und zwar bekomm ich die default seite von nginx einfach nicht weg. hab schon die default seite gelöscht, geändert, etc.. aber ich bekomm sie einfach nicht weg!

      • Jan sagt:

        Hallo Bernhard,

        ich vermute mal, dass bei dir die Variable open_basedir in der CLI-Konfiguration von PHP (/etc/php/7.0/cli/php.ini) das Datenverzeichnis nicht enthält. Darum könnte der Cronjob auf Fehler laufen, da PHP (CLI) kein Zugriff auf dein Datenverzeichnis hat..
        Wenn das auch nicht hilft, und für die anderen Probleme (WebDAV und ownCloud-Client) auch: Schau doch mal bitte in die Log-Dateien (var/log/nginx/error.log bzw. access.log für nginx, /media/data/owncloud_data/owncloud.log für ownCloud). Hier sollte zumindest ein Ansatz zu finden sein, was hier genau schief läuft.

        Die Default-Seite müsste auf jeden Fall nicht erreichbar sein, wenn der default-Host unter /etc/nginx/sites-enabled entfernt wurde. Falls doch, stimmt etwas an der Konfiguration der virtuellen Hosts nicht so ganz.

        Gruß,
        Jan

        • Jan sagt:

          Hallo Bernhard,

          nun ist mir klar, was du mit der Default-Seite meinst, die nicht weg zu bekommen ist: Wenn man die Cloud nun ohne /owncloud aufruft (also https://owncloud9tutorial.goip.de), dann wird in der Tat diese Standard-Seite angezeigt.
          Ich habe den Artikel angepasst, dass dies nun nicht mehr der Fall ist. Dazu einfach im Gateway-Host folgenden Block vor dem owncloud-Block einfügen:
          location = / {
          deny all;
          }

          War es das, was du gemeint hattest?

          Gruß,
          Jan

  • Armin sagt:

    Hallo,
    vielen Dank für das tolle Tutorial!

    Ich habe aktuell einen OC Server unter 8.2.1 laufen und mit Daten gefüllt.
    Der Server läuft mit Apache und einem selbstsignierten Zertifikat, PHP5 und Mysql.

    Ich würde dies gerne auf die hier beschriebene Konfiguration umziehen, allerdings mit OC 8.2.x da es aktuell (meines Wissens nach) noch keinen Upgrade Pfad von 8.2 nach 9.0 gibt.

    Ein Versuch anstelle des OC 9.0 TAR’s das OC 8.2 TAR zuverwenden scheitert, bei der initialen Konfiguration von OC über den Browser enet immer mit der Meldung ‚Not allowed‘

    Was kann ich da tun?

    • Jan sagt:

      Hallo Armin,

      eine Update von 8.2 auf 9.x ist durchaus möglich, auch wenn es dir nicht in der Admin-Oberfläche angeboten wird. Da ich mit dem „automatischen“ Update über das Web-UI nur schlechte Erfahrungen gemacht habe, rate ich auch davon ab und würde empfehlen, das Update manuell durchzuführen. Das scheint zwar erst einmal aufwendiger zu sein, ist allerdings meiner Erfahrung nach deutlich stabiler. Vorher aber bitte ein Backup anfertigen. ;)
      Wie du das Update manuell durchführst, ist in diesem Artikel beschrieben.

      Gruß,
      Jan

  • Marcus sagt:

    Erst einmal vielen Dank für dieses Umfangreiche Tutorial. Habe hier das erste mal nginx als reverse proxy eingesetzt und bin irgendwie noch nicht ganz zufrieden mit der Konfiguration.

    Bei mir sieht es so aus, dass ich keinen Unterordner angelegt habe, sondern dies direkt über den FQDN laufen soll. Demzufolge habe ich location = / { rewrite ^ /index.php$uri; } angefügt.
    Nun bekomme ich entweder 404 Fehler (weil ich über /apps/files schon im Backend bin und versuche, auszuloggen) oder Zugriff verweigert wenn ich direkt den FQDN aufrufe.

    Ich bin am verzweifeln, woran könnte denn mein Problem nun liegen? Ich verstehe die Syntax hinter den location und rewrite Regeln auch leider nicht so ganz bei nginx.

    • Jan sagt:

      Hallo Marcus,

      wenn alles direkt über eine FQDN gehen soll, ist ein Reverse-Proxy evtl. nicht das richtige an dieser Stelle.
      Ich würde hier mit getrennten virtuellen Hosts arbeiten (also ohne den Gateway-Host). Der Host für ownCloud erhält dann den FQDN als server_name. Alle Anweisungen, die durch den im Artikel beschriebenen Gateway-Host durchgeführt werden, müssen dann natürlich im entsprechenden ownCloud-Host aufgeführt werden.
      Bei 404-Fehlern bitte auch mal einen Blick in das nginx-Log werfen (/var/log/nginx/error.log) werfen, hier findet man meist einen Hinweis darauf, wo der Fehler liegen könnte (gerade bei etwas komplexeren Konfigurationen).

      Gruß,
      Jan

      • Marcus sagt:

        Hallo Jan,

        Vielen Dank für die schnelle Antwort auf mein Problem.
        Ich habe die Konfiguration speziell wegen den letsencrypt Zertifikaten abgetippt und fand die Gateway-Lösung an sich recht interessant.

        Das Problem mit der 404 Meldung liegt darin, dass ownCloud speziell beim Ausloggen Parameter übergibt, ohne auf die index.php zu referenzieren. Die rewrite-Regeln fügen jedoch ein / voran, sodass aus ?tokenid plötzlich https://serverurl.com/index.php/?tokenid wird, welche nun logischerweise nicht gefunden wird.

        Da ich eine funktionierende Konfiguration hatte und „nur“ das Letsencrypt-Modul einsetzen wollte, habe ich wohl ziemlich viel Zeit an der Fehlersuche vergeudet. Ich werde meine alte Konfiguration verwenden mit den entsprechenden ssl_ Befehlen aus der hier beschriebenen Konfiguration.

        Ist es notwendig, beim Erneuern der Zertifikate, die Startkonfiguration (hier Teil 1) zurückzuspielen oder überprüft Letsencrypt ledeglich, ob ein Webserver auf Port 80 läuft?
        Übrigens ist es gemäß dem Tool möglich, mit ./letsencrypt-auto renew das Zertifikat ohne Nutzereingabe zu erneuern.

        Viele Grüße
        Marcus

        • Jan sagt:

          Hi Marcus,

          Ist es notwendig, beim Erneuern der Zertifikate, die Startkonfiguration (hier Teil 1) zurückzuspielen oder überprüft Letsencrypt ledeglich, ob ein Webserver auf Port 80 läuft?

          Nein, das Zurückspielen ist nicht notwendig, das wäre viel zu aufwändig. Teil 2 der Konfiguration enthält ja noch die Konfiguration aus Teil 1.

          Übrigens ist es gemäß dem Tool möglich, mit ./letsencrypt-auto renew das Zertifikat ohne Nutzereingabe zu erneuern.

          Guter Hinweis, habe ich aber noch nicht ausprobiert. Der Befehl scheint recht neu zu sein, viele Leute lösen das Problem auch per CronJob.

          Gruß,
          Jan

          • Bernd sagt:

            Jow :) das wäre klasse, wen man das renewing von Letsencrypt als Cronjob machen könnte. –> würde mich sehr über eine ergänzung des Tutorials freuen :)

            Gruß Bernd

  • Mitch sagt:

    danke für das tolle tutorial.
    ich würde meine owncloud gern über „adresse.tld“ anstatt „adresse.tld/owncloud“ erreichen. in welcher config stelle ich das am sinnvollsten ein?
    idealerweise bleibt die restliche struktur mit gateway usw. erhalten, sodass die zertifikatsanforderung mit let’sencrypt weiter funktioniert. (z.b. über einen anderen port)
    andere webdienste benötige ich nicht.

    • Jan sagt:

      Hi Mitch,

      also wenn keine weiteren Webdienste laufen sollen, dann würde ich empfehlen, nur eine einzige Config für ownCloud zu verwenden. Hier kannst du dann direkt die nginx-Config aus dem ownCloud Admin-Manual übernehmen (ownCloud in the webroot of nginx).
      Die Sache mit Let’s Encrypt sollte hier auch funktionieren, da ein spezieller location-Block für LE enthalten ist.

      Gruß,
      Jan

      • Mitch sagt:

        abermals vielen dank für die schnelle antwort.
        letztendlich habe ich auch die config aus dem manual verwendet und es funktioniert. dass der location-block für lets’sencrypt bereits drin ist, hatte ich noch gar nicht gesehen.
        ich muss allerdings heute abend noch die sicherheitsrelevanten teile aus deiner config übernehmen. momentan reicht es nur für ein b-rating im ssl-test.
        falls es noch jemanden interessiert – nextcloud funktioniert hervorragend mit dem tutorial.
        bg
        mitch

        • Jan sagt:

          Hallo Mitch,

          falls es noch jemanden interessiert – nextcloud funktioniert hervorragend mit dem tutorial.

          Gut zu wissen, da muss ich das Tutorial nicht noch einmal neu machen… ;)

          Gruß,
          Jan

      • Marko sagt:

        Das ist echt ein super Tutorial! Vielen Dank. Bei mir läuft das Ganze ziemlich gut in einer VM.
        Ich habe aber noch eine Frage. Ich habe genau das selbe Ziel, dass ich das Ganze über die Hauptdomain aufrufen kann. Ich habe jetzt in das /etc/nginx/sites-enabled/meine.domain.de_owncloud versucht die Sachen einzufügen bzw. anzupassen, aber irgendwie mag das nicht funktionieren. Wenn ich die Seite dann im Browser aufrufe, bekomme ich ein 403. Welche Zeilen muss ich genau ändern?
        Liebe Grüße, Marko

        • Jan sagt:

          Hallo Marko,

          wenn du neben ownCloud keine weiteren Webanwendungen laufen lassen willst, dann kannst du den Gateway-Host auch weglassen und nur einen einzelnen virtuellen Host verwenden. In diesem Fall kannst du die Config aus dem ownCloud Administration Manual direkt verwenden („ownCloud in the webroot of nginx“).

          Falls du den Gateway-Host doch so aus dem Tutorial übernehmen möchtest, dann muss die Weiterleitung auf die Cloud nicht über location ^~ /owncloud {, sondern über das Webroot laufen (location ^~ / {). Im virtuellen Host für ownCloud müssten dann wohl noch die Verzeichnis-Angaben angepasst werden, so dass kein ‚owncloud‘ mehr enthalten ist (z.B. error_page 403 /owncloud/core/templates/403.php; -> error_page 403 /core/templates/403.php;).

          Wenn es nach der Umstellung noch zu Fehlern kommen sollte, hilft meist ein Blick in den Error-Log von nginx (/var/log/nginx/error.log): Meist passt dann etwas nicht mit der Weiterleitung und/oder der Verzeichnis-Struktur. Im Log sollte man schnell einen Hinweis auf das Problem ablesen können.

          Gruß,
          Jan

  • Ingo sagt:

    Hallo

    Kann man das Tutorial auch für Nextcloud verwenden?

    Bis dann
    Ingo

    • Jan sagt:

      Hallo Ingo,

      laut Mitch (siehe Kommentar weiter oben): ja.
      Da Nexcloud ja momentan „nur“ ein Fork von ownCloud ist, sollte die Webserver-Konfiguration bei beiden identisch sein. Zumindest solange die Entwicklung von NC und OC nicht auseinander laufen.

      Gruß,
      Jan

  • Hans sagt:

    Hallo,

    eine nette Erweiterung wäre, wenn noch der cron Job für die automatische Erneuerung des Let’s Encrypt Zertifikats eingebaut werden könnte.

    Grüße
    Hans

  • Tobias sagt:

    Hallo zusammen,

    ich möchte mich an der Stelle auch noch bedanken für das super Tutorial.
    Als Neueinsteiger bei Linux ist es toll so eine detaillierte Anleitung zu haben.
    Allerdings kommt es bei mir auch schon zur ersten Frage: mir zieht es schon die neueste nginx Version 1.11.1 und da scheint sich einiges geändert zu haben. Zumindest existieren bei mir die Ordner „sites-available“ und „sites-enabled“ nicht. Auch die default.conf von nginx liegt an einem anderen Ort „/etc/nginx/conf.d/default.conf“. Und der Benutzer heißt anstatt „www-data“ in der config Datei „nginx“. Den Benutzer kann ich ja entsprechend ändern, aber kann ich die Dateistruktur einfach selbst anlegen, oder wo muss ich den Gateway-Host nun anlegen?
    Kann mir an dieser Stelle jemand weiter helfen?

    Viele Grüße,
    Tobias

    • Jan sagt:

      Hallo Tobias,

      ja, bei nginx ändert sich die Verzeichnisstruktur von Zeit zu Zeit. ;)
      Früher war es denke ich sites-enabled/sites-available. Dann wurde es geändert, so dass nginx alle *.conf-Dateien im Verzeichnis /etc/nginx/conf.d geladen hat (deaktivieren konnte man einen virtuellen Host durch Umbenennen der Dateien, z.B. MeineSete.conf.disabled). In der aktuellsten Version wird wieder das Konzept mit sites-enabled/sites-available unterstützt.

      In dieser Anleitung habe ich mal den Weg über sites-enabled/sites-available gezeigt, da dies der Apache-Konfiguration sehr nahe kommt. Im alten Tutorial (Ubuntu 15.04/ownCloud 8) wird der Weg über /etc/nginx/conf.d gezeigt. Vielleicht kann dir das ja als Anhaltspunkt dienen.

      Welche Configs nginx beim Start lädt, ist übrigens in der Datei /etc/nginx/nginx.conf definiert (im Abschnitt Virtual Host Configs).

      Wenn die Ordner sites-enabled/sites-available bei dir nicht vorhanden sind, dann würde ich diese nicht explizit anlegen, sondern den Weg über /etc/nginx/conf.d gehen. Hier gibt es weder Vor- oder Nachteile.

      Gruß,
      Jan

    • Markus sagt:

      Hallo Tobias,

      dieses Problem hatte ich auch. Um dem Tutorial möglich getreu zu bleiben kann man sich durch diese Zeilen in /etc/apt/sources.list die version 1.11.0 von nginx holen.

      # Nginx (use version 1.11.0)
      deb http://nginx.org/packages/mainline/ubuntu/pool/nginx/n/nginx/nginx-dbg_1.11.0-1~xenial_amd64.deb xenial nginx
      deb-src http://nginx.org/packages/mainline/ubuntu/pool/nginx/n/nginx/nginx-dbg_1.11.1-1~xenial_amd64.deb xenial nginx

  • Daniel sagt:

    Moin,
    ich habe da ein Paar Probleme, als Neuling in der Szene versuche ich mich an einer eigenen Cloud und bin auf dieses Tutorial gestoßen.
    Ich habe einen Raspberry Pi3 und stoße schon am Anfang auf Probleme.
    Beim hinzufügen der Paketquellen in die sources.list gibt es nach dem Befehl apt-get update schon Fehler. Wenn ich diese weglasse bekomme ich spätestens beim Installieren von php7 die meldungen, dass die Paktete nicht gefunden werden… Kann mir da jemand einen Tipp geben?

    • Marcus sagt:

      Hallo Daniel,

      php7 wird unter raspbian / bananian nur in Version 5 ausgeliefert. Dennoch sollte ein apt-get update funktionieren. Solltest du möglicherweise die Paketquellen geändert haben, um nginx hinzuzufügen, wird es Fehler geben, da in den Repositories von nginx kein armhf gibt. Unter Umständen wirst du gezwungen sein, die Pakete selbst zu kompilieren.

  • Markus sagt:

    Vielen Dank für die super Anleitung! Konnte mir so auch als Ubuntu-neuling eine eigene owncloud installieren! :)

  • Ingo sagt:

    Hallo
    Sehr schöne Tutorial.
    Ich hätte eine Frage zu den Virtuelle Host.
    Was muss ich in den Gateway-Host ändern bzw. angeben?
    Und wie ist ein Virtueller Host dafür aufgebaut?
    Können Sie dazu ein Beispiel machen?
    Ich würde gerne unter andren noch Linux Dash installieren.

    • Jan sagt:

      Hallo Ingo,

      ich habe mit Linux Dash noch nie gearbeitet, allerdings gibt es z.B. hier eine Beispiel-Config für nginx.
      Nun kannst du analog zur Let’s Encrypt Config in dieser Anleitung einen neuen virtuellen Host für Linux Dash erstellen. Diese Config beinhaltet dann die für Linux Dash benötigte Konfigurationen (siehe Link mit Beispiel-Config), muss sich aber von anderen virtuellen Host unterscheiden: In Verbindung mit dem Gateway-Host würde ich der Linux-Dash-Config als server_name einfach die lokale IP nehmen (127.0.0.1) und einen von allen anderen virtuellen Hosts abweichenden Port (z.B. 83).
      Nun fehlt nur noch die Weiterleitung vom Gateway-Host zur Linux Dash. Dazu muss der Gateway-Host erweitert werden: Wenn die Linux Dash z.B. unter meinedomain.de/dash erreichbar sein soll, dann wird (analog zum ownCloud-Teil des Gateway-Hosts) eine entsprechende Weiterleitung eingerichtet. Im einfachsten Fall könnte dies dann so aussehen:
      location ^~ /dash {
      proxy_pass http://127.0.0.1:83;
      proxy_redirect off;
      }

      Wie schon bei ownCloud kann es sein, dass der proxy_redirect weitere Variablen an die Config der Linux Dash weitergeben muss (z.B. Timeout-Werte).

      Gruß,
      Jan

  • Nephilim sagt:

    Hallo Jan,

    wie müsste ich vorgehen, wenn ich unter der DynDNS-Adresse die ownCloud aufrufen möchte (https://sub.domain.com:Port) und eine andere Webanwendung unter https://sub.domain.com:Port/Webanwendung?

    Gebt das?

    LG // Nephilim

    • Jan sagt:

      Hallo Nephilim,

      das dürfte auch kein Problem sein.
      Wenn du die Grund-Konfiguration mit dem Gateway-Host + separaten virtuelle Hosts pro Webanwendung übernehmen möchtest, dann leitest du im Gateway-Host einfach das Root-Verzeichnis zum ownCloud-Host weiter, sprich:
      location ^~ / {
      # 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;
      }

      Für die zweite Webanwendung wird dann wie mit der /owncloud-Weiterleitung verfahren (dann eben nur location ^~ /webanwendung)

      Evtl. kannst du dir es einfacher machen, wenn du den ownCloud-Host zum Gateway-Host machst. Hier muss dann nur ebenfalls eine Weiterleitung bei location ^~ /webanwendung erfolgen. Im ownCloud-Host müssen dann natürlich alle Parameter bzgl. Sicherheit enthalten sein.

      Gruß,
      Jan

      • Victor Seitz sagt:

        Hi Jan!

        ich klinke mich hier mal ein weil ich an genau dieser Stelle nicht weiter komme. Ich habe den gleichen Fall wie Nephilim, ich möchte meine owncloud-Installation über domain.de erreichen, will deine Konfiguration aber beibehalten weil ich es für künftige zusätzliche Anwendungen praktisch finde.

        Problem: wenn ich im Gateway-Host bei der location das owncloud weglasse lande ich im Leeren (error.log verrät mir dass er dann auf /var/www nach den Dateien such, nicht in /var/www/owncloud)

        Wie ich so lese haben damit ja viele Leute hier ihre Probleme weil das mit den vielen Stellen in den config-Dateien für Laien ja doch bisschen unübersichtlich ist. Wäre es vielleicht möglich dass du die nötigen Änderungen für dieses Szenario in den Host-Configs in der gesamten Datei postest? Ich bin mir sicher dass ich einfach nur an der falschen Stelle angesetzt habe, aber ohne das Hintergrundwissen wie die Host-Config funktioniert, tu ich mir mit der Fehlersuche wirklich schwer

        • Jan sagt:

          Hallo Victor,

          im Tutorial verwende ich ja ein Unterverzeichnis des Web-Roots. Daher ist sowohl im Gateway-Host, als auch in der ownCloud-Config alles daraufhin angepasst. Um nun ownCloud/Nextcloud über das Web-Root zu hosten, müssen nun einige Sachen angepasst werden:

          1. Die ownCloud-Dateien (*.php etc.) müssen sich dann im Webroot-Verzeichnis befinden (/var/www/).
          2. Die Weiterleitung vom Gateway-Host unter location ^~ /owncloud – die müsste geändert werden in location ^~ /.
          3. Zum anderen alle Verzeichnis-Angaben innerhalb des ownCloud vHosts. Also beispielweise:
            location ~ ^/owncloud/(?:\.|autotest|occ|issue|indie|db_|console) {
                        deny all;
                    }

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

          Man kann natürlich auch an einer beliebigen Stelle in den vHosts ein anderes Root-Verzeichnis setzen. Mache ich persönlich aber nicht so, ich habe nur einen Web-Root und sämtliche Webanwendungen liegen in den entsprechenden Unterverzeichnissen. Somit entspricht dann die vHost-„Struktur“ immer auch der Verzeichnisstruktur.

          Gruß,
          Jan

  • Ingo sagt:

    Hallo Jan,

    habe heute noch mall alles neu Installiert nach der Anweisung.
    Folgende Programmversionen wurden Installiert

    Ubuntu Server 16.04 LTS
    nginx 1.11.2
    MariaDB 10.0.25
    PHP 7
    ownCloud 9.0.3

    Da bei ist mir was aufgefallen beim Installieren von MariaDB wurde ich nach kein Password gefragt und es stand folgender Fehler da:

    E: Failed to fetch http://ftp.hosteurope.de/mirror/mariadb.org/repo/10.1/ubuntu/dists/xenial/main/source/Sources.gz Hash-Summe stimmt nicht überein

    E: Failed to fetch http://ftp.hosteurope.de/mirror/mariadb.org/repo/10.1/ubuntu/dists/xenial/main/binary-amd64/Packages.gz

    E: Einige Indexdateien konnten nicht heruntergeladen werden. Sie wurden ignoriert oder alte an ihrer Stelle benutzt.

    Ist das der Grund warum nur MariaDB 10.0.25 Installiert wurde?

    Und in bei der Konfiguration von MariaDB Fehlte der eintrag [mysqld] in der Datei /etc/mysql/my.cnf

    Habe ich dann eingefügt und auch binlog_format = MIXED

    Bei Zugriffsrechte anpassen Fehelt noch:
    chown -R www-data:www-data /var/www/owncloud/data/

    Dann habe ich zum Schluss noch die Sicherheit überprüft bekomme nur eine Wertung von A

    Liegt das an Fehlerhafte Installation von MariaDB?

    • Jan sagt:

      Hallo Ingo,

      hast du für die MariaDB-Installation mal einen anderen Mirror ausprobiert (kannst du im Repository Configuration Tool auf der rechten Seite wählen)? Wenn du die Paketquellen manuell in die sources.list eingefügt hast, diese aber nicht korrekt herunter gelanden werden können, dann werden als Fallback wohl die Pakete installiert, die mit 16.04 kommen.

      Die Überprüfung der Sicherheit hat nichts mit der Datenbank zu tun (auch wenn diese nicht korrekt installiert worden ist). Wenn hier eine niedrigere Wertung angezeigt wird, sollte dies in fast allen Fällen mit der Webserver-Konfiguration oder dem SSL-Zertifikat zu tun haben. Hier wäre noch wichtig zu wissen, was der SSL-Test als Grund angibt, warum „nur“ eine A-Wertung erzielt werden konnte.

      Gruß,
      Jan

  • Florian sagt:

    Vielen Dank erstmals für die tolle Anleitung. Ich habe allerdings noch ein Problem und zwar habe ich (wie in früheren Owncloud 8 mit Ubuntu 14.04 möglich war) von /var/owncloud_data/florian/files Symbolische Links auf /mnt/Externe gelegt. Die Rechte natürlich auf www:data angepasst.

    Ich sehe zwar alle Verzeichnisse und Files ABER habe keine Rechte darauf zuzugreifen.

    Weißt du vl. warum?

    Die Datei /etc/php/7.0/cli/php.ini habe ich ebenfalls erweitert
    open_basedir = /var/www/:/tmp/:/var/owncloud_data:/mnt/Externe
    wäre das überhaupt notwendig?

    Vielen Dank vorab!

    • Jan sagt:

      Hallo Florian,

      ich habe noch nicht getestet, ob ownCloud symbolische Links unterstützt. Wenn es bei dir aber schon einmal funktioniert hat, sollte das auch unter OC 9 gehen.
      Was sagen die Logdateien von ownCloud/nginx dazu? Vielleicht findest du hier einen Hinweis.

      Ansonsten fällt mir dazu spontan nur der Parameter disable_symlinks von nginx ein. Versuch doch mal disable_symlinks off; im virtuellen Host für ownCloud zu setzen (z.B. im Server-Block).

      Gruß,
      Jan

      • Florian sagt:

        Hallo Jan!

        Die Funktion disable_symlinks hat leider nichts gebracht.

        Nginx Error.log ist leer

        Im owncloud.log finde ich Einträge wie diesen
        {„reqId“:“ZMo4qtciBqrPTlPADmwy“,“remoteAddr“:“62.23.117.166″,“app“:“PHP“,“message“:“fopen(\/var\/owncloud_data\/florian\/files\/TEMP\/apache2.conf): failed to open stream: Operation not permitted at \/var\/www\/owncloud\/lib\/private\/files\/storage\/local.php#261″,“level“:3,“time“:“2016-07-11T09:18:34+00:00″,“method“:“GET“,“url“:“\/owncloud\/core\/preview.png?file=%2FTEMP%2Fapache2.conf&c=aed47d29b9540da46085f2338b93f936&x=32&y=32&forceIcon=0″,“user“:“florian“}

    • Marcus sagt:

      Hallo Florian,

      Ich meine gelesen zu haben, dass symbolische Links nicht mehr unterstützt werden der Sicherheit wegen. Du kannst aber einen Externen Storage (Lokal) erstellen ohne die Zuhilfenahme von Symlinks.
      Andernfalls solltest du nachsehen (ls -ls), ob dein nginx auch auf die Dateien zugreifen darf oder ob es deinem linux-Benutzer vorbehalten ist.

      open_basedir ist in Zeiten von php-fpm auch nicht mehr notwendig, viele Installationen haben damit Schwierigkeiten. In meiner Konfiguration habe ich open_basedir auskommentiert.

      • Florian sagt:

        Hallo Markus,

        habe den Fehler gerade eben gefunden in der site_owncloud musste auch open_basedir=/mnt/Externe hinzugefügt erwerden

        Jetzt funktionierts!

        Danke für die Hilfe!

        @ Jan wäre nettt das noch in der Anleitung zu erwähnen.

        • Jan sagt:

          Hallo Florian,

          schön, dass es nun bei dir funktioniert.
          Ich habe den Artikel aktualisiert und einen Hinweis bei open_basedir hinzugefügt. Damit sollte das nun leichter verständlich sein.

          Gruß,
          Jan

1 2 3 7

Schreibe einen Kommentar

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