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

23. August 2017 / Home-Server / 584 Kommentare

Hinweis: 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:
- Hinweise für Ubuntu Server 18.04 LTS entfernt, da es hier einen neuen Artikel gibt: Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban

Inhalt

1 Motivation, Voraussetzungen und Konzept
2 Installation und Einrichtung Nextcloud
3 Überprüfung der Sicherheit
- 3.1 Qualys SSL Labs
- 3.2 Nextcloud Security Scan
4 Troubleshooting
5 Abschließende Worte
6 Weiterführende Artikel
7 Links

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:

apt-get update && apt-get upgrade -V && apt-get dist-upgrade && apt-get autoremove 
reboot

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:

nano /etc/network/interfaces

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:

auto eth0
iface eth0 inet static
address 192.168.178.60
netmask 255.255.255.0
network 192.168.178.0
broadcast 192.168.178.255
gateway 192.168.178.1
dns-nameservers 192.168.178.1

Nach einem Neustart 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:

apt-get update 
apt-get install nginx

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:

wget -O - http://nginx.org/keys/nginx_signing.key | apt-key add -

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

nano /etc/apt/sources.list

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

# Nginx (Mainline)
deb http://nginx.org/packages/mainline/ubuntu/ xenial nginx
deb-src http://nginx.org/packages/mainline/ubuntu/ xenial nginx

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:

apt-get update
apt-get install nginx

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:

apt-get update 
apt-get install mariadb-server

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

apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8

Anschließend werden die Paketquellen hinzugefügt:

nano /etc/apt/sources.list

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

# MariaDB 10.2 repository list
# http://downloads.mariadb.org/mariadb/repositories/
deb [arch=amd64,i386] http://mirrors.n-ix.net/mariadb/repo/10.2/ubuntu xenial main
deb-src http://mirrors.n-ix.net/mariadb/repo/10.2/ubuntu xenial main

Nun kann die Datenbank installiert werden:

apt-get update 
apt-get install mariadb-server

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

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:

apt-get update 
apt-get install php7.0-fpm php7.0-gd php7.0-mysql php7.0-curl php7.0-xml php7.0-zip php7.0-intl php7.0-mcrypt php7.0-mbstring php7.0-bz2 php-apcu

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:

nano /etc/php/7.0/fpm/pool.d/www.conf

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

user = www-data 
group = www-data

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

listen = /run/php/php7.0-fpm.sock

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:

nano /etc/php/7.0/fpm/php.ini

cgi.fix_pathinfo = 0
Sorgt für eine sichere Interpretation von Pfadangaben.
open_basedir = /var/www/:/tmp/
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:

nano /etc/php/7.0/cli/php.ini

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:

service php7.0-fpm restart

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:

mysql_secure_installation

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

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

service mysql restart

Allgemeine nginx-Konfiguration

Zunächst wir die globale Konfiguration von nginx angepasst:

nano /etc/nginx/nginx.conf

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:

mv /etc/nginx/conf.d/default.conf /etc/nginx/conf.d/default.conf_disabled

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:

mkdir -p /var/www/letsencrypt
mkdir -p /var/www/nextcloud
mkdir -p /var/nextcloud_data
chown -R www-data:www-data /var/www
chown -R www-data:www-data /var/nextcloud_data

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:

nano /etc/nginx/conf.d/nextcloudtutorial.goip.de.conf

Hier fügen wir nun folgenden Inhalt ein:

server {
	listen 80 default_server;
	server_name nextcloudtutorial.goip.de 192.168.178.60;

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

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

Anlegen des 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):

nano /etc/nginx/conf.d/nextcloudtutorial.goip.de_letsencrypt.conf

Dieser Host ist dabei sehr einfach aufgebaut:

server {
	listen 127.0.0.1:81;
	server_name 127.0.0.1;	
	
	location ^~ /.well-known/acme-challenge {
		default_type text/plain;
		root /var/www/letsencrypt;
	}
}

Gelauscht wird auf 127.0.0.1:81. 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:

service nginx restart

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:

apt-get install letsencrypt

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

letsencrypt certonly --webroot -w /var/www/letsencrypt -d nextcloudtutorial.goip.de --rsa-key-size 4096

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:

mkdir -p /etc/nginx/ssl 
openssl dhparam -out /etc/nginx/ssl/dhparams.pem 4096

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:

openssl dhparam -out /etc/nginx/ssl/dhparams.pem 2048

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:

chmod 600 /etc/letsencrypt/live/nextcloudtutorial.goip.de/fullchain.pem
chmod 600 /etc/letsencrypt/live/nextcloudtutorial.goip.de/privkey.pem
chmod 600 /etc/letsencrypt/live/nextcloudtutorial.goip.de/chain.pem
chmod 600 /etc/letsencrypt/live/nextcloudtutorial.goip.de/cert.pem
chmod 600 /etc/nginx/ssl/dhparams.pem

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:

letsencrypt certonly --webroot -w /var/www/letsencrypt -d nextcloudtutorial.goip.de --rsa-key-size 4096

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

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:

nano /etc/nginx/conf.d/nextcloudtutorial.goip.de.conf

Die hinzugefügten Abschnitte sind markiert:

server {
	listen 80 default_server;
	server_name nextcloudtutorial.goip.de 192.168.178.60;

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

	location / {
		# Enforce HTTPS
		# Use this if you always want to redirect to the DynDNS address (no local access).
		return 301 https://$server_name$request_uri;
		
		# Use this if you also want to access the server by local IP:
		#return 301 https://$server_addr$request_uri;
    }		
}

server {
	listen 443 ssl http2;
	server_name nextcloudtutorial.goip.de 192.168.178.60;

	#
	# Configure SSL
	#
	ssl on;
  
	# Certificates used
	ssl_certificate /etc/letsencrypt/live/nextcloudtutorial.goip.de/fullchain.pem;
	ssl_certificate_key /etc/letsencrypt/live/nextcloudtutorial.goip.de/privkey.pem;
  
	# Not using TLSv1 will break:
	#	Android <= 4.4.40
	#	IE <= 10
	#	IE mobile <=10
	# Removing TLSv1.1 breaks nothing else!
        # There are not many clients using TLSv1.3 so far, but this can be activated with nginx v1.13
	ssl_protocols TLSv1.2 TLSv1.3;
	
	# Using the recommended cipher suite from: https://wiki.mozilla.org/Security/Server_Side_TLS
	ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK';
  
	# Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
	ssl_dhparam /etc/nginx/ssl/dhparams.pem;
  
	# Specifies a curve for ECDHE ciphers.
	# High security, but will not work with Chrome:
	#ssl_ecdh_curve secp521r1;  
	# Works with Windows (Mobile), but not with Android (DavDroid):
	#ssl_ecdh_curve secp384r1;
	# Works with Android (DavDroid):
	ssl_ecdh_curve prime256v1; 

	# Server should determine the ciphers, not the client
	ssl_prefer_server_ciphers on;
  
	# OCSP Stapling
	# fetch OCSP records from URL in ssl_certificate and cache them
	ssl_stapling on;
	ssl_stapling_verify on;
	ssl_trusted_certificate /etc/letsencrypt/live/nextcloudtutorial.goip.de/fullchain.pem;
	resolver 192.168.178.1;
  
	# SSL session handling
	ssl_session_timeout 24h;
	ssl_session_cache shared:SSL:50m;
	ssl_session_tickets off;

	#
	# Add headers to serve security related headers
	#  
	# HSTS (ngx_http_headers_module is required)
	# In order to be recoginzed by SSL test, there must be an index.hmtl in the server's root
	add_header Strict-Transport-Security "max-age=63072000; includeSubdomains" always;
	add_header X-Content-Type-Options "nosniff" always;
	# Usually this should be "DENY", but when hosting sites using frames, it has to be "SAMEORIGIN"
	add_header Referrer-Policy "same-origin" always;
	add_header X-XSS-Protection "1; mode=block" always;
	add_header X-Robots-Tag none;
	add_header X-Download-Options noopen;
	add_header X-Permitted-Cross-Domain-Policies none;

	location = / {
		# Disable access to the web root, 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;
	}	
	
	#
	# 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_request_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;
	}	
}

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:

nano /etc/nginx/conf.d/nextcloudtutorial.goip.de_nextcloud.conf

Hier der komplette Inhalt der Datei:

upstream php-handler {
    server unix:/run/php/php7.0-fpm.sock;
}

server {
    listen 127.0.0.1:82;
    server_name 127.0.0.1;

    # Add headers to serve security related headers
    # Use 'proxy_set_header' (not 'add_header') as the headers have to be passed through a proxy.
    proxy_set_header Strict-Transport-Security "max-age=15768000; includeSubDomains; always;";
    proxy_set_header X-Content-Type-Options "nosniff; always;";
    proxy_set_header X-XSS-Protection "1; mode=block; always;";
    proxy_set_header X-Robots-Tag none;
    proxy_set_header X-Download-Options noopen;
    proxy_set_header X-Permitted-Cross-Domain-Policies none;

    # Path to the root of your installation
    root /var/www/;

    location = /robots.txt {
        allow all;
        log_not_found off;
        access_log off;
    }

    # The following 2 rules are only needed for the user_webfinger app.
    # Uncomment it if you're planning to use this app.
    #rewrite ^/.well-known/host-meta /nextcloud/public.php?service=host-meta last;
    #rewrite ^/.well-known/host-meta.json /nextcloud/public.php?service=host-meta-json last;

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

    location /.well-known/acme-challenge { }

    location ^~ /nextcloud {
        # set max upload size
        client_max_body_size 10G;
        fastcgi_buffers 64 4K;

        # Enable gzip but do not remove ETag headers
        gzip on;
		gzip_vary on;
        gzip_comp_level 4;
        gzip_min_length 256;
        gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
        gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;

        # Uncomment if your server is build with the ngx_pagespeed module
        # This module is currently not supported.
        #pagespeed off;

        location /nextcloud {
            rewrite ^ /nextcloud/index.php$uri;
        }

        location ~ ^/nextcloud/(?:build|tests|config|lib|3rdparty|templates|data)/ {
            deny all;
        }

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

        location ~ ^/nextcloud/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|ocs-provider/.+|core/templates/40[34])\.php(?:$|/) {
            include fastcgi_params;
            fastcgi_split_path_info ^(.+\.php)(/.+)$;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_param PATH_INFO $fastcgi_path_info;
			#Avoid sending the security headers twice
            fastcgi_param modHeadersAvailable true;
            fastcgi_param front_controller_active true;
            fastcgi_pass php-handler;
            fastcgi_intercept_errors on;

            # Raise timeout values.
            # This is especially important when the Nextcloud setup runs into timeouts (504 gateway errors)
			fastcgi_read_timeout 600;
			fastcgi_send_timeout 600;
			fastcgi_connect_timeout 600;
            fastcgi_request_buffering off;
	    
            # Pass PHP variables directly to PHP.
            # This is usually done in the php.ini. For more flexibility, these variables are configured in the nginx config.
			# All the PHP parameters have to be set in one fastcgi_param. When using more 'fastcgi_param PHP_VALUE' directives, the last one will override all the others.
            fastcgi_param PHP_VALUE "open_basedir=/var/www:/tmp/:/var/nextcloud_data:/dev/urandom:/proc/meminfo
				upload_max_filesize = 10G
				post_max_size = 10G
				max_execution_time = 3600
				output_buffering = off";
            
            # Make sure that the real IP of the remote host is passed to PHP.
            fastcgi_param REMOTE_ADDR $http_x_real_ip;
        }

        location ~ ^/nextloud/(?:updater|ocs-provider)(?:$|/) {
            try_files $uri/ =404;
            index index.php;
        }

        # Adding the cache control header for js and css files
        # Make sure it is BELOW the PHP block
        location ~* \.(?:css|js)$ {
            try_files $uri /nextcloud/index.php$uri$is_args$args;
            proxy_set_header Cache-Control "public, max-age=7200";
            # Add headers to serve security related headers
            # Again use 'proxy_set_header' (not 'add_header') as the headers have to be passed through a proxy.
            proxy_set_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
            proxy_set_header X-Content-Type-Options nosniff;
            #proxy_set_header X-Frame-Options "SAMEORIGIN";
            proxy_set_header X-XSS-Protection "1; mode=block";
            proxy_set_header X-Robots-Tag none;
            proxy_set_header X-Download-Options noopen;
            proxy_set_header X-Permitted-Cross-Domain-Policies none;
            # Optional: Don't log access to assets
            access_log off;
        }

        location ~* \.(?:svg|gif|png|html|ttf|woff|ico|jpg|jpeg)$ {
            try_files $uri /nextcloud/index.php$uri$is_args$args;
            # Optional: Don't log access to other assets
            access_log off;
        }
    }
}

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.

