DecaTec

Programmieren, Fotografie, Home-Server und einiges mehr

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

ownCloud Logo

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

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

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

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

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

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

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

Zielsetzung und Aufwand

Folgende Ziele sollen mit diesem Artikel erreicht werden:

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

Folgende Programmversionen kommen dabei zum Einsatz.

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

Zeitaufwand: ca. 3 Stunden

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

Warum die Kombination mit nginx und MariaDB Sinn macht

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

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

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

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

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

Voraussetzungen

Betriebssystem/Hardware

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

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

Zugriff per SSH

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

DynDNS

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

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

Arbeiten mit Root-Rechten

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

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

Genug der Vorrede, nun geht es endlich los…

Updates einspielen

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

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

Statische IP-Adresse zuweisen

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

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

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

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

Programm-Installation

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

nginx installieren

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

Hinweis für Raspberry Pi Benutzer

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

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

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

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

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

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

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

Nginx läuft auf dem Server

Nginx läuft auf dem Server

MariaDB installieren

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

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

Dann werden die Paketquellen hinzugefügt:

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

Nun kann die Datenbank installiert werden:

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

Root-Passwort für MariaDB vergeben

Root-Passwort für MariaDB vergeben

PHP installieren

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

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

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

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

Konfiguration des Servers

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

Konfiguration nginx (Teil 1)

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

Virtuelle Hosts und Konfigurations-Dateien von nginx

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

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

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

Sinnvolle Aufteilung in mehrere virtuelle Hosts

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

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

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

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

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

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

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

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

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

Allgemeine nginx-Konfiguration anpassen

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

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

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

Default-Seite deaktivieren

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

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

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

Vorbereitung der Verzeichnisstruktur

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

Anlegen des „Gateway-Hosts“

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

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

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

Hier fügen wir nun folgenden Inhalt ein:

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

Anlegen des Hosts für Let’s Encrypt

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

Dieser Host ist dabei sehr einfach aufgebaut:

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

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

SSL-Zertifikat mit Let’s Encrypt erzeugen

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

Port-Forwarding einrichten

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

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

  • Die Erweiterte Ansicht muss aktiv sein (Menü rechts neben den MyFritz! Einstellungen).
Menü zum Aktivieren der erweiterten Ansicht der FritzBox

Menü zum Aktivieren der erweiterten Ansicht der FritzBox

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

Portfreigabe in der FritzBox einrichten

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

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

Erzeugung eines SSL-Zertifikats mittels Let’s Encrypt

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

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

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

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

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

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

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

Erweiterte Sicherheit: Diffie-Hellman-Parameter

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

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

Zugriffsberechtigungen für Zertifikat-Dateien setzen

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

Erneuerung der Zertifikate nach 90 Tagen

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

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

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

Konfiguration nginx (Teil 2)

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

Gateway-Host für ownCloud vorbereiten

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

Die hinzugefügten Abschnitte sind markiert:

Virtuellen Host für ownCloud anlegen

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

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

Noch ein paar Erläuterungen zu dieser Konfiguration:

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

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

Konfiguration PHP

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

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

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

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

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

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

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

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

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

 Konfiguration MariaDB

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

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

Absichern der MariaDB-Installation

Absichern der MariaDB-Installation

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

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

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

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

Einrichtung ownCloud

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

Download

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

Download-Link für ownCloud

Download-Link für ownCloud

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

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

Anlegen der ownCloud-Datenbak

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

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

ownCloud-Setup

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

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

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

ownCloud Setup

ownCloud Setup

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

Warnungen im Admin-Bereich

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

Warnungen im Admin-Bereich der ownCloud

Warnungen im Admin-Bereich der ownCloud

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

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

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

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

Anpassung der ownCloud-Konfiguration

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

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

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

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

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

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

Zugriffsrechte anpassen

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

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

ownCloud Cronjob einrichten

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

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

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

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

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

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

Umstellung von AJAX auf Cron

Umstellung von AJAX auf Cron

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

Weitere Konfiguration der ownCloud

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

Überprüfung der Sicherheit

Qualys SSL Labs

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

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

SSL-Test der ownCloud-Installation

SSL-Test der ownCloud-Installation

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

ownCloud Vulerability Scanner/Nextcloud Security Scan

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

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

Zugriff auf die ownCloud über das lokale Netzwerk

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

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

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

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

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

Falls es doch einmal hakt…

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

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

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

Download Checkliste

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

Download Checkliste

Meine Daten gehören mir!

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

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

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

Weiterführende Artikel

Links

, , , , , , , , , ,

