DecaTec

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

Nextcloud auf Ubuntu Server mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban

Nextcloud Logo

Hinwies: Dieser Artikel zeigt die Einrichtung von Nextcloud 12 auf Ubuntu Server 16.04 LTS. Ein aktualisiertes Tutorial ist hier zu finden: Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban

Wer seine sensiblen Daten wie Dateien, Kontakte oder Kalender nicht bei einem der großen Cloud-Anbieter wie Google, Apple oder Dropbox speichern möchte, kann mit recht einfachen Mitteln eine eigene Cloud betreiben, in der sämtliche Daten vor neugierigen Blicken geschützt sind.

Nextcloud ist eine Webanwendung, mit der eine solche „Selfmade-Cloud“ realisiert werden kann. Neben der reinen Verwaltung von Daten und Dateien bietet Nextcloud mittlerweile auch erweiterte Features wie Online-Office, Video-Konferenzen, E-Mail-Integration und vieles mehr.

Dieser Artikel zeigt die Installation und Konfiguration von Nextcloud auf Ubuntu Server mit nginx, MariaDB, PHP und Let’s Encrypt. Zur Verbesserung der Performance und Sicherheit wird auch die Einrichtung von Redis und Fail2ban gezeigt.

Die Art des Artikels ist übrigens nicht neu: Hier gab es bereits ein recht umfangreiches Tutorial, welches jedoch die Einrichtung von ownCloud (quasi der Vorgänger von Nextcloud) zeigte: ownCloud 9 auf Ubuntu Server 16.04 LTS mit nginx, MariaDB, PHP 7 und Let’s Encrypt. Vieles davon ist zwar auch direkt auf Nextcloud übertragbar, dennoch ist der aktuelle Artikel genau auf Nextcloud zugeschnitten und wurde an vielen Stellen noch weiter verbessert.

Update-Historie
  • 25.08.2017:
    • Troubleshooting: Hinweis auf apc.enable_cli hinzugefügt, wenn es bei der Ausführung des Cronjobs zu Fehlern mit APCu kommt.
  • 30.08.2017:
    • Variable overwriteprotocol in Nextcloud config.php sollte auf https gesetzt werden.
  • 07.09.2017:
    • Fail2ban: Jail für Nextcloud wird in die Datei /etc/fail2ban/jail.local eingetragen.
  • 23.09.2017:
    • Hinweis auf Anpassung der Verzeichnis-Berechtigungen entfernt. Dies wird seitens der Nextcloud
    • -Dokumentation nicht mehr empfohlen (siehe hier).
  • 22.102.107:
    • Fail2ban: Attribut für Login-Versuche heißt maxretry und nicht maxentry.
  • 07.01.2018:
    • Fail2ban: Erklärung zum Unterschied zwischen verschiedenen Konfigurations-Dateien (*.conf und *.local) hinzugefügt.
    • Fail2ban: Ergänzungen zum E-Mail-Versand bei Ban hinzugefügt.
  • 19.01.2018:
    • Gateway-Host: proxy_request_buffering off; hinzugefügt, damit Requests nicht mehr gepuffert werden.
  • 22.01.2018:
    • Genaueren Hinweis auf die langsame Generierung von Diffie-Hellman-Parameter auf schwacher Hardware hinzugefügt.
  • 14.04.2018:
    • Listen-Direktive für Nextcloud-vHost geändert, so dass nur noch lokal (127.0.0.1) auf Port 82 gelauscht wird.
  • 18.04.2018:
    • TLSv1.3 im Gateway-Host aktiviert (nginx unterstützt ab Version 1.13 TLSv1.3). Momentan macht diese Option nicht viel Sinn, da es noch nicht viele Clients gibt, die TLSv1.3 nutzen, dennoch kann man die neue TLS-Version bereits aktivieren.
  • 29.04.2018:
    • Hinweise für Ubuntu Server 18.04 „Bionic Beaver“ hinzugefügt. Das komplette Tutorial wird allerdings in der nächsten Zeit überarbeitet werden.
  • 03.05.2018:
    • Hinweis für die Installation unter Ubuntu 18.04 bzgl. Let’s Encrypt/certbot hinzugefügt.
    • Hinweis für die Installation für MariaDB auf dem Raspberry Pi hinzugefügt (das manuelle Hinzufügen der MariaDB-Paketquellen ist hier überflüssig).
  • 30.05.2018:

Inhalt

 

Motivation, Voraussetzungen und Konzept

Bevor es losgehen kann, soll an dieser Stelle zunächst einmal die Motivation für den Artikel und die Voraussetzungen erläutert werden. Ebenso gibt es ein paar Hintergrundinfos über das Konzept, welches dieses Tutorial verfolgt.

Ziele und Aufwand

Der Artikel hat folgende Zielsetzungen:

  • Installation von Nextcloud auf Ubuntu Server mit nginx, MariaDB und PHP.
  • Erhöhte Sicherheit (PHP-Konfiguration, SSL, Nextcloud-Konfiguration laut Nextcloud Server Administration Manual).
  • Verschlüsselte Verbindung (HTTPS) zur Cloud mittels Let’s Encrypt Zertifikat.
  • Nextcloud soll in einem Unterverzeichnis des Webservers laufen und daher über die URL https://meine.domain/nextcloud erreichbar sein. Dies macht es möglich, dass neben Nextcloud auch weitere Webanwendungen auf dem gleichen System gehostet werden können – siehe Zweite Web-Anwendung neben ownCloud/Nextcloud einrichten (am Beispiel WordPress).
  • Im Administrator-Bereich von Nextcloud sollen keine Warnungen/Hinweise zu sehen sein.
  • Verbesserung der Performance durch Memory Caching mit Redis.
  • Absicherung gegen Brute-Force-Attacken mittels Fail2ban.
  • Zu guter Letzt soll der Artikel auch für den Linux-Neuling verständlich und nachvollziehbar sein. Sicherlich werden den Linux-Profis unter euch noch einige Sachen einfallen, wie man das hier gezeigte System noch weiter optimieren kann, jedoch würde dies die Sache noch komplizierter machen, als sie ohnehin schon ist. Daher stehen – wie bereits gesagt – Verständlichkeit und Nachvollziehbarkeit klar im Vordergrund.

Gerade auch in Bezug auf den letzten Punkt ist es mir auch ein persönliches Anliegen, dass der Artikel v.a. Wissen vermitteln soll. Das Hosten einer eigenen Cloud ist nicht gerade trivial, daher sollte man im Idealfall genau wissen, was man hier tut. Ich habe mich daher dagegen entschieden, hier nur eine Auflistung an Befehlen zum Installieren und Konfigurieren zu erstellen. Vielmehr soll nach der Lektüre des Artikels so viel Hintergrundwissen vorhanden sein, dass man bei auftretenden Problemen sich selbst eine Lösung erarbeiten kann.

Folgende Versionen kommen dabei zum Einsatz:

  • Ubuntu Server 16.04.3 LTS („Xenial Xerus“)
  • Nextcloud 12.0.2
  • nginx 1.13.4
  • MariaDB 10.2
  • PHP 7.0
  • Redis 3.0.6
  • Fail2ban 0.9.3

Zeitaufwand: ca. 3 Stunden.

Wichtig: Man sollte alle Schritte wie im Tutorial beschrieben ausführen. Die Erfahrung zeigt, dass selbst die kleinste Abweichung (z.B. wenn ein Schritt ausgelassen wird) dazu führen kann, dass es im weiteren Verlauf zu Fehlern oder Problemen kommt.

Voraussetzungen

Betriebssystem und Hardware

Im Rahmen dieses Tutorials wird die Einrichtung der eigenen Cloud auf einem Ubuntu Server 16.04 LTS gezeigt. Der Einsatz einer LTS-Version (Long Term Support) bietet sich hier an, da durch den verlängerten Support-Zeitraum ein solches System lange Zeit betrieben werden kann, ohne dass man jedes Distributions-Update durchführen muss.

Allerdings kann auch eine ganz andere Linux-Distribution zum Einsatz kommen (z.B. Debian). Die Installation sollte auf allen Distributionen nahezu identisch ablaufen, daher ist die Wahl der Distribution hier eher Geschmacksache.

Auch die Server-Hardware ist nicht weiter entscheidend. Hier kann prinzipiell jeder PC verwendet werden, auf dem Linux problemlos läuft. Reizvoll ist hier oftmals die Verwendung eines Kleinst-Rechners wie dem Raspberry Pi (Affiliate Link), der stromsparend und leise läuft, ohne viel Platz zu brauchen. Wenn es etwas mehr Leistung sein darf, dann bietet sich auch ein Intel NUC (Affiliate Link) an.

Die Cloud kann ebenso auf einem virtuellen Systeme (VM) gehostet werden. Wie Ubuntu Server als virtuelle Maschine mittels Hyper-V betrieben werden kann, zeigt der Artikel Ubuntu Server als Hyper-V Gastsystem installieren und optimal einrichten. Einer der Vorteile von virtuellen Systemen ist die Möglichkeit sog. Snapshots anzulegen, die den Zustand der VM zu einem bestimmten Zeitpunkt speichern. Falls später dann etwas bei der Installation/Einrichtung schiefläuft, kann das System in wenigen Sekunden auf einen früheren Zustand zurückgesetzt werden. Das geht erheblich schneller, als sich auf Fehlersuche zu begeben. Darüber hinaus kann die Sicherung einer (Hyper-V-) VM leicht in eine bestehende Backup-Strategie integriert werden.

Zugriff per SSH

Nach der Installation des Betriebssystems läuft eine solcher Server meistens „headless“, d.h. ohne Monitor, Maus oder weitere Peripherie-Geräte. Der Zugriff erfolgt dann in den meisten Fällen über SSH (z.B. mit PuTTY). Mehr Infos über den Zugriff per SSH findet man ebenfalls im Artikel Ubuntu Server als Hyper-V Gastsystem installieren und optimal einrichten.

DynDNS

Die selbst-gehostete Cloud soll nachher natürlich auch aus dem Internet erreichbar sein. Dazu kommt ein DynDNS-Dienst zum Einsatz. Damit ist die Cloud (oder in erster Linie der Router) über eine DynDNS-Adresse erreichbar, die sich nicht mehr ändert – anders als die (externe) IP des Routers, die üblicherweise nach jeder (24h-) Zwangstrennung vom Internet-Provider neu vergeben wird.

Welcher DynDNS-Dienst zum Einsatz kommt, spielt eigentlich keine Rolle. Aus eigener Erfahrung kann ich den Dienst GoIP empfehlen, aber auch viele Webhoster bieten u.a. DynDNS-Dienste (z.B. All-inkl.com im Paket „Privat Plus“).

Im Rahmen des Tutorials verwende ich beispielhaft die Adresse nextcloudtutorial.goip.de.

Arbeiten mit Root-Rechten

Die Installation und Einrichtung vieler Programme erfordert Root-Rechte. Damit nicht vor jedem Befehl ein sudo benötigt wird, kann man sich mit dem Befehl sudo -s für die Dauer der Sitzung Root-Rechte verschaffen. Daher werden alle Befehle im Tutorial ohne vorangestelltes sudo aufgeführt.
Da es nicht empfehlenswert ist, dauerhaft mit Root-Rechten angemeldet zu sein, sollte man sich nach dem Abschluss der Installation/Konfiguration mit dem Befehl exit wieder abmelden.

Konzept

Der Artikel zeigt die Einrichtung von Nextcloud, allerdings nicht in der Standard-Konfiguration. In diesem Abschnitt geht es daher um das Konzept, welches dieses Tutorial verfolgt.

Warum die Kombination nginx/MariaDB?

Nextcloud – wie auch viele andere Webanwendungen – werden üblicherweise auf einem sog. „LAMP-Stack“ betrieben. Darunter versteht man eine Art Standard-Umgebung zum Hosten dynamischer Webanwendungen bestehend aus Linux, Apache, MySQL und PHP.

Dieser Artikel zeigt dagegen die Einrichtung der Cloud auf einem „LEMP-Stack“: Linux, nginx, MariaDB, PHP. Woher das „E“ kommt? Ganz einfach durch die Aussprache von nginx („Engine-X“).

Wieso sollte man nun nicht beim Altbekannten bleiben, sondern Aufwand in die Einrichtung einer alternativen Umgebung stecken? nginx als Webserver und MariaDB als Datenbanksystem bieten hier einige Vorteile:

  • nginx arbeitet ressourcensparender als Apache. Dies liegt im Unterschied begründet, wie die Webserver Client-Anfragen abarbeiten: Während Apache pro Verbindung neue Prozesse bzw. Threads erstellt, arbeitet nginx mit einem sog. Thread-Pool. Dies ist eine fest definierte Anzahl an Threads, die Client-Anfragen parallel abarbeiten können. nginx arbeitet daher weniger speicherintensiv als Apache, was gerade bei begrenzten Hardware-Ressourcen von Vorteil ist (z.B. auf einem Raspberry Pi).
  • MariaDB entstand ursprünglich aus einem Fork von MySQL und ist zu diesem binärkompatibel. Als sog. drop-in-replacement zu MySQL (d.h. ein 1:1 Ersatz) können alle von MySQL bekannten Befehle und Tools auch bei MariaDB zum Einsatz kommen.
    Hier gibt es also nicht so viele Unterschiede, daher ist die Wahl des Datenbank-Systems zweitrangig. Allerdings haben mittlerweile viele Linux-Distributionen MariaDB als Standard-Datenbanksystem den Vorzug gegeben, was das System recht zukunftssicher machen sollte.

Virtuelle Hosts und Konfigurations-Dateien von nginx

Wie bereits erwähnt, soll Nextcloud in einem Unterverzeichnis des Webservers liegen (nextcloudtutorial.goip.de/nextcloud). Dies ist sozusagen die Spezialität dieses Artikels, da andere Tutorials meist nur die „Standard-Installation“ beschreiben, in der Nextcloud direkt über eine Domain aufgerufen wird (nextcloudtutorial.goip.de).