nginx -t 
service nginx restart

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

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

wget https://download.nextcloud.com/server/releases/nextcloud-12.0.2.tar.bz2

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

tar -xjf nextcloud-12.0.2.tar.bz2 -C /var/www 
rm nextcloud-12.0.2.tar.bz2

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

chown -R www-data:www-data /var/www/nextcloud 
chown -R www-data:www-data /var/nextcloud_data

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

mysql -u root -p

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:

create database nextcloud_db;
create user nextcloud_db_user@localhost identified by 'MeInPasSw0rT';
grant all privileges on nextcloud_db.* to nextcloud_db_user@localhost;
flush privileges;
exit;

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.

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.

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:

nano /var/www/nextcloud/config/config.php

Der Memory Cache wird nun einfach durch das Hinzufügen folgender Zeile (ganz am Ende, aber noch vor der letzten geschweiften Klammer) aktiviert:

'memcache.local' => '\OC\Memcache\APCu',

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

array (
	0 => 'nextcloudtutorial.goip.de',
	1 => '192.168.178.60',
),

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.

'overwriteprotocol' => 'https',

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:

'logtimezone' => 'Europe/Berlin',

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:

crontab -u www-data -e

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

*/15 * * * * php -f /var/www/nextcloud/cron.php > /dev/null 2>&1

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.

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:

Server-seitige Verschlüsselung
Externer Speicher
Erweiterung von Nextcloud durch Apps

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:

nano /var/www/nextcloud/config/config.php

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

'auth.bruteforce.protection.enabled' => false,

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:

'logtimezone' => 'Europe/Berlin',

Anschließend kann Fail2ban installiert werden:

apt-get update 
apt-get install fail2ban

Nun wird ein spezieller Filter für Nextcloud angelegt:

nano /etc/fail2ban/filter.d/nextcloud.local

Die Datei wird nun mit folgendem Inhalt gefüllt:

[Definition]
failregex=^{"reqId":".*","remoteAddr":".*","app":"core","message":"Login failed: '.*' \(Remote IP: '<HOST>'\)","level":2,"time":".*"}$
            ^{"reqId":".*","level":2,"time":".*","remoteAddr":".*","app":"core".*","message":"Login failed: '.*' \(Remote IP: '<HOST>'\)".*}$

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

nano /etc/fail2ban/jail.local

Diese Datei hat folgenden Inhalt:

[nextcloud]
enabled=true
port=80,443
protocol=tcp
filter=nextcloud
maxretry=3
bantime=1800
logpath=/var/nextcloud_data/nextcloud.log

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:

service fail2ban restart

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:

[DEFAULT]
# Destination email address used solely for the interpolations in
# jail.{conf,local,d/*} configuration files.
destemail = meineemail@provider.de

# Sender email address used solely for some actions
sender = absenderadresse@provider.de

# E-mail action. Since 0.8.1 Fail2Ban uses sendmail MTA for the
# mailing. Change mta configuration parameter to mail if you want to
# revert to conventional 'mail'.
mta = mail
action = %(action_mwl)s

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:

[Definition]

# Option:  actionstart
# Notes.:  command executed once at the start of Fail2Ban.
# Values:  CMD
#
actionstart =

# Option:  actionstop
# Notes.:  command executed once at the end of Fail2Ban
# Values:  CMD
#
actionstop =

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:

fail2ban-client status nextcloud

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

fail2ban-client set nextcloud unbanip 48.128.36.8

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:

apt-get update 
apt-get install redis-server php-redis

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

nano /etc/redis/redis.conf

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

port 0 
unixsocket /var/run/redis/redis.sock 
unixsocketperm 770

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:

usermod -a -G redis www-data

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

nano /var/www/nextcloud/config/config.php

Folgende Zeilen hier einzufügen:

'filelocking.enabled' => 'true',
  'memcache.locking' => '\OC\Memcache\Redis',
  'redis' => array(
     'host' => '/var/run/redis/redis.sock',
     'port' => 0,
     'timeout' => 0.0,
      ),

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

service redis-server restart

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.

apt-get update 
apt-get install ufw

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:

ufw default deny 
ufw allow proto tcp from 192.168.178.0/24 to any port 22 
ufw allow 80
ufw allow 443 
ufw enable

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

ufw status

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

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:

nano /etc/php/7.0/cli/php.ini

Folgender Wert muss hier noch hinzugefügt werden:

apc.enable_cli = 1

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

584 Kommentare zu „Nextcloud auf Ubuntu Server mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban“

Toby
26. April 2018 um 20:58 Uhr

Hallo Jan,
zuerst mal sehr gut verständliches Tutorial, danke dafür. Leider habe ich das ganze fast vollständig abmalen können, weil ich bei den Konfigurations-Files keine Ahnung habe was die ganzen Zeilen bedeuten. Deshalb habe ich jetzt einen Fehler, für den ich nach längerem suchen keine Lösung gefunden habe.
Ich habe gerade die Nextcloud Installation abgeschlossen und wollte den nginx Webserver ausprobieren. Wenn ich aber das Root-Verzeichniauf der Domain ansteuere bekomme ich einen „403 Forbidden“ error und wenn ich direkt auf die index.html Seite gehen will bekomme ich den „404 Not Found“ Error.
Hier die /etc/nginx/nginx.conf: https://pastebin.com/cjf1YvCH
Und Hier die conf.d/mydomain.com.conf: https://pastebin.com/TW8iHRiu

MfG
Toby

Antworten
1. Jan
  27. April 2018 um 8:11 Uhr
  
  Hi Toby,
  
  sind dies die einzigen vHost-Dateien, die du angelegt hast? Hier fehlt noch der vHost für Nextcloud. Das Konzept, welches ich in diesem Artikel verfolge ist, dass zunächst alle Requests beim sog. Gateway-Host landen (die zweite deiner Dateien). Dieser Gateway-Host leitet dann Requests, die an Nextcloud gerichtet sind, an den Nextcloud-vHost weiter. Ich denke, dass es funktionieren wird, wenn du noch den vHost für Nextcloud hinzufügst (siehe hier).
  
  Gruß,
  Jan
  
  Antworten
Bernd
27. April 2018 um 15:35 Uhr

Hallo,

UBUNTU 18.04 ist ja heute herausgekommen, hast du schon testen können, ob die Anleitung damit funktioniert?

Gruß
Bernd

Antworten
1. Jan
  28. April 2018 um 9:24 Uhr
  
  Hi Bernd,
  
  noch nicht, werde ich die Tage aber mal machen. Ggf. werde ich den Artikel dann aktualisieren, wenn Änderungen notwendig sind.
  
  Gruß,
  Jan
  
  Antworten
  1. Jan
    29. April 2018 um 12:01 Uhr
    
    Hallo,
    
    so, ich habe mal eine Test-VM mit Ubuntu 18.04 aufgesetzt und das Tutorial durchgearbeitet. Es ergeben sich allerdings nur minimale Änderungen, ansonsten bleibt alles beim Alten. Ich habe ganz oben ein paar (temporäre) Hinweise für die Installation unter Ubuntu 18.04 hinzugefügt. Allerdings plane ich, den Artikel komplett zu überarbeiten, so dass dieser auf Ubuntu 18.04 zugeschnitten ist.
    
    Gruß,
    Jan
    
    Antworten
    1. Hans
      29. April 2018 um 17:03 Uhr
      
      Hallo Jan, wie immer TOP!
      
      Gruß Hand
      
      Antworten
Klaus Baumann
2. Mai 2018 um 15:29 Uhr

Hi, ich mal wieder. Habe am Wochenende versucht, deine Anleitung auf einem Raspberry Pi 3 zu installieren, da mein Ubuntu-Server einfach zu laut ist. Geld für einen neuen ist momentan auch nicht da, also den alten Pi genommen und ….. verzweifelt. Habe gelesen, du wirst für 18.04 eine neue Anleitung verfassen. Wird es auch eine für den Raspi und/oder Banana geben?
Danke Klaus

Antworten
1. Jan
  2. Mai 2018 um 16:09 Uhr
  
  Hi Klaus,
  
  wo hakt es denn genau bei der Installation auf dem Raspi? Die Anleitung funktioniert im Prinzip auch für den Raspi, allerdings laufen hier einige Dinge etwas anders als unter Ubuntu. Im Artikel befinden sich allerdings auch immer mal wieder Hinweise auf Spezialitäten bzgl. des Raspis.
  
  Gruß,
  Jan
  
  Antworten
  1. Klaus Baumann
    3. Mai 2018 um 20:33 Uhr
    
    Also, momentan hänge ich bei der Installation von mariadb.
    – auf dem Raspberry ist raspbian-stretch
    – bin auf mariadb-foundation und dort über debian die nötigen dateien geladen.
    
    bei der Befehlseingabe :
    add-apt-repository ‚deb [arch=amd64,i386,ppc64el] http://mirror.daniel-jost.net/mariadb/repo/10.2/debian stretch main‘
    
    kommt dann die Fehlermeldung:
    aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for Raspbian/stretch
    
    Kannst du mir da weiter helfen??
    
    Antworten
    1. Jan
      3. Mai 2018 um 21:00 Uhr
      
      Hi Klaus,
      
      oh ja, das verhält sich auf dem Raspi auch etwas anders. Hier ist das Hinzufügen der MariaDB-Paketquellen auch überflüssig, weil hier auch kein Paket für die ARM-Architektur vorhanden ist (wie schon bei nginx). Falls du schon was bzgl. MariaDB in deine sources.list hinzugefügt hast, dann entferne das wieder. Anschließend einfach ein apt-get install mariadb-server und du kannst mit dem Tutorial ganz normale weiter machen.
      Im Artikel habe ich da noch einen Hinweis mit aufgenommen.
      
      Gruß,
      Jan
      
      Antworten
      1. Klaus Baumann
        3. Mai 2018 um 23:26 Uhr
        
        Danke, dass klappt jetzt.
        Aber nun habe ich folgende Fehlermeldung:
        
        root@raspberry-server:/home/pi# service nginx restart
        Job for nginx.service failed because the control process exited with error code.
        See „systemctl status nginx.service“ and „journalctl -xe“ for details.
        
        Bin den komplettem nginx-Block nochmal durch gegangen aber nichts gefunden. Ok ist 23:25. Vielleicht hast du ne Idee, werde morgen auch nochmal schauen.
        Gruß Klaus
      2. Jan
        5. Mai 2018 um 7:53 Uhr
        
        Hi Klaus,
        
        Ich vermute mal, dass du irgendwo im vHost noch einen Tippfehler drin hast. Geb in diesem Fall einfach mal nginx -t ein (Testmode von nginx). Wenn hier Fehler auftreten, dann nennt dir dieser Befehl die konkrete Stelle mit Zeilenangabe.
        
        Gruß,
        Jan
Paul
2. Mai 2018 um 20:55 Uhr

Hallo Jan,

bisher habe ich immer ein eigenes Zertifikat (eigene Linux CA dafür erstellt) für meine Cloud genommen und nu wollte ich auf Letsencrypt umsteigen, worauf ich auf deinen Artikel gestossen bin.

Ich habe zu Hause auf meinem Router (ipFire) eine VM mit Ubuntu 18.04 und an der Firewall testweise alle Ports zur Weiterleitung auf diese VM aktiviert.
Leider erhalte ich beim ausführen vom Befehl „letsencrypt certonly –webroot -w /var/www/letsencrypt -d cloud.meins.selfhost.de –rsa-key-size 4096“ einen Fehler.
######################
IMPORTANT NOTES:
– The following errors were reported by the server:

Domain: cloud.meins.selfhost.de
Type: connection
Detail: Fetching
http://cloud.meins.selfhost.de/.well-known/acme-challenge/HeY……………………….jSlPHpe2k59U4:
Timeout during connect (likely firewall problem)

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

Die Ordner unter /var/www/ sind alle erstellt und mittels einer Test.index konnte ich die Webseiten auch von Intern & Extern aufrufen.
Beim aufrufen des Befehls wird auch unter „/var/www/letsencrypt“ temporär eine Ordnerstruktur mit Datei erstellt aber nach der Fehlerausgabe wieder gelöscht.

Unter „/etc/nginx/conf.d“ liegen auch meine *.conf Dateien.
###### cloud.meins.selfhost.de.conf ########
server {
listen 80 default_server;
server_name cloud.meins.selfhost.de 10.10.2.5;

root /var/www;

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

sowie

###### cloud.ostzone.selfhost.de.conf_letsencrypt.conf ########
server {
listen 127.0.0.1:81;
server_name 127.0.0.1;

location ^~ /.well-known/acme-challenge {
default_type text/plain;
root /var/www/letsencrypt;
}
}

####################################################

Ich verzweifel gerade an diesem Part und wäre über einen Tipp sehr dankbar von Dir.

Vielen Dank im voraus

MfG Paul (berlin)

Antworten
1. Jan
  3. Mai 2018 um 8:29 Uhr
  
  Hi Paul,
  
  bei Ubuntu 18.04 ist das empfohlene Tool certbot in den Paketquellen enthalten. Leider wurden die Anweisungen für das Tool noch nicht auf Ubuntu 18.04 upgedated (17.04 ist hier das aktuellste). Der einzige Unterschied zu 18.04 sollte aber sein, dass du kein PPA-Package mehr verwenden musst, sondern einfach apt-get install certbot zur Installation eingeben kannst.
  Hier würde ich dann erst einmal sudo certbot --nginx ausprobieren (siehe Dokumentation). Wenn das nicht funktionieren sollte, dann probier mal certbot certonly --webroot -w /var/www/letsencrypt -d nextcloudtutorial.goip.de --rsa-key-size 4096.
  
  Edit: Gerade ausprobiert: Damit sudo certbot --nginx funktioniert, musst du noch folgendes installieren: apt-get install python-certbot-nginx. Auf die Frage des Assistenten, ob der HTTP-Traffic redirected werden soll, Option 1 (Nein) wählen, dann wird nichts an deinen nginx-vHosts verändert.
  Der direkte Befehl (mit --webroot) funktioniert bei mit ebenfalls.
  Erneuern der Zertifikate geht dann ganz einfach mit certbot renew.
  
  Gruß,
  Jan
  
  Antworten
  1. Paul
    6. Mai 2018 um 21:04 Uhr
    
    Hallo Jan,
    
    bei mir lag es wirklich an meiner Firewall (ipFire) da ich hier das GEO-IP nur auf DE zu stehen hatte. Ist nicht so schön das die keine Liste mit IP-Adressen Ihrer Validation Server haben.
    
    Antworten
Hans
5. Mai 2018 um 7:18 Uhr

Hallo Jan,

die ngnix-Repositories sind angeblich noch erforderlich, da sonst die ngnix Konfiguration für das buffering/streaming (MP4-Module) nicht verfügbar ist.

Ich persönlich konnte es leider noch nicht testen.

Kann dies jemand vielleicht mal testen?

Gruß Hans

Antworten
1. Jan
  5. Mai 2018 um 7:54 Uhr
  
  Hi Hans,
  
  du meinst hier sicherlich die Erweiterungen des Artikels für Ubuntu 18.04, oder?
  Hast du dazu vielleicht eine Quellenangabe oder so?
  
  Gruß,
  Jan
  
  Antworten
  1. Hans
    5. Mai 2018 um 9:32 Uhr
    
    Hallo Jan,
    
    ja klar, für Ubuntu 18.
    
    Habe ich in einem Forum gelesen. Ob es wirklich so ist, konnte ich noch nicht testen, da ich noch keinen Ubuntu Server 18 aufgesetzt habe.
    
    Gruß Hans
    
    Antworten
    1. Jan
      6. Mai 2018 um 7:25 Uhr
      
      Hi Hans,
      
      weil du das MP4-Module erwähnt hast: Das ist nur ein Pseudo-Streaming für MP4-Dateien. Das kann aber wohl mit dem Paket nginx-extras nachgerüstet werden.
      
      Gruß,
      Jan
      
      Antworten
Michael
6. Mai 2018 um 12:05 Uhr

Hallo, habe dank dieser Anleitung nun Nextcloud seit einigen Monaten ohne Probleme am laufen. Danke dafür!

Nun wollte ich neben Nextcloud auf meinem Raspberry 3 noch einen Teamspeak3 Server mithilfe von Exagear Desktop laufen lassen. Hab mich da an diese Anleitung gehalten: https://eltechs.com/run-teamspeak-3-server-on-raspberry-pi/
Installation hat auch wunderbar geklappt und per IP-Adresse im eigenen Netzwerk kann eine Verbindung aufgebaut werden, aber leider nicht von außen.
Das Problem liegt wohl nun am Gateway-Host, der zunächst einmal alle Client-Anfragen entgegennimmt und diese nachher an die entsprechenden vHosts weiterleitet.
Lieg ich da nun richtig das ich nun einen weiteren vHost für Teamspeak und/oder für Exagear einrichten muss und den Gateway-Host um diesen vHost erweitern muss?
Habt ihr ein Tipp für mich?

Gruß Michael

Antworten
1. Jan
  6. Mai 2018 um 14:04 Uhr
  
  Hi Michael,
  
  TS habe ich nur temporär mal auf einem Windows-System genutzt, daher kann ich zu TS unter Linux nicht viel sagen.
  Allerdings muss das denke ich nicht über einen vHost geregelt werden. TS nutzt anscheinend diese Ports. Hier „beißt“ sich also nichts mit den von nginx verwendeten Ports 80 und 443. Dafür spricht zumindest, dass die Verbindung bei dir im LAN ja zustande kommt.
  Ich habe allerdings eine Vermutung, warum die Verbindung „von außen“ nicht klappt: Diese ganzen Ports müssen auch im Router (z.B. in der FritzBox) und in einer evtl. anderen Firewall (z.B. ufw) freigeschaltet werden. Dann sollte die Verbindung auch über das Internet/DynDNS funktionieren.
  
  Gruß,
  Jan
  
  Antworten
  1. Michael
    10. Mai 2018 um 10:24 Uhr
    
    Hallo Jan, danke für deine Antwort.
    
    Weil ich noch nicht viel Ahnung von vHost und so weiter habe, hatte ich das naheliegendste, die Port im Router, vergessen. Habs jetzt nochmal getestet und es läuft.
    
    Weil ich jetzt aber schon mal dabei bin am Pi rum zu basteln würde mich auch noch der Plex Media Server interresieren. Habs erfolgreich nach dieser Anleitung http://www.baldnerd.com/plex-media-server-on-a-raspberry-pi-3/ installiert, nur leider kommt beim Aufruf von localhost:34200/web die Fehlermeldung „localhost hat die Verbindung abgelehnt, ERR_CONNECTION_REFUSED“ im Browser.
    
    Wie siehts da mit den vHost aus? Brauchts den? Plex Media Server hat den Port 32400. Habe ihn diesesmal auch im Router freigegeben.
    
    Gruß Michael
    
    Antworten
    1. Jan
      10. Mai 2018 um 10:31 Uhr
      
      Hi Michael,
      
      ich selbst habe Plex noch nie installiert, aber in der von dir verlinkten Anleitung ist wird kein Webserver verwendet, also gehe ich mal davon aus, dass Plex auch eigenständig läuft. Der Aufruf von Plex funktioniert dann über die URL http://ip-des-ip:34200/web, sehe ich das richtig?
      Die Fehlermeldung ist leider sehr unspezifisch. Hier würde ich mal in die Logs von Plex gucken (siehe hier).
      
      Gruß,
      Jan
      
      Antworten
      1. Michael
        10. Mai 2018 um 12:30 Uhr
        
        Hallo Jan, wieder hat mir deine Antwort geholfen. Danke.
        
        Ja, Plex Media Server läuft eigenständig und wird über ip-des-pi:34200/web aufgerufen.
        
        Zum Fehler in den Logs: SQLITE3 Permission denied. Die Lösung zu meinem Problem habe ich im Plex-Forum gefunden (https://forums.plex.tv/discussion/317739/cannot-get-plex-to-work-need-help).
        
        Nun hab ich Plex zum laufen gebracht und kann auch in meinem Netzwerk darauf zugreifen. Jetzt bräuchte ich wieder einen Tipp wie ich wieder von außen darauf zu greifen kann. Der Fehler den ich nun im Browser bekomme ist dieser:
        
        Diese Verbindung ist nicht sicher
        
        Der Inhaber von „meinedomain“.de hat die Website nicht richtig konfiguriert. Firefox hat keine Verbindung mit dieser Website aufgebaut, um Ihre Informationen vor Diebstahl zu schützen.
        
        Diese Website verwendet HTTP Strict Transport Security (HSTS), um mitzuteilen, dass Firefox nur über gesicherte Verbindungen mit ihr kommunizieren soll.
        
        Grüße,
        Michael
      2. Jan
        10. Mai 2018 um 17:42 Uhr
        
        Hi Michael,
        
        OK, Plex funktioniert also zunächst einmal. Dass er nun wegen der nicht sicheren Verbindung meckert, ist auch irgendwie klar, da du ja am Webserver vorbei auf Plex zugreifen willst.
        Damit das mit HTTPS funktioniert, müssen wir also doch durch den Webserver laufen. Also zunächst einmal die Portfreigabe im Router für Plex wieder entfernen, die brauchen wir nicht mehr.
        Dann im Gateway-Host von nginx eine weitere location aufnehmen (ähnlich der nextcloud-location):
        location ^~ /plex { proxy_buffering off; proxy_request_buffering off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_pass http://127.0.0.1:34200; proxy_redirect off; }
        
        nginx neu starten. Danach sollte der Zugriff über https://meindomain.de/plex funktionieren, da Plex nur Server-intern aufgerufen wird.
        Allerdings kann ich dir nicht sagen, welche konkreten Anweisungen Plex vom Proxy benötigt (also alle Anweisungen im Plex-lication-Block). Hier musst du evtl. mal ein wenig ausprobieren. Wenn es nicht auf Anhieb funktioniert, dann einfach mal in die Developer-Console des Brwosers (Chrome: F12) schauen, was bei einem Request an Plex passiert. Ebenso sollte dann das Logfile von nginx mit einigermaßen sinnvollen Logeinträgen gefüllt werden, wenn es nicht gleich funktioniert.
        
        Gruß,
        Jan
      3. Michael
        11. Mai 2018 um 10:12 Uhr
        
        Hier mal ein Updatezu meinem Problem:
        
        wie es aussieht hat das Problem mit der unsicheren Verbindung nichts mit den Einstellungen dieses Tutorials zu tun, sondern ist auf Plex selbst zurück zu führen.
        
        meine.domain.de:32400 verwendet ein ungültiges Sicherheitszertifikat. Das Zertifikat gilt nur für *.11c3a1dda************8865d710009.plex.direct.
        
        Man kann wohl einen eigenen Zertifikatsschlüssel einbinden, dann sollte es passen.
        
        Danke Jan für deine Hilfe und diese klasse Anleitung.
      4. Michael
        11. Mai 2018 um 10:18 Uhr
        
        hallo jan, habe deine antwort erst nach abgeben meines beitrags gesehen, danke für deine Antwort. Werde deinen Lösungsvorschlag auch mal probieren.
Klaus Baumann
8. Mai 2018 um 15:28 Uhr

Hallo Jan,
ist es im Prinzip auch möglich, Nextcloud statt auf einen Raspberry auf einen Banana Pi zu spielen? Mit welchen Problemen (außer Tippfehler) muss ich da rechnen.
Danke
Klaus (mal wieder)

Antworten
1. Jan
  8. Mai 2018 um 18:37 Uhr
  
  Hi Klaus,
  
  ja, das ist eigentlich kein Problem, egal um was es sich für einen Rechner handelt. Es muss nur irgendwie Linux drauf laufen. Da der Banana Pi dem Raspi sehr ähnelt, müssten dort vermutlich auch die Anpassungen wie auf dem Raspi befolgt werden.
  
  Gruß,
  Jan
  
  Antworten
Tobi
8. Mai 2018 um 22:10 Uhr

Hallo,

vorweg, ich bin ein absoluter Neuling in dem Thema und auch bei Linux.

Ich möchte mit Nextcloud einen Cloud für meinen Verein einrichten und zudem auch unsere Website darüber laufen lassen. Zunächst bin ich auf das Problem gestoßen, dass mein Router kein DynDNS Dienst unterstützt hat. Somit habe ich mir über meinen Anbieter (vodafone) ein FritzBox Mietgerät besorgt. Nun habe ich festgestellt, dass ich mein Anschluss einen DS-Lite Tunnel nutzt.
Mittlerweile stellt vodafone nicht mehr auf Dual-Stack um, und einen Businessvertrag möchte ich wegen der zusätzlich unkosten nicht abschließen, weil es sich ja auch um ehrenamtlich vereinsarbeit handelt ohne gewinnabsichten mit dem Server.

Gibt es eine Möglichkeit die Anleitung mit IPv6 (DS-Lite Tunnel) umzusetzen?

Ich wäre echt dankbar. Bin langsam echt am verzweifeln, weil i keine Lösung finde.

Grüß
Tobi

Antworten
1. Jan
  9. Mai 2018 um 7:31 Uhr
  
  Hi Tobi,
  
  DSLite ist leider eine Krücke, die für die Provider am einfachsten ist, der Kunde hat allerdings einige Nachteile. Ich hatte das Problem auch (M-Net) und habe die Sache mit DSLite nicht ans Laufen gebracht. Hat erst wieder funktioniert, als ich eine echte IPv4-Option dazugebucht habe.
  Die Frage ist nun, ob Vodafone generell keine IPv4-Option anbietet, oder die Callcenter-Mitarbeiter nur darauf geschult hat, diese Option erst einmal zu verwehren. Vielleicht hilft hier auch etwas Hartnäckigkeit.
  Hier habe ich einen Thread im Vodafone-Forum gefunden, bei dem sich die Leute auch über DSLite beschweren. Vielleicht hilft es ja weiter.
  
  Gruß,
  Jan
  
  Antworten
  1. Tobi Ma
    9. Mai 2018 um 12:20 Uhr
    
    Hallo Jan,
    
    bin schon hartnäckig dran, weil ich mich noch in den 14 Tagen Widerrufszeit befinde, aber bisher ohne Erfolg.
    
    Aber nochmal auf meine ursprüngliche Frage zurückzukommen. Du siehst keine Möglichkeit das ganze über IPv6 laufen zu lassen?
    
    Gruß
    Tobi
    
    Antworten
    1. Jan
      9. Mai 2018 um 12:57 Uhr
      
      Hi Tobi,
      
      wenn du alles über IPv6 laufen lassen würdest, dann würde es vermutlich auch funktionieren. Allerdings müsstest du dann vermutlich auch dein komplettes LAN auf IPv6 umstellen, was denke ich den Aufwand nicht lohnt. Ich sage extra „vermutlich“, da ich so etwas noch nie ausprobiert habe und nicht garantieren kann, dass das am Ende auch funktioniert.
      Wenn du dich noch innerhalb der Widerrufsfrist befindest, kannst du das ja evtl. auch als „Druckmittel“ einsetzen. Ansonsten wird dir wohl nichts anderes übrig bleiben, als zu einem anderen Provider zu wechseln.
      
      Gruß,
      Jan
      
      Antworten
    2. Tobi
      18. Mai 2018 um 10:26 Uhr
      
      Hey Jan,
      
      hättest recht. Hat zwar gedauert, aber wenn man mal den richtigen Vodafone-Techniker dran hat, dann ist das kein Problem.
      
      Nachdem das ganze nicht so trivial is, als für andere wollte ich dich fragen, wann du ca. den Artikel auf Ubuntu 18 umstellst, und ob du dann auch auf Nextcloud 13 umstellst.
      
      Gruß
      Tobi
      
      Antworten
      1. Jan
        18. Mai 2018 um 11:17 Uhr
        
        Hi Tobi,
        
        hab ich doch gewusst, Hartnäckigkeit zahlt sich hier aus. ;-)
        
        Weil es doch hier und da ein paar Änderungen bei Ubuntu 18.04 gibt, habe ich mich dazu entschlossen, den alten Artikel nicht zu überarbeiten, sondern einen komplett neuen Artikel zu schreiben. Ich bin dran, kann aber noch nichts versprechen, wann ich damit fertig bin. Ich habe dafür leider im Moment nicht so wirklich viel Zeit. Aber der neue Artikel kommt, mit 18.04, NC 13 und einigen Detail-Verbesserungen.
        
        Gruß,
        Jan
      2. Tobi
        18. Mai 2018 um 14:06 Uhr
        
        Respekt, dass du dir die Arbeit machst. Find ich echt super!!!
        
        Dann werde ich wohl wieder zurück wechseln zu 16 und 12.
        
        Danke dir!
      3. Tobi
        25. Mai 2018 um 9:26 Uhr
        
        Hallo Jan,
        
        ich versuche jede freie Minute auf meinen Server Nextcloud zu installieren. Jedoch kann wenn ich über den Browser auf das Nexcloud-Setup zuzugreifen, sagt mir meine FritzBox das der link nicht existiert und leitet mich zu Startseite der FritzBox weiter. Habe deinen Anleitung aufs kleinste Detail des öfteren überprüft und wiederholt bis ich festgestellt habe, dass sich mit den angegebenen Paketquellen nur nginx 1.10, anstatt 1.13.4 installiert. Dann habe ich es mit unterschiedlichen Ubuntu 16.04.3 Versionen von der Website des Herstellers (https://wiki.odroid.com/odroid-xu4/os_images/linux/ubuntu/ubuntu) versucht, aber es wird nicht nginx 1.13.4 installiert. Letztenendes bin ich aktuell wieder bei Ubuntu 18.04 gelandet und das Problem ist immer noch das gleiche.
        
        Mein FritzBox sagt, das der DynDNS erfolgreich angemeldet ist.
        
        Hast du vielleicht eine Idee wo mein Problem liegt?
      4. Jan
        27. Mai 2018 um 11:23 Uhr
        
        Hi Tobi,
        
        ich bräuchte noch ein paar zusätzliche Infos von dir. Daher habe ich dir eine E-Mail geschickt. Das ist glaube ich einfacher als die Kommunikation über Blog-Kommentare.
        
        Gruß,
        Jan
Wolfgang
11. Mai 2018 um 9:07 Uhr

Hallo Jan,

ich weiß nicht mehr weiter. Bei der Zertifizierung bekomme ich immer folgende Meldung:

– The following errors were reported by the server:

Domain: Domain.my-wan.de
Type: unauthorized
Detail: Invalid response from
http://domain.my-wan.de/.well-known/acme-challenge/X…Q:
“
404 Not Found

404 Not Found
“

To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address.

Ich habe alls auf Ubuntu 18.x Server installiert. Die Domain ist von aussen erreichbar. Weiterleitungen auf Port 80 und 443 sind vorhanden. Die Einstellungen habe ich mehrfach geprüft. Wo ist der Fehler?

Gruß Wolfgang

Antworten
1. Jan
  11. Mai 2018 um 9:33 Uhr
  
  Hi Wolfgang,
  
  Let’s Encrypt legt im Rahmen der Zertifikats-Generierung eine zufällige Datei in deinem www-letsencrypt Ordner an und ruft diese dann durch den Webserver ab. Der Fehler 404 bedeutet, dass er diese Datei nicht finden kann. Das wird vermutlich an irgendeiner Kleinigkeit in der vHost-Config (Gateway-Host oder Host für LE) liegen. Schau doch mal ins Logfile von nginx nachdem ein solcher Fehler aufgetreten ist. Hier sollte der Pfad stehen, in dem nginx die Datei erwartet hätte. Das gibt vielleicht Aufschluss darüber, was an den vHosts noch geändert werden muss.
  
  Gruß,
  Jan
  
  Antworten
  1. Wolfgang
    11. Mai 2018 um 15:30 Uhr
    
    Hallo Jan,
    
    der Inhalt vom Gateway_Host:
    
    server {
    listen 80 default_server;
    server_name domain.my-wan.de 192.168.168.10;
    
    root /var/www;
    
    location ^~ /.well-known/acme-challenge {
    proxy_pass http://127.0.0.1:81;
    proxy_redirect off;
    }
    }
    Und von Host_LE:
    server {
    listen 127.0.0.1:81;
    server_name domain.my-wan.de 127.0.0.1;
    
    location ^~ /.well-known/acme-challenge {
    default_type text/plain;
    root /var/www/letsencrypt;
    }
    }
    die dateien liegen beide unter /etc/nginx/conf.d mit den Namen:
    domain.my-wan.de.conf und
    domain.my-wan.de_letsencrypt.conf
    
    so sollte es doch auch sein?
    
    Im error.log von nginx finde ich:
    
    2018/05/10 19:35:44 [emerg] 1823#1823: a duplicate default server for 0.0.0.0:80 in /etc/nginx/sites-enabled/default:22
    2018/05/10 21:37:49 [error] 2891#2891: *17 no „ssl_certificate“ is defined in server listening on SSL port while SSL handshaking, client: 54.158.245.85, server: 192.168.168.10:443
    2018/05/10 21:37:49 [error] 2891#2891: *18 no „ssl_certificate“ is defined in server listening on SSL port while SSL handshaking, client: 54.158.245.85, server: 192.168.168.10:443
    2018/05/11 01:30:19 [error] 2891#2891: *28 no „ssl_certificate“ is defined in server listening on SSL port while SSL handshaking, client: 46.101.161.34, server: 192.168.168.10:443
    2018/05/11 01:35:33 [error] 2891#2891: *29 no „ssl_certificate“ is defined in server listening on SSL port while SSL handshaking, client: 196.52.43.59, server: 192.168.168.10:443
    2018/05/11 06:49:27 [notice] 5575#5575: signal process started
    2018/05/11 06:49:27 [error] 5575#5575: invalid PID number „“ in „/run/nginx.pid“
    2018/05/11 06:49:32 [notice] 5580#5580: signal process started
    2018/05/11 07:41:12 [notice] 5825#5825: signal process started
    2018/05/11 07:41:17 [notice] 5827#5827: signal process started
    2018/05/11 10:12:06 [error] 5828#5828: *29 no „ssl_certificate“ is defined in server listening on SSL port while SSL handshaking, client: 50.116.27.38, server: 192.168.168.10:443
    
    Gruß Wolfgang
    
    Antworten
    1. Jan
      12. Mai 2018 um 9:30 Uhr
      
      Hi Wolfgang,
      
      also zunächst einmal sollte der server_name im LE-vHost so aussehen (Domain entfernen):
      server_name 127.0.0.1;
      Das eigentliche Problem ist aber glaube ich die Verzeichnisstruktur. Im nginx-Log sieht man, dass die Verzeichnisstruktur bei dir anders ist (habe ich auch schon auf 18.04 beobachten können): Hier sind alle vHost, die geladen werden, im Verzeichnis /etc/nginx/sites-enabled gespeichert. Hier müssen also auch deine vHosts (Gateway und LE) liegen. Also einfach hierhin verschieben und nginx neu starten. Den default-vHost solltest du auch hier finden können, den kannst du entfernen.
      
      Gruß,
      Jan
      
      Antworten
Wolfgang
13. Mai 2018 um 12:57 Uhr

Hallo Jan,

die Dateien habe ich angepasst und verschoben. nginx neu gestartet. Zertifizierung angestossen, é voila. Es klappt!

Vielen Dank!

Wolfgang

Antworten
1. Jan
  13. Mai 2018 um 13:52 Uhr
  
  Hi Wolfgang,
  
  super, freut mich!
  Vielen Dank für die Rückmeldung.
  
  Gruß,
  Jan
  
  Antworten
Wolfgang
13. Mai 2018 um 20:01 Uhr

Hallo Jan,
leider habe ich schon wieder einen Fehler bei dem ich nicht weiterkomme. Ich erhalte nach der installation von Nextcloud den Fehler 502 Bad Gateway.
Im nginx.log finde ich die Zeile:
2018/05/13 16:28:46 [crit] 1237#1237: *5 connect() to unix:/run/php/php7.0-fpm.sock failed (2: No such file or directory) 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: „192.168.168.10“
Installiert habe ich PHP7.2
Unter /run/php gibt es nur php7.2. wo kommt diese Version her?

Gruß

Wolfgang

Antworten
1. Jan
  13. Mai 2018 um 20:32 Uhr
  
  Hi Wolfgang,
  
  die Definition des Upstream-Handlers ist ganz oben im Nextcloud vHost definiert. Wenn du PHP 7.2 verwendest, heisst der Socket natürlich anders und muss im vHost angepasst werden. Danach auf jeden Fall nginx nochmal neu starten.
  
  Gruß,
  Jan
  
  Antworten
  1. Wolfgang
    15. Mai 2018 um 10:58 Uhr
    
    Hallo Jan,
    
    vielen Dank. Ich habe in verschiedene *.conf geschaut. In diese mindestend 3 mal; Aber die oberste Zeile jedesmal überlesen…
    
    Gruß
    Wolfgang
    
    Antworten
    1. Dennis
      18. Mai 2018 um 20:19 Uhr
      
      Hallo Wolfgang,
      
      wie Jan schon schrieb, findest du die Zeile in der Nextcloud.conf.
      Ich habe so ziemlich den gleichen Fehler wie du oben beschrieben hast. Allerdings habe ich Ubuntu 18.04 installiert, denn dort gibt es php7.2. Kann es sein, dass du auch Ubuntu 18.04 installiert hast?
      
      Gruß Dennis
      
      Antworten
Frank
18. Mai 2018 um 11:03 Uhr

Hallo Jan.
danke für deine mühevolle Arbeit hier im Forum.
Kannst du mir bitte weiterhelfen, denn ich habe eine Fehlermeldung „systemctl status php7.0-fpm.service, php7.0-fpm.service: Main process exited,
Mai 18 10:44:30 raspberrypi systemd[1]: Failed to start The PHP 7.0 FastCGI Proc;
Benutze eine Raspberry Strech-Lite –
Mai 18 11:00:52 raspberrypi php-fpm7.0[15127]: [18-May-2018 11:00:52] ERROR: [/etc/php/7.0/fpm/pool.d/www.conf:2] unknown entry ‚user‘
Mai 18 11:00:52 raspberrypi php-fpm7.0[15127]: [18-May-2018 11:00:52] ERROR: Unable to include /etc/php/7.0/fpm/pool.d/www.conf from /etc/php/7.0/fpm/php-fpm.conf at line 2
Mai 18 11:00:52 raspberrypi php-fpm7.0[15127]: [18-May-2018 11:00:52] ERROR: failed to load configuration file ‚/etc/php/7.0/fpm/php-fpm.conf‘
Mai 18 11:00:52 raspberrypi php-fpm7.0[15127]: [18-May-2018 11:00:52] ERROR: FPM initialization failed
Mai 18 11:00:52 raspberrypi systemd[1]: php7.0-fpm.service: Main process exited, code=exited, status=78/n/a
Mai 18 11:00:52 raspberrypi systemd[1]: Failed to start The PHP 7.0 FastCGI Process Manager.
— Subject: Unit php7.0-fpm.service has failed
— Defined-By: systemd
— Support: https://www.debian.org/support
—
— Unit php7.0-fpm.service has failed.

Antworten
1. Jan
  18. Mai 2018 um 11:19 Uhr
  
  Hi Frank,
  
  schau mal in die Datei /etc/php/7.0/fpm/pool.d/www.conf, was hier bei user steht. Das müsste eigentlich so aussehen:
  user = www-data group = www-data
  
  Wenn nicht, dann bitte ändern und anschließend PHP-FPM nochmal neu starten.
  
  Gruß,
  Jan
  
  Antworten
Michael
18. Mai 2018 um 22:33 Uhr

Hallo Jan, ich bräuchte noch einmal Deine Hilfe. Ich weiß nicht warum, aber seit kurzem funktioniert der logrotate für nginx nicht mehr. Die error.log wächst und wächst. Ich wusste mir nicht anders zu helfen, als den Ordner /var/log/nginx zu löschen. Danach starte nginx erst einmal nicht. Das habe ich durch ein neues Anlegen des Ordners beheben können. Durch das Löschen muss ich die /var/run/nginx.pid geschrottet haben. Nginx läift zwar, gibt mir aber die Meldung aus: PID file /var/run/nginx.pid not readable. Ich habe nicht rausgefunden, wie ich das fixen kann. Vielleicht weißt Du ja Rat und Hilfe. Muss ich jetzt nich einmal alles neu aufsetzen?

Das Problem mit dem logrotate könnte daran liegen, dass in /etc/logrotate.d/nginx der Parameter create 640 nginx adm steht. Müsste das nicht create 640 www-data adm sein?

Herzliche Grüße
Michael

Antworten
1. Jan
  19. Mai 2018 um 9:03 Uhr
  
  Hi Michael,
  
  also dieses Problem hatte ich noch nie. Auch die Logs unter /var/log/nginx habe ich hin und wieder gelöscht, wenn irgendwas nicht funktioniert hat und ich saubere Logs gebraucht habe.
  Also zu Logrorate habe ich hier eine recht ausführliche Anleitung gefunden.
  
  Zu deinem Problem, dass nginx wegen dem PID File meckert: In dieser Datei speichert nginx einfach nur die Process-ID des Webservers. Schau dazu mal in der Datei /etc/nginx/nginx.conf nach der Zeile pid /var/run/nginx.pid;, ob hier alles passt (nicht auskommentiert oder so). Evtl. die Zeile mal ändern in pid /run/nginx.pid;. Anschließend immer nginx neu starten.
  
  Wenn alles nichts helfen sollte, dann einfach die vHost-Dateien sichern und nginx einmal deinstallieren und neu installieren. Das sollte das Problem denke ich auf jeden Fall beheben.
  
  Gruß,
  Jan
  
  Antworten
  1. Michael
    19. Mai 2018 um 9:41 Uhr
    
    Hallo Jan, vielen herzlichen Dank für Deine Antwort. Nun ja, ich hatte /var/log/nginx im laufenden Betrieb gelöscht. Und danach lief erst einmal nichts, weil er die error.log nicht finden konnte. Ich habe dann wie gesagt den Ordner einfach neu erstellt. nginx hat dann da auch brav die neuen logs erstellt.
    
    Die PID-File habe ich neu erstellt mit: systemtcl deamon-reload und systemtlc start nginx. Sowohl in /var/run/nginx.pid als auch in /run/nginx.pid steht jetzt dieselbe Prozess-ID. Das stimmt also schon einmal. Rechte sind jeweils root.
    
    Pid /var/run/nginx.pid ist nicht auskommentiert. service nginx status gibt aus: nginx.service: PID file /var/run/nginx.pid not readable (yet?) after start: No such file or directory.
    
    Mit v-Host-Dateien meinst Du die unter /etc/nginx/conf.d gespeicherten? Wie sähe eine sauber Deinstallation von nginx aus? nginx.conf sollte sicherlich auch gesichert werden.
    
    Herzliche Grüße
    Michael
    
    Antworten
    1. Jan
      19. Mai 2018 um 10:02 Uhr
      
      Hi Michael,
      
      schau mal in die Definition der service-Datei von nginx (/lib/systemd/system/nginx.service). Hier sollte auch die entsprechende PID-Datei definiert sein: PIDFile=/var/run/nginx.pid im Abschnitt [Service].
      
      Versuch einfach auch mal folgenden Befehl zum Neustarten des Webservers: systemctl restart nginx.service
      
      Wenn doch eine Neuinstallation notwendig ist, dann mit
      apt-get remove --purge nginx nginx-common nginx-full apt-get install nginx service nginx restart
      
      Vorher die vHost (genau, sind unter /etc/nginx/conf.d/ zu finden) und evtl. die globale Konfiguration unter /etc/nginx/nginx.conf sichern.
      
      Gruß,
      Jan
      
      Antworten
      1. Michael
        19. Mai 2018 um 11:42 Uhr
        
        Hallo Jan, vielen Dank für Deine Antwort. Wie immer ist Dein Support Gold wert. Vielen herzlichen Dank! systemctl restart nginx.service hat das Problem gelöst. Nun spuckt auch service nginx status keine Fehlermeldungen mehr aus.
        
        Gibt es eigentlich eine einfache Möglichkeit den log-Ordner von nginx zu leeren? Mir fällt spontan nur cat /dev/null > /var/log/nginx/* ein.
        
        Herzliche Grüße
        Michael
      2. Jan
        19. Mai 2018 um 12:36 Uhr
        
        Hi Michael,
        
        super, danke für die Rückmeldung. systemctl ist eh die „korrektere“ Möglichkeit, einen Service neu zu starten.
        Den Log-Ordner von nginx kann der Webserver nicht selbst leeren. Wie groß sind denn die Logfiles nach welcher Laufzeit? Selbst wenn es ein paar MB sind, dann ist das eigentlich nicht weiter wild.
        Wie man das ganze halbwegs automatisieren kann, ist hier beschrieben.
        
        Gruß,
        Jan
Meiko
22. Mai 2018 um 12:04 Uhr

Hallo Jan,

super Anleitung! Ich habe nun WordPress und Nextcloud parallel im Betrieb. Lieder stelle ich fest, dass nach einem Neustart des Servers der Dienst php7.0-fpm nicht automatisch gestartet wurde. Wenn ich den nun manuell starte, läuft alles. Gibt es etwas, was ich bei der Einrichtung falsch gemacht haben kann? Es läuft ansonsten alles!
Danke
Meiko

Antworten
1. Jan
  22. Mai 2018 um 12:22 Uhr
  
  Hi Meiko,
  
  hast du schonmal ein systemctl enable php7.0-fpm versucht? Danach sollte der Service beim Neustart auch gestartet werden.
  
  Gruß,
  Jan
  
  Antworten
Hansi
29. Mai 2018 um 5:33 Uhr

Hallo Jan,
Danke für die wirklich gute und ausführliche Anleitung. Die offenen Todos meiner Nextcloud-Installation wie letscrypt und fail2ban habe ich Dank deiner Anleitung super umsetzen können. Meine Angst fail2ban umzusetzen konnte ich so überwinden.

Bei meiner Umsetzung trat das Problem auf, dass die vorhandenen und mit der älteren Nextcloud-Instanz verbundenen Geräte sich an der neuen Instanz (die ich mit Deiner Anleitung in Angriff nahm) mit dem alten Password anmelden wollten und durch fail2ban ausgesperrt wurden. Mit neuen Installation hatte ich auch neue Passwörter gesetzt. Damit konnten sich mehrere Geräte aussperren.

Hier kam die Hilfe der unban-Funktion von fail2ban gerade richtig:
-> fail2ban-client set „nextcloud“ unbanip 111.111.111.111 (https://wiki.ubuntuusers.de/fail2ban/#Entbannen)
Die Ban-Regel „nextcloud“ hatten wir in fail2ban Installation nach deiner Anleitung eingerichtet.
Beim Aufsetzten von Nextcloud mit neuen Passwörtern ist es wirklich ärgerlich wenn fail2ban die Arbeits-Ip sperrt und man sich fragt wo denn das Problem ist, weil die vergeblichen Anmeldeversuche von Apps oder Geräte mit falschem Passwort richtigerweise als bruteforce-Attaken erkannt werden. ;) Je mehr Apps oder Geräte man mit einem Dienst verbunden hat umso mehr sollte man seine Server Umsetzung planen.

Folgende kleine Macken gibt es bei meiner Installation noch:
Ist es bei euch auch so, dass bei einer Linkfreigabe (Android Nextcloud Client) ein http-Link erstellt wird anstatt https obwohl in der Nextcloud config overwrite.cli.url‘ => ‚https‘, vorhanden ist? Ich habe nach der Installation auf nextcloud 13.02 upgadeted. Weiß aber nicht ob dass was mit der installierten Version von Nextcloud zu tun hat oder mit der Proxy-Funkion von Nginx weil ja die eigentliche Nextcloud Installation auf http://localhost hört. Wenn man http Link jedoch händisch in https ändert Funktioniert die Linkfreigabe ohne Beanstandung.

Bei der PDF-Freigabe kommt eine Fehlermeldung wie dass der Server sich aufgehängt hat. Wenn man jedoch die Seite neu lädt geht es. Kann jemand die Erfahrungen teilen?

Danke nochmals für die Mühe

Hansi

Antworten
1. Jan
  29. Mai 2018 um 16:33 Uhr
  
  Hallo Hansi,
  
  erstmal danke für das Lob!
  Die zwei von dir beschriebenen Probleme kann ich in der gezeigten Konfiguration leider nicht nachvollziehen. Beim Teilen per Link wird sauber ein HTTPS-Link erzeugt. Wenn hier ein HTTP-Link geteilt wird, dann sollte das aber auch nicht weiter schlimm sein, da im Normalfall ein Redirect HTTP auf HTTPS automatisch erfolgt.
  Bei Teilen einer PDF-Datei könnte das evtl. mit der Preview-Generierung zusammen hängen. Klappt bei mir allerdings auch ohne Fehler.
  Hast du schonmal in die Logs (Nextcloud und ggf. nginx) geguckt, ob hier direkt nach Auftreten eines Problems etwas Auffälliges zu finden ist?
  
  Gruß,
  Jan
  
  Antworten
  1. Hansi
    30. Mai 2018 um 2:51 Uhr
    
    Hallo Jan,
    danke für die prompte Antwort.
    
    Also da ich den Server privat als Hobby betreibe habe ich nur den Port für Https offen. Habe auch Webserver u. Co. so konfiguriert. Das heißt es sind keine redirects von 80 auf 443 definiert. Nginx hört nur auf 443.
    
    Hast Du auch das aktuellste Nextcloud laufen? Komisch bevor ich auf Proxy umgestellt habe, hatte es funktioniert. Mhh dann habe ich Altlast-Konfigs mitgeschleppt ;)
    
    Die Nginx-Logs dies bezüglich habe ich wirklich nicht angeschaut, weil ich dachte dass es mit dem lokalen Webserver htttp://localhost zu tun hat.
    
    Die Nextcloud-Logs sind sauber bis auf folgende Fehler die alle paar Tage kommen:
    -> „Allowed memory size of 536870912 bytes exhausted “ ( obwohl ich in den php.inis 512MB eingetragen habe)
    
    -> Undefined index: name at /var/www/html/nextcloud/3rdparty/sabre/dav/lib/CardDAV/Xml/Filter/AddressData.php#56
    
    -> call_user_func() expects parameter 1 to be a valid callback, class ‚OCA\OcSms\Db\Config‘ not found at /var/www/html/nextcloud/lib/public/AppFramework/Db/Mapper.php#318
    (Ok, dieser Fehler gehört zum Telefon-Sync app; -nur- bei dieser kommt auf der Weboberfläche die Meldung: Verbindung zum Server verloren; die App funktioniert scheint aber bischen buggy zu sein)
    
    Die zweite Fehlermeldung hat etwas mit Carddav zu tun; dass kann ich noch deuten. Aber ob der erste Fehler mit dem Http-Link-Problem zu tun hat kann ich nicht sagen.
    
    Ich will demnächst von Collabora Office zu OnlyOffice wechseln und probieren wie das werkelt, weil dort noch Projektmanagement app und CRM angeboten werden. (Obwohl Nextcloud echt top Sync und Cloud-Leistung bietet fehlt mir die Interaktion der einzelnen Elemente bzw. Apps zusammen innerhalb der Plattform wie bei Tine20 oder EGroupware.)
    
    Somit werde ich die Konfigs durch gehen und alles mal wieder sauber aufsetzen.
    
    Danke!
    Hansi
    
    Edit: Auch in den nginx-error-logs ist nichts. Hier würde ja was stehen wenn der webserver mit einem Aufruf Probleme hätte. Aber der Link wird ja sauber weitergegeben, halt nur in http.
    
    Antworten
Dirk
8. Juni 2018 um 23:34 Uhr

Hallo Jan,
zunächst auch von mir herzlichsten Dank für diese SUUUPER Anleitung. Bis jetzt hat alles geklappt. Nun hänge ich bei (service nginx restart) fest (Anlegen des virtuellen Hosts für Let’s Encrypt). Es gibt die hier bereits öfters erwähnte Fehlermeldung:
Job for nginx.service failed because the control process exited with error code.
See „systemctl status nginx.service“ and „journalctl -xe“ for details.

journalctl -xe bringt folgendes

— The result is failed.
Jun 08 23:18:10 raspberrypi systemd[1]: nginx.service: Unit entered failed state
Jun 08 23:18:10 raspberrypi systemd[1]: nginx.service: Failed with result ‚exit-
Jun 08 23:28:01 raspberrypi systemd[1]: Starting A high performance web server a
— Subject: Unit nginx.service has begun start-up
— Defined-By: systemd
— Support: https://www.debian.org/support
—
— Unit nginx.service has begun starting up.
Jun 08 23:28:01 raspberrypi nginx[16034]: nginx: [emerg] a duplicate default ser
Jun 08 23:28:01 raspberrypi nginx[16034]: nginx: configuration file /etc/nginx/n
Jun 08 23:28:01 raspberrypi systemd[1]: nginx.service: Control process exited, c
Jun 08 23:28:01 raspberrypi systemd[1]: Failed to start A high performance web s
— Subject: Unit nginx.service has failed
— Defined-By: systemd
— Support: https://www.debian.org/support
—
— Unit nginx.service has failed.

grep -R default_server /etc/nginx ergibt folgendes Ergebnis

/etc/nginx/sites-enabled/default: listen 80 default_server;
/etc/nginx/sites-enabled/default: listen [::]:80 default_server;
/etc/nginx/sites-enabled/default: # listen 443 ssl default_server;
/etc/nginx/sites-enabled/default: # listen [::]:443 ssl default_server;
/etc/nginx/sites-available/default: listen 80 default_server;
/etc/nginx/sites-available/default: listen [::]:80 default_server;
/etc/nginx/sites-available/default: # listen 443 ssl default_server;
/etc/nginx/sites-available/default: # listen [::]:443 ssl default_server;
/etc/nginx/conf.d/vpn.dl-ms.de.conf: listen 80 default_server;

Wo müsste ich was ändern, damit ich nginx korrekt starten und mit Deiner herrlichen Anleitung weiter machen kann? Eine Schrittweise Anleitung wäre toll, da ich noch nicht ganz so firm in Linux bin.
Über eine Hilfestellung von Dir würde ich mich sehr freuen. Die Hinweise in den Kommentaren zu Deinen Artikeln haben mich nicht wirklich weitergebracht. Liebe Grüße…

Antworten
1. Jan
  8. Juni 2018 um 23:47 Uhr
  
  Hi Dirk,
  
  geb mal „nginx – t“ in die Konsole ein. Ist denke ich ein Fehler in einem der nginx vHosts. Mit diesem Befehl wird er dir genau sagen, wo das Problem ist.
  
  Gruß,
  Jan
  
  Antworten
Dirk
9. Juni 2018 um 9:17 Uhr

Hi Jan,
danke für die schnelle Antwort. nginx -t gibt folgendes
nginx: [emerg] a duplicate default server for 0.0.0.0:80 in /etc/nginx/sites-enabled/default:22
nginx: configuration file /etc/nginx/nginx.conf test failed

hilft mir aber nicht weiter.
gruß
dirk

Antworten
1. Jan
  9. Juni 2018 um 10:14 Uhr
  
  Hi Dirk,
  
  zunächst einmal habe ich deinen ersten Kommentar etwas gekürzt, in dem ganzen systemctl standen ja nicht wirklich sinnvolle Infos drin. Ich hoffe, das geht in Ordnung.
  Den Fehler hattest du übrigens auch schon im ersten Kommentar mit aufgedeckt: Der server-Block, der auf Port 80 lauscht, ist zwei mal definiert. Anscheinend hast du den default-vHost nicht entfernt. Dazu einfach ein rm /etc/nginx/sites-enabled/default, da der default-Host eh nicht benötigt wird. Danach nginx neu starten und es sollte eigentlich klappen.
  
  Gruß,
  Jan
  
  Antworten
  1. Dirk
    9. Juni 2018 um 10:35 Uhr
    
    Hallo Jan,
    danke für den Tipp. Scheinbar ist nun das Problem behoben. Nginx ließ sich neu starten. NUn mache ich mal weiter im Tutorial. Nochmals Tausend Dank für die super freundliche Hilfe.
    Schönes Wochenende.
    Dirk
    
    Antworten
Constantin Coada
14. Juni 2018 um 9:33 Uhr

Hallo Jan!

Auch ich möchte mich für Deine super Anleitung bedanken, gemessen an das bis jetzt bereits erreichten Ergebnis und meine eher dürftige Fähigkeiten.

Bin etwas gestolpert bei der Einrichtung des cron-Jobs, etwas scheint nicht zu funktionieren, magst Du bitte mir weiter helfen?

Die Fehlermeldung besagt:

Die Ausführung des Cron-Jobs über die Kommandozeile war nicht möglich. Die folgenden technischen Fehler sind dabei aufgetreten:
Your data directory is invalid Ensure there is a file called „.ocdata“ in the root of the data directory.
Cannot create „data“ directory This can usually be fixed by giving the webserver write access to the root directory. See https://docs.nextcloud.com/server/13/go.php?to=admin-dir_permissions

Viele Grüße
Constantin

Antworten
1. Jan
  14. Juni 2018 um 10:07 Uhr
  
  Hi Constantin,
  
  Cron läuft über PHP-CLI (also Kommandozeile). Ich vermute daher mal, dass in der Datei /etc/php/7.2/cli/php.ini bei open_basedir dein Datenverzeichnis nicht mit aufgeführt wird, so dass PHP keinen Zugriff darauf hat.
  Ansonsten: Ein chown -R www-data:www-data /var/nextcloud_data (oder wo auch immer dein Datenverzeichnis liegt) hast du gemacht?
  
  Gruß,
  Jan
  
  Antworten
  1. Constantin Coada
    8. Juli 2018 um 10:24 Uhr
    
    Hi Jan,
    
    und lieben Dank für die schnelle Antwort.
    
    *open_basedir* ist richtig gesetzt, allerdings warum auch immer, bei mir ist die *php.ini* hier zu finden */etc/php/**7.0**/cli/*
    
    Und *www-data* ist der Besitzer des */var/nextcloud-data/* Verzeichnisses.
    
    Viele Grüße
    Constantin
    
    Antworten
    1. Jan
      8. Juli 2018 um 19:51 Uhr
      
      Hi Constantin,
      ok, dann hast du noch PHP 7.0 im Einsatz. Das sollte eigentlich kein Problem sein.
      Wie genau schaut die Zeile für den Cronjob aus, wenn du crontab -u www-data -e aufrufst?
      Viel interessanter wäre aber, ob es im Nextcloud-Log einen Eintrag gibt, wenn der Cronjob eigentlich gerade gelaufen sein sollte? Hier sollte eigentlich eine Fehlermeldung zu finden sein, die genau sagt, was schief gelaufen ist.
      
      Gruß,
      Jan
      
      Antworten
      1. Constantin Coada
        3. September 2018 um 5:49 Uhr
        
        Hi Jan,
        
        entschuldige bitte die verspätete Antwort, andere Pflichten haben mich fern von meinem Hobby gehalten.
        
        Die Zeile für den Cronjob sieht eigentlich korrekt aus:
        “ */15 * * * * php -f /var/www/nextcloud/cron.php > /dev/null 2>&1″
        
        Aber das Nextcloud-Log finde ich in /var/log leider nicht, wo muss ich sonst suchen?
        
        Viele Grüße
        Constantin
      2. Jan
        3. September 2018 um 12:21 Uhr
        
        Hallo Constantin,
        
        das Nextcloud-Log befindet sich im Datenverzeichnis von Nextcloud (also z.B. /var/nextcloud_data).
        Du könntest hier auch mal probieren, den Cronjob manuell auszuführen:
        cd /var/www/nextcloud sudo -u www-data php -f cron.php
        Hier müsste im Fehlerfall dann direkt eine Fehlermeldung auf der Konsole kommen.
        
        Gruß,
        Jan
Dirk
15. Juni 2018 um 22:22 Uhr

Hallo Jan,
ich bin mittlerweile vor der Installation von Nextcloud angekommen. Es sollte ja nginx -t alles prüfen und dann per Restart der Server Neustart erfolgen.

Es kam als erster Fehler:
nginx: [emerg] „location“ directive is not allowed here in
/etc/nginx/conf.d/vpn.dl-ms.de.conf:13
Hier habe ich mal einfach so die { in der Zeile davor entfernt.

Beim zweiten Versuch kam jetzt nur diese Warnung
nginx: [warn] invalid value „TLSv1.3“ in /etc/nginx/conf.d/vpn.dl-ms.de.conf:42
nginx: configuration file /etc/nginx/nginx.conf test failed

Da weiß ich jetzt nicht weiter. Auch das Netz sagt nichts konkretes was weiterhelfen würde.

Wäre klasse, wenn Du weiter weißt!!!

Antworten
1. Jan
  16. Juni 2018 um 14:49 Uhr
  
  Hi Dirk,
  
  vermutlich ist die nginx Version zu alt. TLSv1.3 wird erst ab 1.14.x unterstützt. Daher einfach das „TLSv1.3“ in der entsprechenden Zeile wieder entfernen.
  Ist sicherheitstechnisch auch nicht weiter wild, da TLSv1.3 momentan eh von fast keinem Client unterstützt wird.
  
  Gruß,
  Jan
  
  Antworten
Bodo
21. Juni 2018 um 20:34 Uhr

Hallo Jan,
vorab einen großen Dank an dieses wirklich sehr ausführliche und hilfreiche Tutorial!
Ich konnte alles größtenteils so umsetzen und musste nur wenige Änderungen vornehmen, weil mein Server an einem ds-lite-Anschluss hängt (z.B. im server-Block des Gateway hosts „listen [::]:443 ssl http2;“ eintragen).

Unter normalen Umständen funktioniert der Zugriff auf problemlos. Leider ist so ein ds-lite-Anschluss alles andere als normal…
Das heißt von IPv4-Netzwerken aus muss ich über einen Portmapper gehen. Die ganze URL sieht dann z.B. so aus:

https://nextcloud.feste-ip.net:63472/nextcloud/

Bei einer früheren Installation von nextcloud mit apache2 ging das auch relativ problemlos. Das war insgesamt eine wesentlich simplere Konfiguration und nextcloud hatte ich im Server-root-Verzeichnis, so dass ich in der URL das Unterverzeichnis /nextcloud/ weglassen konnte.

Hier habe ich jedoch das Problem, dass ‚irgendwas‘ mit der zusätzlichen Portnummer hinter dem domain-Namen nicht klarkommt. Wenn ich obige URL im Browser eingebe, lande ich zuerst auf der Login-Seite und werde dann aufgefordert die domain als vertrauenswürdige Domain hinzuzufügen. Das heißt, prinzipiell funktionieren hier Portmapper, Webserver und Browser.

Sobald ich das gemacht habe, verschwindet aus der URL der Port und der Browser findet keine Seite mehr (getestet mit Firefox und Opera). Also es kommt auch keine Fehlermeldung vom Webserver.

Das heißt ‚irgendwas‘ kommt mit der Portnummer nicht klar und lenkt den Browser auf eine falsche URL nach dem Login (je nach Einstellung die Portmapper-URL OHNE Port oder was auch immer in der config.php als overwrite.cli.url eingetragen ist). Näher konnte ich leider nicht identifizieren, wo das Problem liegt. Ich hatte diverse Änderungen in der config.php, in der gateway- und der vhost-Konfiguration versucht – ohne Erfolg.

Kannst du mir hier weiterhelfen, woran es liegen könnte? Ich weiß nicht mehr weiter.

Antworten
1. Jan
  22. Juni 2018 um 10:44 Uhr
  
  Hi Bodo,
  
  das leidige Thema DS-Lite. Hatte früher auch mal kurzzeitig einen DS-Lite Anschluss und habe es nicht sauber hinbekommen, dahinter die Cloud zu hosten. Einfachste Lösung war dann eine IPv4-Option beim Provider dazuzubuchen. Seitdem keine Probleme mehr, aber ich mache einen großen Bogen um DS-Lite.
  Da das bei dir ja anscheinend trotzdem irgendwie klappt, vermute ich hier fast mal folgendes: Nextcloud baut sich intern vermutlich die falschen URLs (ohne Port) zusammen. Schau mal in die config-php von Nextcloud und ergänze mal folgende Einträge, falls noch nicht vorhanden:
  'overwritehost' => 'nextcloud.feste-ip.net:63472', 'overwriteprotocol' => 'https', 'overwritewebroot' => '/nextcloud' 'overwrite.cli.url' => 'https://'nextcloud.feste-ip.net:63472/nextcloud',
  
  Danach sicherheitshalber mal den Webserver neu starten.
  
  Gruß,
  Jan
  
  Antworten
  1. Bodo
    23. Juni 2018 um 15:29 Uhr
    
    (Ich hab mittlerweile den aktualisierten Artikel gefunden, in dem das ganze mit Ubuntu 18.04 etc. gemacht wird, aber das Problem ändert sich dadurch ja nicht.)
    
    Erstmal danke für die Lösungsvorschläge. Haben leider nicht viel geholfen. DS-lite ist wirklich leidig, aber im Moment für mich die einzige Option.
    Das einzige, was half, war immer wieder hartnäckig die Portnummer im Browser nachzutragen. Solange man eingeloggt bleibt, ist das sogar einigermaßen stabil. Nur bezweifle ich, ob das Clientanwendungen, die auf den Kalender oder andere Funktionen zugreifen, helfen wird. Hab ich aber, ehrlich gesagt, noch nicht probiert.
    
    Ich hatte jedoch einen anderen Ansatz verfolgt, wie hier beschrieben: https://community.letsencrypt.org/t/custom-port-in-domain-name-port-mapper-ds-lite/63155/10
    Dabei wird der Portmapper ganz vermieden, indem man Cloudflare als CDN einsetzt. In Grundzügen hat das sogar funktioniert. Sprich, die default-Seite von nginx konnte ich damit z.B. über das Smartphone (ohne WLAN, also aus einem reinen IPv4-Netz) erreichen.
    
    Nur mit komplexeren Konfigurationen, wie der von Nextcloud, scheitert es. Entweder meldet der Browser einen Umleitungsfehler, oder wenn ich „return 301 https://$server_name$request_uri;“ aus dem „location /“-Block der Gateway-Konfiguration auskommentiere, funktioniert das php-handling nicht mehr.
    Der Browser (bzw. alle getesteten, auch der vom Smartphone) bietet lediglich die index.php aus dem Nextcloud-Ordner zum Download an (und ja, Browser-Cache leeren hab ich probiert ;) ).
    
    Hier bin ich leider mit meinem Latein am Ende. Ich hab keine Ahnung, wie diese return-Einstellung sich auswirkt oder was die vielen location-Blöcke im Nextcloud-vHost im Einzelnen bewirken. Oder ob da überhaupt das Problem liegt.
    
    Gruß
    Bodo
    
    Antworten
    1. Jan
      23. Juni 2018 um 22:10 Uhr
      
      Hi Bodo,
      
      lass das return 301 … erst einmal drin und geh direkt über die https-URL. Dann sollte der Redirect von HTTP auf HTTPS gar nicht stattfinden und wir können diesen Redirect erst einmal aus der Gleichung nehmen.
      Ich denke hier ist noch ein Fehler bzgl. Clourflare enthalten. Ich habe Cloudflare selbst noch nie genutzt, aber bekomst du hier eine neue Domain (also von Cloudflare)? Wenn ja, dann müsstest du diese Domain noch in den vHost (Gateway) eintragen. Das wird auch in dem von dir genannten Thread beschrieben.
      Wenn es nicht auf Anhieb funktioniert, dann würde ich mit der Console des Brwosers (z.B. F12 mit Chrome) gucken, was hier an Redirects stattfindet. Hier sollte man einen evtl. auftretenden Fehler schnell erkennen.
      
      Gruß,
      Jan
      
      Antworten
      1. Bodo
        27. Juni 2018 um 22:32 Uhr
        
        Hey,
        die Domain hatte ich vorher bei freenom registriert und dort die entsprechenden nameserver von Cloudflare eingetragen. Ansonsten hatte ich alles schon so gemacht. Und so gesehen ist es erst recht merkwürdig, dass return 301… einen Einfluss hat, selbst wenn ich direkt https://… benutze.
        Und wie gesagt: mein „größter Erfolg“ war, dass ich die index.php runterladen konnte. Also bin ich zumindest schon mal auf dem richtigen Server gelandet ;)
        
        Über die Konsole (in meinem Fall Firefox) konnte ich nichts herausfinden. Die Seite wird 20 mal immer wieder auf die gleiche URL geleitet und in den Kopfzeilen steht u.a. „Status-Code: 301 Moved Permanently“.
        
        Aber gut, soll halt nicht sein…
        Ich hab jetzt festgestellt, dass das Smartphone auch über den Portmapper Kalender und Kontakte mit Nextcloud synchronisieren kann. Die Bedenken waren also unbegründet und damit kann ich Nextcloud schon mal ganz gut nutzen :) Danke nochmal für die Tipps.
    2. Bodo
      5. Juli 2018 um 19:06 Uhr
      
      Nochmal ein kleines Update zur Portmapper-Geschichte:
      
      Ich hab jetzt eine Konfiguration getestet, bei der ich den Nextcloud-Host direkt in die Gateway-Datei gepackt habe (leicht angepasst). Quasi eine klassische Konfiguration.
      
      Damit funktioniert bislang der Zugriff via Portmapper reibungslos. Die Nachteile, keinen Reverse-Proxy mehr zu benutzen, halte ich für vernachlässigbar, da ich sonst eh nicht viel anderes hoste.
      
      Weggelassen habe ich den ganzen „proxy_set_header“-Block (die Funktionen sind per „add_header“ schon in der Gateway-Datei) und „fastcgi_param REMOTE_ADDR $http_x_real_ip;“, weil das zu massenhaft Fehlermeldungen im Log geführt hat.
      Hab auch irgendwo gelesen, dass „remote_addr“ statt „http_x_real_ip“ helfen soll; war bei mir aber genauso gut wie weglassen.
      
      Antworten
      1. Jan
        6. Juli 2018 um 7:19 Uhr
        
        Hi Bodo,
        
        danke für das Update!
        Wäre es denkbar, dass du alle notwendigen Schritte stichpunktartig zusammenfasst und mir per Mail zukommen lässt, um das Ganze mit einem DSLite-Anschluss hin zu bekommen? Evtl. könnte ich da einen Artikel draus machen, der bestimmt für viele Leute interessant wäre.
        
        Gruß,
        Jan
Ingo
21. Juni 2018 um 21:49 Uhr

Hallo,
wegen fehlender Ahnung bekomme ich für folgendes keine Lösung hin:
In der FritzBox ist ein Portweiterleitung für https (443) auf den Serverver mit dem Gateway-Host eingerichtet, um Nextcloud erreichen zu können. Nun kommt man aber von aussen über DSL nicht mehr auf die Konfigurationsoberfläche der FritzBox weil die ja auch über die Domain per https zu erreichen war. Nun müsste man in dem Gateway-Host also auch eine Verlinkung auf die FritzBox machen. Also statt meineDomain.org/nextcloud z.B. meineDomain.org/fritzbox
Wie macht man das?

Antworten
1. Jan
  22. Juni 2018 um 10:55 Uhr
  
  Hi Ingo,
  
  von außen auf die FritzBox zugreifen? Sicher, dass du das willst/musst? Als Absicherung ist hier nur das Passwort der FB da.
  Wenn es unbedingt sein muss, würde ich im Gateway-Host mal folgendes probieren (konkrete IP der FB musst du noch anpassen):
  location /fritz { proxy_pass http://192.168.178.1; proxy_redirect off; proxy_buffering off; }
  
  Eine bessere Lösung wäre, die FB gar nicht in dieses Konstrukt „einzuhängen“, sondern einen VPN-Zugang zu nutzen und die Admin-UI der FB ausschließlich über VPN zu nutzen.
  
  Gruß,
  Jan
  
  Antworten
Murderhead
30. Juni 2018 um 16:26 Uhr

Hallo Jan,

habe mal wieder ein Problem und zwar ist mein Raspberry Pi hängen geblieben. Ich konnte mich auch nicht mehr per SSH anmelden. Nichts ging mehr. Habe dann die kiste vom Strom genommen und neu Hochgefahren.

Jetzt habe ich das Problem das weder WordPress noch Nextcloud gehen.
Wenn ich meine Seite aufrufe kommt direkt „Error establishing a database connection“, Wie Repariere ich das ganze wieder?

Danke schon einmal für die Hilfe.

Antworten
1. Murderhead
  30. Juni 2018 um 21:53 Uhr
  
  Wenn ich mich mit „mysql -u root -p“ und mein „Passwort“ anmelde kommt folgender fehler: „ERROR 2002 (HY000): Can’t connect to local MySQL server through socket ‚/var/run/mysqld/mysqld.sock‘ (2 „No such file or directory“)“
  
  Antworten
2. Murderhead
  30. Juni 2018 um 22:28 Uhr
  
  Und mit „systemctl status mariadb.service“ bekomme ich “ Active: failed (Result: exit-code) since Sat 2018-06-30 22:25:17 CEST; 7s ago
  Process: 6766 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=exited, status=1/FAILURE)
  „
  
  Antworten
  1. Jan
    1. Juli 2018 um 11:56 Uhr
    
    Hi,
    
    so ein Fehler ist mir auch noch nicht untergekommen. Bin ich momentan auch ein wenig überfragt.
    Wenn du MariaDB neu startest (service mysql restart), was steht daraufhin im syslog (/var/log/syslog). Hier könnten ein wenig mehr Infos enthalten sind.
    
    Ansonsten könntest du auch diese Liste mal durcharbeiten. Vielleicht hilft es was.
    
    Wenn alle Stricke reißen, würde ich mal ausprobieren, MariaDB neu zu installieren.
    
    Gruß,
    Jan
    
    Antworten
    1. Murderhead
      1. Juli 2018 um 16:40 Uhr
      
      Hay,
      
      Mit „service mysql restart“ bekomme ich folgenden Fehler: „Failed to restart mysql.service: Interactive authentication required.
      See system logs and ’systemctl status mysql.service‘ for details.“.
      
      Im Syslog steht nicht wirklich was besonderes außer vielleicht:
      „Jun 30 06:31:16 MEINSERVERNAME kernel: [1662525.361408] Under-voltage detected! (0x00050005)
      Jun 30 06:31:22 MEINSERVERNAME kernel: [1662531.591410] Voltage normalised (0x00000000)“
      Was für MariaDB aber auch nicht wirklich von Interesse wäre sowie ein paar blockierungen durch die Firewall..
      
      Eine Idee wie ich die Datenbanken Sichern (Exportieren) kann und MaridDB komplett neu Installieren um dann die Datenbanken zu Importieren?
      
      Bin noch ziemlicher Linux Newbie^^
      
      Antworten
      1. Jan
        2. Juli 2018 um 18:38 Uhr
        
        Hi,
        
        also wenn im syslog nicht mehr drin steht, dann kann man damit auch recht wenig anfangen.
        Um MariaDB neu zu installieren, kannst du folgenden Befehl verwenden.
        apt-get --reinstall install mariadb-server
        Weil du vorher kein apt-get purge mariadb-server sollten die Datenbanken an sich erhalten bleiben.
        
        Gruß,
        Jan
      2. Murderhead
        2. Juli 2018 um 21:31 Uhr
        
        Hay,
        
        das hat leider auch nichts gebracht.
        
        Bin so vorgegangen:
        sudo /etc/init.d/mysql stop
        sudo apt-get –reinstall install mariadb-server
        sudo /etc/init.d/mysql restart
        
        [….] Restarting mysql (via systemctl): mysql.serviceJob for mariadb.service failed because the control process exited with error code.
        See „systemctl status mariadb.service“ and „journalctl -xe“ for details.
        failed!
        
        sudo tail /var/log/syslog
        
        Mit dem Ergebnis:
        
        Jul 2 21:13:49 MEINSERVERNAME systemd[1]: Starting MariaDB database server…
        Jul 2 21:13:51 MEINSERVERNAME mysqld[2194]: 2018-07-02 21:13:51 1995681792 [Note] /usr/sbin/mysqld (mysqld 10.1.23-MariaDB-9+deb9u1) starting as process 2194 …
        Jul 2 21:13:51 MEINSERVERNAME systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE
        Jul 2 21:13:51 MEINSERVERNAME systemd[1]: Failed to start MariaDB database server.
        Jul 2 21:13:51 MEINSERVERNAME systemd[1]: mariadb.service: Unit entered failed state.
        Jul 2 21:13:51 MEINSERVERNAME systemd[1]: mariadb.service: Failed with result ‚exit-code‘.
        
        —
        
        service mysql restart
        
        Ergibt immer noch:
        Failed to restart mysql.service: Interactive authentication required.
        See system logs and ’systemctl status mysql.service‘ for details.
        
        —
        
        systemctl status mariadb.service
        
        Ergibt auch noch:
        Active: failed (Result: exit-code) since Mon 2018-07-02 21:13:51 CEST; 7min ago
        Process: 2194 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=exited, status=1/FAILURE)
        
        —
        
        Hoffe du hast noch irgend eine Idee was ich machen könnte um die Kiste wieder zum laufen zu bekommen.
      3. Murderhead
        2. Juli 2018 um 21:54 Uhr
        
        Hay,
        
        ich hab es hinbekommen! Es läuft wieder alles wieder falls wer das selbe Problem mal hat.
        
        Einfach:
        
        sudo rm /var/lib/mysql/ib_logfile0
        sudo rm /var/lib/mysql/ib_logfile1
        sudo /etc/init.d/mysql restart
        
        Schon sollte alles wieder laufen.
        Zur kontrolle noch schnell:
        
        netstat -tanpl|grep 3306
        
        Fertig ;)
      4. Jan
        3. Juli 2018 um 7:24 Uhr
        
        Hi,
        
        sehr gut, ich wäre nun mit meinem Latein auch am Ende gewesen.
        Wie bist du auf diese Lösung gekommen?
        
        Gruß,
        Jan