Kommentare: 520

  • Wolfram sagt:

    Ist es in Ordnung, dass die Rechte von 0750 auf 0770 geändert werden müssen, erst dann läuft dieOC?

    find /var/www/owncloud/ -type d -print0 | xargs -0 chmod 0770

    • Jan sagt:

      Hi,

      bei 0770 würde die Gruppe (des Webserver-Nutzers) auch Vollzugriff erhalten. Wüsste nicht, warum dies notwendig sein sollte.
      Läuft OC mit 0750 nicht richtig?

      Gruß,
      Jan

  • Wolfram sagt:

    Bei „0750“ wird angezeigt:
    Data directory (/var/www/owncloud/data) not writable by Owncloud
    Berechtigungen können normalerweise repariert werden, indem dem Webserver Schreibzugriff auf das Wurzelverzeichnis gegeben wird.

    Diese Berechtigung wird ja sicher über s.u. gesetzt:
    find /var/www/owncloud/ -type d -print0 | xargs -0 chmod 0750

    ls -l /var/www/
    drwxr-x— 15 root www-data 4096 Mär 6 22:18 owncloud

    ls -l /var/www/owncloud/
    drwxr-x— 29 root www-data 4096 Feb 1 19:45 3rdparty
    drwxr-x— 30 www-data www-data 4096 Mär 7 11:50 apps
    -rw-r—– 1 root www-data 8301 Feb 1 19:44 AUTHORS
    drwxr-x— 2 www-data www-data 4096 Mär 6 22:44 config
    -rw-r—– 1 root www-data 4136 Feb 1 19:44 console.php
    -rw-r—– 1 root www-data 34520 Feb 1 19:44 COPYING-AGPL
    drwxr-x— 17 root www-data 4096 Feb 1 19:45 core
    -rw-r—– 1 root www-data 5141 Feb 1 19:44 cron.php
    drwxr-x— 7 root www-data 4096 Mär 7 19:31 data
    -rw-r—– 1 root www-data 35830 Feb 1 19:44 db_structure.xml
    -rw-r—– 1 root www-data 179 Feb 1 19:44 index.html
    -rw-r—– 1 root www-data 3064 Feb 1 19:44 index.php
    drwxr-x— 3 root www-data 4096 Feb 1 19:44 l10n
    drwxr-x— 6 root www-data 4096 Feb 1 19:44 lib
    -rw-r—– 1 root www-data 283 Feb 1 19:44 occ
    drwxr-x— 2 root www-data 4096 Feb 1 19:44 ocs
    drwxr-x— 2 root www-data 4096 Feb 1 19:44 ocs-provider
    -rw-r—– 1 root www-data 3086 Feb 1 19:44 public.php
    -rw-r—– 1 root www-data 5428 Feb 1 19:44 remote.php
    drwxr-x— 4 root www-data 4096 Feb 1 19:44 resources
    -rw-r—– 1 root www-data 26 Feb 1 19:44 robots.txt
    drwxr-x— 11 root www-data 4096 Feb 1 19:44 settings
    -rw-r—– 1 root www-data 1893 Feb 1 19:44 status.php
    drwxr-x— 3 www-data www-data 4096 Feb 1 19:44 themes
    drwxr-x— 7 root www-data 4096 Feb 1 19:45 updater
    -rw-r—– 1 root www-data 233 Feb 1 19:44 version.php

    (Entschuldigung für die sicher simplen Fragen, ich bin ein sehr „junger“ Linuxnutzer)

    • Jan sagt:

      Hallo Wolfram,

      dein Daten-Verzeichnis liegt anscheinend direkt unter dem owncloud-Ordner owncloud/data. Empfohlen wird im Allgemeinen, dass das data-Verzeichnis nicht im owncloud-Ordner liegt (Sicherheits-Feature). Daher liegt es bei mir im Verzeichnis /var/owncloud_data.

      Ich würde bei dir erst einmal ein chown -R www-data:www-data /var/www/owncloud/data ausprobieren. Besitzer wäre dann www-data, der dürfte dann auch bei 0750 schreiben.
      Unter welchem User läuft nginx bei dir (wird in der Datei /etc/nginx/nginx.conf angegeben)?

      Gruß,
      Jan

  • Bernd sagt:

    Hallo,

    nach dem letzten nextcloud update geht bei mir der cron job nicht mehr 🙁

    wenn ich die cron.php direkt ausführe bekomme ich folgende fehlermeldung ausgegeben:

    root@ubuntu-server-nextcloud:/var/www/nextcloud# php -f /var/www/nextcloud/cron.php
    PHP Warning: require_once(): open_basedir restriction in effect. File(/var/www/nextcloud/lib/base.php) is not within the allowed path(s): (0) in /var/www/nextcloud/cron.php on line 42
    PHP Warning: require_once(/var/www/nextcloud/lib/base.php): failed to open stream: Operation not permitted in /var/www/nextcloud/cron.php on line 42
    PHP Fatal error: require_once(): Failed opening required ‚/var/www/nextcloud/lib/base.php‘ (include_path=‘.:/usr/share/php‘) in /var/www/nextcloud/cron.php on line 42

    hat jemand eine Ahung wie mann das beheben kann?

    Vielen lieben Dank für die Hilfe schon mal

    Gruß Bernd

    • Bernd sagt:

      bzw. könnte es auch das letzte php update gewesen sein…

    • Bernd sagt:

      php -i | grep „pdo“
      gibt mir folgendes aus:
      /etc/php/7.0/cli/conf.d/10-pdo.ini,
      /etc/php/7.0/cli/conf.d/20-pdo_mysql.ini,
      API Extensions => mysqli,pdo_mysql
      pdo_mysql
      pdo_mysql.default_socket => /var/run/mysqld/mysqld.sock => /var/run/mysqld/mysqld.sock

      php sollte passen oder?

      • Jan sagt:

        Hi Bernd,

        das letzte PHP-Update hat neue Standard-Configs mitgebracht. Er fragt normalerweise nach, ob er diese beim Update überschreiben soll, oder ob er die alten Configs behalten soll. Falls bei die die Standard-Configs genommen wurden: Überprüf doch mal sämtliche im Tutorial gezeigten Änderungen bzgl. PHP, besonderen in der CLI-Config (open_basedir).

        Gruß,
        Jan

  • René sagt:

    Hi,

    habe auch deine schöne Anleitung gefunden, aber leider hängt es bei mir an der Verbindung zwischen Nginx und PHP, es werden einfach keine php Seiten im Browser gezeigt. Die entsprechenden Dateien werden wie ein Download geöffnet.
    Habe z.B. den upstream php-handler direkt in die Gateway.conf gepackt auch schon probiert mit dem Path des php7.0-fpm.sock

    Wurde ggf. etwas geändert? Da ich eine ganz frische Installation gemacht habe.

    Danke und Grüße
    René

    • René sagt:

      So habs hinbekommen, irgendwie wurde der Owncloud Host nicht richtig angesprochen, nachdem das behoben war hatte ich noch den Fehler:

      unix:/run/php/php7.0-fpm.sock failed (13: Permission denied) while connecting to upstream

      Habe dann den Nutzer von nginx zu www-data geändert

      Jetzt läufts 🙂

      • Jan sagt:

        Hi René,

        super, dass du es hinbekommen hast.
        Der nginx-Nutzer ist nur ein kleines Zahnrad im ganzen System, aber umso wichtiger. Wenn man das vergisst, läuft der ganze Laden nicht und der Grund ist relativ scher heraus zu finden.

        Gruß,
        Jan

  • Stefan sagt:

    Hallo, kann ich beim direkten Aufrufen der URL die Meldung 403 Forbiden umgehen, das die Cloud direkt aufgerufen wird?
    z.B http://www.meineSeite.de/owbloud

    • Jan sagt:

      Hallo Stefan,

      leider verstehe ich nicht so ganz, wo dein Problem liegt.
      Ich will es aber mal versuchen: Du bekommst einen HTTP 403 beim Versuch, auf http://www.meineSeite.de/owncloud zuzugreifen. Dies spricht erst einmal dafür, dass hier etwas an der vHost-Konfiguration nicht so ganz passt. Irgendwo in deiner Config wird vermutlich ein deny all; stehen. Dies wird an dieser Stelle greifen und hier den Zugriff unterbinden.

      Gruß,
      Jan

      • Stefan sagt:

        Hallo Jan,

        habe mich vielleicht falsch ausgedrückt. Ich habe anhand deiner Beschreibungen meherer vHost’s angelegt, die auch alle super funktionieren.
        http://www.meineseite.de/nextcloud, /owncloud und /wordepress.

        Jetzt wollte ich es so anpassen, dass nach Eingabe von http://www.meineseite.de gleich der Login für z. B. die owncloud erscheint, ohne den Zusatz /owncloud.

        Ich weiss nicht ob das so einfach möglich ist.

        Schon mal vielen Dank.

        Gruss Stefan

        • Jan sagt:

          Hi Stefan,

          ok, jetzt verstehe ich dein Problem.
          Ist kein Problem: Such einfach im Gateway-vHost nach der Stelle, an dem der Zugriff auf das Root-Verzeichnis unterbunden wird:
          location = / {
          # Disable access to the web root, otherwise nginx will show the default site here.
          deny all;
          }

          Hier setzt du einfach ein Redirect auf die gewünschte Web-Anwendung (z.B. ownCloud):

          location = / {
          rewrite ^ /owncloud;
          }

          Gruß,
          Jan

  • Fixel sagt:

    Hallo jan,

    erst einmal ein großes Lob an dich! Super Anleitung die du hier bereit stellst!

    Anfangs hatte ich ein Paar Probleme, doch inzwischen war ich schon in der Owncloud Oberfläche.

    Anschließend habe ich allerdings die von dir empfohlenen Zugriffsrechte angepasst, seit dem geht nichts mehr! 🙁

    Dazu habe ich hier schon einen ähnlichen beitrag gesehen, da war wohl die Lösung den User Owncloud zur Gruppe www-data hinzuzufügen.

    Ich wüsste aber nicht, dass ich den User owncloud überhaupt erstellt habe.

    Wäre super, wenn du auf die schnelle weißt, wie ich mein Rechte-Problem wieder in den Griff kriege!

    Zusärtlich werde ich immer auf die intere IP des Raspis weitergeleitet, wenn ich versuche über meine Domain zur connecten 😮

    Das ist natürlich schlecht, da ich aus dem Internet diese Adresse nicht erreichen kann.

    Also so –> https://meineDomain.de –> https://192.168.1.88

    Habe mich hiermit noch nicht näher beschäftigt, wäre aber auch super, wenn du da eine Lösung hättest!!!

    Gruß und vielen Dank Fixel

    • Jan sagt:

      Hi Fixel,

      zu deinem ersten Problem: Der User, unter dem alles läuft (v.a. nginx), ist nicht „owncloud“, sondern „www-data“. Daher solltest du den User, unter dem nginx läuft, mal kontrollieren. Zu finden ist dies in der Datei /etc/nginx/nginx.conf („user“). Dieser Punkt wird häufig übersehen und ist immer mal wieder die Ursache für verschiedenste Probleme.

      Zum Redirect auf die LAN-IP: Wenn ich das richtig sehe, hat das nichts mit der Weiterleitung HTTP > HTTPS zu tun, da du ja bereits die HTTPS-Adresse aufrufst. Ist (im Gateway-Host) unter server_name auch die DynDNS-Adresse angegeben?
      Falls ja, wäre es mal interessant, wo dieser Redirect herkommt. Ich nutze dazu gern die Developer-Console von Chrome (F12). Dann einfach die URL aufrufen und Chrome zeigt dir jeden einzelnen Schritt, der bei der Abarbeitung des Requests ausgeführt wird. Vielleicht ist hier ein Hinweis auf das Problem zu finden.

      Gruß,
      Jan

      • Fixel sagt:

        Hi,
        irgendwie ist mein geposteter Beitrag hier nicht zusehen, deswegen schreibe ich nochmal kurz was ich bereits getan habe.

        Zum Problem 1.)

        nginx läuft bereits mit dem user www-Data.

        Wie schon bereits gesagt hatte ich schon zugriff auf OC, bis ich die Rechte nach deiner Anleitung beschrieben erneut angepasst habe.

        Deswegen meine Vermutung, dass das wohl mit den zuletzt eingestellten Rechten zusammen hängen muss.

        Problem 2.)

        Ich muss mich korriegieren, anders als gesagt werde ich auf die Intere IP adresse nur umgeleitet, wenn ich über http mit nginx kommuniziere. Wenn ich über https gehe, kriege ich die Webseite angezeigt, bzw 403 Forbidden. Auch das schöne Gründe Schloss, was sagt das die verbindung sicher ist, ist zu sehen!

        So meine Annahme, dass das wohl doch mit dem weiterleiten von HTTP zu HTTPS zusammenhängen muss.

        Danke für deine Hilfe und ein schönes Wochenende,
        Fixel

        Ergänzung:
        Auch die DynDns Adresse ist im Gateway Host unter server_name zusammen mit der Internen IP angegeben.

        • Jan sagt:

          Hi Fixel,

          ich war mal so frei und habe deine Kommentare zusammengefügt. Dein erster Kommentar ist leider im Spamfilter hängen geblieben (warum auch immer). Falls so etwas nochmal passieren sollte, einfach etwas abwarten, ich gebe solche Kommentare dann manuell frei.

          1. Problem mit den Zugriffsrechten:
          Ob es wirklich mit dem Rechten zu tun hat, kannst du überprüfen, wenn du die Anpassungen rückgngig machst:
          chown –R www-data:www-data /var/www/owncloud
          chown –R www-data:www-data /var/www/oc_data

          Wenn es danach immer noch nicht laufen sollte, haben die Rechte mit dem Fehler nichts zu tun.
          Wie dem auch sei, das Problem kann man vermutlich nur anhand der Log-Dateien des Webservers nachvollziehen. Dazu könntest du mir mal die Datei /var/log/nginx/error.log schicken, dann schau ich da mal drüber.

          2. Fehlerhafte Weiterleitung:
          OK, wenn es bei der Weiterleitung HTTP > HTTPS hakt, sieht die Lösung wohl recht einfach aus: Einfach im Gateway-Host (bei der HTTP-Server Definition) die Weiterleitung anpassen (erster Block mit „return 301…“ auskommentiert, den Kommentar beim zweiten entfernt):
          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;
          }

          Nun sollte er immer auf die DynDNS-Adresse weiterleiten. Ich kann dir leider nicht genau sagen, warum die erste Weiterleitung nicht so funktioniert wie gedacht, da ich dieses Szenario lokal bei mit nicht nachstellen kann. Einziger Nachteil dieser Lösung: Ein Zugriff über die LAN-IP ist nun nicht mehr möglich (außer direkt über HTTPS). Das sollte aber eigentlich auch kein Problem darstellen, da man normalerweise immer über die DynDNS-Adresse gehen sollte, da für diese ja das SSL-Zertifikat ausgestellt wurde. Mit dem Zugriff über die lokale IP erhält man wieder Warnungen im Browser, etc.

          Ich wünsche auch ein schönes Wochenende.

          Gruß,
          Jan

  • Andi sagt:

    Nach dem Anlegen des „Gateway-Hosts“, kann man nginx nicht neustarten.
    Es kommt der Fehler:
    root@odroid64:~# service nginx restart
    Job for nginx.service failed because the control process exited with error code. See „systemctl status nginx.service“ and „journalctl -xe“ for details.

    Problem dabei ist, dass nun nginx nicht mehr erreichbar ist – also auch nicht die default-Seite von ngnix.
    Damit ist dann auch gleichzeitig das ausstellen des SSL Zertifikats nicht möglich:
    Failed authorization procedure. domain.de (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to domain.de

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

    Domain: domain.de
    Type: connection
    Detail: Could not connect to domain.de

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

    Irgendwelche Ideen dazu?

    Lieben Gruß,
    Andi

    • Jan sagt:

      Hi Andi,

      das liegt in vielen Fällen an einem Fehler in den virtuellen Hosts. Meistens ist das nur ein Tippfehler und kann schnell beseitigt werden.
      Warum nginx nicht mehr startet, findest du mit dem Befehl nginx -t heraus. Hier wird dir die fehlerhafte Config und auch eine genaue Zeilennummer genannt.

      Gruß,
      Jan

  • Axel sagt:

    Hallo, eine super Anleitung!
    Eine Frage habe ich aber noch: nach dieser Anleitung habe ich alles eingerichtet und es funktioniert auch so weit. Ich muß Owncloud jetzt so aufrufen: meine-lokale-ip/owncloud oder meine-externe-ip/owncloud. Was muß ich tun, damit ich die externe IP ohne Zusatz „/owncloud“ aufrufen kann und trotzdem direkt auf die Owncloud-Seite geleitet werde?
    Gruß
    Axel

    • Jan sagt:

      Hi Axel,

      da ist nur eine minimale Änderung notwendig:
      Such einfach im Gateway-vHost nach der Stelle, an dem der Zugriff auf das Root-Verzeichnis unterbunden wird:
      location = / {
      # Disable access to the web root, otherwise nginx will show the default site here.
      deny all;
      }

      Hier setzt du einfach ein Redirect auf die gewünschte Web-Anwendung (z.B. ownCloud):

      location = / {
      rewrite ^ /owncloud;
      }

      Ich denke, ich werde hierzu noch einen Hinweis im Artikel mit aufnehmen, da diese Frage schon häufiger gestellt wurde.

      Gruß,
      Jan

  • Volker sagt:

    Hallo Jan, eine super Anleitung!
    Ich hatte vor 10-15 Jahren die letzte Befassung mit Linux.
    Konnte mich an vieles erinnern.
    Deine Ausführungen sind super klasse. Ich habe ca.95% verstanden.
    Vielen herzlichen Dank für deine Arbeit und Mühe.
    Bei mir läuft jetzt eine ownCloud !!!!!!
    Danke. Danke. Danke ……

  • Marcus Drinhaus sagt:

    Hallo Gemeinde
    Nutze die oben beschriebene Installation und ich muss sagen läuft super, jedoch stellt sich mir die Frage ob man die letsencrypt aktualisierung der 90 Tage auch automatisieren kann damit man sich darum nicht mehr kümmern muss?
    Dafür fehlt mir jedoch das wissen.

    Gruß drini

  • Paule sagt:

    Hammer! Schnurpelt erste Sahne – hätte ich never ever so allein hinbekommen. Fettes *DANKE*!!!

  • Bernd sagt:

    Hallo,

    falls jemand Android 7 und z.B. Davdroid zum synchronisieren einsetzt, muss eine kleinigkeit ändern.

    und zwar:
    im Gateway Host folgende Zeile auskommentieren
    ssl_ecdh_curve secp384r1;
    und diese dafür einfügen:
    ssl_ecdh_curve auto;

    Problem ist hier nicht die Serverconfig, sondern ein Bug in Android 7.

    evtl hilft es jemandem.

    Gruß Bernd

    • Jan sagt:

      Hi Bernd,

      danke für den Hinweis.
      Leider macht die Einstellung ssl_ecdh_curve immer mal wieder Probleme. Komisch, dass es gerade hier bei Android 7 einen Bug gibt.

      Gruß,
      Jan

  • Elies sagt:

    Hi Jan!

    Super Anleitung!
    Bis auf eine Sache klappt auch alles. Beim aufrufen von http://www.meineDomäääne.de werde ich auf eine Seite weitergeleitet wo dann steht: Diese vebrindung ist nicht sicher.
    Wenn ich https://meinedomäääne.de/ komme ich drauf mit https.
    Hast du eine Ahnung woran das liegt?

    LG
    Elies

    • Jan sagt:

      Hi Elies,

      eigentlich sollte der Aufruf mit HTTP automatisch auf die (sichere) Verbindung mit HTTPS weiterleiten.
      Wenn du über HTTP gehst und die Meldung wegklickst: Was für ein Zertifikat wird dir hier angezeigt (z.B. beim IE auf das Schloss-Symbol und auf Zertifikate anzeigen klicken). Ist das dein (Let’s Encrypt) Zertifikat?

      Gruß,
      Jan

      • Elies sagt:

        Sorry ich habe mich flasch ausgedrückt. Ich würde gerne auf https://meine domäääne.de kommen auch wenn ich www im web browser eingebe.
        Das ist ja eigentlich eine Subdomain…Wenn ich die Seite mit www davor aufrufe kommt : Unsichere Verbindung bla bla.
        Ist ja eigentlich auch klar, da das Cert nicht für www ausgestellt wurde. Gibt es dennoch die möglichkeit das man sich vom www direkt weiterleiten lassen kann?

        • Jan sagt:

          Hi Elies,

          ok, verstehe. Das dürfte durch eine kleine Änderung in der HTTP Server-Konfiguration möglich sein:
          server {
          listen 80 default_server;
          server_name meineDomäääne.de www.meineDomäääne.de 192.168.178.20;

          root /var/www;
          ...

          Dann werden die Domains meineDomäääne.de und www. meineDomäääne.de gleich behandelt, nämlich mit einem Redirect auf die HTTPS-Adresse.

          Gruß,
          Jan

          • Elies sagt:

            Das habe ich bereits ausprobiert in meiner meinedomääne.de.conf datei.
            Nachdem ich das gemacht habe und mal den cache vom browser gelöscht habe wurde ich tatsächlich korrekt weiter geleitet. Tab geschlossen und ein zweites mal ausprobiert: nicht mehr korrekt weiter geleitet. Das selbe wie vorher: Diese Verbindung ist nicht sicher. Vielleicht sollte ich erwähnen das die www Domäne nicht existiert. Möchte lediglich das man meine Cloud auch mit dem www vorangesetzt erreichen kann.

          • Jan sagt:

            Hallo Elies,

            komisch, dass das nur einmal funktioniert. Die www-Domäne existiert, sobald du diese in einem vHost deklarierst.
            In dem Fall wo es nicht klappt: Auf welche HTTPS-Domäne wirst du weitergeleitet (https://meinedomääne.de oder https://www.meinedomääne.de)? Um zu sehen, was hier genau abläuft, kannst du auch die Developer-Console von Chrome verwenden (F12). Hier werden alle Weiter- und Umleitungen visualisiert – hat mir schon öfter geholfen, wenn nicht wirklich klar war, was „unter der Haube“ passiert.

            Noch eine Frage: Willst du, dass die Cloud auch über https://www.meinedomääne.de erreichbar ist? In diesem Fall musst du auf jeden Fall ein weiteres Let’s Encrypt Zertifikat für die www-Domäne erzeugen (also pro Subdomain ein Zertifikat). Anschließend müsstest du auch zwei https-server-Blöcke im vHost definieren und die korrekten Zertifikate einbinden. Damit sich der Rest gleich verhält, sollten alle anderen Anweisungen (des https-Blocks) in eine separate conf-Datei ausgelagert werden und in beiden https-server-Blöcken inkludiert werden.

            Gruß,
            Jan

          • Elies sagt:

            Ich werde auf https://www.meinedomääne.de weitergeleitet.

            Ich möchte meine Website nicht über eine weiter Adresse erreichbar machen. Ich möchte nur das man weitergeleitet wird wenn man www im Browser vorher ein gibt.

            Das mit der Developer console probiere ich später Mal aus

          • Jan sagt:

            Hi Elies,

            das sollte eigentlich nicht passieren (die Weiterleitung auf https://www…), hier sollte eigentlich auf https://meineDomäääne.de verwiesen werden. Hintergrund: Die Reihenfolge der Definitionen bei server_name meineDomäääne.de http://www.meineDomäääne.de 192.168.178.20; ist wichtig. Die später verwendete Variable $server_addr sollte immer auf die erste Adresse unter server_name aufgelöst werden (also meineDomäääne.de – ohne www).

            Wenn es für dich in Ordnung ist, dass du dann nicht mehr über die lokale IP auf deine Cloud kommst (sondern immer nur über die DynDNS-Adresse), kannst du den redirect auch mal folgendermaßen anpassen:
            return 301 https://$server_name$request_uri;

            Wenn das auch noch nichts bringt, dann hilft wohl nur eine „feste Verdrahtung“:
            return 301 https://meineDomäääne.de$request_uri;

            Dies sollte dann auf jeden Fall klappen.

            Gruß,
            Jan

          • Elies sagt:

            Vielleicht noch ganz interessant: Chrome Console:

            General:
            Request URL:http://www.datafixundfertig.de/
            Request Method:GET
            Status Code:307 Internal Redirect
            Referrer Policy:no-referrer-when-downgrade

            Response Header:
            Location:https://www.datafixundfertig.de/
            Non-Authoritative-Reason:HSTS

          • Elies sagt:

            Feste Verdrahtung bringt leider auch kein Erfolg.
            Hier mal der Ausschnit aus /etc/nginx/conf.d/meinedomääne.de.conf:

            server {
            listen 80 default_server;
            server_name datafixundfertig.de http://www.datafixundfertig.de 192.168.178.44;

            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://datafixundfertig.de$request_uri;
            }
            }

          • Jan sagt:

            Hi Elies,

            da hat sich noch ein kleiner Fehler eingeschlichen. Die http-server-Definition muss so aussehen (kein „http://“ im server_name):
            server {
            listen 80 default_server;
            server_name datafixundfertig.de www.datafixundfertig.de 192.168.178.44;
            ...

            Also ich war mal so frei und habe auch mal mit Chrome die URL (http://www…) aufgerufen: Bei mir funktioniert es – ich werde auf https://… (ohne www) weitergeleitet. Das Problem kann ich also nicht ganz nachvollziehen.

            Gruß,
            Jan

          • Elies sagt:

            Ich fasse mal zusammen:

            Chrome developer Console :

            Generel:
            Request URL:http://www.datafixundfertig.de/
            Request Method:GET
            Status Code:307 Internal Redirect
            Referrer Policy:no-referrer-when-downgrade

            Response Header:
            Location:https://www.datafixundfertig.de/
            Non-Authoritative-Reason:HSTS

            Mit dieser Konfiguration funktioniert es nicht:

            server {
            listen 80 default_server;
            server_name meine domääne.de http://www.meinedomääne.de 192.168.x.x;

            root /var/www;

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

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

            # Use this if you always want to redirect to the DynDNS address (no local access).
            return 301 https://meinedomääne$request_uri;
            }
            }
            .
            .
            .
            Server {
            listen 443 ssl http2;
            .
            .
            .

          • Jan sagt:

            Hi,

            wie gesagt: hier das „http://“ raus:
            listen 80 default_server;
            server_name meine domääne.de http://www.meinedomääne.de 192.168.x.x;

            Und der fest verdrahtete Redirect muss so aussehen (hier fehlt „.de“):
            return 301 https://meinedomääne.de$request_uri;

            Gruß,
            Jan

          • Elies sagt:

            Ja beim ersten Aufruf der Website nachdem ich die Browserdaten gelöscht habe, funktioniert es auch. Bei einem zweiten aufruf über http://www.datafixundfertig.de kommt wieder die unsichere Verbindung.

          • Elies sagt:

            server {
            listen 80 default_server;
            server_name datafixundfertig.de http://www.datafixundfertig.de 192.168.x.x;

            root /var/www;

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

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

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

            Kein erfolg beim zweiten aufruf der Seite mit http://www...

            Vielleicht setze ich alles nochmal neu auf.

            Gruß
            Elies

          • Elies sagt:

            Das „http://“ ist nicht bei Server_name…keine ahnung warum die kommentar Funktion davor ein „http://www“ macht.
            In meiner Konfig ist auf jeden fall bei Server_name NUR www ohne http

          • Jan sagt:

            Hi,

            ok, dann ist das wohl ein WordPress-Automatismus mit dem http:// 😉

            Vielleicht setze ich alles nochmal neu auf.

            Das würde vermutlich helfen, auch wenn es wohl ziemlich aufwendig ist.

            Du könntest nochmal die nginx-Logs prüfen, vielleicht steht hier was drin, womit wir was anfangen können.

            Gruß,
            Jan

          • Elies sagt:

            Hier mal ein auszug vom error.log nach dem Aufruf der Seite:

            2017/04/20 10:59:22 [warn] 2036#2036: *842 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/6/02/0000000026 while reading upstream, client: 217.110.63.164, server: datafixundfertig.de, request: „GET /owncloud/core/vendor/backbone/backbone.js?v=4911ecb4c5f15ca9afe434774bffb338 HTTP/2.0“, upstream: „http://127.0.0.1:82/owncloud/core/vendor/backbone/backbone.js?v=4911ecb4c5f15ca9afe434774bffb338“, host: „datafixundfertig.de“
            2017/04/20 10:59:22 [warn] 2036#2036: *842 an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/7/02/0000000027 while reading upstream, client: 217.110.63.164, server: datafixundfertig.de, request: „GET /owncloud/core/js/js.js?v=4911ecb4c5f15ca9afe434774bffb338 HTTP/2.0“, upstream: „http://127.0.0.1:82/owncloud/core/js/js.js?v=4911ecb4c5f15ca9afe434774bffb338“, host: „datafixundfertig.de“
            2017/04/20 11:00:28 [warn] 2036#2036: no resolver defined to resolve ocsp.int-x3.letsencrypt.org while requesting certificate status, responder: ocsp.int-x3.letsencrypt.org, certificate: „/etc/letsencrypt/live/datafixundfertig.de/fullchain.pem“

          • Jan sagt:

            Hi,

            alles nichts auffälliges. Zumindest hat das nichts mit dem falschen Redirect zu tun.

            Mich wundert nur nach wie vor, dass ich das Problem nicht nachvollziehen kann. Sowohl bei Chrome, als auch bei IE funktioniert der Redirect wie erwünscht.

            Gruß,
            Jan

            Edit: Gerade nochmal probiert: Nun bekomme ich auch die Warnung in Chrome („NET::ERR_CERT_COMMON_NAME_INVALID“). Das liegt wohl daran, dass von http://www… auf https://www… weitergeleitet wird.

          • Elies sagt:

            Komisch da der Redirect ja nicht auf https://www…weiterleiten soll sondern nur auf https://

          • Elies sagt:

            Ich habe eine Lösung gefunden für alle die es Interessiert:

            Im HTTPS host gibt es die stelle: add_header Strict-Transport-Security „max-age=63072000; includeSubdomains; preload“;

            Wenn man diese auskommentiert, wird man IMMER korrekt weiter geleitet.
            Vielleicht muss man diese zeile nicht unbedingt auskommentieren sondern nur die Parameter ändern. Das kann ich aber nicht sagen.

            LG
            Elies

          • Jan sagt:

            Hi Elies,

            oh, da hat dir HSTS einen Strich durch die Rechnung gemacht. Das hatte ich gar nicht auf dem Schirm. Durch diese Anweisung im vHost wird gesteuert, dass der Server immer einen sog. „Strict-Transport-Security“ Reader mitsendet. Das sagt dem Client (Browser) dann, dass er immer auf die hier angegebene Adresse verbinden soll – egal, ob vom Server noch andere Redirects oder so gesendet werden. Wie lange dieser Zustand angegeben wurde, wird in Sekunden angegeben (die große Zahl).

            Soviel zum Hintergrund. Warum das Ganze bei dir nun zum nicht nachvollziehbaren Redirect geführt hat, liegt vermutlich daran, dass beim allerersten Aufruf ein falscher Redirect konfiguriert war. Danach hat der Browser auf die anderen Redirect-Versuche einfach nicht mehr „gehört“.

            Aber: Auch wenn es nun scheinbar funktioniert, würde ich diese Zeile nicht einfach auskommentieren. HSTS ist ein wichtiges Sicherheits-Feature des Webservers und sollte auf jeden Fall aktiviert bleiben.

            Ich habe aber einen Weg gefunden, das „HSTS-Gedächtnis“ von Chrome zu löschen. Dazu einfach chrome://net-internals/#hsts in die Adresszeile eingeben. Ganz unten unter Query domain kannst du mal deine Domain eintragen. Hier sollte er anschließend „Found“ melden.
            Wenn du die Domain nun in das Feld Delete domain einträgst, kannst du alle HSTS-relevanten Infos löschen.

            Wenn du nun http://www.datafixundfertig.de aufrufst, sollte der Redirect wie erwartet funktionieren.

            Sorry, dass ich da nicht eher draufgekommen bin. Werde es aber mal im Hinterkopf behalten.

            Gruß,
            Jan

          • Elies sagt:

            Ja hab ich mir gedacht, dass es nicht ganz unwichtig ist.
            Würde es reichen an der stelle include Subdomains raus zu nehmen?
            add_header Strict-Transport-Security „max-age=63072000; includeSubdomains; preload“;

            Ohne IncludeSubdomains funktioniert es nämlich auch.

            LG
            Elies

          • Jan sagt:

            Hi,

            Ja, das includeSubdomains kann man notfalls rausnehmen. Ist immerhin noch besser, als HSTS komplett zu deaktiviere.

            Hat der Trick mit Chrome nicht geklappt?

            Gruß,
            Jan

          • Elies sagt:

            Doch der Trick mit dem Chrome hat geklappt! Nur bin ich eingefleischter Firefox User 😛
            Vielen vielen Dank für deine Denkanstöße bezüglich redirect etc. Klasse Sache!

            LG
            Elies

          • Jan sagt:

            Hi,

            Kein Problem, hier gibt’s eine Anleitung, wie man das gleiche bei Firefox machen kann.
            Dann kannst du auch wieder includeSubdomains in die Konfiguration mit aufnehmen und bist so auf der sicheren Seite.

            Gruß,
            Jan

          • Elies sagt:

            Ah super danke!
            Wäre natürlich super wenn auch wer anders ohne diese Browser Konfiguration vernünftig weitergeleitet wird wenn man versucht die Seite mit www auf zu rufen. Irgend eine dauerhafte Lösung muss es ja geben ohne seinen Browser zu modifizieren

            LG
            Elies

          • Jan sagt:

            Hi Elies,

            diesen „Trick“ mit dem Löschen der HSTS-Daten musst du nur auf den Browsern ausführen, die (ursprünglich) mal durch einen falschen Redirect umgeleitet wurden. Wenn deine Cloud noch nicht „live“ ist, sollten das nur deine Browser sein.
            Wenn die Weiterleitung nun korrekt eingerichtet ist, und ein Browser das erste Mal Kontakt mit deiner Website hat, ist nichts weiter zu tun. Hier sollte alles ohne weiteren Eingriff funktionieren.

            Gruß,
            Jan

          • Elies sagt:

            Achso dann klappt der redirect return 301 also?
            Hab gedacht da gäb es dauerhafte konflikte mit hsts.
            Aber gut dann sollte der Redirect ja mit der eintragung http://www.datafixundfertig.de im http host, klappen.

            LG
            Elies

          • Elies sagt:

            Also ich hab das jetzt mal mit firefox und chrome gemacht und mein redirect korrekt eingerichtet. Wird weiterhin ein mal korrekt weitergeleitet und ein zweites mal dann wieder nicht. So als würde der redirect einfach ignoriert werden.

  • Elies sagt:

    Ja hab ich mir gedacht, dass es nicht ganz unwichtig ist.
    Würde es reichen an der stelle include Subdomains raus zu nehmen?
    add_header Strict-Transport-Security „max-age=63072000; includeSubdomains; preload“;

    Ohne IncludeSubdomains funktioniert es nämlich auch.

    LG
    Elies

  • Wolfram sagt:

    Bei der Installation von MariaDB auf einer Raspberry Pi3 mit Ubuntu Mate 16.04.2 LTS stolpere ich über diesen Fehler:

    root@raspwa-pi:~# apt-get install mariadb-server
    Paketlisten werden gelesen… Fertig
    Abhängigkeitsbaum wird aufgebaut.
    Statusinformationen werden eingelesen…. Fertig
    Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass
    Sie eine unmögliche Situation angefordert haben oder, wenn Sie die
    Unstable-Distribution verwenden, dass einige erforderliche Pakete noch
    nicht erstellt wurden oder Incoming noch nicht verlassen haben.
    Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen:

    Die folgenden Pakete haben unerfüllte Abhängigkeiten:
    mariadb-server : Hängt ab von: mariadb-server-10.1 (= 10.1.22+maria-1~xenial) ist aber nicht installierbar
    E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte Pakete.

    Hat jemand eine Idee?

    • Jan sagt:

      Hallo Wolfram,

      hast du vor der Installation deine sources.list modifiziert? Falls ja, mimm diese Stelle mal wieder raus:
      # 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

      Danach nochmal ein apt-get install mariadb-server
      Kann sein, dass du hier nicht die aktuellste Version von MariaDB bekommst (welche in den offiziellen Paketquellen enthalten ist), aber die Installation sollte durchlaufen.

      Hintergrund: Wie man in der sources.list sieht, fehlt hier unter arch= eine Definition für ARM. Diese wäre beim Raspi allerdings notwendig.

      Gruß,
      Jan

  • Wolfram sagt:

    Danke für ie Hilfe – es funktioniert. Es wurde die Version 10.0.29 installiert.

  • McG sagt:

    Hallo Jan,
    ich habe Deine Anleitung befolgt und OC läuft.
    Leider meckern die Browser über das Sicherheitszertifikat.
    Dies ist keine sichere Verbindung

    Dieser Server konnte nicht beweisen, dass er XXX.XXX.XXX.XXX ist. Sein Sicherheitszertifikat stammt von meineURL.goip.de. Mögliche Gründe sind eine fehlerhafte Konfiguration oder ein Angreifer, der Ihre Verbindung abfängt.

    Was muss ich ändern?

    Danke und guten Gruß 😉

    McG

    • Jan sagt:

      Hi,

      hier stimmt vermutlich etwas an den Redirects nicht. Daher brauche ich etwas mehr Info:

      • Welche URL rufst du genau im Browser auf?
      • Auf welche URL passiert der Redirect?

      Um besser zu erkennen, was genau abläuft (Redirects, etc.), kannst du die Developer-Console in Chrome verwenden (Shortcut: F12). Hier wird jeder Request und Response aufgelistet. Vermutlich kann man so besser erkennen, wo es hier hakt.

      Gruß,
      Jan

  • Wolfram sagt:

    Hallo Jan!
    Habe die Installation auf einer RaspberryPi3 abgeschlossen. Beim Start von Owncloud erschein nun der Fehler:

    „Es scheint, dass diese Owncloud-Instanz unter einer 32.bit-PHP-Umgebung läuft und open_basedir in der Datei php.ini konfiguriert worden ist. Von einem solchen Betrieb ist abzuraten, weil es dabei zu Problemen mit Dateien kommt, deren Größe 4 GB übersteigt. Bitte entferne die open_basedir-Einstellung in deiner php.ini oder wechsele zu 64-Bit-PHP.“

    Testweise habe ich die „open_basedir“-Def. unter fpm und cli wieder raus genommen und php neu gestartet – der Fehler erscheint trotzdem.

    Was sollte ich tun? Das Dateien >4GB unter 32bit nicht funktionieren, damit habe ich gerechnet. Was soll der Hinweis, open_basedir zu entfernen?

    Danke für die Hilfe sagt Wolfram

    • Jan sagt:

      Hi Wolfram,

      diese Meldung ist etwas verwirrend und sagt eigentlich nur aus, dass du keine Dateien >4GB hochladen kannst (Beschränkung eines 32 Bit Dateisystems). Dieses „Problem“ ist allerdings unabhängig von open_basedir. Daher kannst du diese Meldung ruhig ignorieren.

      Falls du open_basedir dennoch entfernen möchtest, musst du das auch im ownCloud-vHost nachziehen, da hier die Werte aus der php.ini überschrieben werden:
      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";

      Gruß,
      Jan

  • Carlsson sagt:

    Hallo Jan,

    wunderbares Tutorial (tatsächlich eines der wenigen, dass sogar ich als Linux-Laie verstehe). Gut geschrieben und recht motivierend, sodass auch ich mich dran versuche.

    Allerdings bin ich schon bei der Auswahl des richtigen Images gescheitert. Ich habe für meinen Raspberry 3 das Image „ubuntu-16.04-preinstalled-server-armhf+raspi3.img.xz“ benutzt.
    Schon nach „sudo apt-get update && sudo apt-get upgrade“ und dem anschließenden Reboot landet der Pi in einer Schleife und kommt gar nicht erst zum Login.

    Weiß nicht, ob Links hier erlaubt sind, falls nicht erwünscht, also bitte löschen –
    mein Fehler ist so ziemlich dieser hier:
    https://raspberrypi.stackexchange.com/questions/61342/raspberry-pi-3-ubuntu-16-04-server-upgrade-error

    Also habe ich versucht das ganze über Raspbian/Debian Jessie („2016-09-23-raspbian-jessie-lite.zip“) versucht. Das hat auch soweit gut funktioniert, bis auf dass ich im weiteren Verlauf wahrscheinlich viele Anpassungen vornehmen müsste.
    Das fängt schon an bei der Deaktivierung der default-Site des nginx-Servers „mv /etc/nginx/conf.d/default_disabled“.
    Ich denke, es hat was damit zu tun, dass „conf.d“ bei dieser Konstellation gar nicht benutzt wird, sondern die Ordner „sites-available“ etc. . (Und ich denke, deswegen funktionierte der Befehl „mv“ auch nicht so wie er sollte und wollte ein weiteres Argument).

    Um nicht jedes Mal bei solchen Stellen gefühlt 15 Tabs zur Recherche öffnen zu müssen, würde ich gerne den ursprünglichen Fehler beseitigen und es nochmals in deiner Konstellation und mit Ubuntu Server Classic 16.04. LTS probieren. Die auf der oben angegebenen Seite vorgeschlagene Lösung der Änderung der config.txt scheint mir eventuell später weitere Probleme auszulösen und nicht das Problem ansich zu beheben.

    Gibt es hier eine andere Lösung? Vielen Dank im Voraus für eine Beantwortung.

    Grüße,
    Carlsson

    • Jan sagt:

      Hi Carlsson,

      also ich nutze momentan keine RasPi und habe hier auch nur Erfahrungen mit dem Standard-Debian-OS für den Pi. Was das Problem mit Ubuntu auf dem RasPi ist, kann ich dir leider nicht sagen.

      Wegen dem nicht vorhandenen Verzeichnis mit den vHosts: In verschiedenen nginx Versionen orientiert man sich sehr an Apache: Es gibt zwei Verzeichnisse (/etc/nginx/sites-available/ und /etc/nginx/sites-enabled/). Die vHosts, die geladen werden sollen, befinden sich hier im sites-enabled Ordner, die nicht zu ladenden vHosts in sites-available. Die Dateiendungen spielen hier keine Rolle, deshalb funktioniert an dieser Stelle keine Deaktivierung durch Umbenennung. Um einen vHost zu deaktivieren, darf dieser nicht in /etc/nginx/sites-enabled/ gespeichert sein. Das ist alles.

      Gruß,
      Jan

  • Robert sagt:

    Top Anleitung

    Als Linux Neuling musste ich mich ganz schön belesen und informieren über die ganzen Befehle doch ich habe es geschafft meine Probleme und Fehler zu finden und jetzt lauft Owncloud sogar mit PHP7 auf denn Raspberry Pi 3 und mit einer Externer Festplatte.

    mfg

    Robert

  • Michael sagt:

    Moin Moin, die Anleitung ist super, nur habe ich folgendes Problem. Ich möchte das Datenverzeichniss auslagern. Aber egal, was ich mache, es kommt die Meldung Das Datenverzeichniss /cloud/owncloud_data/ kann nicht erstellt oder es kann darinn nicht geschrieben werden.

    Rechte sind gesetzt und der Pfad ist in der php.ini gesetzt. Nu bin ich ratlos

    • Jan sagt:

      Hi Micheal,

      ich denke, dass der Pfad nicht ganz korrekt ist: probier es doch mal mit /var/cloud/owncloud_data oder /var/owncloud_data. Des weiteren braucht der Webserver-User die entsprechenden Rechte (chown -R www-data:www-data /var/owncloud_data/).

      Gruß,
      Jan

      • Michael sagt:

        Danke für die schnelle Antwort. Ich habe das jetzt mal umgestellt und Rechte vergeben. Nun kommt

        Daten-Verzeichnis (/var/owncloud_data/) ist ungültig
        Bitte stelle sicher, dass das Datenverzeichnis auf seiner ersten Ebene eine Datei namens „.ocdata“ enthält.

        Die Pfade in der php.ini habe ich auch angebasst und php sowie ngingx neu getartet. Nur die Datei finde ich nicht.

        • Michael sagt:

          Habe den Fehler gefunden. in der owncloud9tutorial.goip.de_owncloud.conf Zeile 89 ist nochmals die open_basedir vorhanden. Hier mus der Pfad auf das neue Verzeichniss hinzugefügt werden. Nu funktioniert es.

          Vielen Dank

          Michael

          • Jan sagt:

            Hi Michael,

            ja, in diesem vHost sind nochmal ein paar spezielle PHP-Einstellungen für ownCloud aufgeführt. Die vergisst man gerne mal.
            Super, dass es nun bei dir klappt.

            Gruß,
            Jan

  • Hendrik Marten sagt:

    Hi Jan,
    zunächst danke für diese super Anleitung, die mit einigen Modifikationen auch unter debian super performant läuft.

    Das einzige Problem, das ich nach der vollständigen Einrichtung hatte war, dass der Login zur nextcloud sehr lange dauerte (20 – 30 Sekunden).

    Per Zufall habe ich diesen Beitrag gefunden https://wiki.swechsler.de/doku.php?id=software:nextcloud:longlogin

    Es ist wohl tatsächlich so, wie dort beschrieben, dass nextcloud versucht eine vermeintliche brute force Attacke zu verhindern.

    Nachdem ich die Punkte aus der Anleitung umgesetzt hatte, lief es wieder super schnell.

    Vielleicht betrifft das Thema ja noch andere Nutzer und du kannst es hier einbauen.

    Gruß
    Hendrik

    • Jan sagt:

      Hi Hendrik,

      ja, das mit dem vermeintlichen Brute-Force-Schutz ist meiner Meinung nach etwas suboptimal gelöst.
      Wenn häufiger falsche Daten eingegeben werden, dann sind wir hier zeitlich schon im Minuten-Bereich. Wer daher das ganze über fail2ban gelöst hat, kann den Brute-Force-Schutz getrost ausstellen.

      Gruß,
      Jan

1 4 5 6

Schreibe einen Kommentar

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