Diese Entscheidung beeinflusst stark die Konfiguration des Webservers, der entsprechend eingerichtet werden muss. Hier macht es Sinn, sich etwas mit der Funktionsweise von nginx auseinander zu setzen. Das ist besonders dann von Vorteil, wenn es später im Praxis-Teil nicht auf Anhieb klappen will.

Bei nginx können – ähnlich wie beim Webserver Apache – virtuelle Hosts definiert werden. Ein virtueller Host (vHost) stellt dabei eine genau definierte Konfiguration für eine Website/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.

Die einzelnen Konfigurationen werden dabei „nach unten vererbt“: Die globale Konfiguration vererbt sämtliche Einstellungen an alle aktiven virtuellen Hosts. Ein vHost kann aber jederzeit die globalen Einstellungen überschreiben.

Aufteilung in mehrere virtuelle Hosts mit nginx

Warum sollte man nun mehrere virtuelle Hosts verwenden? Reicht hier nicht ein vHost vollkommen aus?

In diesem Tutorial geht es ja in erster Linie um die Einrichtung von Nextcloud. In der Tat würde hier ein virtueller Host ausreichen. Dennoch soll der Webserver möglichst flexibel sein, so dass später auch andere Webanwendungen (wie z.B. WordPress) auf dem gleichen System (parallel) gehostet werden können.

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

  • Ein einzelner virtueller Host: Hierbei werden alle Webanwendungen über den gleichen virtuellen Host konfiguriert. Diese Lösung mag auf den ersten Blick die einfachste sein, jedoch wird die Konfigurations-Datei (des einzigen vHosts) auf die Dauer sehr unübersichtlich. Ebenso besteht hier das Risiko, dass durch einen kleinen Fehler im einzigen vHost gleich alle Webanwendungen lahmgelegt werden. Ebenso kann eine Webanwendung nicht „mal eben schnell“ deaktiviert werden, da dazu große Teile des virtuellen Hosts entfernt oder auskommentiert werden müssten.
  • Ein virtueller Host pro Webanwendung: Bei diesem Ansatz gibt es einen virtuellen Host pro Webanwendung. Durch die strikte Trennung ist diese Lösung deutlich flexibler und weniger fehleranfällig.
    Dennoch gibt es ein Problem: Ein virtueller Host wird durch einen Server-Namen (die URL) und einen Port definiert. Diese Kombination 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. Aus diesem Grund müssten alle Webanwendungen auf unterschiedlichen Ports laufen. Das macht diesen Ansatz aber wieder recht 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).
  • Mehrere virtuelle Hosts + Reverse-Proxy: Es gibt allerdings auch einen weiteren Ansatz, der die Flexibilität von getrennten virtuellen Hosts bietet, die oben angesprochenen Nachteile jedoch vermeidet. 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 Gateway-Host ist die einzige direkte Schnittstelle „nach außen“. Alle Client-Anfragen kommen auf diesem Weg zunächst beim Gateway-Host an, der diese dann gezielt an andere vHosts weiterleitet.

Für dieses Tutorial habe ich mich für den dritten Ansatz entschieden, da dieser am flexibelsten ist und am wenigsten Einschränkungen hat. Leider ist diese Lösung auch die komplizierteste, was die Konfiguration der virtuellen Hosts etwas umfangreicher macht. Dennoch ist man mit dieser Vorgehensweise am besten bedient, v.a. wenn der Webserver nachher noch erweitert werden und weitere Webanwendungen hosten soll.

Auch wenn Nextcloud zunächst als einzige Web-Applikation auf dem Server installiert wird, kann das Konzept gleich in die Praxis umgesetzt werden, da wir für die Erzeugung des HTTPS-Zertifikats einen weiteren vHost für Let’s Encrypt benötigen werden. Auch wenn Let’s Encrypt keine Webanwendung im herkömmlichen Sinne ist, sollte das Vorgehen danach klar sein.

In einem weiterführenden Artikel habe ich bereits beschrieben, wie neben der Cloud auch WordPress auf dem gleichen Server installiert werden kann: Zweite Web-Anwendung neben ownCloud/Nextcloud einrichten (am Beispiel WordPress).

Installation und Einrichtung Nextcloud

Nach diesem eher theoretischen Teil soll das Ganze nun in die Praxis umgesetzt werden.

Updates

Zunächst erfolgt das obligatorische Update des Systems:

Statische IP zuweisen

Falls noch nicht geschehen sollte man dem System eine statische IP-Adresse zuweisen. Andernfalls wird der Rechner nach jedem Reboot eine neue IP-Adresse über DHCP vom Router bekommen, was für einen Server nicht gerade optimal ist.

Dazu wird folgende Datei bearbeitet:

Hier sind alle Netzwerkkarten und die dazu gehörenden IP-Konfigurationen hinterlegt. In diesem Tutorial gehe ich davon aus, dass der verwendete Router die IP 192.168.178.1 hat und der Server die statische IP 192.168.178.60 haben soll (diese Adressen dienen hier nur als Beispiel müssen dem eigenen Netzwerk entsprechend angepasst werden). Dazu werden die Einstellungen des entsprechenden Netzwerkadapters (eth0 ist die primäre Netzwerkkarte) auf folgende Werte gesetzt:

Nach einem Neustart wird der Rechner nun immer die IP 192.168.178.60 zugewiesen bekommen.

Hinweis: Durch die Verwendung einer statischen IP kann das System meist nicht mehr einfach über den Rechner-Namen im Netzwerk angesprochen werden. Die betrifft v.a. den SSH-Zugriff über PuTTY. Hier sollte nun immer die IP-Adresse zum Verbinden genutzt werden, da sich diese in Zukunft auch nicht mehr ändern wird.

Programm-Installation

Bevor Nextcloud eingerichtet werden kann, sind zunächst einmal der Webserver, das Datenbank-System und PHP zu installieren.

Installation nginx

nginx ist bereits in den Ubuntu-Paketquellen enthalten und könnte direkt installiert werden. Dennoch empfehle ich das offizielle nginx-Repository in die Paketquellen mit aufzunehmen, um stets eine aktuelle Version des Webservers zu betreiben.

Hinweis für Raspberry Pi Benutzer

Beim Raspberry Pi sieht die Sache etwas anders aus, da in den nginx-Paketquellen kein Paket für die ARM-Architektur vorhanden ist, die für den Kleinstcomputer benötigt werden würde. Daher wird hier empfohlen, die nginx-Version zu installieren, die in den Raspbian-Paketquellen enthalten ist. Hier reichen also folgende Befehle:

Die folgenden Schritte zur Installation des Webservers sind auf einem Raspberry Pi daher nicht durchzuführen.

Zunächst wird der Schlüssel des nginx-Repositories auf dem System bekannt gemacht. Dies sorgt dafür, dass später keine Warnungen ausgegeben werden, wenn aus diesem Repository Pakete abgerufen werden:

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

Am Ende der Datei wird einfach folgender Inhalt eingefügt:

Wenn eine anderen Distribution bzw. Version zum Einsatz kommt, müssen diese Zeilen jedoch angepasst werden (siehe nginx: Linux packages).

Hinweis: Mit der Angabe dieser Paket-Sourcen wird die Mainline-Version von nginx verwendet. Die Mainline stellt den aktuellen Entwicklungszweig dar. Daneben gibt es auch noch einen Stable-Entwicklungszweig. Dieser ist etwas stabiler als der Mainline-Zweig, wird allerdings nur bei kritischen Sicherheitslücken und Problemen aktualisiert. Bis neue Features in den Stable-Zweig einfließen, vergeht in der Regel viel Zeit.
Da der Mainline-Zweig aber generell auch als stabil gilt, lautet die Empfehlung, diesen Entwicklungszweig zu verwenden (siehe nginx-Blogbeitrag).

Nach der Aktualisierung der Paketquellen kann der Webserver installiert werden:

Ob alles geklappt hat, kann man nach einem Neustart des Rechners durch die Eingabe der IP-Adresse des Servers in einem Browser überprüfen.

Erster Aufruf - der Webserver läuft

Erster Aufruf – der Webserver läuft

Installation MariaDB

Bei MariaDB verhält es sich ähnlich wie schon mit der Installation von nginx: Entweder kann man die Version nehmen, die bereits in den Paketquellen der Distribution enthalten ist, oder man fügt das offizielle MariaDB-Repository in die Liste der Paketquellen hinzu und kann somit eine aktuellere Version der Datenbank verwenden.

Hinweis für Raspberry Pi Benutzer

Beim Raspberry Pi ist in den MariaDB-Paketquellen ebenfalls kein Paket für die ARM-Architektur vorhanden (wie schon bei nginx). Daher können folgenden Schritte mit dem Hinzufügen der MariaDB-Paketquellen bei Raspberry Pi ebenfalls übersprungen werden. Hier reichen dann folgende Befehle:

Auf der Homepage von MariaDB findet man dazu ein praktisches Repository Configuration Tool. Die einzelnen Schritte im Detail:

Zunächst wird der Key-Server für MariaDB bekannt gemacht (sonst gibt es im weiteren Verlauf u.U. Warnungen):

Anschließend werden die Paketquellen hinzugefügt:

Folgende Zeilen werden am Ende der Datei angefügt. 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

Installation PHP

PHP 7 ist bereits in den Paketquellen von Ubuntu enthalten, daher entfällt hier das Hinzufügen von weiteren Paketquellen.

Die Nextcloud-Dokumentation liefert einen Hinweis auf die benötigten PHP-Pakete, die an dieser Stelle zu installieren sind. Es können durchaus noch weitere Pakete benötigt werden, wenn spezielle Features von Nextcloud zum Einsatz kommen sollen. Für den Standard-Umfang genügt die Installation der folgenden Pakete:

Werden später weitere Pakete benötigt (z.B. zum Einbinden vom Samba-Freigaben als externen Speicher), dann kann die Installation zu einem späteren Zeitpunkt nachgeholt werden.

Server Konfiguration

Nachdem alle benötigten Programme und Pakete installiert wurden, geht es nun an die Konfiguration des Servers.

Konfiguration PHP

Zunächst werden die allgemeinen Einstellungen für PHP bearbeitet.

PHP wird dabei über FPM (FastCGI Process Manager) betrieben. Dies ist eine performante Möglichkeit der Kommunikation zwischen Webserver und PHP. FPM definiert dabei einen sog. Thread-Pool, der Threads zur Abarbeitung von Anfragen bereithält. Die dazu gehörende Konfiguration ist in folgender Datei zu finden:

Als erstes sollte man hier kontrollieren, unter welchem User der Thread-Pool betrieben wird. Dies sollte der User www-data sein:

Die Kommunikation zwischen Webserver und PHP soll später über einen Socket stattfinden. Daher sollte auch folgender Eintrag in der Datei zu finden sein:

Zu guter letzt sucht man noch nach dem Eintrag Pass environment variables like LD_LIBRARY_PATH. ALL $VARIABLES are taken from the current environment (Shortcut für die Suche in nano: STRG + W). Standardmäßig sind hier alle Einträge, die mit env beginnen auskommentiert, diese werden jedoch für den Betrieb von Nextcloud benötigt. Daher werden die Kommentare an den entsprechenden Zeilen entfernt – einfach das Semikolon am Zeilenanfang entfernen.

Neben der Pool-Konfiguration gibt es bei PHP noch eine weitere Stelle, an der globale Optionen verwaltet werden: Die in der Datei php.ini definierten Werte wirken sich auf alle PHP-Anwendungen aus, die auf dem Server laufen. Die meisten Einstellungen kann man hier auf den Standard-Werten belassen. Anpassungen, die nur für eine Web-Applikation gelten sollen, werden später in den virtuellen Hosts von nginx definiert.

Hier ändern wir also nur wenige Werte ab:

  • cgi.fix_pathinfo = 0
    Sorgt für eine sichere Interpretation von Pfadangaben.
  • open_basedir = /var/www/:/tmp/
    Schränkt den Zugriff von PHP auf das Webroot- und das temporäre Verzeichnis ein. Dadurch kann PHP auf sonst keine Dateien des Systems zugreifen oder diese verändern.
  • opcache.enable = 1
    opcache.enable_cli = 1
    opcache.memory_consumption = 128
    opcache.interned_strings_buffer = 8
    opcache.max_accelerated_files = 10000
    opcache.revalidate_freq = 1
    opcache.save_comments = 1
    Dies sind die Werte zum Konfigurieren des PHP OPcache (erhöht die Performance durch das Ablegen vorkompilierten Bytecodes in den Arbeitsspeicher). Diese Einträge sollten in der php.ini bereits vorhanden sein (allerdings auskommentiert). Eine Suche in der Datei sollte einiges an Tipparbeit sparen.

Neben FPM kann PHP auch über die Kommandozeile aufgerufen werden (CLI – Command Line Interpreter/Interface). Diese Art des Zugriffs wird später für Cronjobs benötigt, die im Rahmen von Nextcloud laufen. Hierfür gibt es eine separate php.ini, in der ebenfalls Änderungen durchgeführt werden müssen:

  • cgi.fix_pathinfo = 0
    siehe oben
  • open_basedir = /var/www/:/tmp/:/var/nextcloud_data
    Schränkt die oben erwähnt den Zugriff von PHP ein. Zusätzlich wird hier das spätere Datenverzeichnis von Nextcloud mit angegeben, da dies außerhalb des Webroots liegt.

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

Konfiguration MariaDB

Es folgt die Konfiguration der Datenbank, die nach der Installation noch nicht auf maximale Sicherheit getrimmt ist. Dies kann mit dem folgenden Befehl nachgeholt werden:

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.

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

Allgemeine nginx-Konfiguration

Zunächst wir die globale Konfiguration von nginx angepasst:

In den meisten Fällen ist die Standard-Konfiguration ein guter Ausgangspunkt, jedoch sollte man ein paar wenige Punkte überprüfen und ggf. anpassen:

  • 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 ausgibt. 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