Meiko
8. Juli 2018 um 19:02 Uhr

Hallo Jan,

super Anleitung und Hilfe von dir!

Ich möchte gern die App „Talk“ für Nextcloud nutzen und habe nun auch verstanden, dass ich dafür einen TURN Server laufen haben muss. Coturn scheint hier die erste Wahl zu sein. Habe den bereits installiert, scheitere aber an der Konfiguration von nginx.

Hast du eine Idee, was ich in die config eintragen muss? Und ist es überhaupt möglich TURN hinter dem Proxy laufen zu haben?

Danke dir!
Meiko

Antworten
1. Jan
  8. Juli 2018 um 20:20 Uhr
  
  Hi Meiko,
  
  mit Talk/Coturn habe ich bisher keine Erfahrungen machen können. Allerdings habe ich hier eine Anleitung für dich, bei der man gar nichts an der nginx-Konfiguration ändern muss. Damit sollte es eigentlich recht einfach möglich sein, Coturn in Betrieb zu nehmen.
  
  Gruß,
  Jan
  
  Antworten
  1. Meiko
    8. Juli 2018 um 22:49 Uhr
    
    Hallo Jan,
    
    danke dir. Ich habe uwf deaktiviert und die Portweiterleitung auf meinem Router aktiviert. Bei Aufruf meineurl.de:5349 erscheint
    
    Fehler: Gesicherte Verbindung fehlgeschlagen
    Beim Verbinden mit meineurl.de:5349 trat ein Fehler auf. SSL hat ungültige NPN-Erweiterungsdaten erhalten. Fehlercode: SSL_ERROR_NEXT_PROTOCOL_DATA_INVALID
    
    Ich habe in der Coturn Config die gleichen Letsencrypt Daten (Key und Cert) eingetragen. Was könnte es sein?
    
    Antworten
    1. Jan
      9. Juli 2018 um 9:45 Uhr
      
      Hi Meiko,
      
      da habe ich hier einen Hinweis gefunden (in den Kommentaren). Offensichtlich ist in den Debiab-Paketquellen eine veraltete Version von Coturn enthalten. Vielleicht ist das bei dir ja auch der Fall. Dann einfach mal mit einer neueren Version probieren.
      
      Gruß,
      Jan
      
      Antworten
      1. Meiko
        10. Juli 2018 um 8:04 Uhr
        
        Das war es ;-)
        
        Vielen Dank für deine Hilfe