Wenn direkt nach der Installation die IP des Rechners im Browser eingegeben wird, präsentiert nginx eine sog. Default-Seite. Diese wird im weiteren Verlauf nicht mehr benötigt und kann daher deaktiviert werden.

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

Durch die Änderung der Dateiendung wird dieser vHost anschließend nicht mehr automatisch von nginx geladen.

Vorbereiten der Verzeichnisstruktur

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

Anlegen des Gateway-Hosts

Als erstes wird nun der Gateway-Host angelegt, der zunächst einmal alle Client-Anfragen entgegennimmt und diese nachher an die entsprechenden vHosts weiterleitet. Der Einfachheit halber benennen wir die Datei nach der Domain, über die das System später erreichbar sein soll:

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 virtuellen Hosts für Let’s Encrypt

Damit der proxy_pass Befehl des Gateway-Hosts korrekt ausgeführt werden kann, brauchen wir nun einen separaten vHost für Let’s Encrypt. Als Dateinamen verwende ich hier immer die Domain und den Namen des Dienstes (getrennt durch einen Unterstrich):

Dieser Host ist dabei sehr einfach aufgebaut:

Gelauscht wird auf 127.0.0.1:81. Der Port ist hier entscheidend: Dieser muss mit dem Port aus der Anweisung proxy_pass des Gateway-Hosts übereinstimmen. Da sich die Anweisungen listen und server_name auf die lokale Loopback-Adresse 127.0.0.1 beziehen, ist sichergestellt, dass dieser virtuelle Host nur auf dem lokalen Rechner angesprochen werden kann. Der Zugriff erfolgt damit ausschließlich über den Gateway-Host, ein direktes Ansprechen des Hosts für Let’s Encrypt ist damit „von außen“ nicht möglich.

Damit die beiden neu angelegten virtuellen Hosts auch geladen werden, muss nginx noch neu gestartet werden:

SSL-Zertifikat mit Let’s Encrypt erzeugen

Der Webserver wurde nun so weit vorbereitet, dass ein SSL-Zertifikat generiert werden kann.

Port-Forwarding und DynDNS einrichten

Zunächst ist es wichtig, dass der Server auch tatsächlich aus dem Internet erreichbar ist. Hierfür muss ein Port-Forwarding für die Ports 80 (HTTP) und 443 (HTTP) auf den Server (192.168.178.60) eingerichtet werden. Dies geschieht normalerweise am Router. Das Vorgehen hierzu unterscheidet sich von Router zu Router. Im Zweifel hilft hier ein Blick in die Hilfe des Routers, aber auch Google kann hier sicher weiterhelfen. Die Hilfeseiten von AVM beschreiben beispielsweise das Vorgehen für eine FritzBox.

Darüber hinaus muss der Router so konfiguriert sein, dass er sich beim DynDNS-Dienst korrekt anmeldet, um so per DynDNS-Adresse aus dem Internet erreichbar zu sein. Auch hier ist das Vorgehen nicht einheitlich und hängt sowohl vom verwendeten Router, als auch vom DynDNS-Dienst ab. Wie man den DynDNS-Dienst GoIP auf verschiedenen Router-Modellen zum Laufen bekommt, ist beispielsweise auf den GoIP-Hilfeseiten gut beschrieben.

Generierung des SSL-Zertifikats

Nun kann das SSL-Zertifikat mit Let’s Encrypt erzeugt werden.

Bei Ubuntu 16.04 ist Let’s Encrypt bereits in den Paketquellen enthalten, daher reicht zur Installation folgender Befehl:

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

Hier wird zunächst nach einer E-Mail-Adresse gefragt. Dies dien dazu, dass Let’s Encrypt Benachrichtigungen zu ablaufenden Zertifikaten schicken kann (diese Zertifikate sind allgemein nur 90 Tage lang gültig). Hier sollte man also eine echte Mail-Adresse angeben, beim Auslaufen der Zertifikate ist das eine gute Erinnerung per Mail.

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/nextcloudtutorial.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
Diffie-Hellman-Parameter

Das SSL-Zertifikat ist der wichtigste Schritt, damit die Verbindungen zur Cloud nachher verschlüsselt ablaufen. Man kann die Sicherheit noch weiter erhöhen, indem man zusätzlich sog. Diffie-Hellman-Parameter generiert. 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:

Nicht wundern: Die Generierung kann (gerade auf schwacher Hardware) eine ganze Weile dauern (z.B. mehrere Stunden auf einem Raspberry Pi 3). Wer hier nicht so lange warten kann/will, kann auch einen Schlüssel mit 2048 Bit generieren:

Zugriffsberechtigungen für Zertifikat-Dateien setzen

Die Zertifikat-Dateien sind natürlich schützenswert, daher sollten die Dateiberechtigungen angepasst werden, so dass nur noch der Besitzer der Dateien Lese- bzw. Schreibrecht hat:

Erneuerung der Zertifikate nach 90 Tagen

Die von Let’s Encrypt generieren Zertifikate sind auch Sicherheitsgründen nur 90 Tage lang gültig und müssen spätestens nach Ablauf dieser Frist erneuert werden. Kurz vor diesem „Verfallsdatum“ erhält man automatisch eine E-Mail, die einen daran 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.

Die Erneuerung der Zertifikate wird von vielen eher als lästige Arbeit angesehen, weil man hier immer als Administrator des Webservers tätig werden muss. Wie man die Erneuerung der Zertifikate per Cronjob automatisieren kann, habe ich bereits in folgendem Artikel erläutert: Let’s Encrypt Zertifikate per Cron automatisch erneuern.

Gateway-Host für Nextcloud vorbereiten

Da wir später einen eigenen vHost für Nextcloud hinzufügen werden, muss dies im Gateway-Host vorbereitet werden:

Die hinzugefügten Abschnitte sind markiert:

Hier wurde zunächst die Einbindung des SSL-Zertifikats hinzugefügt. Ebenso wurden alle SSL-Parameter konfiguriert, die für alle Webanwendungen gelten sollen.
Falls die Cloud später sowohl über die Domain direkt, als auch über das Unterverzeichnis erreichbar sein soll (also nextcloudtutorial.goip.de/nextcloud und zusätzlich direkt über nextcloudtutorial.goip.de), muss der Block location = / noch dahingehend angepasst werden. Das deny all; muss in diesem Fall durch die Redirect-Anweisung ersetzt werden.
Zu guter Letzt wird noch die Weiterleitung an den Nextcloud-vHost eingerichtet.

Virtuellen Host für Nextcloud anlegen

Ähnlich wie schon bei Let’s Encrypt wird für Nextcloud ein separater virtueller Host angelegt:

Hier der komplette Inhalt der Datei:

Diese Konfiguration ist angelehnt an die vorgeschlagene nginx-Konfiguration im Nextcloud Administration Manual. Trotzdem noch ein paar Erläuterungen dazu:

  • Es wird nur ein HTTP-Server definiert (kein HTTPS). Die HTTPS-Verbindung wird über den Gateway-Host sichergestellt.
  • Gelauscht wird wieder über die Adresse 127.0.0.1. Zusammen mit dem entsprechenden server_name kann auch hier keine direkte Verbindung zu diesem virtuellen Host aufgebaut werden (ohne den Gateway-Host zu passieren).
  • Der Port ist diesmal 82, da Port 81 bereits vom Let’s Encrypt vHost „belegt“ ist. Eine Eindeutigkeit (server_name/Port) wird hier über einen anderen Port erreicht.
  • Die proxy_set_header Anweisungen dienen der erhöhten Sicherheit. Ohne diese Einträge werden später Warnungen im Admin-Bereich von Nextcloud 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 Nextcloud zuständig ist) beinhaltet neben den Nextcloud-spezifischen Anweisungen auch noch weitere Parameter, die bestimmte 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. Besonders wichtig ist hier die Direktive open_basedir, da PHP ansonsten keinen Zugriff auf das Datenverzeichnis von Nextcloud hat.
    Falls später z.B. eine externe Festplatte als externer Speicher eingebunden werden soll, muss auch das Verzeichnis dieses Laufwerks in die open_basedir Anweisung mit aufgenommen werden.

Bevor der Webserver nun neu gestartet wird, sollte ein Testlauf mit den soeben erstellten Konfigurationen gemacht werden. Dafür sorgt der erste Befehl. Falls hier Fehler gefunden werden (Tippfehler schleichen sich hier schnell mal ein), dann wird dies hier angezeigt.
Mit dem zweiten Befehl wird der Webserver anschließend neu gestartet.

Installation Nextcloud

Nun ist der Server soweit konfiguriert und eingerichtet, dass als nächstes Nextcloud installiert werden kann.

Download

Einen Link zu der aktuellsten Version von Nextcloud bekommt man über die Download-Seite von Nextcloud. Hier sollte man nach Möglichkeit das .tar.bz2 Archiv nehmen, da dies ohne weitere Software auf dem Server entpackt werden kann (zu finden über den Button Details and Download options).

Download-Link für Nextcloud

Download-Link für Nextcloud

Zurück auf der Linux-Maschine kann man nun den Download ausführen (hier mit Nextcloud Version 12.0.2):

Anschließend wird das Archiv an die passende Stelle entpackt. Zum Schluss kann das Archiv wieder entfernt werden:

Für die weiteren Schritte ist es wichtig, dass die Datei-Berechtigungen richtig gesetzt werden:

Datenbank für Nextcloud anlegen

Bevor das Setup der Cloud über den Browser aufgerufen werden kann, muss noch die Datenbank für Nextcloud erstellt werden. Dies geschieht mittels der MySQL-Kommandozeile, die mit Root-Rechten aufgerufen wird (das Passwort wurde zuvor bei der Installation von MariaDB festgelegt):

Naben der Datenbank wird auch gleich ein eigener Nutzer für Nextcloud erstellt. Die Angabe localhost sorgt dabei dafür, dass der Zugriff auf diese Datenbank nur auf dem lokalen Rechner möglich ist (kein Remote-Zugriff). Auch hier sollte man wieder ein sicheres Passwort wählen. Man beachte das Semikolon am Ende jeder Zeile:

Nextcloud-Setup

Nun erfolgt der Aufruf des Setups mittels Browser über die URL https://nextcloudtutorial.goip.de/nextcloud.

Falls an dieser Stelle noch fehlende Abhängigkeiten entdeckt werden, weist das Setup darauf hin. In diesem Fall sollte man die fehlenden Pakete nachinstallieren und anschließend das Setup erneut aufrufen.

Im Rahmen des Setups wird das erste Benutzer-Konto eingerichtet, welches automatisch Administrator-Rechte in der Cloud hat. Der Nutzername ist frei wählbar und man sollte auf jeden Fall ein sicheres Passwort vergeben, da die Cloud ja öffentlich über das Internet erreichbar ist. Weitere Punkte bei der Einrichtung sind das Nextcloud-Datenverzeichnis (/var/nextcloud_data) und die Zugangsdaten für die zuvor angelegte Datenbank. Mit einem Klick auf Installation abschließen wird die Ersteinrichtung angestoßen.

Nextcloud Setup

Nextcloud Setup

Hinweis: Auf langsameren Rechnern kann das Setup eine ganze Weile dauern. Im schlimmsten Fall kann es passieren, dass der Webserver irgendwann einen Timeout meldet (504 Gateway Timeout). nginx kappt in diesem Fall die Verbindung zum Client (Browser), das Setup wird aber weiterhin ausgeführt. Hier kann man ein paar Minuten warten und die URL anschließend erneut aufrufen. In diesem Fall sollte man in den virtuellen Hosts (Gateway und Nextcloud) die Timeout-Werte etwas erhöhen.

Warnungen im Admin-Bereich

Nach der erfolgreichen Installation sollte man zunächst einen Blick in den Administrator-Bereich der Cloud werfen: Zahnrad-Symbol (oben rechts) > Verwaltung. Nextcloud führt hier u.a. einige Checks aus, ob die Cloud richtig konfiguriert wurde. Falls Optimierungsbedarf besteht, werden hier entsprechende Warnungen ausgegeben.

Warnungen im Admin-Bereich

Warnungen im Admin-Bereich

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

Es wurde kein PHP Memory Cache konfiguriert. Zur Erhöhung der Leistungsfähigkeit kann ein Memory-Cache konfiguriert werden. Weitere Informationen finden Sie in unserer Dokumentation.

Diese Meldung stellt zunächst keinen Fehler dar und sagt lediglich aus, dass die Performance der Cloud durch den Einsatz einen Memory-Caches optimiert werden kann.

Hinweis: Falls hier weitere Warnungen oder Fehler (diese erscheinen dann in roter Schrift) angezeigt werden, sollten die einzelnen Schritte zur Einrichtung von Nextcloud nochmals kontrolliert werden. In der Nextcloud-Dokumentation findet man eine Übersicht über die Fehler und Warnungen, die an dieser Stelle angezeigt werden können. Ebenfalls werden hier Hinweise und Tipps aufgelistet, wie diese Fehler zu beseitigen sind.

Anpassung der Nextcloud-Konfiguration

Um diese eine Warnung im Admin-Bereich zu entfernen, ist eine manuelle Anpassung der Nextcloud-Konfiguration notwendig. Dazu rufen wir einfach die dazugehörige Config-Datei auf:

Der Memory Cache wird nun einfach durch das Hinzufügen folgender Zeile (ganz am Ende, aber noch vor der letzten geschweiften Klammer) 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:

Ebenfalls wichtig ist das Setzen der Variablen overwriteprotocol: Diese sollte auf den Wert https gesetzt werden, da Nextcloud hinter einem Proxy (Gateway-Host) läuft und dadurch zunächst beim Ermitteln von URLs nicht klar ist, dass immer HTTPS verwendet wird. Wenn dies nicht korrekt eingestellt ist, dann äußert sich das später meistens darin, dass bestimmte Inhalte (wie das Hintergrundbild während der Anmeldung) nicht angezeigt werden.

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 im Log zu bestimmen:

Wenn man nun den Admin-Bereich der Cloud neu aufruft, sollte die Warnung verschwunden sein und die Meldung Alle Überprüfungen bestanden erscheinen.

Eine Übersicht über alle Parameter der config.php findet man in der Nextcloud-Dokumentation.

Cronjob für Nextcloud einrichten

Nextcloud führt in regelmäßigen Abständen Hintergrund-Aufgaben aus (z.B. Aufräum-Arbeiten). Dies wird in der Standard-Einstellung über AJAX realisiert. Dies ist zwar die einfachste Möglichkeit, jedoch gibt es hier zwei Nachteile: Zum einen kann ein Hintergrund-Job nur dann ausgeführt werden, 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.

Aus diesem Grund wird generell empfohlen, diese Hintergrund-Aufgaben per Cron laufen zu lassen: Hier wird in regelmäßigen Abständen automatisch ein Hintergrund-Dienst gestartet, der dann alle zu erledigenden Hintergrund-Jobs abarbeitet. Die Einrichtung eines Cronjobs ist besonders auf schwacher Hardware empfehlenswert.

Um diesen Cronjob anzulegen, 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.

Zum Schluss fehlt noch die Umstellung in der Admin-Oberfläche der Cloud. Hier wählt man einfach den Punkt Cron.

Umstellung von AJAX auf Cron

Umstellung von AJAX auf Cron

Ob der Cronjob nun ordnungsgemäß ausgeführt wird, kann man an der Anzeige Letzte Aufgabe ausgeführt erkennen: Immer nach 15 Minuten sollte die Anzeige wieder zurückgesetzt werden (gerade eben).

Weitere Konfiguration der Cloud

Damit ist die grundsätzliche Einrichtung von Nextcloud abgeschlossen. Alle weiteren Einstellungen hängen von individuellen Einsatzzweck der Cloud ab.

Folgende Punkte sind auf jeden Fall einen Blick Wert:

Generell ist bei der erweiterten Konfiguration und Einrichtung ein Blick in das Administrations-Handbuch von Nextcloud sinnvoll.

Optimierung von Nextcloud

Auch wenn die Cloud nun prinzipiell einsatzbereit ist, gibt es noch ein paar Punkte zur Optimierung von Nextcloud. Die Umsetzung ist hier optional und hängt vom späteren Einsatzzweck der Cloud ab.

Fail2ban

Nextcloud bringt einen eingebauten Brute-Force-Schutz mit. Dieser sorgt dafür, dass nach einer gewissen Anzahl an fehlgeschlagenen Login-Versuchen alle weiteren Logins aus dem gleichen Subnetz des Netzwerks gedrosselt werden. Dies führt zu einer verlangsamten Anmeldung an der Cloud (wird bis zu 30 Sekunden verzögert). Auch wenn dies aus Gründen der Sicherheit sinnvoll sein kann, empfehle ich für diese Aufgabe den Einsatz von Fail2ban. Der Einsatz dieses Programms bietet gegenüber dem eingebauten Schutzmechanismus folgende Vorteile:

  • Fail2ban arbeitet IP-basiert. Es wird nur die entsprechende IP blockiert, von er aus zu viele fehlgeschlagene Login-Versuche unternommen werden. Andere Nutzer aus dem gleichen Netzwerk werden dadurch nicht mehr ausgebremst (wie beim Nextcloud-Brute-Force-Schutz).
  • Mit Fail2ban kann nicht nur die Nextcloud-Installation abgesichert werden, sondern auch weitere Teile des Systems (z.B. den SSH-Zugriff).

Ein genereller Hinweis zu Fail2ban: Das Programm kennt zwei Arten von Konfigurations-Dateien: *.conf und *.local. Die conf-Dateien sind dabei die von Fail2ban ausgelieferten Dateien. Wenn Änderungen an der Konfiguration vorgenommen werden sollen, dann sollte man die conf-Dateien nie direkt bearbeiten, da diese bei einem Update von Fail2ban jederzeit überschrieben werden können. Besser ist hier, eine Datei mit dem gleichen Namen, aber der Datei-Endung .local anzulegen. Die local-Dateien werden dabei „on top“ auf die conf-Dateien geladen und überschreiben so die Standard-Einstellungen. Wenn nun bei einem Update von Fail2ban die conf-Dateien geändert werden, sind die individuellen Anpassungen in den local-Dateien davon nicht betroffen. Dadurch kann eure Fail2ban-Installation durch ein Update nicht „kaputt gemacht “ werden.

Installation und Einrichtung Fail2ban

Wenn Fail2ban zum Einsatz kommt, dann ist die Brute-Force-Schutz bei Nextcloud natürlich überflüssig und kann deaktiviert werden. Dies passiert wieder über die config.php von Nextcloud:

Ausgeschaltet wird diese Funktion durch das Hinzufügen folgender Zeile:

Auch sollte in dieser Datei gleich kontrolliert werden, ob die richtige Zeitzone für Nextcloud eingestellt ist. Dies ist wichtig, da Fail2ban ansonsten u.U. auf Grund von falschen Zeitangaben in den Logs nicht richtig funktionieren kann:

Anschließend kann Fail2ban installiert werden:

Nun wird ein spezieller Filter für Nextcloud angelegt:

Die Datei wird nun mit folgendem Inhalt gefüllt:

Damit dieser Filter beim Start von Fail2ban auch geladen wird, muss der Filter dem System noch bekannt gemacht werden:

Diese Datei hat folgenden Inhalt:

Dies sorgt dafür, dass nach drei fehlgeschlagenen Login-Versuchen die entsprechende IP für 1800 Sekunden (30 Minuten) gesperrt (gebannt) wird. Ein negativer Wert bei bantime sorgt für eine permanente Sperre.

Nach einem Neustart ist Fail2ban einsatzbereit:

E-Mail-Versand durch Fail2ban

Fail2ban arbeitet zunächst im Hintergrund: Wenn eine IP gebannt wird, dann bekommt man als Administrator davon zunächst wenig mit, außer man sichtet in regelmäßigen Zeitabständen die entsprechenden Logs.

Eine sinnvolle Erweiterung stellt daher der Versand einer E-Mail dar, wenn Fail2ban tätig wurde. Um einfach unter Linux Mails versenden zu können, kann sSMTP verwendet werden. Die Installation und Einrichtung dieses Programms ist im Artikel Linux: Einfach E-Mails senden mit sSMTP erklärt.

Wenn sSMTP konfiguriert wurde, funktioniert das Senden von Mails über Fail2ban erstaunlich einfach, da der E-Mail-Versand bereits vorgesehen ist. Dazu reicht eine kleine Anpassung an der Datei /etc/fail2ban/jail.local. Am Anfang der Datei werden einfach noch folgende Zeilen hinzugefügt:

destemail ist dabei die Mail-Adresse, an die Benachrichtigungen geschickt werden sollen, sender die Adresse, von der die E-Mail gesendet werden soll. Wichtig ist insbesondere die Zeile action = %(action_mwl)s: Hierdurch werden E-Mails standardmäßig versendet.

Nun bekommt ihr bei allen Aktionen, die Fail2ban vornimmt automatisch eine E-Mail zugesendet. Das einzige, was dabei evtl. etwas unschön ist: Auch wenn ein „Jail“ gestoppt oder geladen wurde, wird eine E-Mail versendet. Startet einfach mal Fail2ban neu (service fail2ban restart) und wundert euch über die „Mail-Flut“. Um wirklich nur noch Mails zu erhalten, wenn eine IP gebannt wurde, sind noch Anpassungen an ein paar Dateien notwendig. Die betroffenen conf-Dateien im Verzeichnis /etc/fail2ban/action.d werden dabei durch entsprechende local-Dateien ergänzt:

  • mail-buffered.local
  • mail.local
  • mail-whois-lines.local
  • mail-whois.local
  • sendmail-buffered.local
  • sendmail-common.local

Im Klartext werden die o.g. Dateien neu angelegt und mit folgendem Inhalt gefüllt:

Nach einem Neustart von Fail2ban werden nun nur noch E-Mails versendet, wenn eine IP gebannt wurde.

Fail2ban Staus und Sperren entfernen

Nun kann es durchaus mal vorkommen, dass man sich selbst aus der Cloud aussperrt, wenn man zu oft falsche Anmelde-Daten eingibt. Probiert es ruhig mal aus, diese Sperre kann auch manuell wieder aufgehoben werden.

Um zu sehen, welche IPs aktuell für Nextcloud gesperrt sind, kann folgender Befehl genutzt werden:

Alle gebannten IPs werden hier in der Liste Banned IP list aufgeführt.
Um eine bestimmte IP zu entsperren reicht folgender Befehl (hier mit der fiktiven IP 48.128.36.83):

Redis

Nextcloud nutzt das sog. Transactional File Locking, um Datei-Sperren auf einer höheren Ebene als dem Dateisystem zu realisieren. Vereinfacht gesagt werden hier Dateien „gelockt“, die gerade im Zugriff sind.

Nach der Standard-Installation nutzt Nextcloud für diese Aufgaben die Datenbank, um solche Sperren zu verwalten. Hier kann mit Redis aber auch eine In-Memory-Datenbank verwendet werden, welche für solche Aufgaben optimiert ist und daher in bestimmten Szenarien einen deutlichen Performance-Schub bringen kann.

Wichtig: Auch wenn hier Potential zur Optimierung besteht, ist der Einsatz von Redis nur für große Cloud-Installationen mit vielen Nutzern und parallelen Zugriffen wirklich sinnvoll. Wenn die private Cloud nur 3-5 Nutzer hat, dann wird man vom Einsatz von Redis kaum einen Effekt spüren.

Die Installation von Redis erfolgt mit den Befehlen:

Nach der Installation muss die In-Memory-Datenbank noch konfiguriert werden:

Wie schon bei PHP bietet es sich hier an, Redis über einen Socket laufen zu lassen. Folgende Einstellungen sind dazu in dieser Datei vorzunehmen:

Mit der Angabe port 0 wird dafür gesorgt, dass Redis prinzipiell nicht auf einem Port „lauscht“. Mit den beiden anderen Zeilen ein Socket für Redis (diese Zeilen sind bereits in der Konfiguration enthalten, jedoch auskommentiert). Wichtig ist auch das Setzen der korrekten Berechtigungen (steht standardmäßig auf 700, dies funktioniert jedoch im Zusammenspiel mit Nextcloud nicht).

Also nächstes wird der Webserver-User www-data in die Gruppe der Redis-Benutzer mit aufgenommen, damit dieser Redis nutzen darf. Wird dieser Schritt vergessen, bekommen man später im Nextcloud-Log Meldungen der Art redis went away zu sehen:

Um Nextcloud nun anzuweisen, Redis für das Transaction File Locking zu verwenden, muss hier noch die config.php angepasst werden:

Folgende Zeilen hier einzufügen:

Zu guter Letzt wird der Redis-Dienst noch neu gestartet, dass die Änderungen auch übernommen werden:

ufw einrichten

ufw (uncomplicated firewall) ist eine Firewall-Lösung, die bei Ubuntu Server bereits vorinstalliert ist. Oftmals übernimmt im privaten Bereich der Router die Aufgabe, sämtlichen eingehenden Traffic ins Heimnetzwerk zu blockieren (daher ist hier ja auch die Freigabe der Ports 80 und 443 notwendig). Daher ist hier die Einrichtung von ufw optional. In manchen Szenarien kann die Einrichtung einer Firewall auf dem Server jedoch helfen, die Sicherheit weiter zu erhöhen.

Bei Distributionen, bei den ufw noch nicht vorhanden ist, kann die Firewall mit folgendem Befehl installiert werden.

Im Prinzip soll hier sämtlicher eingehender Traffic blockiert werden, jedoch mit zwei Ausnahmen:

  • Der Zugriff über SSH (standardmäßig über Port 22) – allerdings nur aus dem Heimnetzwerk (hier 192.168.178.0/24).
  • Zugriff über das Web (Port 80 bzw. 443).

Dies kann mit folgenden Befehlen erreicht werden:

Den Status der Firewall kann man anschließend mit diesem Befehl herausfinden:

Überprüfung der Sicherheit

Der Aspekt der Sicherheit war ja von Anfang an ein Ziel dieses Tutorials. Nach dem Einrichten der Cloud können abschließend noch Tests durchgeführt werden, um zu kontrollieren, ob dieses Ziel erreicht wurde.

Qualys SSL Labs

Der erste Check dient der Überprüfung aller Parameter, die für die SSL-Verschlüsselung zuständig sind. Dazu gehört zum einen das SSL-Zertifikat von Let’s Encrypt, aber auch alle SSL-Einstellungen seitens nginx.

Für diesen Test kann der SSL Server Test von Qualys SSL Labs verwendet werden. Mit der hier gezeigten Konfiguration sollte auf jeden Fall eine sehr gute  ‚A+‘-Wertung erreicht werden können.

SSL-Test der Nextcloud-Installation

SSL-Test der Nextcloud-Installation

Falls im Rahmen des Tests Sicherheitsmängel festgestellt werden, sollten die beanstandeten Punkte nochmals kontrolliert werden. Meist ist das Problem dazu in den Konfigurations-Dateien von nginx zu finden.

Nextcloud Security Scan

Ein weiterer Sicherheits-Check ist der Nextcloud Security Scan. Hier werden öffentlich verfügbare Informationen (z.B. Nextcloud-Version und vom Webserver ausgelieferte HTTP-Header) überprüft.

Auch hier sollte mit der aktuellen Konfiguration mindestens ein ‚A‘-Rating erreicht werden können. Der einzige Punkt, der hier „Hardenings“ als verbesserungswürdig angezeigt wird, ist „__Host-Prefix“. Dies hat allerdings etwas damit zu tun, dass die Cloud über ein Unterverzeichnis des Webroots aufgerufen wurde und nicht im Webroot selber liegt. Der Punkt stellt somit kein Sicherheitsrisiko dar.

Troubleshooting

Wenn die Einrichtung von Nextcloud nicht wie im Tutorial beschrieben klappen möchte, hier noch ein Hinweis für die Fehlersuche: Es ist wirklich wichtig, dass alle Punkte des Artikels befolgt wurden. Die Praxis zeigt leider, dass die Installation einer Cloud alles andere als trivial ist und man schnell mal einen kleinen Punkt übersieht. Im schlimmsten Fall kann das dann dazu führen, dass „das große Ganze“ dann nicht mehr wie erwartet funktioniert.

In diesem Fall gibt es drei Ansatzpunkte, die zur Lösung des Problems beitragen können oder zumindest einen Hinweis liefern können, wo es genau hakt:

  • nginx Error-Log (zu finden unter /var/logs/nginx/error.log): Dies ist der allgemeine Error-Log von nginx. Hier findet man alle Warnungen und Fehler, die beim Webserver aufgetreten sind. Dies ist meist die wichtigste Anlaufstelle, wenn irgendwelche Probleme auftreten.
  • Nextcloud-Log (zu finden unter /var/nextcloud_data/nextcloud.log): Hier werden Warnungen und Fehler seitens Nextcloud gelistet. Die gleichen Einträge findet man in der Admin-Oberfläche der Cloud. Hier sollte man nachgucken, wenn die Cloud prinzipiell schon mal zu erreichen ist (der Webserver also vermutlich richtig konfiguriert wurde), es aber trotzdem zu Problemen kommt.
  • Chrome Developer Console: Die Developer Console hilft in vielen Fällen, wenn anscheinend gar nichts funktioniert und in beiden o.g. Log-Dateien keine hilfreichen Einträge zu finden sind. Hier wird genau aufgelistet, was mit einem abgesetzten Request passiert. Meist liefert das schon einen konkreten Hinweis auf das Problem.

Einige Probleme scheinen häufiger aufzutreten als andere. Die folgende Liste bietet eine Übersicht über bekannte Probleme und den dazu passenden Lösungen:

Bekannte Probleme und Lösungen

Bei der Ausführung des Cronjobs kommt es zu Fehlern bzgl. Caching/APCu

Es kann passieren, dass im Nextcloud-Log in regelmäßigen Abständen (alle 15 Minuten) folgende Fehlermeldungen zu sehen sind:

Memcache \OC\Memcache\APCu not available for distributed cache
Memcache \OC\Memcache\APCu not available for local cache

Dies liegt meist darin begründet, dass der Cronjob mittels PHP-CLI abläuft, CLI allerdings kein APCu nutzen kann. In diesem Fall muss die php.ini angepasst werden:

Folgender Wert muss hier noch hinzugefügt werden:

Dies sorgt dafür, dass CLI vom Caching über APCu Gebrauch machen kann.

Abschließende Worte

Das war nun eine ganze Menge Arbeit, die sich jedoch gelohnt hat: Ab sofort ist man Herr über die eigenen Daten, ohne von irgendwelchen Cloud-Diensten abhängig zu sein. Man sollte sich nur im Klaren darüber sein, dass das Hosten der eigenen Cloud auch etwas administrativen Aufwand mit sich bringt. Man sollte regelmäßig Updates des Betriebssystems einspielen (apt-get update && apt-get upgrade -V) und auch Nextcloud selbst auf dem aktuellsten Stand halten. Dieser Aufwand hält sich allerdings sehr in Grenzen.

Ich hoffe, dass der Artikel hilfreich ist und so manch einem etwas Zeit (und v.a. Nerven!) bei der Einrichtung der eigenen Cloud sparen kann.
Auch freue ich mich immer über konstruktive Kritik oder Verbesserungsvorschläge. Hinterlasst mir dazu doch einfach einen Kommentar.

Weiterführende Artikel

Links

, , , , , , , , , , , , , ,