Hans
30. Juli 2018 um 13:30 Uhr

Hallo,

nur zur Info, falls du die Beta von NC 14 noch nicht getestet hast.

Im Log wird im Sekundentakt folgender Fehler ausgegeben.
Redis::connect(): connect() failed: Permission denied at /var/www/nextcloud/lib/private/RedisFactory.php#84

Zudem werden noch folgende Meldungen ausgegeben.

Die Verwendung des eingebauten PHP-Mailers wird nicht länger unterstützt. Bitte aktualisiere die E-Mail-Server-Einstellungen ↗.

Der „Referrer-Policy“ HTTP-Header ist nicht gesetzt auf „no-referrer“, „no-referrer-when-downgrade“, „strict-origin“ oder „strict-origin-when-cross-origin“. Dadurch können Verweis-Informationen preisgegeben werden. Siehe die W3C-Empfehlung.

Wie gesagt, nur zur Info, ist ja noch ne Beta :)

Gruß Hans

Antworten
1. Jan
  30. Juli 2018 um 17:31 Uhr
  
  Hi Hans,
  
  danke für die Hinweise. Ich denke, dass sich da aber bis zum Release von Nextcloud 14 noch einiges ändern wird.
  Ggf. passe ich den Artikel (also nicht diesen hier, sondern den neuen Artikel) dann an.
  
  Gruß,
  Jan
  
  Antworten