Kommentare: 582

  • Hans sagt:

    Hallo Jan, wie immer super Anleitung.

    Habe Nextcloud mit deiner Anleitung von owncloud (umgeschrieben) installiert und bin auf 1-2 Probleme gestoßen die ich mit dieser Anleitung eben beheben konnte.

    Gruß Hans

  • Hans sagt:

    Hallo Jan,

    ich habe im Log von Nextcloud folgende Einträge.

    Memcache \OC\Memcache\APCu not available for distributed cache
    Memcache \OC\Memcache\APCu not available for local cache

    Alle 15 min.

    Hast du eine Idee?

    Vielen Dank

    • Jan sagt:

      Hi Hans,

      kann ich auf meiner Test-Installation leider nicht nachvollziehen.
      Wenn es alle 15 Minuten kommt: Passiert das zufälligerweise immer dann, wenn der Cronjob läuft? Wenn dem so ist, dann kannst du mal versuchen, in der Datei /etc/php/7.0/cli/php.ini folgenden Wert zu setzen: apc.enable_cli = 1. Eigentlich wird das nicht benötigt, ich kann mir die Meldung in den Logs aber momentan nicht anders erklären.

      Gruß,
      Jan

      • Hans sagt:

        Hi Jan,

        genau alle 15 min. wird der Fehler in das Log geschrieben,

        Mit dem Eintrag (apc.enable_cli = 1) ist der Fehler jetzt weg,

        Vielen Dank

        • Jan sagt:

          Hi Hans,

          OK, danke für die Rückmeldung. Vielleicht nehme ich diese Anweisung dann auch noch in das Tutorial mit auf.
          Wundert mich nur, dass das Problem bei mir nicht auftritt (ohne, dass der Wert gesetzt ist). Ich werde mal schauen, ob sich noch mehr Leute mit dem Problem melden.

          Gruß,
          Jan

          • Daniel sagt:

            Hi Jan,

            nur kurze Rückmeldung: Hans war nicht der einziger mit dem Fehler.
            Mit apc.enable_cli = 1 in der Datei /etc/php/7.0/cli/php.ini ist der Fehler aber weg.

            Gruß,
            Daniel

  • emi sagt:

    Danke für die klasse Anleitung.
    Als Anwender mit recht geringem Linuxgrundkenntnissen (oder vergessenem Wissen) hilft sie enorm, besonders durch die zusätzlichen Erklärungen.

    Eine Frage blieb mir noch offen:
    Beim initialen Start von Nextcloud wird auch der Port der DB am erfragt.
    Ist dieser bei dem Setup relevant?
    Müsste dass dann hier nicht 82 sein (vermutlich habe ich einen gewaltigen Denkfehler)?

    Es funktioniert auch mit dem Beispielport 5432 :-)
    Standard wäre ja 3306 daher meine Frage.

    Grüße,

    emi

    • Jan sagt:

      Hi emi,

      beim Setup von Nextcloud kann ein Port (oder Socket) angegeben werden, das ist richtig. Ist allerdings vollkommen optional, wenn man auf eine lokale Datenbank zugreift („localhost“). Das spielt denke ich nur eine Rolle, wenn man einen dedizierten Datenbank-Server verwendet, auf den man dann über das Netzwerk zugreift. Ansonsten während des Setups einfach „localhost“ eintragen.
      Nur der Port 82 ist von der Logik her nicht ganz korrekt: Der Datenbank-Port hat nichts mit den Ports zu tun, die in den nginx vHosts eingetragen werden. Die vHosts werden per HTTP über diese Ports angesprochen (z.B. 82), das andere ist nur die Verbindung zur Datenbank.

      Gruß,
      Jan

  • Bernd sagt:

    Hi Jan,
    Wieder eine klasse Anleitung!
    Die werd ich nächstes Wochenende gleich ausprobieren und die Nextcloud neu aufsetzen.
    Das wird zwar wieder n Kraftakt die Daten und User umziehen aber das nehme ich gerne in Kauf! Die aktuellen 400GB reichen aktuell auch gerade so…. und mit der Neuinstallation kann ich auf 1 TB erweitern!
    Vielen Dank

    Gruß Bernd

    • Jan sagt:

      Hi Bernd,

      danke für das Lob!
      Wenn es um den Umzug auf einen anderen Rechner geht: Nextcloud auf anderen Rechner umziehen
      Wenn die neue Cloud auf dem gleichen PC geht, ist die Sache noch einfacher: Hier kann ja die Datenbank und das Datenverzeichnis einfach so übernommen werden. Hier reicht es dann prinzipiell aus, Nextcloud neu herunter zu laden, zu entpacken und die notwendigen Anpassungen in der config.php vorzunehmen.

      Gruß,
      Jan

  • Bernd sagt:

    in sowas bin ich nicht so geübt.
    Die Cloud ist auf einem Proxmox virtualisiert.
    KA wie ich die Sachen von A nach B bekomme :) aus dem Grund soll jeder ein Backup machen und ich setze neu auf!
    Aber vielen Dank für den Hinweis.

    Gruß Bernd

    • Jan sagt:

      Hi Bernd,

      aus dem Grund soll jeder ein Backup machen

      Jeder User? Das ist eigentlich nicht notwendig. Wenn du die Datenbank, das komplette Datenverzeichnis und die config.php auf den neuen Rechner/VM überträgst, werden sämtliche Daten aller User mitgenommen.
      Wenn du natürlich komplett von vorn starten möchtest (also ohne Übernahme von Daten), dann sollte jeder ein Backup machen. In diesem Fall ist die Gefahr aber groß, dass irgendwas vergessen wird, was dann erst später auffällt.

      Gruß,
      Jan

  • Frank sagt:

    Hi Jan,

    Super Anleitung!

    Ein kleines Problem habe ich doch.

    Bei der Generierung des SSL-Zertifikats mit Let’s Encrypt bekomme ich die Fehlermeldung “ The server could not resolve a domain name :: No valid IP addresses found for…“.
    In deiner Beschreibung hierzu verweist Du auf die Hilfe von GoIP. Hier wir für einen Cisco Router auf die Zeilen…

    =========
    ip ddns update method goip
    & HTTP
    add https://goip.de/setip?username=&password=&subdomain=.goip.de
    remove https://goip.de/setip?username=&password=&subdomain=.goip.de
    interval maximum 1 0 0 0
    !

    und

    interface Dialer0
    ip ddns update hostname .goip.de
    ip ddns update goip
    .
    .
    .
    =============

    …verwiesen.

    Wo müsste ich diese Zeilen einfügen, damit ich hinter dem Router mit meinem Server das SSL-Zertifikats mit Let’s Encryp generieren kann.

    Vielen Dank für deine Unterstützung.

    Gruß
    Frank

    • Jan sagt:

      Hi Frank,

      die Anleitung bei GoIP ist in der Tat etwas dürftig. Ich habe leider noch nie mit einem Cisco Router gearbeitet, aber die Befehle müssen definitiv direkt am Router selbst eingegeben werden, also nicht auf der Linux-Maschine, auf der die Cloud später laufen soll.

      Gruß,
      Jan

      • Frank sagt:

        Hi Jan,

        die Anleitung für GoIP ist aus meiner Sicht schon ok so. Wenn alle Eventualitäten beschrieben werden müssten, dann hätte deine Anleitung sicherlich eine Rolle Toilettenpapier als Erweiterung, um alles zu beschreiben.

        Mit GoIP (oder anderem IP Hoster) komme ich daher leider so nicht weiter, weil ich das SSL-Zertifikat über Let’s Encrypt nicht generieren kann. Let’s Encrypt akzeptiert leider keine reinen IP-Adressen.

        Hast Du per Zufall noch eine Idee, wie ich Let’s Encrypt überreden kann (z.B. ddclient, etc.)? Mein Cisco Router akzeptiert für DDNS-Einstellungen leider nur DynDNS und TZO…

        Gruss,
        Frank

        • Jan sagt:

          Hi Frank,

          genau, Let’s Encrypt funktioniert nicht bei reinen IP-Adressen.
          Genau das ist ja der Sinn von DynDNS: Das Abbilden einer Domain (irgendwas.goip.de) auf die (externe) IP deines Routers. Die Domain verweist dann immer auf die aktuelle IP-Adresse, so dass alle Anfragen aus dem Web dann an diese IP-Adresse weitergeleitet werden. Ob das Ganze auch funktioniert, kannst du relativ schnell überprüfen: Über die Kommandozeile führst du einfach einen Ping auf deine DynDNS-Adresse aus (ping irgendwas.goip.de). Wenn die DynDNS-Adresse aufgelöst werden kann, dann zeigt ping auch die IP dieser Domain an. Diese sollte dann der externen IP deines Routers entsprechen.

          Mehr kann ich dazu leider nicht sagen, da ich das beschriebene Szenario noch nie auf einem Cisco-Router ausprobieren konnte. Hier habe ich noch eine Anleitung für Cisco-Router gefunden, welche allerdings die Verwendung von no-ip.com als DynDNS-Dienst verwendet. Vielleicht hilft dir ja das schon weiter.

          Gruß,
          Jan

  • Kai sagt:

    Hallo Jan,
    vielen Dank für deine Anleitung. Diese ist wirklich sehr sehr gut und ausführlich. Ich konnte letztes Wochenende erfolgreich eine VM mit Ubuntu und Nextcloud aufsetzen.
    Als Idee für eine Erweiterung des Artikels oder Folgeartikel: Update der bestehenden Nextcloud auf neue Releases. (z.B. 12.0.3 oder 12.1)

    Werde deine Webseite jetzt wohl regelmäßig besuchen! ;-)

    Viele Grüße
    Kai

    • Jan sagt:

      Hallo Kai,

      zunächst einmal danke für das Lob!
      Ich habe hier bereits einen Artikel über die Durchführung von ownCloud verfasst. Seit Nextcloud hat sich hier einiges (zum Positiven) verändert, die Updates sind nun meist problemlos und ohne großen Aufwand durchzuführen. Ich nehme deinen Vorschlag mal mit und werde wohl einen Folgeartikel schreiben, wenn das nächste Nextcloud-Update kommt.

      Gruß,
      Jan

  • Frank sagt:

    Hi Jan,

    manchmal sind die Dinge simpel….einfach alle Forwardingeinträge im Cisco löschen, Port 80/443 neu einrichten und schon hat es geklappt. Hat mich allerdings einige Zeit gekosten. Ein DynDNS-Dienst muss zunächst nicht auf dem Cisco eingerichtet werden, damit es mit dem Zertifikat funktioniert. Jetzt schaue ich einmal mit ddclient weiter.

    Eine Kleinigkeit habe ich noch. Wie schaffe ich es, die Datenbank auf eine andere Festplatte umzuziehen, ohne die Installation zu „zerschlagen“. Eine Idee habe ich hier (https://help.nextcloud.com/t/howto-change-move-data-directory-after-installation/17170) gefunden, bin mir aber nicht sicher, ob dies in diesem Fall auch klappt. Was meinst Du?

    Gruß,
    Frank

    • Jan sagt:

      Hi Frank,

      du meinst sicher das Datenverzeichnis (hier liegen die Daten der Cloud-User), nicht die Datenbank selbst (hier sind sämtliche Verwaltungsinformationen der Cloud enthalten).
      Die Anleitung, die du gefunden hat, ist schonmal ein guter Ansatzpunkt. Ich hätte das nun auch mal so wie unter „Solution 1“ beschrieben durchgeführt. Wie die Anleitung aber weiter ausführt, gibt es damit das Problem, dass die File-IDs neu vergeben werden. Das führt dann u.U. zu Nebeneffekten (Datei-Shares funktionieren vielleicht nicht mehr, vergebene Tags oder Kommentare sind nicht mehr verfügbar, etc.). Bei einer Cloud, in der sich eh noch keine Daten befinden, ist das sicherlich nicht weiter schlimm.

      Eine saubere Lösung wäre hier, Nextcloud nochmal komplett neu zu installieren: Datenbank entfernen (drop), config.php von Nextcloud löschen, danach wird das Setup beim Aufruf im Browser neu ausgeführt. Hier ist dann das neue Datenverzeichnis mit anzugeben. Nachdem dann alle User neu angelegt wurden (mit identischem Passwort, wenn die server-seitige Verschlüsselung aktiv war), können die Dateien aus dem alten Datenverzeichnis in das neue kopiert werden. Danach noch ein files:scan –all und das sollte es eigentlich gewesen sein.
      Aber egal, wie du nun vorgehst: Mach vorher ein Backup der bestehenden Nextcloud-Installation, man weiß ja nie…

      Ach ja: Wenn deine Kommentare hier nicht gleich angezeigt werden, sind diese nicht „verschwunden“, sondern nur im Spam-Filter gelandet. In diesem Fall einfach etwas warten, ich schalte diese Kommentare dann manuell frei. ;-)

      Gruß,
      Jan

      • Frank sagt:

        Hi Jan

        Grundsätzlich hat deine Lösung mit der Neuinstallation geklappt. Ich komme auf die Installationsseite, gebe die Daten brav ein und Nextcloud behauptet, es könne das Datenverzeichnis nicht erstellen oder darin nicht geschrieben werden…
        Die Datenbank hatte ich vorher wieder eingerichtet, die Pfade wo notwendig (nginx, etc.) entsprechend angepasst, die Rechte in den Zielordnern per chmod auf www-data gesetzt….und nun das…
        Bin ein wenig am verzweifeln. Selbst Dr. Google ist ratlos…
        Hast Du per Zufall noch eine Idee, woran es haken kann? Wäre genial!

        Gruß,
        Frank

        • Jan sagt:

          Hi Frank,

          ich weiß nicht genau, wo du dein Datenverzeichnis haben möchtest, ich gehe einfach mal von einem fiktiven Mount unter /mnt/exthdd aus. Dann müsste folgendes an der Konfiguration angepasst werden:

          • In /etc/php/7.0/cli/php.ini muss /mnt/exthdd in open_basedir mit aufgenommen werden (damit der Cronjob nachher Zugriff hat).
          • chown -R www-data:www-data /mnt/exthdd: Verzeichnisrechte setzen.
          • In /etc/nginx/conf.d/nextcloudtutorial.goip.de_nextcloud.conf: Hier muss das Verzeichnis in den Block fastcgi_param PHP_VALUE (Variable open_basedir) aufgenommen werden.

          Das sollten eigentlich alle Stellen gewesen sein, an den Anpassungen gemacht werden müssten.

          Gruß,
          Jan

          • Frank sagt:

            Hi Jan,

            Genau diese Änderungen hatte ich auch druchgeführt und es klappt leider einfach nicht…
            – In /etc/php/7.0/cli/php.ini „/media/user/Nr der ext4 festplatte/Ordner/Ordner“ bei open_basedir
            – chown -R www-data:www-data /media/user/Nr der ext4 festplatte/Ordner/Ordner
            – In /etc/nginx/conf.d/nextcloudtutorial.goip.de_nextcloud.conf bei fastcgi_param PHP_VALUE (Variable open_basedir) auf
            /var/www/:/tmp/:/media/user/Nr der ext4 festplatte/Ordner/Ordner abgeändert

            Ergebnis:
            Das Datenverzeichnis /var/www/:/tmp/:/media/user/Nr der ext4 festplatte/Ordner/Ordner kann nicht erstellt oder es kann nicht darin geschrieben werden.

            Muss ich die Platte vielleicht neu mounten um Erfolg zu haben?

            Gruß,
            Frank

          • Jan sagt:

            Hi Frank,

            um was für ein gemountetes Laufwerk handelt es sich hier? Irgendwas spezielles?
            Probier doch mal das Setzen der Rechte im Verbose-Mode: chown -Rv www-data /media/user…. Wird hier irgendwas Relevantes angezeigt?

            Gruß,
            Jan

          • Frank sagt:

            Hi Jan,

            aus meiner Sicht ist es kein spezielles Laufwerk (Raid1 aus zwei identischen HDD).

            Das setzen Setzen der Rechte im Verbose-Mode chown -Rv www-data /media/user… ergibt nicht auffälliges:

            „der Eigentümer von ‚/media/user…‘ wurde als www-data erhalten.“

            Wenn ich allerdings ’sudo -u www-data ls -lsia media/user…‘ probiere, sieht die Geschichte plötzlich anders aus:

            „ls: Zugriff auf ‚media/user…‘ nicht möglich: Keine Berechtigung

            Gruss,
            Frank

  • Daniel sagt:

    Wieso nutzt du /nginx/conf.d/ und nicht /nginx/sites-available/? Ist das nicht sauberer? Oder ich hab was missverstanden.

    • Jan sagt:

      Hi Daniel,

      wo die Config-Dateien der vHosts liegen, ist abhängig von der nginx-Version. In früheren Versionen von nginx war es durchaus üblich, die vHosts in sites-available bzw. sites-enabled zu speichern (so, wie es auch bei Apache üblich ist). Bei neueren Versionen gibt es nur noch ein Verzeichnis (/etc/nginx/conf.d): Wenn man einen vHost nun deaktivierten will, muss man die Datei nicht mehr von sites-enabled in sites-available verschieben, sondern es reicht hier, die Datei umzubenennen (so, dass diese nicht mehr auf *.conf endet).
      Das sind eigentlich nur unterschiedliche Konzepte, die beide gut funktionieren. Ich kann nicht erkennen, dass ein System das „sauberere“ sein sollte.

      Gruß,
      Jan

      • Daniel sagt:

        Ja, hast Recht, sollte beides funktionieren. Grundsätzlich erstellt man von sites-available zu sites-enabled (soweit mir das bekannt ist) einfach einen Symlink, den man ohne Probleme wieder löschen kann. Das Original bleibt unverändert unter sites-available. Mit deiner Lösung muss man halt wieder ein bisschen rumpfuschen und Dinge umbenennen, deswegen „sauberer“. Man „zerstört“ praktisch etwas, anstatt es einfach zu deaktivieren. Hat mich alles in allem nur gewundert, warum man bei nginx immer so viele verschiedene Tutorials mit unterschiedlichen Verzeichnisangaben findet.

        • Jan sagt:

          Hi Daniel,

          ja, wie schon gesagt, das hat sich bei verschiedenen nginx-Versionen immer mal wieder geändert. Meiner Meinung nach haben sie dadurch für ziemlich viel Verwirrung gesorgt. ;-)
          Und ob ich eine Datei nun umbenenne, oder einen Symlink anlege/lösche, ist vom Aufwand her egal. Für Anfänger ist es sicherlich einfacher, einfach die Datei per mv umzubenennen.

          Gruß,
          Jan

          • Daniel sagt:

            Hab es jetzt mal in conf.d hinterlegt. Weißt du zufällig noch, was genau ich am vHost anpassen müsste, um direkt über die Subdomain cloud.domain.tld auf die Cloud zu kommen (ohne /nextcloud)?

          • Jan sagt:

            Hi Daniel,

            ja, dazu muss der Gateway-Host angepasst werden location = / { ... }.
            Steht auch direkt schon als Kommentar in der conf-Datei drin, siehe hier.

            Gruß,
            Jan

  • Carsten sagt:

    Hallo Jan,

    habe meine Nextcloud mit der alten Anleitung installiert. Wollte nun die virtuellen Hosts nach der dieser neuen Anleitung ändern. Leider ist dann meine Cloud nicht mehr erreichbar. Verstehe nicht, warum das so ist. Hast du eine Idee?

    • Jan sagt:

      Hi Carsten,

      vermutlich ist hier etwas an den vHosts nicht korrekt eingestellt. Versuch mal den Befehl nginx -t, hier sollte dann ein evtl. vorhandenes Problem gezeigt werden.

      Gruß,
      Jan

      • Carsten sagt:

        Ich hatte zwischenzeitlich die vorhergehende Konfiguration wiederhergestellt. Danach wurden mir plötzlich diverse Fehler angezeigt. Datenbank ungültig. Kein Zugriff auf Datei . ocdata, obwohl vorhanden. Hab dann mein rsync backup von letzter Nacht wiederhergestellt. Probiere es morgen noch einmal. Vielen Dank für deine schnelle Antwort. Deine Anleitungen sind echt die besten.

        • Jan sagt:

          Hi Carsten,

          gut, wenn es nun wieder funktioniert.
          Wäre aber mal trotzdem interessant, was vorher schief gelaufen ist…

          Gruß,
          Jan

          • Carsten sagt:

            Konnte nun alle Einstellung auf die neue Anleitung anpassen. Die Cloud war nicht erreichbar, da deine Einträge alle auf nextcloud_data verwiesen, ich meine aber alle auf nextcloud-data hatte. Brauchte das nur anpassen. Den fehlenden Zugriff auf die Datenbank konnte ich beheben, indem ich das „Strong Directory Permissions“-Script von docs.nextcloud.com benutzte. Weder das aus deiner neuen, noch das aus deiner alten Anleitung gingen. Obwohl das Script aus der alten Anleitung monatelang funktionierte. Hab mir das noch nicht genau angeschaut, weiß nicht woran es liegt. Der Fehler lag auf jeden Fall bei mir. Danke für deine tolle Arbeit.

  • Hans sagt:

    Hallo, ein kleiner Tipp an alle Leser.
    Jan hat auch ein super Backup und Restore Skrip (Bash) geschrieben.

    Ich persönlich kenne keinen anderen der sich so viel Mühe macht eine deutsche Anleitung so verständlich zu erstellen und diese dann auch noch online stellt. Vielen Dank nochmal!

    Gruß Hans

    PS: Jan, könntest du noch ne eMail Benachrichtigung nach erfolgreichem Backup plus Log mit einbauen?

    • Jan sagt:

      Hi Hans,

      Wahnsinn, kaum ist das Skript online, schon wird es gefunden. ;-)
      Warte mal ab, ein entsprechender Artikel mit mehr Infos ist bereits in der Pipeline…
      Es geht übrigens um diese Skripte: https://github.com/DecaTec/Nextcloud-Backup-Restore

      Die Mail-Benachrichtigung ist nicht ganz so einfach, weil diese direkt aus der Linux-Kommandozeile versendet werden muss. Aber auch her habe ich schon was in Planung.

      Gruß,
      Jan

      • Bernd sagt:

        Jow sehr sehr nice!
        Freu mich drauf!
        Kann man die Backupfules mit dem script dann direkt im Data Directory vom Admin login aus hoch und runterladen.

        Vielen dank für die Zeit und die klasse Arbeit.

        Gruß Vernd

        • Jan sagt:

          Hallo Bernd,

          willst du die Backup-Files wieder direkt in der Cloud speichern?
          Das würde nicht viel Sinn machen, da die Daten (die Cloud) und die Backup-Dateien dann auf dem gleichen Rechner auf der gleichen Festplatte liegen würden. Wenn der Rechner abrauchen sollten, dann wäre im schlimmsten Falle alles weg. Daher sollten die Backup-Files zumindest auf einer anderen Festplatte oder sogar auf einem anderen Rechner liegen.

          Mehr dazu dann im entsprechenden Artikel.

          Gruß,
          Jan

  • Hans sagt:

    Hallo Jan, Twitter machts möglich 😉.

    Gruß Hans

  • Matthias Böttcher sagt:

    Hallo Jan,

    warum gehst du denn den Umweg von Port 443 über proxy_pass http://127.0.0.1:82, warum lässt du den Vhost für nextcloud nicht direkt an 443 lauschen?

    Eine sehr gute und detaillierte Anleitung – Danke!
    Ich werde sie für mich für Debian 9 mit certbot (statt letsencryot) und MariaDB und nginx aus dem Debian-Repository adaptieren.

  • QuelonaSec sagt:

    Gute Anleitung.

    Eine kurze Randbemerkung: Durch das Permissions-Skript funktioniert die Updater-App nicht. In der aktuellen Version fehlt daher auch der entsprechende Hinweis in den Docs:

    https://github.com/nextcloud/documentation/pull/431

    Ob die eingeschränkten Rechte die Sicherheit tatsächlich erhöhen (oder nur ein „gutes“ Gefühl vermitteln) ist mir nicht ganz klar. Was denkst du dazu?

    Mir scheint der Sicherheitsgewinn größer, wenn ich möglichst schnell und einfach (z.B. auch wenn ich unterwegs bin) aktuelle Sicherheitsfixes einspielen kann.

    Sinnvoller erscheint mir die Cloud in ein lokales Netz zu verlagern und den Usern dorthin VPN Zugang zu gewähren. Natürlich ist das, wie immer, ein Abwägen zwischen Sicherheit und Usability.

    • Jan sagt:

      Hi,

      danke für den Hinweis!
      In der Tat wurden alle Hinweise auf die „Strong Directory Permissions“ in der Nextcloud-Doku entfernt. Ich denke , dass diese Einstellung nicht essentiell war: Wer erst einmal auf dem System eingedrungen ist, hat andere Möglichkeiten. Ich vermute aber auch mal stark, dass an einem Autoupdate-Mechanismus gearbeitet wird (ähnlich wie bei WordPress) und hier würden diese speziellen Verzeichnis-Berechtigungen einen Strich durch die Rechnung machen.

      Ich habe den Hinweis auf die Verzeichnis-Berechtigungen im Artikel entfernt.

      Gruß,
      Jan

      • QuelonaSec sagt:

        Hast du auf 12.03 über die GUI updaten können? Bei mir klappt leider immer noch nicht. Beim Klick auf den entsprechenden Buttom im Admin-Menü passiert nichts (weiße Seite mit Nextcloud Kopfzeile und der linken Navigationsleiste).

        Im Chrome wird im Inspektor (Network) an der Stelle ein Redirect gemeldet (301 oder 302 – weiß gerade nicht mehr genau…).

        Kann es sein, dass Nginx da irgendwo zu streng ist? :-)

        Wie dem auch sei: manuell hat es dann funktioniert.

        https://docs.nextcloud.com/server/12/admin_manual/maintenance/update.html#using-the-command-line-based-updater

        • Jan sagt:

          Hi,

          das Update 12.0.3 hat bei mir problemlos über die Admin-UI geklappt. Gab es bei dir irgendwelche Fehler im Nextcloud-Log?
          Aber ja, es gibt zum Glück mehrere Möglichkeiten das Update durchzuführen (siehe hier). Wenn eine nicht klappt, bleiben ja noch zwei andere… ;)

          Gruß,
          Jan

      • Marv sagt:

        Hallo und danke für die Anleitung ich habe sie schon vor ein paar Wochen eingerichtet, meine NExtcloud dank der Anleitung.

        Welche Rechte sollte ich jetzt wo und wie ändern?

        Grüße
        Marv

        • Jan sagt:

          Hi Marv,

          du beziehst dich hier sicher auf das Update des Artikels am 23.09., oder?
          Hierzu einfach folgende Rechte setzen:
          chown -R www-data:www-data /var/www/nextcloud
          chown -R www-data:www-data /var/nextcloud_data

          Gruß,
          Jan

  • Hans sagt:

    Hallo,

    kennt einer zufällig ne gute Anleitung für Collabora Online mit Ngnix auf deutsch.

    Wäre klasse!

    Vielen Dank

    Gruß Hans

    • Jan sagt:

      Hi Hans,

      die Sache mit Collabora scheint nicht ganz so einfach zu sein, aber ein guter Ansatzpunkt könnte dieser Artikel sein.
      Wenn Bedarf besteht, könnte ich mir die Sache auch mal genauer ansehen und ggf. eine Anleitung verfassen, die in mein bestehendes Konzept (Gateway-Host, etc.) passt.

      Gruß,
      Jan

      • Hans sagt:

        Hallo Jan,

        danke, ich kämpfe mich mal da durch.
        Ne Anleitung von dir ist natürlich auf deutsch besser, allein vom Verständnis her.

        Vielen Dank

        Gruß Hans

        • Jan sagt:

          Hi Hans,

          wenn ich wieder mal etwas Zeit über habe, kann ich mich ja mal mit dem Thema Collabora beschäftigen.
          Wenn du bis dahin irgendwelche Erkenntnisse sammeln konntest, dann kannst du dich ja nochmal melden (gern auch per Mail).

          Gruß,
          Jan

        • Jan sagt:

          Hi Hans,

          habe es auf meiner Test-Cloud hinbekommen mit Collabora. Brauche nun nur etwas Zeit, dazu einen Artikel zu verfassen.

          Gruß,
          Jan

          • QuelonaSec sagt:

            Ich hätte daran auch Interesse. Der Webserver aus diesem Artikel könnt dann doch direkt als Proxy für eine Collbora-VM dienen?

            Muss Collabora dann von außen erreichbar sein, oder reicht es wenn Nextcloud es intern sehen kann?

          • Jan sagt:

            Hi,

            ich arbeite mich gerade etwas in das Thema ein. Auf meiner Test-Installation habe ich Collabora über Docker verfügbar gemacht – also keine eigen VM. Zugriffe werden dann durch nginx als Reverse-Proxy geroutet.
            Stay tuned, sicherlich werdet ihr bald hier zu dem Thema etwas lesen können. ;)

            Gruß,
            Jan

  • Marco sagt:

    Hallo Jan,

    Chapeau! Ich ziehe meinen Hut.

    Danke für dieses klasse Tutorial. Es gibt gaube ich nicht sehr viele Menschen im Internet die Ihr Wissen so ausführlich teilen. Danke.

    FYI:
    Ich hatte einen Fehler bei der Nextcloud Installation. Ich konnte mich einfach nicht mitt der Datenbank verbinden obwohl alles gestimmt hat…..
    Ich habe User und DB neu erstellt aber nichts half.
    Die Lösung ist so dermaßen simpel, dass es schon fast blöd ist.
    Sobald man die Kennwörter(Nextcloud oder MariaDB oder beide) per C&P einfügt gibt es einen DB Fehler. Trägt man diese von Hand ein funktioniert alles ;) Nur falls mal jemand darüber stolpert.

    Nun habe ich allerdings auch noch ein Problem mit dem Upload von großen Datein. Lade ich ein Ubuntu ISO mit ~800MB hoch, kein Problem. Eine ~2GB ISO verursacht folgende Exception:

    Fatal webdav Sabre\DAV\Exception\BadRequest: expected filesize 2245081088 got 21527183360./var/www/nextcloud/apps/dav/lib/Connector/Sabre/Directory.php – line 151: OCA\DAV\Connector\Sabre\File->put(Resource id #18)
    1./var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php – line 1096: OCA\DAV\Connector\Sabre\Directory->createFile(‚VeeamBackup&Rep…‘, Resource id #18)
    2./var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/CorePlugin.php – line 525: Sabre\DAV\Server->createFile(‚VeeamBackup&Rep…‘, Resource id #18, NULL)
    3.[internal function] Sabre\DAV\CorePlugin->httpPut(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))
    4./var/www/nextcloud/3rdparty/sabre/event/lib/EventEmitterTrait.php – line 105: call_user_func_array(Array, Array)
    5./var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php – line 479: Sabre\Event\EventEmitter->emit(‚method PUT‘, Array)
    6./var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php – line 254: Sabre\DAV\Server->invokeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))
    7./var/www/nextcloud/apps/dav/appinfo/v1/webdav.php – line 76: Sabre\DAV\Server->exec()
    8./var/www/nextcloud/remote.php – line 162: require_once(‚/var/www/nextcl…‘)
    9.{main}

    Ich denke nicht, dass Nextcloud hier prinzipiell ein Problem hat. Mit meiner Nextcloud Installation auf Apachebasis funktioniert das tadellos.
    Weist du hierzu eine Lösung?

    Grüße

  • Marco sagt:

    Ok, ich habe den Fehler gefunden.

    Ich hatte die Einstellungen in der PHP.ini so:
    (falsch) cgi.fix_pathinfo=0

    korrekt ist es aber so
    (richtig) cgi.fix_pathinfo = 0

    Wahnsinn, dass das einen Unterschied macht…

    • Jan sagt:

      Hi Marco,

      erstmal danke für das Lob, sowas hört man gerne!

      Das mit Copy&Paste über PuTTY ist immer etwas tückisch, meiner Erfahrung nach passiert es hier häufig, dass hier zu viel oder zu wenig kopiert/eingefügt wird. Daher mache ich das immer schön manuell. ;)

      Mit deinem anderen Problem mit den großen Uploads: Bist du sicher, dass das Einfügen von Leerzeichen etwas bewirkt hat? Eigentlich sollte dies gar keinen Unterschied machen. Sieht man sich mal eine Standard-php.ini an, dann werden viele Werte mal mit, mal ohne Leerzeichen beim „=“ angegeben.
      Des weiteren sieht es für mich auch nicht so aus, als ob cgi.fix_pathinfo etwas mit der Fehlermeldung zu tun hat.

      Aber wenn es bei dir geholfen hat, dann bin ich echt so verwundert wie du. Beobachte das Verhalten mal weiter, ob das Problem vielleicht wieder auftritt. Würde mich echt mal interessieren, ob es was mit den Leerzeichen zu tun haben kann.

      Gruß,
      Jan

      • Marco sagt:

        Hallo Jan,

        das mit „cgi.fix_pathinfo=0“ war nur ein Beispiel. Im Endefekt waren alle Optionen im PHP Block bei mir so, also ohne Leerzeichen.

        Ich habe es gerade nochmal getestet. Bei mir ist das devinitiv reproduzierbar.

        5GB Rar Datei über Firefox hochgeladen – funktionert.
        PHP Optionen angepasst, also Leerzeichen raus.
        Gleiche 5GB Rar Datei über Firefox hochgeladen – Exception
        Wieder PHP Optionen angepasst – funktionert.

        Was mir auch noch aufgefallen ist. Wenn ich die Leerzeichen entferne und meine Netzzwerkauslastung beobachte sehe ich, dass der Upload stark schwankt. So zwischen 980 und 40 MBit/s.

        Sobald ich die Leerzeichen setze läuft der Upload konstant zwischen 980 und 960 MBit/s durch.

        Klingt komisch, ist aber so! ;)

  • Jonas sagt:

    Hallo Jan.

    Erstmal vielen Dank für dein Tutorial. Nach Tagen der Verzweiflung als Linuxneuling läuft die Cloud perfekt.

    Wie oben erwähnt habe ich so gut wie keine Ahnung, deshalb verzeih die möglicherweise blöden Fragen.

    Auf meinem NAS läuft Ubuntu Server 16.04 mit folgenden Diensten:

    Nextcloud (seit heute, hab Dank)
    Emby

    Emby würde ich nun auch gern über meine Domain erreichen, am besten wie folgt:

    emby = domain.net/
    nextcloud = domain.net/nextcloud

    Vorher hatte ich einen einfachen Reverseproxy mit folgendem Block:

    #Emby
    location / {
    # Send traffic to the backend
    proxy_pass http://192.168.0.102:8096;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-for $proxy_add_x_forwarded_for;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $remote_addr;
    proxy_set_header X-Forwarded-Protocol $scheme;
    proxy_redirect off;

    # Send websocket data to the backend aswell
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection „upgrade“;
    }

    Mit der Konfiguration war ich jedoch nicht in der Lage Nextcloud zum Laufen zu bringen.

    Hast Du für mich einen Rat/Tipp?

    Vielen Dank für deine Hilfe,

    Gruß Jonas

    • Jan sagt:

      Hi Jonas,

      hier muss man auf jeden Fall Hand am Gateway-Host anlegen. Vermutlich steht bei dir hier folgendes drin:
      location = / {
      # Disable access to the web root, otherwise nginx will show the default site here.
      deny all;
      }

      Genau in diesen Block würde mich mal die Weiterleitung auf Emby einbauen:
      #Emby
      location = / {
      # Send traffic to the backend
      proxy_pass http://192.168.0.102:8096;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-for $proxy_add_x_forwarded_for;
      proxy_set_header Host $host;
      proxy_set_header X-Forwarded-Proto $remote_addr;
      proxy_set_header X-Forwarded-Protocol $scheme;
      proxy_redirect off;

      # Send websocket data to the backend aswell
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
      }

      Wenn es das noch nicht tut, dann versuch mal, das „=“ aus dem location-Block raus zu nehmen.

      Gruß,
      Jan

      • Jonas sagt:

        Hi Jan. Vielen Dank für deine schnelle Hilfe. Leider führt es nicht zum Erfolg:

        nginx: [emerg] duplicate location „/“ in /etc/nginx/conf.d/domain.de.conf:94

        Egal ob mit oder ohne „=“.

        So sieht der Teil aus:

        location = / {
        # Disable access to the web root, the Nextcloud subdir should be used instead.
        deny all;

        # If you want to be able to access the cloud using the webroot only, use the following command instead:
        # rewrite ^ /nextcloud;
        }
        #Emby
        location / {
        # Send traffic to the backend
        proxy_pass http://192.168.0.102:8096;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-for $proxy_add_x_forwarded_for;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $remote_addr;
        proxy_set_header X-Forwarded-Protocol $scheme;
        proxy_redirect off;

        # Send websocket data to the backend aswell
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection „upgrade“;

        }

        #
        # Nextcloud
        #
        location ^~ /nextcloud {
        # Set max. size of a request (important for uploads to Nextcloud)
        client_max_body_size 10G;
        # Besides the timeout values have to be raised in nginx‘ Nextcloud config, these values have to be raised for the proxy as well
        proxy_connect_timeout 3600;
        proxy_send_timeout 3600;
        proxy_read_timeout 3600;
        send_timeout 3600;
        proxy_buffering off;
        proxy_max_temp_file_size 10240m;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_pass http://127.0.0.1:82;
        proxy_redirect off;

        }

        Wahrscheinlich übersehe ich durch meine Unwissenheit nur irgendwas?
        Vielen Dank und Gruß, Jonas

        • Jan sagt:

          Hi Jonas,

          ja, die /-location ist zwei mal vorhanden. Bei deiner bestehenden Config einfach die erste /-location entfernen, also diesen Teil:
          location = / {
          # Disable access to the web root, the Nextcloud subdir should be used instead.
          deny all;

          # If you want to be able to access the cloud using the webroot only, use the following command instead:
          # rewrite ^ /nextcloud;
          }

          Danach sollte zumindest der Fehler beim Neustarten von nginx verschwunden sein.

          Gruß,
          Jan

          • Jonas sagt:

            Guten Abend Jan. Nur als kurzes Feedback: das war der Tipp!

            Haben vielen Dank für dein ausgesprochen gutes Tutorial und deine persönliche, sehr schnelle und kompetente Hilfe.

            Grüße, Jonas

  • Hendrik sagt:

    Hi Jan,
    dank deiner super Anleitung habe ich nextcloud gerade auf einem banana pi mit OS armbian (stretch) installieren können.

    Auf dem Pi würde ich gerne auch noch pi hole installieren. Da die Kiste eh den ganzen Tag rennt kann sie auch den DNS Verkehr regeln.

    Leider bekomme ich das nicht hin :-(

    In der gateway.conf habe ich folgendes eingetragen:
    location ^~ /piholeadmin {
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For
    $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_pass http://127.0.0.1:83;
    proxy_redirect off;
    }

    Dann eine neue pihole.conf angelegt:
    server {
    listen 83;
    server_name 127.0.0.1;
    root /var/www/;
    index index.html index.htm index.php;

    location / {
    expires max;
    return 204 ‚pixel‘;
    }

    location /piholeadmin {
    root /var/www;
    index index.php;
    }

    location ~ \.php$ {
    try_files $uri =404;
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_param PATH_INFO $fastcgi_path_info;
    fastcgi_pass php-handler;
    fastcgi_connect_timeout 60;
    fastcgi_index index.php;
    }
    }

    Tja, leider zeigt sich gar keine Seite. Irgendwann kommt ein timeout. Google hat da auch noch keine gute Idee gehabt bzw. ich habe sie nicht gefunden.

    Hast du vielleicht einen Tipp für mich?

    Gruß
    Hendrik

    • Jan sagt:

      Hi Hendrik,

      anhand der Config schwer zu sagen. Diese sieht zunächst einmal gut aus.
      Hinweise findest du vermutlich in der error.log von nginx. Ein weiterer Ansatzpunkt wäre die Developer Console von Chrome. Hier findest du meist Hinweise, wenn hier irgendwelche Redirects, etc. nicht passen.
      Wenn du magst, dann schick mir doch mal die error.log und deine Domain per Mail. Dann kann ich mir das in einer ruhigen Minute mal ansehen.

      Gruß,
      Jan

      • Hendrik sagt:

        Hi Jan,
        danke für dein freundliches Angebot !

        Ich habe noch etwas rumgespielt und mit folgenden Einstellungen kann ich pihole über die interne IP Adresse ansprechen.
        Das reicht mir vollkommen aus, denn von extern will ich da gar nicht drauf.

        # location ^~ /html/admin {
        # proxy_pass http://localhost:83/admin/;
        # proxy_set_header Host $host;
        # proxy_set_header X-Real-IP $remote_addr;
        # proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        # }

        Gruß
        Hendrik

  • Michael Werner sagt:

    Ich finde solche Tutorial einfach klasse! Liegt wohl daran das ich das alles nicht kann. Solche Tutorials ermöglichen mir aber halt doch so einiges machen zu können was mir sonst nicht möglich wäre. Hier mal vielen Dank dafür. Ich habe mir das mal alles auf meinen ubuntu home Server installiert,
    was auch alles tadellos funktioniert. Was ich mir aber wünschen würde, wäre
    das der Aufruf meiner Website, nicht mit domain.de/wordpress sondern halt domain.de klappen würde. was muss ich tun damit ich das Unterverzeichnis beim Webside aufruf los werde. LG euch allen M.Werner

    • Hendrik sagt:

      Hi Michael,
      in der gateway.conf musst du nur zwei Zeichen tauschen:

      ORIGINAL
      location = / {
      # Disable access to the web root, the Nextcloud subdir should be used instead.
      deny all;

      # If you want to be able to access the cloud using the webroot only, use the following command instead:
      # rewrite ^ /nextcloud;
      }

      ÄNDERUNG
      location = / {
      # Disable access to the web root, the Nextcloud subdir should be used instead.
      #deny all;

      # If you want to be able to access the cloud using the webroot only, use the following command instead:
      rewrite ^ /nextcloud;
      }

      => Raute hinzufügen vor ‚deny all‘ und Raute entfernen vor ‚rewrite ….‘

      Dann service nginx restart

      und schon kannst du mit domain.de wordpress aufrufen.

      Gruß
      Hendrik

  • Hendrik sagt:

    Hi Jan,
    ich bin gestern – mal wieder – über die bruteforce Einstellung gestolpert. Zwar habe ich den Eintrag vorgenommen, aber es waren schon IP Adressen hinterlegt.
    Die Lösung ist relativ trivial:

    1. in mysql einloggen
    2. folgende Befehle absetzen:

    use nextcloud_db;
    DELETE FROM oc_bruteforce_attempts;

    3. nextcloud genießen ;-)

    Vielleicht magst du das ja in deinem Tutorial noch ergänzen.
    Gruß
    Hendrik

  • Hans sagt:

    Hallo Jan,

    ich habe mir testweise einen V-Server bei Strato geholt und auf diesem NC nach deiner Anleitung installiert. Zusätzlich habe ich meine Domain auf den Server umgeleitet – funktioniert soweit ganz gut.

    Jetzt rufe ich meine Seite (mycloud.de/nextcloud) auf und erhalte 502 Bad Gateway und im Log von Nginx wird folgender Fehler ausgegeben.

    2017/09/29 12:04:45 [crit] 709#709: *4 connect() to unix:/run/php/php7.0-fpm.sock failed (13: Permission denied) while connecting to upstream, client: 127.0.0.1, server: 127.0.0.1, request: „GET /nextcloud HTTP/1.0“, upstream: „fastcgi://unix:/run/php/php7.0-fpm.sock:“, host: „mycloud.de“

    Vielen Dank

    PS: ich antworte dir auf deine Email später :)

    Gruß Hans

    • Jan sagt:

      Hi Hans,

      wie die Sache auf einem V-Server aussieht, habe ich noch nicht probieren können.
      Die Fehlermeldung sieht so aus, als ob hier Berechtigungen fehlen, um PHP über einen Socket zu nutzen. Dazu schau einfach mal in die passende Konfiguration (nano /etc/php/7.0/fpm/pool.d/www.conf): Hier muss der richtige user/group angegeben werden. Weiter unten findest du dann listen.owner und listen.group, hier müsste der gleiche User/Gruppe angegeben werden. Noch weiter unten ist dann listen.mode zu finden: Versuch das mal auf 0660 zu stellen (versuchsweise auch auf 0770). Vielleicht bringt das ja was.
      Wenn alles nichts hilft, sollte dir der Hoster vom V-Server weiter helfen können.

      Gruß,
      Jan

      • Niklas sagt:

        Hallo Jan,

        leider habe ich das gleich Problem wie Hans damals. Wenn ich meine Seite („domain.de/nextcloud“) aufrufe bekomme ich auch 502 Bad Gateway. Im Log von Nginx wird mir genau die selbe Zeile ausgegeben.

        2017/12/26 11:44:32 [crit] 1314#1314: *53 connect() to unix:/run/php/php7.0-fpm.sock failed (13: Permission denied) while connecting to upstream, client: 127.0.0.1, server: 127.0.0.1, request: „GET /nextcloud HTTP/1.0“, upstream: „fastcgi://unix:/run/php/php7.0-fpm.sock:“, host: „domain.de“

        Es bringt auch nichts „listen.owner oder listen.group“ zu verändern, probiert habe ich es mit „www-data“ und „nginx“ (wie einen post weiter unten beschrieben). Den Wert bei „listen.mode“ von 0660 auf 0770 zu stellen bringt auch keine Besserung.

        Nextcloud läuft bei mir zuhause in einer VM auf einem mit VMware ESXi Virtualisierten Server. Meine Domain habe ich wie Hans einfach weitergeleitet (DynDNS nutze ich wegen static-ip nicht, falls das überhaupt eine rolle spielen sollte^^)

        Ich wäre dir sehr dankbar wenn du vielleicht noch eine Idee hättest an was es liegen könnte bzw. was ich möglicherweise falsch gemacht habe.

        Grüße,
        Niklas

        • Jan sagt:

          Hi Niklas,

          bist du das Tutorial nochmal ganz genau Schritt für Schritt durchgegangen?
          Diese Fehler hatte ich bei mir auf den Testmaschinen nie, daher scheint hier irgendwas nicht zusammen zu passen. Von daher nochmal der grobe Ablaufplan mit User/Rechten/etc.:

          In /etc/php/7.0/fpm/pool.d/www.conf konfigurierst du zunächst einmal den User, unter dem der PHP-Socket laufen soll: www-data. Ansonsten sollte da dieser conf-Datei alles soweit passen.
          In /etc/nginx/nginx.conf stellst du den User ein, unter dem der Webserver laufen soll: Ebenfalls www-data
          Beide Benutzer müssen also gleich sein, weil der Webserver (mit dem User www-data) den PHP-Socket aufrufen soll. Damit hier kein „User-Sprung“ entsteht, sind beide benutzer gleich.

          Nach allen Änderungen am besten immer PHP und den Webserver neu starten:
          service php7.0-fpm restart
          service nginx restart

          Ansonsten nochmal ins syslog gucken, ob hier vielleicht irgendwelche Auffälligkeiten bzgl. PHP zu finden sind.

          Gruß,
          Jan

  • Hans sagt:

    Hallo Jan,

    mit den Einstellungen läuft es.

    listen.owner = nginx
    listen.group = nginx
    listen.mode = 0660

    Ich bleibe bei meinem Server zu Hause, läuft besser :)

    Danke

    • Jan sagt:

      Hi Hans,

      OK, dann weißt du zumindest, woran es lag.
      Warum läuft es bei deinem Server zu Hause besser? Würde mich mal interessieren, da ein V-Server sich ja grundsätzlich nicht viel von einem eigenen Server unterscheiden sollte.

      Gruß,
      Jan

      • Hans sagt:

        Hallo Jan,

        doch, auf deiner Hardware zu Hause läuft nur dein System, beim Hoster teilst du dir die Hardware mit anderen.

        ich hatte das Problem mit der Performance. Am Vormittag alles wunderbar und ab Mittag ging der Server immer mehr in die Knie.

        Da gibt es Unterschiede zwischen den Hoster (z. B
        .Dedicated RAM und Dynamic RAM).

        Gruß Hans

  • Jonas sagt:

    Hallo Jan. Ich muss dich mal wieder mit einem meiner kleinen Probleme konfrontieren:

    Bei meiner Installation, exakt nach deinem großartigen HowTo, funktioniert Cron nicht.

    Folgende Ausgabe erhalte ich:

    sudo -u www-data php /var/www/nextcloud/cron.php
    PHP Fatal error: Uncaught Doctrine\DBAL\DBALException: Failed to connect to the database: An exception occured in driver: could not find driver in /var/www/nextcloud/lib/private/DB/Connection.php:61
    Stack trace:
    #0 /var/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(429): OC\DB\Connection->connect()
    #1 /var/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(389): Doctrine\DBAL\Connection->getDatabasePlatformVersion()
    #2 /var/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(328): Doctrine\DBAL\Connection->detectDatabasePlatform()
    #3 /var/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(623): Doctrine\DBAL\Connection->getDatabasePlatform()
    #4 /var/www/nextcloud/lib/private/DB/Connection.php(148): Doctrine\DBAL\Connection->setTransactionIsolation(2)
    #5 /var/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/DriverManager.php(172): OC\DB\Connection->__construct(Array, Object(Doctrine\DBAL\Driver\PDOMySql\Driver), Object(Doctrine\DBAL\Configura in /var/www/nextcloud/lib/private/DB/Connection.php on line 61
    PHP Fatal error: Uncaught Doctrine\DBAL\DBALException: Failed to connect to the database: An exception occured in driver: could not find driver in /var/www/nextcloud/lib/private/DB/Connection.php:61
    Stack trace:
    #0 /var/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(429): OC\DB\Connection->connect()
    #1 /var/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(389): Doctrine\DBAL\Connection->getDatabasePlatformVersion()
    #2 /var/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(328): Doctrine\DBAL\Connection->detectDatabasePlatform()
    #3 /var/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(623): Doctrine\DBAL\Connection->getDatabasePlatform()
    #4 /var/www/nextcloud/lib/private/DB/Connection.php(148): Doctrine\DBAL\Connection->setTransactionIsolation(2)
    #5 /var/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/DriverManager.php(172): OC\DB\Connection->__construct(Array, Object(Doctrine\DBAL\Driver\PDOMySql\Driver), Object(Doctrine\DBAL\Configura in /var/www/nextcloud/lib/private/DB/Connection.php on line 61

    Die Nextclouddoku hilft mir leider nicht weiter. Hast Du mal wieder den rettenden Tipp?

    Vielen Dank und Gruß

  • Nils sagt:

    Hallo Jan,
    ich glaube in dem Gateway-Host für Nextcloud hat sich ein kleiner Fehler eingeschlichen:
    proxy_max_temp_file_size 10240m; müsste glaube ich heißen
    proxy_max_temp_file_size 1024m;
    Viele Grüße
    Nils

    • Jan sagt:

      Hi Nils,

      doch, der Wert 10240m ist hier korrekt und korrespondiert mit den max. Upload-Werten im Nextcloud vHost (z.B. upload_max_filesize = 10G – 10 GB = 10240 MB).
      Die 10240 MB sorgen dafür, dass solche Uploads auch „durch den Gateway-Host passen“.

      Gruß,
      Jan

1 2 3 7

Schreibe einen Kommentar

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