Markus
15. August 2018 um 13:09 Uhr

Hallo Jan,

dank Deiner Anleitung bin ich schon sehr weit gekommen, aber jetzt hänge ich bei der Installation von Nextcloud.
Mein Datenverzeichnis für Nextcloud liegt unter /media/mgeminn/myCloudDrive/nextclouddata. Bei der Installation erhalte ich die Fehlermeldung „Can’t create or write into the data directory /media/mgeminn/myCloudDrive/nextclouddata“.
Das Verzeichnis steht in den beiden open_basedir Anweisungen, chown www-data:www-data für das Verzeichnis ist ebenfalls durchgeführt. Was kann / muß ich tun um weiterzukommen?

Vielen Dank im Voraus für Deine Hilfe.
Markus

Antworten
1. Jan
  15. August 2018 um 13:14 Uhr
  
  Hi Markus,
  
  hier fehlt vermutlich noch der Eintrag im vHost für Nextcloud: fastcgi_param PHP_VALUE „open_basedir=…
  Hier müsstest du noch dein Datenverzeichnis mit aufnehmen.
  
  Gruß,
  Jan
  
  Antworten
  1. Markus
    15. August 2018 um 17:09 Uhr
    
    Hallo Jan,
    
    das steht da schon drin, habs mehrfach überprüft. Auch kein Tippfehler drin oder so.
    
    Gruss Markus
    
    Antworten
  2. Markus
    15. August 2018 um 17:48 Uhr
    
    Hallo Jan,
    
    ich hab grad gesehen: im vHost für Nextcloud unter fastcgi_param… ist open_basedir mit Gänsefüßchen eingeleitet, am Ende sind keine. Wenn ich diese einfüge, kommt die Meldung „192.168.2.xn--101request_uri-2qa hat die Verbindung abgelehnt“.
    
    Gruss Markus
    
    Antworten
    1. Jan
      16. August 2018 um 11:06 Uhr
      
      Hi Markus,
      
      das ist normal. Der komplette Block sieht so aus:
      fastcgi_param PHP_VALUE "open_basedir=/var/www:/tmp/:/var/nextcloud_data:/dev/urandom:/proc/meminfo upload_max_filesize = 10G post_max_size = 10G max_execution_time = 3600 output_buffering = off";
      
      Das ist quasi ein Befehl, der mit den letzten Gänsefüßchen endet. Direkt hinter open_basedir dürfen keine Gänsefüßchen stehen.
      
      Welches Dateisystem hat die Festplatte mit dem Datenverzeichnis? Mache Dateisysteme (z.B. NTFS) können mit den Linux-Dateiberechtigungen nicht umgehen, daher können hier gar keine Rechte für den User www-data gesetzt werden.
      Probier doch mal ein chown mit Verbose-Output: chown -R www-data:www-data /media/mgeminn/myCloudDrive/nextclouddata -v
      Die Recht kannst du dann mit folgendem BEfehl überprüfen: ls -l
      
      Gruß,
      Jan
      
      Antworten
      1. Markus
        16. August 2018 um 19:48 Uhr
        
        Hallo Jan,
        
        hab die Festplatte neu formatiert mit ext4, bei Rechtezuweisen mit -v kommt folgende Meldung: ownership of ‚/media/mgeminn/myCloudDrive/nextclouddata‘ retained as www-data:www-data.
        Trotzdem gibt es die gleiche Fehlermeldung
        
        Gurss Markus
      2. Jan
        18. August 2018 um 14:57 Uhr
        
        Hallo Markus,
        
        was liefert der Befehl „ls -l /media/mgeminn/myCloudDrive/“?
        Sieht so aus, als ob das alles korrekt konfiguriert wäre.
        
        Man könnte testhalber mal versuchen, ein anderes Datenverzeichnis anzugeben (z.B. /var/nextcloud_data_test) und open_basedir dementsprechend zu setzen. Wenn das dann mit dem Test-Datenverzeichnis funktioniert, dann wüssten wir schonmal, dass es irgendwie mit der (externen) Festplatte zu tun hat.
        
        Gruß,
        Jan
      3. Markus
        20. August 2018 um 10:26 Uhr
        
        Hallo Jan,
        
        wenn ich wie von Dir vorgeschlagen auf /var/nextcloud_data gehe läuft alles.
        
        Gruss Markus
      4. Jan
        20. August 2018 um 16:12 Uhr
        
        Hi Markus,
        
        dann vermute ich mal fast, dass bei dem anderen Pfad die Rechte irgendwie nicht korrekt gesetzt werden können.
        Was ergibt der Befehl „ls -l“ nachdem die Rechte mit chown gesetzt worden sind?
        
        Gruß,
        Jan
      5. Markus
        21. August 2018 um 8:28 Uhr
        
        Hallo Jan,
        
        angezeigt wird
        drwxr-xr-x 2 www-data www-data 4096 Aug 16 19:28 nextclouddata
        
        Gruss Markus
      6. Jan
        21. August 2018 um 12:28 Uhr
        
        Hi Markus,
        
        OK, die Verzeichnisrechte sind hier offensichtlich richtig gesetzt.
        Als nächstes würde ich prüfen, ob der User www-data wirklich Dateien schreiben kann. Dazu einfach in das entsprechende Verzeichnis wechseln und dann mit dem Webserver-User eine Datei anlegen:
        sudo -u www-data touch test.txt
        Kommt hier eine Fehlermeldung?
        Falls nicht, dann würde ich open_basedir mal komplett ausnehmen (also aus den beiden php.ini Dateien, als auch im vHost von Nextcloud). Danach Rechner nochmal komplett neu starten.
        
        Ich sehe gerade, dass dein Kommentar unter einem alten Tutorial gepostet wurde. Hier gibt es schon längst ein Nachfolge-Tutorial, bei dem viele Verbesserungen eingeflossen sind und bei dem aktuellere Programm-Versionen zum Einsatz kommen (siehe hier). Vielleicht kannst du ja mal deine Konfiguration mit dem neuen Tutorial gegenchecken, evtl. fällt hier noch etwas auf.
        
        Gruß,
        Jan
      7. Markus
        21. August 2018 um 21:51 Uhr
        
        Hallo Jan,
        
        ich hatte mir unbekannte Probleme mit der USB Festplatte. Installiere gerade neu, im Moment ( und die nächsten Tage) wird die Platte formatiert (9TB brauchen ihre Zeit!). Danach versuchen ich mal sie über fstab zu mounten statt über Gnome Oberfläche. Obs was hilft? Ich geb Dir Bescheid.
        
        Bis dahin vielen Dank für Deine Unterstützung
        Markus