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

Nextcloud Logo

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

Dieser Artikel beschreibt die Installation und Konfiguration von Nextcloud auf Ubuntu Server 18.04 LTS („Bionic Beaver“) mit nginx, MariaDB, PHP und Let’s Encrypt. Zur Verbesserung der Sicherheit und Performance wird ebenfalls die Einrichtung von Redis, Fail2ban und ufw behandelt.

Wer regelmäßig diesen Blog liest, wird der dies bestimmt bekannt vorkommen: Zu diesem Thema gab es bereits einige Artikel. Die letzte Anleitung (Nextcloud auf Ubuntu Server mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban) war sehr ähnlich aufgebaut, jedoch kam seinerzeit Ubuntu Server 16.04 LTS zum Einsatz. Nach nun gut zwei Jahren ist im April 2018 eine neue LTS-Version von Ubuntu erschienen. Da sich hier bei der Installation und Konfiguration einiges geändert hat, ist es an der Zeit, dem Thema der selbstgehosteten Nextcloud einen neuen Artikel zu gönnen.

Update-Historie (letztes Update: 03.02.2020)
  • 03.02.2020:
    • Cipher Suite DHE-RSA-AES256-GCM-SHA384 entfernt.
  • 25.10.2019:
    • Anpassungen einiger Anweisungen im virtuellen Host von Nextcloud bzgl. PHP (Auslöser: Sicherheitslücke nginx/php-fpm, siehe hier).
  • 03.10.2019:
    • Anpassungen für Nextcloud 17:
      • Header X-Frame-Options
      • Regulärer Ausdruck für Fail2ban angepasst
  • 17.08.2019:
    • acme.sh sollte nicht mit Root-Rechten ausgeführt werden, daher wird für die Ausführung von acme.sh ein spezieller User angelegt.
  • 24.07.2019:
    • Anpassungen für TLSv1.3 (ssl_ciphers und ssl_ecdh_curve).
  • 15.06.2019:
    • ECDHE-RSA-AES256-SHA384 aus den ssl_ciphers entfernt (wird beim Qualys SSL Labs Test als „weak“ eingestuft).
  • 24.05.2019:
    • Erklärung für die Anweisung „resolver“ im Gateway-Host hinzugefügt.
  • 18.05.2019:
    • Hinweis hinzugefügt, dass bei der Generierung der Zertifikate am besten Copy&Paste und „Suchen & Ersetzen“ genutzt wird.
  • 26.04.2019:
    • Artikel komplett für Nextcloud 16 überarbeitet.
    • Manuelles Hinzufügen von Ubuntu-Paketquellen entfernt, da diese bei 18.04.2 standardmäßig enthalten sind.
    • Modifizierung der Datenbank für big int Support entfernt, da dies automatisch im Rahmen des Nextcloud-Setups erfolgt.
    • Der Cronjob für Nextcloud wird nun alle 5 Minuten ausgeführt (siehe Nextcloud Admin-Manual).
    • Eingesetzte Programm-Versionen aktualisiert.
  • 14.04.2019:
    • [arch=amd64] beim den Paketquellen für nginx (/etc/apt/sources.list.d/nginx.list) hinzugefügt.
    • Die Versionsangaben (php7.2-fpm) beim Installieren von PHP entfernt.
  • 12.04.2019:
    • Für den Versand von E-Mails von Fail2ban kommt nun msmtp zum Einsatz.
  • 07.03.2019:
    • Beim Setzen der SSL-Header wird nun der Parameter always mit angegeben, damit der Header unabhängig vom Response-Code geliefert wird.
  • 02.03.2019:
    • Anweisungen für ocm-provider bzw. ocs-provider im Gateway-Host hinzugefügt, da es ansonsten unter Nextcloud 15.0.5 zu Warnungen im Admin-Bereich kommt.
    • vHost für Nextcloud überarbeitet.
  • 27.02.2019:
    • Beschreibung zur Generierung der TLS-Zertifikate komplett auf acme.sh umgestellt, Anleitung für Certbot entfernt.
  • 02.02.2019:
    • Hinweis für acme.sh zum Generieren der TLS-Zertifikate hinzugefügt.
  • 21.01.2019:
    • Setzen von max_input_time = 3600 als PHP-Value im virtuellen Host von Nextcloud.
  • 03.01.2019:
    • Schritte zur Konvertierung der Datenbanktabellen auf big int nach dem Setup hinzugefügt.
  • 24.12.2018:
    • Verbesserung beim Anlegen der Datenbank für Nextcloud: Der UTF-8 Multibyte-Support wird nun gleich beim Anlegen der Datenbank aktiviert, so dass die Datenbank nicht mehr nach dem Nextcloud-Setup modifiziert werden muss.
    • Update der eingesetzten Programm-Versionen.
  • 19.12.2018:
    • Überarbeitung der virtuellen Hosts (Gateway-Host und vHost für Nextcloud): Überflüssige Anweisungen entfernt (proxy_set_header Answeiungen und locations für Well-Known-URLs/acme-challenge im Nextcloud vHost) und Konfiguration auf Nextcloud 15 abgestimmt.
    • Bei bestehenden Installationen bitte nochmals den Gateway-Host und den vHost für Nextcloud mit den bestehenden virtuellen Hosts abgleichen!
  • 15.12.2018:
    • Installation PHP: php-imagick hinzugefügt.
  • 12.12.2018:
    • Anpassungen für Nextcloud 15: Well-Known-URLs und angepasste Links.
  • 11.11.2018:
    • Informationen zu den Default-Werten in der Datei jail.local hinzugefügt.
  • 13.10.2018:
    • „Well-Known-URLs“ für DAV im Gateway-Host hinzugefügt, da es ansonsten ab Nextcloud 14.0.2 zu einer Warnung im Admin-Bereich kommt.
  • 04.10.2018:
    • Konfiguration der Paketquellen unter Ubuntu Server 18.04.1: Vor der Installation der Programme werden die Ubuntu-Repositories Universe, Multiverse und Restricted hinzugefügt.
  • 19.09.2018:
    • Fehler bei „Trusted Domains“ in der config.php von Nextcloud.
  • 07.09.2018:
    • Ergänzungen für Nextcloud 14.
      • Hinweis für Meldung „Die Verwendung des eingebauten PHP-Mailers wird nicht länger unterstützt“ hinzugefügt.
      • Links zum Nextcloud Administration Manual aktualisiert.
    • Im Gateway-Host wird die Referrer-Policy nun auf „no-referrer“ gesetzt.
    • Update der verwendeten Programm-Versionen.
  • 31.05.2018:
    • SSL-Konfiguration im Gateway-Host geändert: unter ssl_trusted_certificate wird nun die Datei chain.pem angegeben.
  • 02.06.2018:
    • Anleitung zum Aktivieren von 4-Byte-Support der Nextcloud-Datenbank hinzugefügt.
  • 07.06.2018:
    • Anleitung für nginx 1.15 überarbeitet (Achtung: veränderte Verzeichnisstruktur).
  • 08.06.2018:
    • Gateway-Host: Anpassung von ssl_ciphers und ssl_ecdh_curve.
    • Der SSL-Test sollte nun A+ (100%) ergeben.
  • 10.06.2018:
    • Warnung für die Aktivierung vom 4-Byte-Support hinzugefügt, da dies auf manchen Systemen zu Problemen führen kann.
  • 13.06.2018:
    • Hinweis für Internet-Anschlüsse mittels DS-Lite hinzugefügt. Um die Schritte dieses Tutorials durchzuführen, wird ein „echter“ IPv4-Anschlus benötigt.
    • Hinweis auf Zertifikat-Erneuerung durch Certbot überarbeitet, da bei der Installation automatisch ein Cronjob eingerichtet wird.

Inhalt

Motivation, Voraussetzungen und Konzept des Artikels

Wer meine Artikel regelmäßig liest, wird sicher wissen, dass ich großen Wert darauf lege, Wissen zu vermitteln. Das ist zunächst auch das Ziel dieses Tutorials. Da die Schritte zur Installation der eigenen Cloud im Prinzip einfach von oben nach unten abgearbeitet werden könnten, würde hier auch eine einfache Liste mit Anweisungen/Kommandozeilen-Befehlen reichen. Dennoch ist es meiner Meinung nach wichtig zu wissen, was man hier tut, anstatt einfach nur ein paar Befehle auf der Kommandozeile zu kopieren – besonders bei einer eigenen Cloud, in der u.U. auch sensible Daten gespeichert werden. Daher möchte ich mit dem Artikel Hintergrundwissen vermitteln, so dass der Leser nach Durcharbeiten des Tutorials die Zusammenhänge und Hintergründe versteht und somit auch eigene Lösungen bei evtl. auftretenden Problemen erarbeiten kann.

Ziele

Neben der Wissensvermittlung werden mit dem Artikel folgende konkrete Ziele verfolgt:

  • Installation der eigenen Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB und PHP.
  • Erhöhte Sicherheit der Cloud (PHP-Konfiguration, SSL, Nextcloud-Konfiguration laut Nextcloud Administation Manual).
  • Verschlüsselte Verbindung zur eigenen Cloud mittels HTTPS. Dazu kommt ein Zertifikat von Let’s Encrypt zum Einsatz.
  • Nextcloud soll in einem Unterverzeichnis des Webservers laufen und über die URL https://meinedomain.de/nextcloud erreichbar sein. Dadurch wird es möglich, neben der Cloud auch weitere Webanwendungen auf dem gleichen Server zu betreiben, siehe Zweite Web-Anwendung neben ownCloud/Nextcloud einrichten (am Beispiel WordPress).
  • In der Admin-Oberfläche von Nextcloud sollen keine Warnungen angezeigt werden.
  • Das Datenverzeichnis von Nextcloud soll außerhalb des www-Verzeichnisses liegen.
  • Verbesserung der Performance durch Verwendung von Redis für das Transactional File Locking.
  • Absicherung gegen Brute-Force-Attacken mit Fail2ban.
  • Einrichtung der Firewall ufw.

Zeitaufwand und Programm-Versionen

Zeitaufwand: ca. 3 Stunden

Eingesetzte Programm-Versionen:

  • Ubuntu Server 18.04.2 LTS („Bionic Beaver“)
  • Nextcloud 17.0.0
  • nginx 1.17.2
  • MariaDB 10.3.11
  • PHP 7.2.17
  • Redis 4.0.9
  • Fail2ban 0.10.2
  • OpenSSL 1.1.1

Voraussetzungen

Betriebssystem und Hardware

Als Betriebssystem kommt Ubuntu 18.04 LTS („Bionic Beaver“) zum Einsatz. Eine LTS-Version (Long Term Support) bietet sich für ein eigenes Cloud-Projekt an, da durch den verlängerten Support-Zeitraum (in diesem Fall fünf Jahre – bis April 2023) ein solches System über eine lange Zeit betrieben werden kann, ohne dass ein Distributions-Update zwingend erforderlich ist.

Prinzipiell kann aber auch jede andere Linux-Distribution (z.B. Debian) eingesetzt werden, die Schritte sollten überall nahezu identisch sein.

Die Hardware ist auch nicht entscheidend, erforderlich ist hierbei nur ein PC, auf dem Linux läuft. So ist es auch denkbar, das Tutorial auf einem Kleinstrechner wie dem  Raspberry Pi (Affiliate-Link) umzusetzen, da dieser weder viel Strom noch Platz braucht. Wenn etwas mehr Leistung benötigt wird, dann bietet sich auch ein Intel NUC (Affiliate Link) an.

Besonders interessant finde ich den Einsatz einer virtuellen Maschine (VM) für das Hosten der eigenen Cloud. Der Vorteil ist hierbei, dass bei virtuellen Systemen Snapshots angelegt werden können, die den Zustand der VM zu einem gewissen Zeitpunkt speichern. Im Notfall kann man dann die komplette virtuelle Maschine auf einen bestimmten Snapshot zurücksetzen. Darüber hinaus können virtuelle Systeme auch leicht in ein bestehendes Backup-Konzept mit eingebunden werden. Wie Ubuntu Server 18.04 als virtuelle Maschine unter Hyper-V eingerichtet und konfiguriert werden kann, zeigt der Artikel Ubuntu Server 18.04 LTS als Hyper-V Gastsystem installieren und optimal einrichten.

Zugriff per SSH

Nach der Installation wird man einen Server normalerweise „headless“ laufen lassen, d.h. ohne angeschlossenen Monitor, Maus oder weitere Peripheriegeräte. Der Zugriff findet dann in der Regel über SSH statt (z.B. mit dem Programm PuTTY). Mehr Infos zum Zugriff mittels SSH sind ebenfalls im Artikel Ubuntu Server 18.04 LTS als Hyper-V Gastsystem installieren und optimal einrichten zu finden.

DynDNS

Wenn die eigene Cloud nach der Installation auch aus dem Internet erreichbar sein soll, dann ist die Verwendung eines DynDNS-Dienstes ebenfalls eine Voraussetzung. DynDNS sorgt dabei dafür, dass die (öffentliche) IP des Servers immer auf eine DynDNS-Domain gemappt wird. Dies hat zum einen den Vorteil, dass man sich die (öffentliche) IP des Servers (genauer gesagt: des Routers) nicht merken muss. Sinnvoll wäre dies sowieso nicht, da sich nach der bei den meisten Providern üblichen Zwangstrennung nach 24 Stunden die IP-Adresse meistens ändert.
Zum anderen wird eine Domain für die Erzeugung des SSL-Zertifikats benötigt, da Let’s Encrypt keine Zertifikate für IP-Adressen ausstellen kann.

Welcher DynDNS-Dienst zum Einsatz kommst, spielt eigentlich keine Rolle. Ein solcher Dienst ist oftmals bei einem Hosting-Paket eines Webhosters bereits enthalten, so z.B. bei All-Inkl.com (Affiliate Link) im Paket „Privat Plus“.
Als kostenlosen Dienst mit gutem Support kann ich GoIP empfehlen.

Im Rahmen des Artikels verwende ich beispielhaft die Domain meinedomain.de. Diese Domain muss dann natürlich bei euch entsprechend angepasst werden.

Internet-Anschluss

Eine weitere Voraussetzung liegt beim Internet-Anschluss. In der heutigen Zeit nutzen viele Internet-Provider durch die Knappheit von IPv4-Adressen einen Mechanismus, der  Dual-Stack Lite (DS-Lite) genannt wird. Ohne nun genau auf die technischen Details einzugehen, werden im Netzwerk des Benutzers/Kunden IPv4-Adressen verwendet, nach außen (also Richtung Internet) handelt es sich jedoch um einen IPv6-Anschluss.

DS-Lite führt beim Kunden meist zu Problemen, da für portbasierte Protokolle (TCP, UDP), auf die wir im Rahmen des Tutorials angewiesen sind, keine Portfreigaben mehr eingerichtet werden können, da die Pakete an die öffentliche IP-Adresse des Kunden bereits beim Provider ausgefiltert werden.

Daher wird zum Hosten einer eigenen Cloud zwingend ein „echter“ IPv4-Anschluss benötigt. Mit einem DS-Lite-Anschluss ist es nicht möglich, mit der hier gezeigten Vorgehensweise eine eigene Cloud aufzusetzen.

Wer einen DS-Lite-Anschluss hat, kann evtl. eine Zusatz-Option für einen echten IPv4-Anschluss beim Provider dazu buchen. Falls der Provider eine solche Option nicht direkt anbietet, kann es oftmals auch helfen, beim Provider anzurufen und nach einer solchen Option zu fragen, die dann evtl. manuell gebucht werden kann.

Root-Rechte auf dem Server

Für die Installation und oftmals auch die Konfiguration von Programmen sind unter Linux meistens Root-Rechte erforderlich. Damit nicht vor jeden Befehl ein sudo mit angeführt werden muss, ist es empfehlenswert, sich am Anfang der Installation/Konfiguration einmalig Root-Rechter mit dem Befehl sudo -s zu verschaffen. Für die Dauer der Anmeldung arbeitet man dann mit Admin-Rechten auf dem System. Man sollte sich am Ende der Arbeiten allerdings wieder mit dem Befehl exit abmelden – ein dauerhaftes Arbeiten mit Root-Rechten ist nicht empfohlen.

Konzept

Dieser Artikel unterscheidet sich von vielen anderen Tutorials zum Thema Nextcloud. Der folgende Abschnitt beschreibt daher, was die Eckpfeiler dieses Artikels sind und welches Konzept sich dahinter verbirgt.

LEMP-Stack statt LAMP-Stack

Wenn es um das Webhosting geht, dann habt ihr sicher schon einmal von einen LAMP-Stack gehört. Darunter versteht man ganz einfach nur bestimmte Programme, die häufig zum Hosting von Websites verwendet werden: Linux (Betriebssystem), Apache (Webserver), MySQL (Datenbank) und PHP (Skriptsprache). Setzt man die Anfangsbuchstaben dieser Programme zusammen, versteht man, warum diese Konstellation als LAMP-Stack bezeichnet wird.

Ein sog. LEMP-Stack ist nun einfach eine Variante dieses Software-Pakets: Als Grundlage kommt hier auch Linux als Betriebssystem zum Einsatz, allerdings wird nginx als Webserver verwendet. Im Rahmen dieses Artikels habe ich mich auch gegen MySQL und für MariaDB entschieden. PHP kommt aber auch hier zum Einsatz, allein aus dem Grund, dass Nextcloud eine PHP-Anwendung ist. Die Bezeichnung LEMP-Stack ergibt sich wieder aus dem Anfangsbuchstaben der Programme (das „E“ kommt von der Aussprache von nginx: „Engine-X“).

Warum nutze ich hier also „abweichend vom Standard“ eine andere Software-Konfiguration? nginx als Webserver und MariaDB als Datenbanksystem bieten hier einige Vorteile:

  • nginx arbeitet im Allgemeinen ressourcenschonende als Apache. Hintergrund ist die Art und Weise, wie hier Web-Requests abgearbeitet werden: Apache erstellt pro Verbindung mit einem Client neue Threads bzw. Prozesse. Die Erzeugung derselben ist allerdings teuer, da vergleichsweise viel Rechenleistung benötigt wird.
    nginx geht hier etwas anders vor: Der alternative Webserver arbeitet mit einem sog. Thread-Pool, d.h. hier werden bei Start des Programms verschiedene Threads „im Voraus“ erzeugt, die dann Requests der Clients abarbeiten. Wenn die Arbeit eines Threads beendet ist, kann dieser Thread für den nächsten Request wiederverwendet werden. Dies ist besonders auf leistungsschwacher Hardware (wie z.B. einem Raspberry Pi) von Vorteil, da nginx weniger speicherintensiv zu Werke geht.
  • MariaDB ging aus einem Fork von MySQL hervor und ist zu diesem binärkompatibel. Damit ist MariaDB ein sog. Drop-In-Replacement zu MySQL (quasi ein 1:1 Ersatz). Daher müssen bei den darauf aufbauenden Anwendungen keine Änderungen am Quellcode vorgenommen werden. Ebenfalls sind alle Tools und Programme, die für MySQL entwickelt wurde auch automatisch mit MariaDB kompatibel.
    Durch die Binärkompatibilität ergeben sich hier nicht wirklich große Unterschiede zu MySQL. Allerdings steht hinter MariaDB kein großes Unternehmen (wie Oracle bei MySQL), sondern es handelt sich dabei um „echte“ Open-Source-Software. So setzen mittlerweile viele Linux-Distributionen MariaDB als Standard-Datenbanksystem ein. Somit sieht es so aus, als ob MariaDB das zukunftssicherere System wäre, was nicht „unter der Fuchtel“ eines Großkonzerns steht. Aus diesem Grund habe ich im Rahmen des Artikels MariaDB als Datenbanksystem den Vorzug gegeben.

Virtuelle Hosts und Konfigurations-Dateien von nginx

Bevor es hier etwas konkreter wird, ist es sinnvoll, sich etwas mit den Konfigurationsdateien von nginx zu beschäftigen. Der Webserver verwendet – wie schon Apache – sog. virtuelle Hosts (vHosts). Ein virtueller Host ist dabei erst einmal eine reine Textdatei, die die Webserver-Konfiguration für genau eine Website beschreibt. Folgende Dateien/Verzeichnisse sind dabei wichtig:

  • /etc/nginx/nginx.conf: Das ist zunächst einmal die globale Konfiguration des Webservers. Hier werden alle globalen Einstellungen definiert, die für alle Websites gelten sollen.
  • /etc/nginx/conf.d: In diesem Verzeichnis sucht der nginx nach virtuellen Hosts. Ein solcher vHost muss in diesem Verzeichnis liegen und mit der Dateiendung *.conf gespeichert werden. Andere Dateien, die nicht mit .conf enden, werden beim Start des Webservers ignoriert.

Die Einstellungen werden dabei vererbt: Die globalen Einstellungen gelten dabei für alle vHosts, daher müssen diese nicht in jedem virtuellen Host neu definiert werden. Allerdings kann ein vHost auch jederzeit die globalen Einstellungen überschreiben. Diese gelten dann nur im Kontext dieses einzelnen virtuellen Hosts.

Hinweis bei abweichender Verzeichnisstruktur bei nginx

Je nach verwendeter nginx-Version (siehe weiter unten), kann es sein, dass die Verzeichnisstruktur etwas abweicht. Am besten überprüft man direkt nach der Installation, wo der default-vHost zu finden ist. Wenn dieser im oben genannten Verzeichnis gespeichert ist, dann können die Schritte des Tutorials einfach weiter befolgt werden.

Wenn der default-vHost allerdings nicht in /etc/nginx/conf.d zu finden ist, dann liegt dieser meist unter /etc/nginx/sites-enabled. In diesem Fall kommt eine alternative Verzeichnisstruktur bei nginx zum Einsatz. In diesem Fall läuft die Verwaltung der virtuellen Hosts etwas anders ab:

  • /etc/nginx/sites-available: In diesem Verzeichnis sind die virtuellen Hosts enthalten, die nginx beim Start nicht lädt. Wenn man einen neuen vHost anlegt, dann nutzt man meist normalerweise dieses Verzeichnis. Die Dateiendung ist dabei egal und man lässt diese für gewöhnlich weg.
  • /etc/nginx/sites-enabled: Hier sind die vHosts enthalten, die der Webserver beim Starten lädt.
  • Um einen virtuellen Host zu aktivieren, muss sich dieser also im Verzeichnis sites-enabled befinden. Um nun nicht mit zwei unterschiedliche Dateien unter sites-available und sites-enabled hantieren zu müssen, kann einfach eine symbolische Verknüpfung für einen vHost angelegt werden. Wenn beispielsweise ein (deaktivierter) vHost /etc/nginx/sitesavailable/meinedomain.de aktiviert werden soll, dann wird eine solche Verknüpung mit diesem Befehl angelegt:
    ln -s /etc/nginx/sites-available/meinedomain.de /etc/nginx/sites-enabled/

Wenn diese alternative Verzeichnisstruktur bei nginx zum Einsatz kommt, dann ist im weiteren Verlauf des Artikels darauf zu achten, die Dateien der virtuellen Hosts an der richtigen Stelle zu platzieren.

Die Aufteilung in mehrere virtuelle Hosts

Was macht diesen Artikel nun besonders? In den meisten Tutorials zum Thema Nextcloud wird eben nur die eigene Cloud auf dem Server gehostet und ist dann direkt über die Root-Domain (also z.B. https://meinedomain.de) erreichbar. Das ist zunächst einmal kein Problem, wenn ausschließlich Nextcloud auf dem System gehostet werden soll. Aber was, wenn man sich die Möglichkeit offenhalten will, weitere Websites oder Webanwendungen auf dem gleichen Server zu hosten?

Hier gibt es prinzipiell mehrere Möglichkeiten, allerdings sollte man sich im Vorfeld Gedanken machen, wie dies mit virtuellen Hosts umgesetzt werden kann.

  • Ein einzelner virtueller Host:
    Dies ist vermutlich die naheliegendste Lösung. Hierbei werden alle Webanwendungen (bzw. die entsprechenden Webserver-Konfigurationen) in einem einzelnen virtuellen Host definiert. Das macht die Sache allerdings auf fehleranfällig, da ein kleiner Fehler in diesem virtuellen Host den ganzen Webserver und damit auch alle Websites lahmlegen kann. Ebenfalls kann eine Webanwendung nicht „mal eben schnell“ deaktiviert werden, da dazu sämtliche Anweisungen im virtuellen Host gelöscht oder auskommentiert werden müssten.

    Schematische Darstellung: Einzelner vHost für mehrere Webanwendungen
    Schematische Darstellung: Einzelner vHost für mehrere Webanwendungen
  • Ein virtueller Host pro Webanwendung:
    Ein besserer Ansatz zur Trennung der einzelnen Websites ist die Verwendung eines vHosts pro Website. Durch die strikte Trennung ist diese Lösung deutlich flexibler und weniger fehleranfällig.
    Allerdings gibt es hier evtl. ein Problem: Ein virtueller Host wird durch den Server-Namen (die Domain) und einen Port definiert. Um einen Client-Request genau einer Website zuordnen zu können, muss sich daher die Kombination Domain/Port für jede Website unterscheiden. Dieses Ziel kann man zum einen durch den Einsatz unterschiedlicher (Sub-)Domains erreichen. Im Rahmen des Artikels soll eine DynDNS-Domain verwendet werden und hier liegt evtl. das Problem: Viele Router bieten nur die Möglichkeit, eine einzelne DynDNS-Domain zu konfigurieren. Hier könnte man sich beim Einsatz mehrerer Domains mit einem sog. CNAME Resource Record behelfen, bei dem eine (Sub-)Domain einfach auf eine andere Domain (die DynDNS-Domain) gemappt wird.
    Die zweite Möglichkeit, eine Eindeutigkeit von Domain/Port zu erreichen ist natürlich die Verwendung der gleichen (Sub-)Domain bei unterschiedlichen Ports. Allerdings führt dies meistens zu Einschränkungen in der Benutzung der Webanwendungen. Wenn nämlich vom Standard (HTTP: 80, HTTPS: 443) abweichende Ports verwendet werden, müssen diese zum einen in der Firewall (Router) geöffnet werden, was Angreifern eine größere Angriffsfläche bietet. Zum anderen muss dann bei sämtlichen Client-Anwendungen die URL des entsprechenden Dienstes immer mit dem Port angegeben werden. Hier hat man dann meist einen erhöhten Aufwand bei der Einrichtung der Client-Anwendungen. Das macht diese Lösung (zumindest bei der Verwendung unterschiedlicher Ports) etwas unflexibel.

    Schematische Darstellung: Ein vHost pro Webanwendung (Eindeutigkeit durch unterschiedliche Ports)
    Schematische Darstellung: Ein vHost pro Webanwendung (Eindeutigkeit durch unterschiedliche Ports)
  • Gateway-Host + einzelne virtuelle Host pro Webanwendung:
    Die dritte Möglichkeit ist eine Mischung aus den beiden anderen Vorgehensweisen. Hierzu kommt ein sog. Gateway-Host zum Einsatz, der erst einmal alle Client-Request auf den Standard-Ports (80/443) entgegennimmt. Die einzelnen Websites laufen dabei nicht im Web-Root, sondern in Unterverzeichnissen. Der Gateway-Host nutzt nun die Reverse-Proxy-Fähigkeiten von nginx, um die Anfragen auf Grund des Ziels (Verzeichnis) an einen anderen vHost weiter zu leiten. Dazu gibt es dann pro Webanwendung wieder einen virtuellen Host. Diese verwenden immer den gleichen Server-Namen (die lokale IP), aber unterschiedliche Ports. Da die vHosts „hinter“ dem Gateway-Host nur Server-intern arbeiten und nur der Gateway-Host die direkte Schnittstelle zum Internet/den Clients ist, ist die Auswahl der Ports hier nebensächlich. Dadurch müssen hier auch keine weiteren Ports in der Firewall geöffnet werden, da sämtliche Webanwendungen scheinbar die Standard-Ports 80 und 443 verwenden. Welche Webanwendung letzten Endes angesprochen werden soll, wird nur durch das Unterverzeichnis des Web-Roots (und nicht durch die Kombination Domain/Port) festgelegt.

    Schematische Darstellung: Gateway-Host und einzelne vHosts pro Webanwendung
    Schematische Darstellung: Gateway-Host und einzelne vHosts pro Webanwendung

Jede dieser drei Möglichkeiten hat dabei ihre Vor- und Nachteile. Die dritte Vorgehensweise bietet jedoch zum einen Flexibilität und ist technisch auch einfach umzusetzen. Daher ist nun das Ziel und die Besonderheit dieses Artikels, dass Nextcloud in einem Unterverzeichnis des Webservers laufen soll, später also über die URL https://meinedomain.de/nextcloud aufgerufen werden soll.

Weitere Webanwendungen können dann ohne großen Aufwand neben der eigenen Cloud auf dem gleichen Webserver betrieben werden. In einem weiterführenden Artikel habe ich bereits beschrieben, wie neben der Nextcloud auch WordPress auf dem gleichen Server installiert werden kann: Zweite Web-Anwendung neben ownCloud/Nextcloud einrichten (am Beispiel WordPress).

Installation und Konfiguration aller benötigten Programme

Nach diesem eher theoretischen Teil des Artikels soll es nun in die Praxis gehen.

Als Basis für dieses Tutorial dient der Artikel Ubuntu Server 18.04 LTS als Hyper-V Gastsystem installieren und optimal einrichten, Voraussetzung ist also ein fertig installierter Ubuntu Server 18.04 LTS.

Ebenfalls sollte bereits eine statische IP-Adresse für den Server konfiguriert worden sein (die Vorgehensweise dazu ist auch im o.g. Artikel beschrieben). Ich gehe im weiteren Verlauf des Tutorials von der statischen IP 192.168.178.60 für den Server aus.

Betriebssystem-Updates

Zunächst wird das Betriebssystem auf den aktuellen Stand gebracht:

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

Programm-Installation

Bevor Nextcloud selbst installiert werden kann, müssen zunächst einmal alle anderen Programme (Webserver, Datenbank und PHP) installiert werden.

Exkurs: Installation aus dem Ubuntu-Paketquellen vs. Installation aus den Hersteller-Paketquellen

Doch vorher noch kurz ein Hinweis zu den Installationen: Meistens sind die verwendeten Programme bereits in den offiziellen Ubuntu-Paketquellen enthalten. Daher spricht erst einmal nichts dagegen, die Programme auch aus diesen Paketquellen zu installieren. Jedoch handelt es sich meistens auf Grund der Stabilität um ältere Programmversionen, die ebenfalls keine größeren (Feature-)Updates mehr bekommen, sondern nur noch kleinere Updates für Fehlerbehebungen. Dadurch kommt ein System schnell mal „in die Jahre“ und man kann beispielsweise keine Funktionen nutzen, die erst in neueren Programmversionen geliefert werden.

Die Alternative dazu ist die Installation der entsprechenden Programme aus den (offiziellen) Repositories der jeweiligen Anbieter. Diese Programmversionen sind meist wesentlich aktueller und werden auch in regelmäßigen Abständen mit (Feature-)Updates versorgt. Meist unterscheiden die Hersteller dabei nochmals zwischen zwei (oder sogar mehr) Entwicklungs-Branches: Oftmals gibt es einen Stable-Branch, der möglichst stabil gehalten wird. Auch hier sind meist keine größeren Updates mehr zu erwarten und neue Features werden erst nach z.T. langer Zeit in diesen Branch mit aufgenommen. Daneben gibt es meist noch einen Mainline-Branch, der zwar auch stabil sein sollte, aber zeitnah mit Updates und neuen Features versorgt wird.

Die Entscheidung, welche Programm-Versionen bzw. Branches zum Einsatz kommen, liegt nun beim Anwender:

  • Wenn Stabilität die wichtigste Eigenschaft der Programme ist, dann sollten die offiziellen Ubuntu-Repositories verwendet werden.
  • Meistens möchte man ein System allerdings über einen längeren Zeitraum betreiben, z.B. bis zum Erscheinen einer neuen Ubuntu LTS-Version. Wenn man hier Wert auf Stabilität legt und trotzdem einigermaßen aktuelle Software einsetzen will, dann sollte man auf den Stable-Branch der Hersteller setzen.
  • Wer dagegen gern auf neue Features setzt und die Programme auf einem möglichst aktuellen Stand halten möchte, der sollte den Mainline-Brach der Software-Hersteller nutzen.

Meine Erfahrung hat gezeigt, dass die Mainline-Branches der Hersteller ausreichend stabil sind. Ebenfalls setze ich gern auf neue Features, die meistens Vorteile in Sachen Performance geben. Zu guter Letzt möchte ich verhindern, dass die Software mit der Zeit „herausaltert“. Daher nutze ich in diesem Tutorial meist die Mainline-Branches aus den offiziellen Paketquellen der Hersteller.

Wer sich hier für andere Programm-Versionen entscheidet, der muss dies beim Eirichten der entsprechenden Repositories im späteren Verlauf beachten und ggf. die Schritte geringfügig anpassen.

Hinweis für Raspberry Pi Benutzer: Oftmals verzichten die Software-Hersteller darauf, in ihren Paketquellen Programm-Versionen für die ARM-Architektur bereit zu stellen. In diesem Fall würde ein Hinzufügen der Hersteller-Repositories zu einem Fehler bei der Programm-Installation führen. In diesem Fall muss man auf die Paketquellen von Raspbian/Debian zurückgreifen und kann keine Hersteller-Repositories einbinden.

nginx

Das erste Programm, was installiert wird, ist der Webserver.

Paketquellen hinzufügen

Optional: Wer nicht die Paketquellen aus dem offiziellen Ubuntu-Repository nutzen möchte, muss zunächst die gewünschten Paketquellen zum System hinzufügen. Ich habe mich hier für die Mainline-Version von nginx entschieden, da diese noch mit (Feature-)Updates versorgt wird und trotzdem für meine Zwecke ausreichend stabil ist (siehe nginx Blogbeitrag). Für andere Ubuntu-Versionen oder gar andere Distributionen sind die Paketquellen ggf. anders anzugeben, siehe nginx: Linux packages.

Zunächst wird der Key der nginx-Repositories auf dem System bekannt gemacht. Dieser Schritt ist notwendig, damit es bei der späteren Installation zu keinen Warnungen kommt:

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

Anschließend werden die Paketquellen selbst hinzugefügt. Die originale Datei für die Paketquellen (/etc/apt/sources.list) wird dabei nicht modifiziert, sondern es wird eine eigene Datei für nginx angelegt:

nano /etc/apt/sources.list.d/nginx.list

Hier fügen wir folgenden Inhalt ein:

# Nginx (Mainline)
deb [arch=amd64] http://nginx.org/packages/mainline/ubuntu/ bionic nginx
deb-src [arch=amd64] http://nginx.org/packages/mainline/ubuntu/ bionic nginx
Installation nginx

Nach der Aktualisierung der Paketquellen kann der Webserver installiert werden:

apt-get update 
apt-get install nginx

Ob der Webserver korrekt läuft, kann man nach einem Neustart des Rechners durch den Aufruf der IP des Severs im Browser testen:

Der Webserver läuft
Der Webserver läuft

MariaDB

Also nächstes wird das Datenbank-System installiert.

Paketquellen hinzufügen

Bei MariaDB gibt es keine Unterscheidung zwischen Stable/Mainline, sondern nur Stable/Development. Allerdings gibt es mehrere Stable-Versionen, die parallel gepflegt werden. In den Ubuntu-Paketquellen ist ein „alter“ Stable-Release von MariaDB enthalten (10.1). Hier habe ich mich für den aktuellen Stable-Release (10.3) entschieden, da diese über einen längeren Zeitraum unterstützt wird (bis Mai 2023). Mehr Informationen zu den Releases von MariaDB gibt es in der MariaDB-Knowledgebase.

Zum einfachen Hinzufügen der MariaDB-Repositories gibt es ein praktisches MariaDB-Repository-Tool.

Wie schon bei nginx muss hier zunächst der Repository-Key bekannt gemacht werden, um später keine Warnungen zu erhalten:

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

Die Paketquellen werden wieder in eine eigene Datei hinzugefügt:

nano /etc/apt/sources.list.d/MariaDB.list
# MariaDB 10.3 repository list
# http://downloads.mariadb.org/mariadb/repositories/
deb [arch=amd64] http://ftp.hosteurope.de/mirror/mariadb.org/repo/10.3/ubuntu bionic main
deb-src http://ftp.hosteurope.de/mirror/mariadb.org/repo/10.3/ubuntu bionic main
Installation MariaDB

Nun kann das Datenbanksystem installiert werden:

apt-get update 
apt-get install mariadb-server

Im Rahmen der Installation wird gleich nach einem Root-Passwort für MariaDB gefragt. Hier sollte man gleich ein ausreichend starkes Passwort wählen.

MariaDB: Angabe des Root-Passworts während des Setups
MariaDB: Angabe des Root-Passworts während des Setups

Wenn keine Abfrage nach dem Root-Passwort erscheint (z.B., wenn man keine Paketquellen für MariaDB hinzugefügt hat und die Version aus den Ubuntu Paketquellen installiert), dann wird das Passwort einfach später bei der Einrichtung von MariaDB vergeben.

PHP

In den Paketquellen von Ubuntu ist PHP 7.2 bereits enthalten. Hier gehe ich eher konservativ an die Sache heran, da in der Vergangenheit öfters mal Breaking Changes in neueren PHP-Versionen enthalten waren. Daher nehme ich hier die Version aus den Ubuntu-Repositories:

apt-get update 
apt-get install php-fpm php-gd php-mysql php-curl php-xml php-zip php-intl php-mbstring php-bz2 php-json php-apcu php-imagick

Werden später weitere PHP-Pakete benötigt (z.B. zum Einbinden von SMB-Speicher unter Nextcloud), so können diese auch zu einem späteren Zeitpunkt installiert werden. Die hier aufgeführten Pakete sind quasi nur die „Minimal-Ausstattung“.

Let’s Encrypt/acme.sh

Zum Erzeugen des SSL-Zertifikats wird nun noch Let’s Encrypt benötigt. Hier gibt es mittlerweile einige Client-Implementierungen. Hier empfehle ich gerne acme.sh. Dies ist ein reines Bash-Skript, daher entfällt die Installation von Programmen aus dem Paketquellen. Hintergründe und Details sind im Artikel Let’s Encrypt Zertifikate mit acme.sh und nginx enthalten.

Hinweis: acme.sh sollte nicht mit Root-Rechten (also auch nicht mit sudo) ausgeführt werden. Daher legen wir dafür einen speziellen User an.

Dieser wird folgendermaßen angelegt und anschließend der Gruppe www-data hinzugefügt:

adduser letsencrypt 
usermod -a -G www-data letsencrypt

Der User braucht nun die Berechtigungen, um nginx später ohne Passwort neu laden zu können:

visudo

Am Ende wird folgende Zeile hinzugefügt:

letsencrypt ALL=NOPASSWD: /bin/systemctl reload nginx.service

Für die Installation von acme.sh wechseln wird nun den User:

su - letsencrypt

Anschließend kann acme.sh installiert werden:

curl https://get.acme.sh | sh

Am Ende wechseln wir wieder auf den normalen User:

exit

Konfiguration Programme/Server

Die soeben installierten Programme sollten für einen optionalen Betrieb von Nextcloud noch angepasst/optimiert werden.

Konfiguration nginx

Zunächst wird die globale Konfiguration von nginx angepasst:

nano /etc/nginx/nginx.conf

In den meisten Fällen ist hier die Standard-Konfiguration schon recht gut geeignet, dennoch sollten einige Punkte überprüft/angepasst werden:

  • user: Gibt den Benutzer an, unter dem der Webserver läuft. Dies sollte immer www-data sein.
  • worker_processes: Die Anzahl der Threads, die nginx dazu verwendet, Client-Requests abzuarbeiten. Mit der Angabe auto wird pro CPU-Kern ein Thread angelegt, was in den meisten Fällen bereits die optimale Einstellung darstellt.
  • server_tokens: Mit der Angabe off sorgt man dafür, dass nginx keine Versions-Informationen preisgibt (z.B. auf Fehlerseiten). Daher sollte diese Option aus Sicherheitsgründen ausgeschaltet werden. Wenn diese Variable nicht vorhanden ist, muss man diese im HTTP-Block der Datei einfügen: server_tokens off;

Default-Seite deaktivieren

Nun ist es auch an der Zeit, die Default-Seite von nginx zu deaktivieren, da diese nur zur Überprüfung gedacht ist, ob der Webserver ordentlich läuft.

Dazu wird der virtuelle Host („default“) einfach aus dem Verzeichnis /etc/nginx/conf.d umbenannt, so dass dieser nicht mehr geladen wird und der Webserver anschließend neu gestartet:

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

Konfiguration MariaDB

Die Datenbank muss nicht spezielle angepasst werden, jedoch ist diese nach der Installation noch nicht auf maximale Sicherheit getrimmt. Dies übernimmt folgender Befehl:

mysql_secure_installation

Wenn während der Installation ein Root-Passwort vergeben wurde, muss dies zunächst einmal eingegeben werden. Falls noch kein Root-Passwort festgelegt ist, sollte man spätestens an dieser Stelle unbedingt eines setzen.

Alle weiteren Fragen des Assistenten sollte man mit Ja (y) beantworten.

Konfiguration PHP

Bei PHP gibt es dann ein paar mehr Optionen die angepasst werden sollten.

In unserem Fall wird PHP über FPM (FastCGI Process Manager) betrieben. Dies ist eine performante Möglichkeit der Kommunikation zwischen PHP und dem Webserver. FPM definiert einen sog. Thread-Pool, der die Anfragen abarbeitet (ähnlich wie schon bei nginx). Die Konfiguration dazu ist in folgender Datei enthalten:

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

Folgende Anpassungen sollte man hier vornehmen:

  • user/group: Der Benutzer, unter dem PHP ausgeführt wird. Dies ist wieder unser Webserver-User, also
    user = www-data 
    group = www-data
  • listen: Die Kommunikation zwischen Webserver und PHP soll über einen Socket ablaufen. Dazu muss hier folgendes angegeben werden:
    listen = /run/php/php7.2-fpm.sock
  • Umgebungs-Variablen: Umgebungs-Variablen werden von PHP standardmäßig nicht veräußert, diese sind aber für den Betrieb von Nextcloud zwingend erforderlich. Dazu suchen wir 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). Alle Einträge, die hier mit env beginnen, sind hier auskommentiert. Durch das Entfernen der Semikola am Zeilenanfang werden die Kommentare entfernt und die Weitergabe der Umgebungs-Variablen aktiviert:
    env[HOSTNAME] = $HOSTNAME
    env[PATH] = /usr/local/bin:/usr/bin:/bin
    env[TMP] = /tmp
    env[TMPDIR] = /tmp
    env[TEMP] = /tmp

Neben der Pool-Konfiguration von PHP gibt es noch weitere Stellen, die angepasst werden sollten. Die in der Datei php.ini enthaltenen Anweisungen gelten dabei für alle PHP-Anwendungen. Die meisten Einstellungen können hier auf den Standard-Werten belassen werden. Anpassungen, die nur für eine Webanwendung speziell gelten sollen, werden nachher in den vHost-Dateien von nginx definiert.

Folgende Werte sollten in der php.ini angepasst werden:

nano /etc/php/7.2/fpm/php.ini
  • cgi.fix_pathinfo: Sorgt für eine sichere Interpretation von Pfadangaben:
    cgi.fix_pathinfo = 0
  • open_basedir: Schränkt den Zugriff von PHP auf das Webroot- und das temporäre Verzeichnis ein. Dadurch kann PHP aus Sicherheitsgründen auf sonst keine Dateien des Systems zugreifen oder diese verändern.
    open_basedir = /var/www/:/tmp/
  • memory_limit: Dieser Wert gibt an, wie viel Speicher ein PHP-Skript nutzen darf. Nextcloud benötigt später 512 MB als Memory Limit:
    memory_limit = 512M
  • opcache: 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. Folgende Werte sind hier anzugeben:
    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

Neben FPM wird PHP allerdings noch auf eine andere Art und Weise verwendet, nämlich direkt über die Kommandozeile (CLI – Command Line Interpreter/Interface). Diese Art des Zugriffs wird für Cronjobs benötigt, die im Rahmen von Nextcloud laufen (sollten). Die Einstellungen für PHP-CLI befinden sich in einer separaten php.ini:

nano /etc/php/7.2/cli/php.ini

Folgende Einstellungen sollten an dieser Stelle angepasst werden:

  • cgi.fix_pathinfo: Wie oben beschrieben:
    cgi.fix_pathinfo = 0
  • open_basedir: Hier muss die Liste der Verzeichnisse etwas erweitert werden, da diese Option beim CLI-Zugriff nicht über den Webserver laufen und daher auch nicht in den vHosts überschrieben werden kann. Somit muss das spätere Nextcloud-Datenverzeichnis in die Liste mit aufgenommen werden, da der Nextcloud-Cronjob hier Zugriff benötigt:
    open_basedir = /var/www/:/tmp/:/var/nextcloud_data

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

service php7.2-fpm restart

Verzeichnisstruktur vorbereiten

Als nächstes werden die für die folgenden Schritte benötigten Verzeichnisse 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 in einer Minimal-Ausführung hinzugefügt:

nano /etc/nginx/conf.d/meinedomain.de.conf

Hier reichen zunächst folgende Zeilen:

server {
	listen 80 default_server;
    listen [::]:80 default_server;
	server_name meinedomain.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 auch ein Ziel für die Weiterleitung vorhanden ist, wird nun der vHost für Let’s Encrypt angelegt:

nano /etc/nginx/conf.d/meinedomain.de_letsencrypt.conf

Auch dieser virtuelle 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;
	}
}

Dieser vHost lauscht auf 127.0.0.1:81. Der Port ist hier entscheidend, dieser muss mit der proxy_pass Direktive aus dem Gateway-Host übereinstimmen. Die Anweisungen listen und server_name sind auf die lokale Loopback-Adresse (127.0.0.1) festgelegt, so dass dieser vHost nur Server-intern (also nur lokal) aufgerufen werden kann. Der Zugriff „von außen“ erfolgt ausschließlich über den Gateway-Host.

Damit die virtuellen Hosts geladen werden, sollte der Webserver noch neu gestartet werden:

service nginx restart

SSL-Zertifikat mit Let’s Encrypt/acme.sh erzeugen

Der Webserver ist nun soweit vorbereitet, dass nun das SSL-Zertifikat generiert werden kann.

Port-Forwarding und DynDNS einrichten

Damit der Server nun auch aus dem Internet erreichbar ist, muss ein sog. Port-Forwarding im Router für die Ports 80 (HTTP) und 443 (HTTPS) für die IP des Servers (192.168.178.60) konfiguriert werden. Das Vorgehen unterscheidet sich dabei von Router zu Router, daher kann hier keine detaillierte Anleitung erfolgen. Hier sollte ein Blick in die Anleitung des Routers die gewünschten Informationen liefern. Oftmals beschreiben die Hersteller das genaue Vorgehen auch auf ihren Internet-Seiten. Beispielsweise findet man die Vorgehensweise für die Einrichtung von Port-Weiterleitungen für eine FritzBox auf den Hilfeseiten vom AVM.

Darüber hinaus muss der Router so konfiguriert werden, dass er sich korrekt an einem DynDNS-Dienst anmeldet, um so per DynDNS-Domain aus dem Internet erreichbar zu sein. Das Vorgehen hierzu hängt wieder vom verwendeten Router-Modell, aber auch vom DynDNS-Dienst ab. Wieder sind hier die Hersteller-Seiten des Routers (z.B. AVM), aber auch die Websites der jeweiligen DynDNS-Dienste (z.B. GoIP) die richtige Anlaufstelle, um diese Informationen zu ermitteln.

Generierung des SSL-Zertifikats

Hinweis: Wie bereits erwähnt, sollte acme.sh nicht mit Root-Rechten ausgeführt werden, daher müssen einige Vorbereitungen getroffen werden.

Zunächst legen wir die entsprechenden Verzeichnisse an und vergeben die erforderlichen Rechte:

mkdir -p /var/www/letsencrypt/.well-known/acme-challenge
chown -R www-data:www-data /var/www/letsencrypt
chmod -R 775 /var/www/letsencrypt
mkdir -p /etc/letsencrypt/meinedomain.de
chown -R www-data:www-data /etc/letsencrypt
chmod -R 775 /etc/letsencrypt

Anschliueßend wechseln wir auf den User, unter dem acme.sh ausgeführt werden soll:

su - letsencrypt

Das Zertifikat selbst wird nun mit einem Befehl generiert.

Tipp: Am besten übernimmt man den Befehl mittels Copy&Paste in einen beliebigen Text-Editor, mit dem man dann die Domain mit „Suchen und Ersetzen“ einfach durch die tatsächlich verwendete Domain einfügt. Auf diese Weise kann man Tippfehler vermeiden.

acme.sh --issue -d meinedomain.de --keylength 4096 -w /var/www/letsencrypt --key-file /etc/letsencrypt/meinedomain.de/key.pem --ca-file /etc/letsencrypt/meinedomain.de/ca.pem --cert-file /etc/letsencrypt/meinedomain.de/cert.pem --fullchain-file /etc/letsencrypt/meinedomain.de/fullchain.pem --reloadcmd "sudo /bin/systemctl reload nginx.service"

Nun sollte nach einigen Augenblicken das Zertifikat ohne Fehlermeldung erfolgreich generiert worden sein.

Die Zertifikat-Dateien findet man anschließend im Verzeichnis /etc/letsencrypt/meinedaomin.de:

  • cert.pem: Das öffentliche Zertifikat in Reinform
  • ca.pem: Öffentliches Zertifikat aus der sog. Keychain
  • fullchain.pem: Entspricht cert.pem + chain.pem
  • key.pem: Privates Zertifikat (diese Datei sollte man daher niemals weitergeben)

Im Anschluss wechseln wir wieder auf den normalen User:

exit

Diffie-Hellman-Parameter

Das soeben erzeugte SSL-Zertifikat ist der wichtigste Schritt, damit später sämtliche Verbindungen zur eigenen Cloud verschlüsselt ablaufen. Die Sicherheit dabei kann aber durch den Einsatz sog. Diffie-Hellman-Parameter weiter erhöht werden. Das Thema ist etwas komplexer, aber einfach ausgedrückt geht es hierbei um einen sicheren Schlüsselaustausch bei Verbindungsaufbau. Die Generierung der Parameter ist recht einfach.

Achtung: Auf schwächerer Hardware kann die Generierung hier einige Stunden dauern. Wer nicht so lange warten möchte, der kann auch einen Schlüssel mit „nur“ 2048 Bit errechnen lassen (die Zahl des zweiten Befehls gibt hierbei die Länge des Schlüssels in Bit an).

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

Erneuerung der Zertifikate

Zertifikate von Let’s Encrypt sind nur 90 Tage lang gültig und müssen spätestens nach dem Ablauf dieser Zeitspanne erneuert werden.

Beim hier gezeigten vorgehen über acme.sh wird auf dem System ein Cronjob eingerichtet, der die Erneuerung der Zertifikate automatisch vornimmt. Hier muss man sich dann nicht mehr selbst um die Erneuerung der Zertifikate kümmern.

Gateway-Host für Nextcloud/SSL vorbereiten

Da nun ein SSL-Zertifikat vorhanden ist und Nextcloud später einen eigenen virtuellen Host spendiert bekommt, muss der Gateway-Host nun für die Verwendung von SSL und Nextcloud vorbereitet werden.

nano /etc/nginx/conf.d/meinedomain.de.conf

Die hinzuzufügenden Abschnitte sind hier markiert:

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

server {
	listen 80 default_server;
	listen [::]:80 default_server;
	server_name meinedomain.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;
	listen [::]:443 ssl http2;
	server_name meinedomain.de 192.168.178.60;
  
	# Certificates used
	ssl_certificate /etc/letsencrypt/meinedomain.de/fullchain.pem;
	ssl_certificate_key /etc/letsencrypt/meinedomain.de/key.pem;
  
	# Not using TLSv1 will break:
	#	Android <= 4.4.40
	#	IE <= 10
	#	IE mobile <=10
	# Removing TLSv1.1 breaks nothing else!
	# TLSv1.3 is not supported by most clients, but it should be enabled.
	ssl_protocols TLSv1.2 TLSv1.3;
	
	# Cipher suite from https://cipherli.st/
	# Max. security, but lower compatibility 
	ssl_ciphers 'TLS-CHACHA20-POLY1305-SHA256:TLS-AES-256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384';

	# Cipher suite from https://wiki.mozilla.org/Security/Server_Side_TLS
	#ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';

	# (Modern) cipher suite from https://mozilla.github.io/server-side-tls/ssl-config-generator/
	#ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';

	# Diffie-Hellman parameter for DHE ciphersuites, recommended 4096 bits
	ssl_dhparam /etc/nginx/ssl/dhparams.pem;
  
	# Use multiple curves.
	ssl_ecdh_curve secp521r1:secp384r1;

	# Server should determine the ciphers, not the client
	ssl_prefer_server_ciphers on;
  
	# OCSP Stapling
	# fetch OCSP records from URL in ssl_certificate and cache them
	ssl_stapling on;
	ssl_stapling_verify on;
	
	# This should be ca.pem
	# See here: https://certbot.eff.org/docs/using.html
	ssl_trusted_certificate /etc/letsencrypt/meinedomain.de/ca.pem;
	
	# This is the local DNS server (e.g. the IP of the Router if it is used as DNS server in the local network)
	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; preload;" always;
	add_header X-Content-Type-Options "nosniff" always;
	add_header X-XSS-Protection "1; mode=block" always;
	add_header X-Robots-Tag none always;
	add_header X-Download-Options noopen always;
	add_header X-Permitted-Cross-Domain-Policies none always;
	add_header Referrer-Policy no-referrer always;
        add_header X-Frame-Options "SAMEORIGIN" always;

        # Remove X-Powered-By, which is an information leak
        fastcgi_hide_header X-Powered-By;	
	
	location = / {
        # Disable access to the web root, otherwise nginx will show the default site here.
		deny all;
        }	

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

	# These two location blocks are needed, otherwise you'll get warnings in the Nextcloud admin UI later on
	location = /.well-known/carddav {
		return 301 $scheme://$host/nextcloud/remote.php/dav;
	}

	location = /.well-known/caldav {
		return 301 $scheme://$host/nextcloud/remote.php/dav;
	}
	
	# Well-known URL for Webfinger
	# Regardless of this rule, you'll get a warning in the admin UI when the social app is not installed
	location = /.well-known/webfinger {
		return 301 $scheme://$host/nextcloud/public.php?service=webfinger;
	}

	location ~ /(ocm-provider|ocs-provider)/ {
		return 301 $scheme://$host/nextcloud/$1/;
	}
}

Folgende Änderungen wurden nun durchgeführt:

  • Ein Handler für PHP wurde hinzugefügt. Durch die Platzierung im Gateway-Host ist dieser Handler auch für alle anderen vHosts verfügbar (notwendig, falls mehrere PHP-Anwendungen gehostet werden sollen).
  • Die für Let’s Encrypt benötigten Anweisungen (HTTP) wurden nicht verändert.
  • Anweisungen für die Verwendung des SSL-Zertifikats und weitere Anweisungen bzgl. SSL wurden hinzugefügt. Hintergrund ist, dass nur der Gateway-Host das SSL-Handling übernehmen soll. Alle virtuellen Hosts, die „darunter“ liegen, sollten von der Verwendung von SSL nicht mitbekommen. Auf diese Weise sind alle SSL-Einstellungen an einer Stelle zu finden.
  • Am Ende der Datei wurde eine Weiterleitung an den Nextcloud-vHost angelegt. Wie schon beim vHost für Let’s Encrypt läuft die Kommunikation hier rein Server-intern ab (also über die IP 127.0.0.1). Zu beachten, ist hier die Änderung des Ports: Da der virtuelle Host für Let’s Encrypt bereits auf Port 81 lauscht, nutzen wir hier einen abweichenden Port (82). Dieser ist später für den Nextcloud-vHost wichtig.
  • Die Anweisungen für die sog. Well-known-URLs werden empfohlen, da es ansonsten später zu Warnungen im Admin-Bereich von Nextcloud kommen kann. Die ersten beiden sind dabei für CalDAV bzw. CardDAV zuständig. Die letzte Anweisung (webfinger) wird benötigt, wenn die später die Nextcloud App Social (Nextcloud-Integration mit Mastodon und weiteren Social Media Netzwerken) genutzt werden soll.
    Wichtig dabei ist, dass diese Well-Known-URLs über die Root-Domain (meinedomain.de) und nicht nur über das Unterverzeichnis (/nextcloud) erreichbar sind.
  • Die Anweisungen für ocm-provider bzw. ocs-provider sind ebenfalls an dieser Stelle für die Root-Domain aufzuführen, ansonsten würde es auch hier später zu Warungen im Admin-Bereich der Nextcloud geben.

Ich habe in der Datei auch Kommentare hinterlassen, die es ermöglichen sollten, den Gateway-Host an die eigenen Bedürfnisse anzupassen. Daher bitte auch die Kommentare in der Datei beachten.

Ebenfalls muss hier immer die angegebene Domain meinedomain.de an die tatsächlich verwendete Domain angepasst werden.

Virtuellen Host für Nextcloud anlegen

Die Weiterleitung im Gateway-Host ist bereits konfiguriert, nun fehlt noch der eigentliche virtuelle Host für Nextcloud:

nano /etc/nginx/conf.d/meinedomain.de_nextcloud.conf

Diese Datei ist mit folgendem Inhalt zu füllen:

server {
    listen 127.0.0.1:82;
    server_name 127.0.0.1;

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

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

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

        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\/.+|oc[ms]-provider\/.+)\.php(?:$|\/) {
            fastcgi_split_path_info ^(.+?\.php)(\/.*|)$;
            set $path_info $fastcgi_path_info;
            try_files $fastcgi_script_name =404;
			include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_param PATH_INFO $fastcgi_path_info;
			
			# Important: disable HTTPS, otherwise no log in will be possible!
            #fastcgi_param HTTPS on;

            fastcgi_param modHeadersAvailable true; #Avoid sending the security headers twice
            fastcgi_param front_controller_active true;
            fastcgi_pass php-handler;
            fastcgi_intercept_errors on;

            # Raise timeout values.
            # This is especially important when the 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
				max_input_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 ~ ^\/nextcloud\/(?:updater|ocs-provider|ocm-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 ~ ^\/nextcloud\/.+[^\/]\.(?:css|js|woff2?|svg|gif)$ {
			try_files $uri /nextcloud/index.php$request_uri;
			proxy_set_header Cache-Control "public, max-age=15778463";
			# 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=63072000; includeSubdomains; preload;";
			proxy_set_header X-Content-Type-Options nosniff;
			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;
			proxy_set_header Referrer-Policy no-referrer;
			
			# Optional: Don't log access to assets
			access_log off;
		}

		location ~ ^\/nextcloud\/.+[^\/]\.(?:png|html|ttf|ico|jpg|jpeg)$ {
			try_files $uri /nextcloud/index.php$request_uri;
			# Optional: Don't log access to other assets
			access_log off;
		}
    }
}

Die Konfiguration ist an die vorgeschlagene nginx-Konfiguration im Nextcloud Administation Manual angelehnt. Zu beachten ist hier folgendes:

  • Es wird nur ein server für HTTP (nicht HTTPS) definiert, da die HTTPS-Kommunikation nur vom Gateway-Host übernommen wird. Die Weiterleitung eines Requests an den Nextcloud-vHost findet nur Server-intern statt, daher reicht hier HTTP aus.
  • Gelauscht wird hier dazu auf der lokalen IP 127.0.0.1, daher ist es nicht möglich, eine Verbindung zum Nextcloud-vHost aufzubauen, ohne vorher den Gateway-Host passiert zu haben.
  • Der Port ist diesmal 82, da Port 81 bereits vom virtuellen Host für Let’s Encrypt belegt wird. Dieser Port muss mit dem Port der Weiterleitung (proxy_pass) für Nextcloud im Gateway-Host übereinstimmen.
  • Da die Header-Anweisungen bereits im Gateway-Host konfiguriert wurden, müssen diese nicht im vHost für Nextcloud angegeben werden.
  • Der vHost für Nextcloud soll mit ein paar speziellen Einstellungen für PHP arbeiten. Daher werden per fastcgi_param PHP_VALUE die Einstellungen aus der php.ini (FPM) überschrieben. 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.
  • Auch hier bitte wieder auf die Kommentare in der Datei achten. Hier sind auch wieder Hinweise zu finden, um den virtuellen Host an die eigenen Bedürfnisse anzupassen.

Nach dem Anlegen des vHosts muss der Webserver noch neu gestartet werden:

service nginx restart

Installation Nextcloud

Nun ist der Server soweit fertig eingerichtet, dass nun die Installation von Nextcloud angegangen werden kann.

Download

Einen Link zur aktuellsten Version von Nextcloud erhält man auf der Download-Seite von Nextcloud. Mit einem Klick auf Details and Download options bekommt man einen Link auf ein .tar.bz2 Archiv präsentiert. Dessen Link kopiert man sich am besten in die Zwischenablage.

Download-Link für die aktuellste Nextcloud-Version ermitteln
Download-Link für die aktuellste Nextcloud-Version ermitteln

Zurück auf der Linux Maschine kann die aktuellste Version der Cloud-Software nun heruntergeladen werden (hier mit Version 17.0.0):

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

Nach ein paar Sekunden sollte der Download abgeschlossen sein und Nextcloud kann nun in das entsprechende Verzeichnis entpackt werden, was zuvor schon vorbereitet wurde. Anschließend löschen wir das Archiv wieder, da dies nicht mehr benötigt wird:

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

Nun sollten nochmals die Dateiberechtigungen 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 nun das Setup von Nextcloud aufgerufen werden kann, ist es notwendig, dass eine Datenbank für die Cloud angelegt wurde. Dies geschieht am einfachsten mit der MySQL-Kommandozeile, die mit Root-Rechten aufgerufen wird:

mysql -u root -p

Nach der Eingabe des Root-Passworts wird nun zunächst die Datenbank selbst erstellt. Im Zuge dessen wird auch gleich ein spezieller Nutzer für Nextcloud eingerichtet, der die entsprechenden Zugriffsrechte auf diese eine Datenbank hat. Die Angabe localhost sorgt dafür, dass der Zugriff auf die Datenbank nur auf dem lokalen System erfolgen kann. Ein Remote-Zugriff über das Netzwerk (auf diese Datenbank) ist damit aus Sicherheitsgründen nicht möglich. Die Befehle auf der MySQL-Kommandozeile müssen mit einem Semikolon abgeschlossen werden:

CREATE USER nextcloud_db_user@localhost IDENTIFIED BY 'MeInPasSw0rT';
CREATE DATABASE nextcloud_db CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
GRANT ALL PRIVILEGES on nextcloud_db.* to nextcloud_db_user@localhost;
FLUSH privileges;
exit;

Nextcloud-Setup

Nun kann auch schon das Setup der Cloud-Software über die URL https://meinedomain.de/nextcloud aufgerufen werden.

Das Setup prüft daraufhin erst einmal, ob alle Voraussetzungen erfüllt sind, oder ob es noch Probleme gibt, wie z.B. fehlende Abhängigkeiten oder Schreibrechte in bestimmten Verzeichnissen. Falls Fehler gefunden werden sollten diese zunächst behoben werden, bevor das Setup nochmals aufgerufen werden kann.

Beim Setup der Cloud werden nun drei Dinge angegeben:

  • Benutzer/Passwort (Administrator): Im Rahmen des Setups wird nun ein erster Benutzer angelegt, der automatisch Admin-Rechte für die Cloud besitzt. Der Benutzername ist dabei frei wählbar, allerdings sollte man (wie eigentlich immer) auf ein starkes Passwort achten, da die Cloud ja nachher öffentlich aus dem Internet erreichbar sein wird.
  • Datenverzeichnis: Ebenso wird hier nun der Pfad des Datenverzeichnisses angegeben. Standardmäßig will das Setup diesen Datenpfad innerhalb des www-Verzeichnisses erstellen. Allerdings wird aus Gründen der Sicherheit empfohlen, dass das Datenverzeichnis außerhalb des Verzeichnisses /var/www liegen sollte (siehe Nextcloud Administration Manual). Daher sollte man hier genau darauf achten, dass hier das richtige Verzeichnis angegeben wird, welches wir vorher im Rahmen des Tutorials bereits erstellt hatten (/var/nextcloud_data).
  • Datenbank-Verbindung: Hier sind die Zugangsdaten für die soeben angelegte Datenbank zu hinterlegen.

Mit einem Klick auf Installation abschließen wird das Setup alle Einstellungen übernehmen.

Nextcloud-Setup
Nextcloud-Setup

Hinweis: Auf langsamen Rechner dauert das Setup evtl. etwas länger. Hier kann es dann vereinzelnd vorkommen, dass der Webserver irgendwann einen Timeout meldet (504 Gateway Timeout). Hier hat nginx dann die Verbindung zu Client (Browser) unterbrochen, noch bevor das Setup abgeschlossen werden konnte. In diesem Fall sollte man dem System ein paar Minuten geben und anschließend nochmals die Nextcloud-URL aufrufen. Wenn es zu keinen weiteren Problemen gekommen ist, sollte das Setup „im Hintergrund“ weitergelaufen und nach ein paar Minuten abgeschlossen worden sein. Hier wäre es dann auch eine Überlegung wert, in den virtuellen Hosts (Gateway-Host und Nextcloud-vHost) die Timeout-Werte etwas zu erhöhen.

Warnungen im Admin-Bereich

Nach erfolgreicher Installation sollte man gleich einen Blick in den Admin-Bereich der Cloud werden (oben rechts auf das Symbol für den Benutzer Klicken und dann Einstellungen wählen). Weil der erste angelegte Benutzer Admin-Rechte hat, findet man nun auf der linken Seite unter Übersicht eine Zusammenfassung über die Cloud.

Hier sollte direkt nach der Installation der Cloud nur eine Warnung angezeigt werden: Diese bezieht sich darauf, dass kein PHP-Memory-Cache konfiguriert ist.

Nextcloud: Warnung im Admin-Bereich
Nextcloud: Warnung im Admin-Bereich

Diese spezielle Warnung ist hierbei nicht als Fehler zu verstehen, sondern lediglich als Hinweis, dass die Performance der Cloud durch den Einsatz eines PHP-Memorycaches optimiert werden könnte. Dies führen wir im nächsten Abschnitt durch: Anpassen der Nextcloud-Konfiguration.

Wenn mehr Warnungen im Admin-Bereich angezeigt werden: An dieser Stelle sollte wirklich nur diese eine Warnung zu sehen sein. Wenn hier noch mehr Warnungen zu sehen sein sollten, dann bitte nochmals alle Schritte dieses Tutorials überprüfen, ob nicht ein kleines Detail ausgelassen wurde (besonders die PHP-Konfiguration).
Im Nextcloud Administration Manual findet man auch eine Übersicht über die Warnungen, die hier im Admin-Bereich angezeigt werden könnten und entsprechende Lösungsansätze.

Anpassen der Nextcloud-Konfiguration

Nextcloud speichert seine Konfiguration in der Datei /var/www/nextcloud/config/config.php. Genau hier sollten wir wegen des PHP-Memorycaches und auch wegen ein paar weiteren Einstellungen ansetzen:

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

Folgende Änderung werden hier durchgeführt:

  • PHP-Memorycache: Um die Warnung im Admin-Bereich zu entfernen und gleichzeitig die Performance der Cloud zu erhöhen, wird der Memory-Cache hinzugefügt (am Ende der Datei, aber vor der letzten geschweiften Klammer):
    'memcache.local' => '\OC\Memcache\APCu',
  • HTTPS als Standard definierten: Da Nextcloud hinter durch einen (HTTPS-)Proxy läuft (der Gateway-Host), kann es bei der automatischen Ermittlung von URLs zu Fehlern kommen, da hin und wieder ein http:// vorangestellt wird. Um strikt die Verbindung nur über https:// zu forcieren, sollte hier folgende Variable gesetzt werden:
    'overwriteprotocol' => 'https',
  •  Trusted Domains: Wenn man später auch über die lokale (LAN-)IP auf Nextcloud zugreifen möchte, dann kann man hier auch gleich die lokale IP als sog. Trusted Domain hinzufügen:
    'trusted_domains' => array ( 0 => 'meinedomain.de', 1 => '192.168.178.60', ),
  •  Timezone für Log-Einträge: Die richtige Zeitzone (z.B. für die Timestamps der Log-Einträge) wird durch diese Variable konfiguriert:
    'logtimezone' => 'Europe/Berlin',

Nach dem Speichern der config.php und erneutem Aufruf der Cloud sollten nun die Warnungen in der Admin-Oberfläche verschwunden sein („Alle Prüfungen bestanden“).

Eine Übersicht über alle Parameter der config.php von Nextcloud findet man im Nextcloud Administration Manual.

Cronjob für Nextcloud einrichten

Nextcloud ist darauf angewiesen, dass regelmäßig bestimmte Hintergrund-Aufgaben (z.B. Aufräumen der Datenbank) ausgeführt werden. Nach der Installation wird dies per AJAX realisiert: Immer wenn  ein User angemeldet ist und im Browser die Cloud nutzt, wird beim Laden einer Seite geprüft, ob Hintergrund-Aufgaben anstehen und werden ggf. ausgeführt. Diese Methode hat jedoch zwei Nachteile: Es wird zunächst immer ein angemeldeter Benutzer benötigt, denn nur durch diesen werden die Hintergrund-Aufgaben angestoßen (beim Laden einer Seite). Wenn die Cloud nun lange ohne Benutzeranmeldung läuft, dann werden u.U. auch lange keine Hintergrund-Jobs erledigt. Zum anderen ist die Lösung über AJAX weniger performant.

Es wird daher empfohlen, die Hintergrund-Aufgaben per Cron ausführen zu lassen. Hier prüft ein Hintergrund-Dienst in regelmäßigen Abständen, ob Hintergrund-Jobs fällig sind. Besonders auf schwächerer Hardware ist diese Methode deutlich effizienter.

Um Cron zur Erledigung der Hintergrund-Aufgaben nutzen zu können, muss zunächst ein neuer Cronjob für den Webserver-Benutzer angelegt werden:

crontab -u www-data -e

Das System fragt nun nach, mit welchem Editor die Datei bearbeitet werden soll. Hier wählt man einfachheitshalber am besten nano (1). Danach wird der Datei am Ende folgender Inhalt hinzugefügt:

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

Dies sorgt nun dafür, dass dieser Cronjob alle 5 Minuten automatisch ausgeführt wird. Theoretisch könnte hier auch eine andere Zeitspanne genutzt werden, allerdings ist die allgemeine Empfehlung 5 Minuten (siehe Nextcloud Admin-Manual).

In der Admin-Oberfläche muss nun nur noch eingestellt werden, dass zukünftig Cron zur Erledigung von Hintergrund-Jobs verwendet werden soll. Die Einstellung dazu findet man wieder in der Admin-Überfläche unter Grundeinstellungen.

Da hier auch gleich angegeben wird, wann das letzte Mal Hintergrund-Aufgaben ausgeführt wurde, kann man auf diese Weise auch erkennen, ob der Cronjob wie erwartet läuft: Immer nach 15 Minuten sollte bei Letzte Aufgabe ausgeführt folgendes stehen: Gerade eben.

Nextcloud: Ausführung von Hintergrund-Aufgaben per Cron
Nextcloud: Ausführung von Hintergrund-Aufgaben per Cron

4-Byte-Support aktivieren

Wichtig: Die folgenden Schritte sind nicht notwendig, wenn die Datenbank bereits mit UTF-8-Support angelegt wurde. Wenn ihr die Datenbank also bereits mit folgendem Befehl erzeugt habt, dann kann dieser Absatz übersprungen werden:

CREATE DATABASE IF NOT EXISTS nextcloud_db CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

Falls die Datenbank ohne UTF-8-Support angelegt wurde, dann sollten die Schritte in diesem Abschnitt befolgt werden. Der Befehl zum Anlegen der Datenbank ohne UTF-8-Support sah dann so aus:

CREATE DATABASE IF NOT EXISTS nextcloud_db;

Achtung: Die folgenden Schritte stellen mehr oder weniger eine Operation am offenen Herzen der Datenbank dar. Daher sollten diese Anweisungen nur dann ausgeführt werden, wenn

  • MariaDB in einer Version >= 10.3 installiert ist.
  • Der 4-Byte-Support wirklich benötigt wird.

Bei einer MariaDB-Version 10.1 oder 10.2 kann der 4-Byte-Support ebenfalls aktiviert werden, allerdings sind hier zusätzliche Schritte erfolderlich. In diesem Fall bitte nach dieser Anleitung vorgehen. Diese Anleitung ist dabei eher als experimentell anzusehen, daher sollte man hier genau wissen, was man hier tut. In jedem Fall sollte vorher ein Backup (zumindest von der Datenbank) angefertigt werden, falls im weiteren Verlauf etwas schief gehen sollte.

Nach der Installation von Nextcloud unterstützen die angelegten Tabellen noch keinen UTF8-Zeichensatz. Dadurch ergeben sich ein paar Einschränkungen: Beispielsweise können bei den Datei- und Ordnernamen keine Emojis angegeben werden (wer es denn braucht…). Versucht doch einfach mal einen Ordner mit dem Dateinamen „Test😋“ anzulegen. Hier wird eine Fehlermeldung erscheinen, dass der Ordner nicht angelegt werden kann.

Den 4-Byte-Support kann man jedoich einfach nachrüsten. Im Nextcloud Administration Manual gibt es eine Anleitung dazu, die jedoch mit MariaDB 10.3 nicht mehr funktioniert. Dies liegt darin begründet, dass die entsprechenden Variablen nicht mehr gesetzt werden können, da diese veraltet sind und bei MariaDB 10.3 entfernt wurden.

Wenn bei euch keine Dateien mit Emojis angelegt werden können, dann kann der 4-Byte-Support allerdings leicht nachgerüstet wreden: Dazu geht man einfach über die MySQL-Kommandozeile:

mysql -u root -p

Nach der Eingabe des Root-Passworts wählt man die korrekte Datenbank aus:

use nextcloud_db;

Hier wird zunächst einmal der verwendete Zeichensatz kontrolliert:

show variables like "character_set_database";

Hier sollte nach einer frischen Nextcloud-Installation latin1 ausgegeben werden.

Folgender Befehl sorgt dafür, dass der Zeichensatz geändert wird:

ALTER DATABASE nextcloud_db CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

Danach sollte nach nochmaliger Eingabe von

show variables like "character_set_database";

utf8mb4 ausgegeben werden. Mit exit; kann man die MySQL-Kommandozeile wieder verlassen.

Zum Schluss muss die Veränderung in den Nextcloud-Tabellen übernommen werden:

cd /var/www/nextcloud

Folgender Befehl setzt die entsprechende Variable in der Config-Datei:

sudo -u www-data php occ config:system:set mysql.utf8mb4 --type boolean --value="true"

Der letzte Befehl fürht ein Update auf die entsprechenden Tabellen durch:

sudo -u www-data php occ maintenance:repair

Anschließend kann man in Nextcloud auch Dateien mit erweiterten Zeichen (Emojis, etc.) anlegen.

Weitere Konfiguration Nextcloud

Die grundsätzliche Konfiguration von Nextcloud ist damit abgeschlossen. Am besten geht man nun noch durch sämtliche Einstellungen im Admin-Bereich der Cloud und passt die Optionen den eigenen Wünschen entsprechend an.

Es gibt nun viele Möglichkeiten, die eigene Cloud um Funktionen zu erweitern. Folgende Punkte sind auf jeden Fall einen Blick wert:

Generell ist bei der erweiterten Konfiguration von Nextcloud ein Blick ins Nextcloud Administration Manual empfehlenswert.

Optimierungen der Server-Umgebung für Nextcloud

Auch wenn die eigene Cloud nun direkt genutzt werden könnte, gibt es ein paar Möglichkeiten zur Optimierung von Nextcloud bzw. der verwendeten Server-Umgebung.

Die Umsetzung dieser Maßnahmen ist optional und hängt vom späteren Einsatzzweck der Cloud und den eigenen Bedürfnissen ab.

Fail2ban

Ab Version 11 ist bei Nextcloud ein Brute-Force-Schutz enthalten. Dieser sorgt dafür, dass nach einer bestimmten Anzahl an erfolglosen Login-Versuchen alle weiteren Logins aus dem betroffenen Subnetz gedrosselt werden. Dies führt bei Brute-Force-Attacken zu verzögerten Login-Versuchen (max. 30 Sekunden). Auch wenn dies den „Bad Guys“ das Leben etwas schwerer macht, wird dabei keine IP gebannt, so dass eine Brute-Force-Attacke lediglich verzögert wird. Daher ist hier alternativ oder zusätzlich der Einsatz von Fail2ban sinnvoll. Dieses Programm bietet im Vergleich zum eingebauten Brute-Force-Schutz folgende Vorteile:

  • Mittels Fail2ban können IPs automatisch gebannt werden. Nach einem solchen Ban kann die betroffene IP nicht mehr auf die Nextcloud-Instanz zugreifen, es wird lediglich eine Fehlermeldung des Browsers angezeigt.
  • Fail2ban arbeitet IP-basiert: Es wird nur die entsprechende IP blockiert, von der aus zu viele fehlgeschlagene Login-Versuche unternommen wurden. Andere Nutzer als dem gleichen Netzwerk (Subnet) werden dabei nicht gebannt.
  • Mit Fail2ban kann nicht nur die Nextcloud-Installation, sondern auch weitere Anwendungen auf dem Server abgesichert werden (z.B. Webserver und SSH).

Konfigurations-Dateien von Fail2ban

Bevor es um die Einrichtung von Fail2ban geht, ein Hinweis zu den Konfigurations-Dateien dieses Programms: Hier gibt es zwei Arten von Konfigurations-Dateien: *.conf und *.local. Die conf-Dateien kommen bei der Installation von Fail2ban mit. 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. Dafür kann man hier eine Datei mit dem gleichen Namen, aber mit der Dateiendung .local anlegen. 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 ist es nicht möglich, dass durch ein Update von Fail2ban unbeabsichtigt die Konfiguration geändert wird.

Konfiguration/Deaktivieren Nextcloud Brute-Force-Schutz

Wenn Fail2ban zum Einsatz kommt, ist der Brute-Force-Schutz von Nextcloud nicht mehr so wichtig. Dieser kann daher komplett deaktiviert werden.Dies wird wieder in der Konfigurations-Datei von Nextcloud vorgenommen:

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

Deaktiviert wird die Funktion durch das Hinzufügen folgender Zeile:

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

An dieser Stelle sollte auf jeden Fall noch einmal überprüft werden, ob für das Logging in Nextcloud die richtige Zeitzone angegeben wurde, da dies später für die Funktion von Fail2ban wichtig ist:

'logtimezone' => 'Europe/Berlin',

Optional: Wenn man den integrierten Brute-Force-Schutz in Nextcloud nicht komplett deaktivieren möchte, kann auch die App Brute-force settings aus dem Nextcloud App-Store installieren (oben auf den Benutzernamen und dann auf Apps klicken – die gesuchte App befindet sich in der Kategorie Sicherheit). Mit Hilfe dieser App kann man in den Admin-Einstellungen unter Sicherheit das eigene lokale Netzwerk in eine Whitelist mit aufnehmen. In unserem Beispiel wäre dies das Netzwerk 192.168.178.0/24. Für alle anderen Netzwerke (und v.a. auch Internet-IPs) würde der Brute-Force-Schutz dann noch greifen.

Whitelisting des LANs mittels der App "Brute-force settings"
Whitelisting des LANs mittels der App „Brute-force settings“

Einrichtung Fail2ban

Anschließend kann Fail2ban installiert werden:

apt-get update 
apt-get install fail2ban

Nun wird ein spezieller Filter für Nextcloud angelegt (Dateiendung beachten, s.o.):

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

Diese Datei wird mit folgendem Inhalt gefüllt. Dieser reguläre Ausdruck beschreibt die Logeinträge, nach den Fail2ban später in der Nextcloud-Logdatei sucht, um fehlgeschlagene Login-Versuche zu erkennen:

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

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

nano /etc/fail2ban/jail.local

Der Inhalt der Datei:

[DEFAULT]
maxretry=3
bantime=1800

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

[nginx-http-auth]
enabled = true

Der Teil unter [DEFAULT] gilt dabei für alle Regel-Sets (Jails). Hier werden die Standard-Einstellungen für Bans hinterlegt:

  • maxretry: Anzahl der Fehlversuche, bevor Fail2ban eine IP sperrt.
  • bantime: Zeitraum in Sekunden, für den eine IP gesperrt werden soll. Wird hier ein negativer Wert angegeben (-1), handelt es sich um eine permanente Sperre. Ansonsten wird eine IP nach dem Ablauf dieser Zeitspanne wieder automatisch entsperrt.

Unter [nextcloud] wird dann neues Jail für Nextcloud angelegt. Folgende Einstellungen werden hier angegeben und gelten nur für Nextcloud:

  • enabled: Aktivierung dieser Regel. Falls das Jail später (temporär) deaktiviert werden soll, kann dies einfach durch diese Option erfolgen.
  • port: Möglicher Port, hier nur 80 (HTTP) und 443 (HTTPS).
  • protocol: Das verwendete Protokoll.
  • filter: Name des Filters aus gleichnamiger Datei unter /etc/fail2ban/filter.d. Den Filter für Nextcloud haben wir ja bereits vorher angelegt.
  • logpath: Log-Datei, die Fail2ban für dieses Jail beobachten soll. Auf diese Datei wird der oben definierte Filter angewendet.
  • Hier könnten auch noch Werte für maxretry und bantime hinterlegt werden, die dann sie Standard-Werte überschreiben und nur für das Nextcloud-Jail gelten.

Die Anweisung unter [nginx-http-auth] aktiviert daneben noch die Überwachung der Logs des Webservers. Dieses Jail ist bereits in den Standard-Jails (/etc/fail2ban/jail.conf) definiert und wird an dieser Stelle lediglich scharf geschaltet. Dies sorgt für eine Überwachung bei anderen Webanwendungen, bei den eine HTTP-Basic-Authentifizierung zum Einsatz kommt. Die Ban-Optionen (maxretry und bantime) werden hier nicht angegeben, daher gelten die Standard-Werte, die in der Sektion [DEFAULT] angegeben wurden.

Nach einem Neustart von Fail2ban ist das Programm einsatzbereit

service fail2ban restar

E-Mail-Versand durch Fail2ban

Das Programm arbeitet nun zunächst im Hintergrund: Wird eine IP gebannt, bekommt der Administrator davon nur etwas mit, wenn er den Status von Fail2ban überprüft (dazu später mehr) oder einen Blick in die Logs wirft.

Sinnvoll ist daher eine Konfiguration, bei der Fail2ban automatisch eine E-Mail an den Admin sendet, wenn eine IP gebannt wurde. Das geht allerdings nicht out-of-the-box, das Linux-System muss zunächst auf den Versand von Mails vorbereitet werden. msmtp ist dabei die einfachste Möglichkeit, um unter Linux einfach und schnell E-Mails versenden zu können. Die Installation und Einrichtung des Programms wurde bereits im Artikel Linux: Einfach E-Mails senden mit msmtp ausführlich erklärt.

Wenn msmtp erfolgreich konfiguriert wurde, funktioniert das Senden von E-Mails über Fail2ban erstaunlich einfach, da der Mail-Versand bereits vom Programm vorgesehen ist. Dazu reicht eine kleine Anpassung an der Datei /etc/fail2ban/jail.local. Am Anfang der Datei (in der Default-Sektion) werden einfach noch folgende Zeilen hinzugefügt (hier markiert):

[DEFAULT]
maxretry=3
bantime=1800

# 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 ist die Adresse, von der die E-Mail gesendet werden soll (Absender).
  • Wichtig ist insbesondere die Zeile action = %(action_mwl)s: Hierdurch werden E-Mails standardmäßig versendet.

Nun bekommt man bei allen Aktionen, die Fail2ban vornimmt, automatisch eine E-Mail geschickt. Unschön dabei: 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“. Eigentlich interessiert uns hier ja nur, wenn Fail2ban tatsächlich eine IP gebannt hat. Damit nur noch bei diesem Ereignis eine E-Mail zu erhalten, müssen noch ein paar Anpassungen vorgenommen werden. 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

Die o.g. Dateien werde dazu einfach 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 =

Dazu am besten eine entsprechende Datei anlegen (mail-buffered.local) und diese dann einfach kopieren:

cp /etc/fail2ban/action.d/mail-buffered.local /etc/fail2ban/action.d/mail.local
cp /etc/fail2ban/action.d/mail-buffered.local /etc/fail2ban/action.d/mail-whois-lines.local
cp /etc/fail2ban/action.d/mail-buffered.local /etc/fail2ban/action.d/mail-whois.local
cp /etc/fail2ban/action.d/mail-buffered.local /etc/fail2ban/action.d/sendmail-buffered.local
cp /etc/fail2ban/action.d/mail-buffered.local /etc/fail2ban/action.d/sendmail-common.local

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

Fail2ban Status und Sperren entfernen (Test der Funktionalität)

Nun kann es ja mal vorkommen, dass man sich mittels Fail2ban aus der eigenen Cloud aussperrt, weil man z.B. das Passwort zu oft falsch eingegeben hat. Dies ist zugleich ein guter Test, ob das System auch wie erwartet funktioniert. Daher gebt doch einfach drei Mal ein falsches Passwort in eurer Nextcloud-Anmeldung an. Bei der vierten Anmeldung seht ihr nun Fail2ban in Aktion: Die Website kann gar nicht mehr geladen werden (Timeout) und ihr solltet eine E-Mail erhalten haben, wenn ihr den Mail-Versand konfiguriert habt.

Um nun zu kontrollieren, welche IPs aktuell für Nextcloud gebannt sind, reicht folgender Befehl:

fail2ban-client status nextcloud

Hier sollte nun eure IP zu finden sein, mit der soeben erfolglose Anmeldeversuch unternommen wurde.

Mit diesem Befehl wird diese IP wieder entsperrt:

fail2ban-client set nextcloud unbanip 48.128.36.83

Anschließend kann man wieder wie gewohnt auf Nextcloud zugreifen.

Redis

Nextcloud nutzt das sog. Transactional File Locking, um Sperren bei parallelem Zugriff auf Dateien zu realisieren. Einfach gesagt werden Dateien „gelockt“, wenn diese gerade in Verwendung sind. Dadurch kann es zu keinen Datenverlusten kommen, wenn eine Datei z.B. durch zwei Benutzer zeitgleich geöffnet bzw. gespeichert wird.

In der Standard-Konfiguration nutzt Nextcloud für das Verwalten der Sperren die Datenbank. Hier gibt es jedoch mit Redis eine In-Memory-Datenbank, die für genau solche Aufgaben optimiert ist und daher in bestimmten Szenarien eine verbesserte Performance erzielen kann.

Auch wenn hier Optimierungs-Potential besteht, wird Redis nur in großen Cloud-Instanzen eine spürbare Verbesserung der Performance bringen. Bei kleinen Nextcloud-Installationen mit 3-5 Nutzern wird man hier kaum einen Effekt bemerken können.

Installation und Konfiguration Redis

Redis kann mit folgenden Befehlen installiert werden. Das PHP-Paket wird zusätzlich benötigt, um per PHP Zugriff auf Redis zu erhalten:

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

Nach der Installation wird die In-Memory-Datenbank noch konfiguriert:

nano /etc/redis/redis.conf

Wie schon bei PHP ist es bei Redis empfehlenswert, die Kommunikation über einen Socket laufen zu lassen. Dazu sind folgende Einstellungen vorzunehmen. Die Einstellungen sind etwas in der Datei verteilt und z. T. nur auskommentiert. Am besten einfach in der Datei suchen (STRG+W) und die Einstellungen anpassen.

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

Hiermit werden folgende Optionen gesetzt:

  • port: Redis „lauscht“ standardmäßig auf dem Port 6379. Da wir allerdings einen Socket zur Kommunikation bevorzugen, soll Redis auf gar keinem Port lauschen.
  • unixsocket: Hiermit wird der eigentliche Socket definiert.
  • unixsocketperm: Berechtigungen für diesen Socket.

Als nächstes muss nun der Webserver-User in die Gruppe der Redis-Benutzer aufgenommen werden, damit dieser Redis auch nutzen kann:

usermod -a -G redis www-data

Am Ende wird Redis neu gestartet, damit die Änderungen angewendet werden:

service redis-server restart

Aktivierung von Redis in Nextcloud

Damit Nextcloud nun auch die In-Memory-Datenbank nutzt, muss dieses noch in der Konfigurations-Datei eingestellt werden:

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

Folgende Zeilen werden hier eingefügt:

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

Anschließend nutzt Nextcloud Redis für das Transactional File Locking.

ufw

ufw (uncomplicated firewall) ist eine Software-Firewall, die auf einer Ubuntu-Installation standardmäßig bereits vorinstalliert ist. Normalerweise übernimmt der Router die Aufgaben einer Firewall, daher ist die Einrichtung von ufw optional. In bestimmten Szenarien kann hiermit jedoch die Sicherheit noch etwas erhöht werden.

Falls ufw noch nicht installiert sein sollte, kann man dies mit folgenden Befehlen erledigen:

apt-get update 
apt-get install ufw

Die Firewall wird nun so eingerichtet, dass sämtlicher eingehender Traffic blockiert wird, jedoch mit zwei Ausnahmen:

  • SSH (Port 22): Hier soll der Zugriff nur aus dem Heimnetzwerk erlaubt sein.
  • HTTP/HTTPS (Ports 80/443): Da der Zugriff aus dem Web erforderlich ist, muss hier auch eine Ausnahme hinzugefügt werden.

Mit folgenden Befehlen werden diese Regeln umgesetzt:

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

Der Status der Firewall kann jederzeit mit folgendem Kommando überprüft werden:

ufw status

Hinweis: Wenn auf dem Server weitere Anwendungen installiert werden, nutzen diese u.U. andere Ports, die mit dieser Konfiguration natürlich nicht erreichbar sind. Oftmals liegt es dann eben an dieser Firewall, wenn scheinbar alles korrekt eingerichtet und konfiguriert wurde, die Anwendung aber nicht richtig laufen will. In diesem Fall sollten die Firewall-Regeln entsprechend erweitert oder die Firewall temporär deaktiviert werden (ufw disable).

Überprüfung der Sicherheit

Die Sicherheit der eigenen Cloud war ja von Anfang an ein wichtiges Ziel dieses Artikels. Nach der Einrichtung von Nextcloud gibt es einige Tools, mit Hilfe derer geprüft werden kann, ob dieses Ziel auch erreicht wurde.

Qualys SSL Labs

Der erste Check gilt zunächst einmal der HTTPS-Verschlüsselung. Hier spielt das verwendete Let’s Encrypt Zertifikat, als auch die SSL-Einstellungen des Webservers eine wichtige Rolle.

Für diesen Test eignet sich der SSL Server Test von Qualys SSL Labs. Wenn alles richtig konfiguriert wurde, sollte man hier die beste Bewertung (A+) erzielen können. Wenn die SSL-Konfiguration des Gateway-Hosts wie oben beschrieben übernommen wurde, sollte man in jeder einzelnen Kategorie 100% angezeigt bekommen.

Ergebnis des SSL-Test
Ergebnis des SSL-Test

Falls hier eine niedrigere Bewertung angezeigt werden sollte, liegt dies vermutlich an der SSL-Konfiguration des Webservers. In diesem Fall sollten im Gateway-Host nochmals alle Einstellungen kontrolliert werden.

Nextcloud Security Scan

Ein weiterer Test ist der Nextcloud Security Scan. Dieses Tool prüft die öffentlich verfügbaren Informationen der Cloud und kann eventuelle Schwachstellen aufzeigen. Mit der hier gezeigten Konfiguration sollte ein A-Rating angezeigt werden.

Nextcloud Security Scan
Nextcloud Security Scan

Hier wird lediglich kein A+ Rating erzielt, da unter Hardenings der Eintrag __Host-Prefix bemängelt wird. Dies liegt darin begründet, dass Nextcloud über ein Unterverzeichnis aufgerufen wird und nicht im Root-Verzeichnis der Domain läuft (siehe GitHub-Issue). Dieser Punkt stellt aber kein Sicherheits-Risiko dar und kann daher ignoriert werden.

Troubleshooting

Manchmal kann es passieren, dass die Nextcloud-Installation nicht auf Anhieb erfolgreich verläuft. Daher an dieser Stelle noch ein paar Tipps für die Fehlersuche:

  • Alle Schritte korrekt ausgeführt?
    Die Installation einer eigenen Cloud ist alles andere als trivial und erfordert ziemlich viele Schritte. Die Praxis zeigt, dass man hin und wieder einen Schritt einfach übersieht. In diesem Fall kann die kleinste Abweichung dazu führen, dass „das große Ganze“ nicht mehr funktioniert. Als erster Schritt der Fehlersuche sollten daher noch einmal alle Punkte einzeln überprüft werden.
  • Log-Dateien kontrollieren
    Oftmals hilft auch ein Blick in die entsprechenden Log-Dateien:

    • nginx (/var/log/nginx/error.log): Hier findet man alle Warnungen und Fehler, die der Webserver aufgezeichnet hat. Dies ist die erste Anlaufstelle, wenn Nextcloud gar nicht aufgerufen werden kann bzw. Links nicht richtig funktionieren.
    • Nextcloud (/var/nextcloud_data/nextcloud.log): Hier sind Fehler/Warnungen von Nextcloud selbst enthalten. Die gleichen Einträge findet man in der Admin-Oberfläche der Cloud. Hier lohnt ein Blick, wenn Nextcloud prinzipiell erreichbar ist (der Webserver also vermutlich korrekt eingerichtet wurde), es aber bei der Benutzung von Nextcloud zu Problemen kommt.
  • Developer-Console im Browser
    Gerade wenn Links nicht korrekt funktionieren und man überprüfen möchte, ob beispielsweise eine Weiterleitung ins Leere führt, dann kann die Developer-Console im Browser (meist zu öffnen mit F12) wertvolle Hinweise liefern, da hier aufgezeigt wird, was auf Grund von Client-Request passiert. Die Bedienung der Console läuft in jedem Browser etwas anders ab, daher hilft ein Blick in die entsprechende Dokumentation:

Falls ihr also Probleme bei der Einrichtung von Nextcloud haben solltet, bitte erst einmal diese Punkte überprüfen. Oftmals findet man dann relativ schnell die Ursache der Probleme. Wenn alles nicht hilft, dann könnt ihr hier natürlich einen Kommentar hinterlassen, vielleicht kann euch hier schnell weitergeholfen werden.

Falls sich bestimmte Probleme häufen sollte, werde ich den Artikel ggf. anpassen und/oder erweitern.

Nextcloud: Ein sicherer Ort für all deine Daten

Dieser Slogan von Nextcloud fasst es relativ gut zusammen: Die Einrichtung der eigenen Cloud ist sicherlich etwas aufwändig und erfordert mehr Kenntnisse, als die Benutzung irgendeiner Cloud eines bestimmten Anbieters. Aber wenn die eigene Nextcloud erst einmal läuft, dann ist man Herr über seine eigenen Daten und ist nicht mehr von Anbietern wie Google, Microsoft oder Apple anhängig.

Man sollte sich nun aber auch im Klaren darüber sein, dass man nun auch für die eigenen Daten verantwortlich ist. Die eigene Cloud erfordert einen gewissen administrativen Aufwand, beispielsweise muss man selbst dafür sorgen, dass das Betriebssystem, die installierten Programme und v.a. Nextcloud auf einem aktuellen Stand gehalten werden. Der Aufwand sollte sich hier allerdings in Grenzen halten.

Ich hoffe, dass dieser Artikel hilfreich war und ich einigen unter euch etwas Zeit (und Nerven) bei der Einrichtung der eigenen Cloud ersparen konnte. Für konstruktive Kritik und Verbesserungsvorschläge bin ich immer offen, daher hinterlasst mir doch gern einen Kommentar.

In diesem Sinne: Viel Spaß mit eurer eigenen Nextcloud!

Weiterführende Artikel

Links

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

  1. Hallo Jan, erstmal vielen Dank für das Tutorial, habe damit schon diverse Male diverse Raspis erfolgreich bearbeitet!
    Leider hatte ich neulich durch einen kaputten USB-Stick (auf dem die Root-Partition lag) ein kleines Problem. Mittlerweile habe ich NC20 auf einem Pi 3b+ neu aufgesetzt, aber meine Datensicherungen (nach Deinen Skripten) von früher sind von Version 16. Ich schätze, das kann ich daher nicht einfach zurückspielen. Also wollte ich auf meinem alten Pi b+ NC 16 installieren, die Backups importieren und dann Kontakte und Kalender (darum geht es im Wesentlichen) als vcf/ics exportieren und in 20 wieder einbinden.
    Problem: Wenn ich „meinedomain/nextcloud“ eingebe, kann Firefox keine Verbindung aufbauen. nginx startet ohne Fehlermeldung. Ich habe keine Ahnung, wie ich herausfinden kann, wo das Problem liegt. Dyndns (über Fritzbox) eher nicht, denn mit der (internen) IP geht es auch nicht, und NC20 auf dem anderen Pi läuft Die Server-Anfrage scheint nicht bei der NC-Instanz zu landen, aber warum? Würde mich sehr über Hinweise freuen und sorry, dass ich damit nerve. Ergoogle mir sonst nächtelang die Lösungen für sowas, aber hier weiß ich echt nicht weiter!
    Viele Grüße
    Johannes

    1. Hi Johannes,

      hier gilt es erst einmal heraus zu finden, ob der Request wirklich auf der entsprechenden Maschine ankommt oder nicht. Also erst einmal in der Developer-Console des Browsers (F12) den Request nachverfolgen, oft kommen hier schon interessante Hinweise. Anschließend in den Logs von nginx nach diesen Zugriffen suchen (in der error.log und der access.log). Wenn es bis hierhin keine Fehler gegeben hat, dann einen Blick ins Nextcloud-Log werfen.
      So würde ich nun erst einmal vorgehen.

      Gruß,
      Jan

      1. Danke für die Antwort! Firefox meckert schon mal nicht, die Konsole bleibt einfach blank. error.log und access.log zeigen keine Einträge von heute, nachdem ich versucht habe, zuzugreifen. Und das NC-Log gibt es noch nicht, weil ja die Ersteinrichtung gar nicht funktioniert. Höchst merkwürdig! Ich habe eben testweise die 3 conf-Dateien aus dem sites-enabled-Ordner entfernt und die default.conf hineingepackt – dann komme ich immerhin mit der internen IP zur nginx-Meldung. Der läuft also.

        1. Hi,

          also wenn im access.log kein Eintrag zu finden ist, dann bedeutet dies, dass du gar nicht auf deinem Server „rauskommst“. In diesem Fall würde ich mal „vor“ dem Server suchen: Router und (DynDNS-)Domain.
          Was passiert, wenn du versuchst, auf die NC mit der lokalen IP zuzugreifen?

          Gruß,
          Jan

          1. So, also wenn ich mit der lokalen IP zugreifen möchte, dann rödelt Firefox zuerst und zeigt dann in der Adresszeile am Ende doch wieder die Dyndns-Adresse. Laut Fritzbox läuft der DynDns-Dienst ohne Probleme (und es funktioniert ja auch alles, wenn ich den anderen Raspi einstecke). Im Router sind die Portfreigaben entsprechend konfiguriert, sonst käme ja wahrscheinlich auch direkt eine Fehlermeldung. In der meinedomain.conf habe ich jetzt mal nur die lokale IP als Server eingetragen, ändert sich nichts. Und in der access.log findet sich nun ein einziger Eintrag (wobei ich nicht genau sagen kann, ob das die Reaktion auf IP oder Domain-Versuch ist):
            „IP meines Rechners — [Zugriffszeit] „GET / HTTP/1.1“ 301 178 „-“ „Mein Browser“
            Hilft das irgendwie? Kann das mit der TLS-Version zusammenhängen? Das ist das Einzige, was ich geändert habe, v1.3 auskommentiert, weil es da eine Fehlermeldung gab.
            Gruß
            Johannes

          2. Hi Johannes,

            bei der Eingabe der lokalen IP darf nichts „rödeln“. Wenn du auf dem Server einen default-vHost oder einen vHost hast, der auf die lokale IP reagiert, dann muss hier sofort eine Warnung im Browser bzgl. des Zertifikats kommen. Er sollte hier nicht auf die DynDNS-Adresse umspringen.
            Es müsste also erst einmal geklärt werden, wo der Redirect von lokaler IP auf die DynDNS-Domain herkommt. An dieser Stelle vermute ich mal den Fehler. Wird hier echt nichts in der Developer Console des Browsers angezeigt?

            Gruß,
            Jan

  2. Moin Jan,
    ich habe ein Lösung gefunden, die ich noch nicht verstanden habe und von der ich nicht weiß, ob sie überhaupt eine ist. Ich habe Ubuntu und Windows im Dualboot und hatte heute abend ausnahmsweise mal Windows an. Habe spaßeshalber meine Dyndns Domain angegebn und eine nginx-Meldung bekommen. Dann also nextcloud aufgerufen und das hat geklappt! Verstehe ich überhaupt nicht. Dann hat es mit dem Router wohl eher doch nix zu tun?!Spannend wird dann die Frage, ob ich nach der Einrichtung von nextcloud dann mit Ubuntu zugreifen kann. Ich werde berichten, bzw. fällt Dir vielleicht etwas ein, was das erklären könnte?
    Gruß, Johannes

    1. Hi Johannes,

      eine Erklärung habe ich dafür nicht. Wenn an Ubuntu nichts „verpfuscht“ ist (z.B. manuelle Einträge in der /etc/hosts), dann sollte dies eigentlich analog zu Windows funktionieren.
      Was passiert, wenn du die URL über Mobilfunk (also außerhalb deines Netzwerks) aufrufst?

      Gruß,
      Jan

  3. Hallo Jan, ich hatte gestern wohl doch nicht mit der Dyndns-Adresse, sondern mit der lokalen IP gearbeitet. Daraufhin habe ich es mit der öffentlichen IP mit dem Handy über Mobilfunk nochmal von außen versucht, was auch nicht funktioniert hat. Also habe ich dann doch noch mal in die Fritzbox geguckt, und dort sah ich, dass die Portfreigaben für 80 und 443 von der Box auf 60632 o.ä. umgebogen wurden. Nicht verwunderlich, dass es dann von außen nicht geklappt hat. Dennoch merkwürdig, dass Mozilla die interne IP in Ubuntu in die externe Domain übersetzt und in Windows nicht. Aber wenn es jetzt offensichltich erreichbar ist (zumindest mit dem Handy), dann klappt es hoffentlich auch in Ubuntu. Im Moment habe ich nur noch die Fehlermeldung: Zugriff über eine nicht vertrauenswürdige Domain – auf dem Handy und dem Windows-PC. Darum kümmer ich mich morgen mal, das kann ich mir wahrscheinlich ergoogeln, jetzt bin ich zu müde!
    Viele Grüße
    Johannes

    1. Hi Johannes,

      schau dazu mal in die config.php von Nextcloud. Hier ist ein Array „trusted_domains“ definiert. Hier musst du deine DynDNS-Adresse hinzufügen. Ebenso sollten dann Werte, die vermutlich auf die interne IP verweisen (z.B. „overwrite.cli.url“, „overweritehost“, etc.), auf die echte Domain verweisen.

      Gruß,
      Jan

      1. Hallo Jan,
        das habe ich mittlerweile hinbekommen, lief dann auch unter Ubuntu. Lustigerweise kam ich dann aber dann nicht mehr per SSH auf den Raspi. In Windows geht hingegen beides. Scheint tatsächlich ein Ubuntu-Problem zu sein. Ist aber aktuell ein sekundäres Problem. Denn NC ist ja nun erstmal erreichbar. WAR erreichbar, denn dann wollte ich das Backup zurückspielen. Was dann passierte, schreibe ich Dir dort in dem Forum :-(
        Gruß,
        Johannes

  4. Hallo Jan.

    Vielen Dank für das sehr gute Tutorial!!!
    Ich habe es auf einer Test-VM erfolgreich zum laufen gebracht. Besonders gut finde ich die Absicherung der Webseite.

    Neben Nextcloud möchte ich noch zusätzlich Kopano installieren und betreiben. Alles hat soweit auch recht gut funktioniert. Jetzt hänge ich seit einigen Tagen aber an dem Problem, daß ich keinen Zugriff auf „Webapp“ habe (https://meineseite.de/webapp), da ich vermutlich etwas an der Pfadberechtigung „open_basedir“ falsch gemacht habe. Kommentiere ich in der /etc/php/7.2/fpm/php.ini den Eintrag „open_basedir = /var/www/:/tmp/“ aus (ebenso wie aus meiner webapp.conf), funktioniert es einwandfrei.
    Nehme ich den Eintrag wieder rein und versuche, eine Änderung von open_basedir in der webapp.conf durchzuführen, dann kommt im Logging folgende Meldungen:

    2020/11/08 14:55:42 [error] 4187#4187: *6 FastCGI sent in stderr: „Passing INI directive through FastCGI: unable to set ‚register_globals‘
    Passing INI directive through FastCGI: unable to set ‚magic_quotes_gpc‘
    Passing INI directive through FastCGI: unable to set ‚magic_quotes_runtime‘
    PHP message: PHP Warning: file_exists(): open_basedir restriction in effect. File(/usr/share/kopano-webapp/config.php) is not within the allowed path(s): (/var/www:/tmp/:/usr/share/kopano-webapp/) in /usr/share/kopano-webapp/server/includes/bootstrap.php on line 22“ while reading response header from upstream, client: 127.0.0.1, server: 127.0.0.1, request: „GET /webapp/ HTTP/1.1“, upstream: „fastcgi://unix:/run/php/php7.2-fpm.sock:“, host: „meineseite.de“

    Meine aktuelle /etc/nginx/conf.d/webapp.conf sieht so aus:
    server {
    listen 127.0.0.1:83;
    server_name 127.0.0.1;

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

    location = /robots.txt {
    allow all;
    log_not_found off;
    access_log off;
    }
    charset utf-8;
    server_tokens off;

    add_header X-Frame-Options SAMEORIGIN;
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection „1; mode=block“;

    location /webapp {
    alias /var/www/kopano-webapp/;
    index index.php;
    }

    location ~ /webapp/presence/ {
    rewrite ^/webapp/presence(/.*)$ $1 break;
    proxy_pass http://localhost:1234;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection „upgrade“;
    proxy_http_version 1.1;
    }

    location ~* ^/webapp/(.+\.php)$ {
    alias /var/www/kopano-webapp/;

    # deny access to .htaccess files
    location ~ /\.ht {
    deny all;
    }

    fastcgi_param PHP_VALUE “
    open_basedir=/var/www:/tmp/:/var/www/kopano-webapp
    register_globals=off
    magic_quotes_gpc=off
    magic_quotes_runtime=off
    post_max_size=31M
    upload_max_filesize=30M
    max_execution_time=3660
    „;

    include fastcgi_params;
    fastcgi_index index.php;
    #fastcgi_param HTTPS on;
    fastcgi_param SCRIPT_FILENAME $document_root$1;
    fastcgi_pass php-handler;
    access_log /var/log/nginx/kopano-webapp-access.log;
    error_log /var/log/nginx/kopano-webapp-error.log;

    # CSS and Javascript
    location ~* \.(?:css|js)$ {
    expires 1y;
    access_log off;
    add_header Cache-Control „public“;
    }

    # All (static) resources set to 2 months expiration time.
    location ~* \.(?:jpg|gif|png)$ {
    expires 2M;
    access_log off;
    add_header Cache-Control „public“;
    }

    # enable gzip compression
    gzip on;
    gzip_min_length 1100;
    gzip_buffers 4 32k;
    gzip_types text/plain application/x-javascript text/xml text/css application/json;
    gzip_vary on;
    }
    }

    map $http_upgrade $connection_upgrade {
    default upgrade;
    “ close;
    }

    Was habe ich falsch gemacht?

    Nochmals vielen Dank für das wirklich tolle Tutorial!

    Gruß
    Helmut

    1. Hi Helmut,

      in den Logs sagt er ja schon, dass „/usr/share/kopano-webapp/“ in open_basedir fehlt (nicht zu verwechseln mit /var/www/kopano-webapp/).
      Ich denke, wenn du den erstgenannten Pfad noch mit aufnimmst, wird es funktionieren.

      Gruß,
      Jan

      1. Hallo Jan.

        Vielen Dank für Deine Hilfe.
        Dein Hinweis hat sehr geholfen. Zum einen hatte ich /var/www und /usr/share verwechelt aber das eigentliche Problem war die Tatsache, daß „open_basedir“ nicht über symlinks hinweg funktioniert. Die Datei „config.php“ im Verzeichnis /var/www/kopano-webapp ist ein symlink auf /etc/kopano/webapp/config.php:
        lrwxrwxrwx 1 www-data www-data 29 Nov 8 15:28 config.php -> /etc/kopano/webapp/config.php

        Nachdem ich dann auch /etc/kopano/webapp in „open_basedir“ mit aufgenommen hatte, funktioniert es einwandfrei.

        Vielen Dank nochmal für Deine tollen Tutorials und Deine Hilfe.

        Gruß
        Helmut

  5. Hallo,
    ich habe seinerzeit mit der ersten Version dieser Anleitung meinen Server aufgesetzt, der auch bis heute stabil läuft. Viele der Anpassungen habe ich natürlich nachträglich auch eingefügt. Dennoch läuft bei mir bis heute die erste Let’s Encrypt Implementierung und ich habe leider keinen Plan wie ich das ändern kann.

    27.02.2019:
    Beschreibung zur Generierung der TLS-Zertifikate komplett auf acme.sh umgestellt, Anleitung für Certbot entfernt.

    Wie bekomme ich den Certbot sauber deinstalliert und acme.sh installiert?

    Dann noch ein andere Frage, wie gehe ich am besten vor wenn ich den Server an sich auf 20.04 LTS upgraden möchte. Oder sollte ich nur php 7.4 installieren?

    1. Hi,

      das hier dürfte für dich die passende Anleitung sein.

      Du kannst unter Ubuntu 18.04 nur PHP 7.2 installieren. Mehr ist in den Paketquellen nicht enthalten. Nun kannst du PHP 7.3 oder gar 7.4. per PPA nachinstallieren, aber das sind dann Fremd-Pakete, was ich im Allgemeinen nicht empfehle. Sauberer wäre hier, gleich auf Ubuntu 20.04 upzudaten. Hier kommt dann PHP 7.4 gleich mit. Allerdings musst du dann PHP von Grund auf neu konfigurieren, da die Konfiguration von PHP 7.2 nicht automatisch übernommen wird.

      Gruß,
      Jan

      1. Vielen Dank!

        Dann werde ich das jetzt mal zweistufig versuchen. Erst Umstellung auf acme.sh und dann das Serverupgrade. Da kann ich mich ja an die entsprechende Anleitung bei der Konfiguration halten.

        Gruß,
        Joshua

  6. Hallo,

    ich habe mit dieser Anleitung meine NextCloud damals perfekt aufsetzen können und bisher läuft diese auch. Nun hatte ich gestern auf 21.0.0 aktualisiert und schaffe es nicht folgende Meldungen wegzubekommen.

    Dein Web-Server ist nicht richtig eingerichtet um „/.well-known/webfinger“ aufzulösen. Weitere Informationen findest Du in der Dokumentation.
    Dein Web-Server ist nicht richtig eingerichtet um „/.well-known/nodeinfo“ aufzulösen. Weitere Informationen findest Du in der Dokumentation.

    Kann mir einer bitte helfen und sagen wo ich was eintragen muss und diese Apps (Social etc.) habe ich nicht bei mir aktiviert.

    Vielen Dank vorab schon mal.

    MfG Paul

    1. Hi Paul,

      du schreibst hier unter dem alten Tutorial. Hier gibt es mittlerweile einen neuen Artikel.
      Gleiche die Anweisungen von hier mal mit deiner Installation ab. Dein Problem wird aber konkret am vHost von Nextcloud hängen, daher hier nochmal genau kontrollieren.

      Gruß,
      Jan

    2. Hallo Paul,

      Du bist nicht alleine. Die gleiche Meldung erhalte ich mit 21 ebenfalls.
      Aber ich habe die Ursache bisher nicht gefunden.
      Wäre nett, wenn du posten würdest, wenn Du etwas weiter gekommen bist.
      Grüße
      Patrick

      1. Ich habe nun versucht die App Social zu installieren und erhalte eine Fehlermeldung: Could not extract app social: Out-of-path file extraction…

        Daher werde ich die Meldung erst mal einfach ignorieren, da ich diese App eh nicht verwende…

    3. Auch ich bekomme die beiden Meldungen nach dem Update auf NC21. Ich hatte meine Cloud damals nach diesem Tutorial aufgesetzt. Jetzt habe ich erstmal mein Ubuntu auf 20.04 geupgraded, dann die NC auf 21. Alles läuft sehr gut, jedoch bekomme ich diese beiden Meldungen nicht weg.

      Es wäre schon wenn hier jemand die Lösung posten könnte, danke.

    4. An alle, die diese Meldung auch angezeigt bekommen haben:

      Entfernt in euer „/etc/nginx/conf.d/euredomain.de.conf“ (nicht die „euredomain.de_nextcloud.conf“) den folgenden Part:

      # Well-known URL for Webfinger
      # Regardless of this rule, you’ll get a warning in the admin UI when the social app is not installed
      location = /.well-known/webfinger {
      return 301 $scheme://$host/nextcloud/public.php?service=webfinger;
      }
      und ersetzt ihn durch:
      location = /.well-known/webfinger {
      return 301 $scheme://$host/nextcloud/index.php/.well-known/webfinger;
      }
      location = /.well-known/nodeinfo {
      return 301 $scheme://$host/nextcloud/index.php/.well-known/nodeinfo;
      }

      Da die Nextcloud nach diesem Tutorial in einem Unterverzeichnis läuft, müssen Anfragen auf
      -> euredomain.de/index.php/.well-known/webfinger bzw nodeinfo
      an
      ->euredomain.de/nextcloud/index.php/.well-known/nodeinfo bzw webfinger
      weitergeleitet werden.

      Nach den Änderung nginx neustarten und die Meldung ist verschwunden, auch ohne die Social-App installiert zu haben.

      Gruß,
      Thomas

  7. Hallo Jan,

    vor ca. 1 Jahr habe ich erfolgreich mit dieser Anleitung einen Nextcloud-Server aufgesetzt und er läuft sehr stabil und wird von vielen Mitarbeitern genutzt. Nun möchte ich aber auch die Nextcloud auf die neueste Version updaten. Das setzt wiederum eine höhere PHP-Version voraus und die höhere PHP-Version ein höheres Ubuntu.

    Also war meine Idee, erst einmal Ubuntu von 18.04 auf 20.04 upzugraden. Im nächsten Schritt würde ich dann PHP updaten und dann zum Schluss die Nextcloud.

    Ist dann einfach so durchführbar? Kann ich im ersten Schritt einfach ein Upgrade auf Ubuntu 20.04 druchführen, ohne die NExtcloud zu zerschießen. Klappt das auch mit den anderen Schritten einfach so? Was muss ich beachten? Die Cloud wird produktiv eingesetzt, da darf natürlich nichts schiefgehen.

    Ich würde mich über eine Antwort freuen.

    MfG Ron

    1. Hi Ron,

      zunächst einmal der wichtigste Tipp: Backup machen!
      Ansonsten funktioniert das grob genau so wie du beschrieben hast. Nach dem Update auf Ubuntu 20.04 hast du PHP 7.4. Hier wird dann die Cloud erst einmal nicht mehr laufen (falscher Upstream-Socket). Ebenso muss PHP von Grund auf neu konfiguriert werden (ini- und conf-Dateien).
      Evtl. ist es auch sinnvoll, auf MariaDB 10.5 (das aktuellste Stable Release) upzudaten.
      Wenn du professionelle Hilfe benötigst, kannst du dich auch gern über meine geschäftliche Seite melden.

      Gruß,
      Jan

  8. Hallo Jan,

    ich fahre noch exakt diese/deine „alte“ Konfig, 18.04 LTS + PHP 7.4.
    Jetzt das Upgrade auf Nextcloud 21.0.1

    ##OCC_Problem##
    OCC geht erst mal nicht mehr. Das liegt an einem Setting in der
    /var/www/nextcloud/config/config.php
    ‚loglevel‘ => 0 verhindert das Ausführen von OCC. „Killed“ kommt nach ewig langer Wartezeit.
    Fix: ‚loglevel‘ => 2

    bei der Gelegenheit vielleicht noch
    ‚debug‘ => false,
    ‚default_phone_region‘ => ‚DE‘,
    hinzufügen, eliminiert eine weitere Fehlermeldung

    Im Anschluss können dann auch per OCC wieder die fehlenden Indices in der DB generiert werden.
    sudo -u www-data php occ db:add-missing-indices im Verzeichnis /var/www/nextcloud, aber das ist ja bekannt.

    ##WebFinger, NodeInfo##
    Nicht gelöst:
    Your web server is not properly set up to resolve „/.well-known/webfinger“.
    Your web server is not properly set up to resolve „/.well-known/nodeinfo“.

    Alles was ich hierzu finde führt zumindest dazu, dass die NextCloud nicht mehr verfügbar ist nachdem ich das versuichte habe nachzustellen.. Wäre gut, wenn du dir das mal anschaust.
    In dieser Konfig ist das wohl die conf in /etc/nginx/conf.d/.conf

    ##Imagick##
    Module php-imagick in this instance has no SVG support. For better compatibility it is recommended to install it.

    konnte ich nur lösen, indem ich alles manuell deinstallierte und danach neu installierte. Problem wurde dadurch gelöst:

    sudo apt remove imagemagick
    sudo apt remove php-imagick
    sudo apt install php-imagick imagemagick

    Was jetzt bleibt und hier die Bitte an dich, das mal zu checken, ist das Problem mit dem Webfinger und der NodeInfo. Hier gibts wohl auch die Diksussion über einen Bug in NC, über die Feststellung, dass die App Social installiert ist oder nicht, und dementsprechend die „Falschmeldung“ ein Bug sei.

    Danke schonmal vorab.

    Viele Grüße
    Chris mit Dank an Martin

    1. Hi Chris,

      das OCC-Problem konnte ich bisher noch nicht beobachten. Aber gut, dass du dafür eine Lösung finden konntest.
      Wegen den anderen Problemen: Du schreibst den Kommentar unter einen alten Artikel. Der neue Artikel ist hier zu finden. Dort ist auch alles enthalten, was die beschriebenen Probleme behebt. Beispielsweise wird für die Well-Known-URLs eine Anpassung am vHost für NC benötigt.

      Gruß,
      Jan

      1. Ich weiß, dass dies der alte Artikel ist, weil ich ja auch noch die 18.04 im Einsatz habe. Beim Aufbau der 20.04 hast du ja einiges grundlegend geändert, sollte ich das richtig verstanden haben. Und ich traue mich im Moment noch nicht das Inplace upgrade auf Ubuntu 20.04 zu fahren. Mit meinen Linux Kenntnissen gleich gar nicht :-) Wenns schief geht, war’s das. Jetzt schaue ich mir den Artikel zur NC auf 20.04 mal an wegen dem Hinweis zu Well-known-ULRLs.

        1. Hi,

          das Update auf 20.04 läuft eigentlich recht problemlos. Danach sind aber einige Anpassungen vorzunehmen (z.B. PHP neu konfigurieren und im vHost den PHP-Upstream anpassen). Aber hier kannst du denke ich noch ein wenig warten und dann gleich auf 21.04 gehen.
          Ansonsten gilt wie immer: Vorher Backups anfertigen, dann ist man auf der sicheren Seite.

          Gruß,
          Jan

  9. Moin, sagt dir der folgende Fehler irgendwas? Ich versuche größere Dateien hoch zuladen und bekomme dann aber eine Fehlermeldung. Nextcloud Version ist mittlerweile die 20.0.11.

    Sabre\DAV\Exception\BadRequest: Expected filesize of 10485760 bytes but read (from Nextcloud client) and wrote (to Nextcloud storage) 2940928 bytes. Could either be a network problem on the sending side or a problem writing to the storage on the server side.

    1. Hi,

      dieser Fehler tritt immer mal wieder auf und ich habe dafür noch keine Lösung gefunden.
      Kommt die Datei denn richtig in Nextcloud an, oder ist diese nach dem Upload „kaputt“?

      Gruß,
      Jan

      1. Hallo Jan,
        der bricht ab und die Datei ist gar nicht vorhanden. Ich konnte das Problem nun auch etwas weiter einschränken. Wie in der Meldung angegeben betrifft dies nur Dateien mit einer Größe größer 10 MB. Das Problem haben auch nur User die über einen Side2Side VPN Tunnel sich zur Nextcloud in unserer DMZ verbinden. User die normal übers Internet Dateien hochladen, haben dieses Poblem nicht. Gestern hatte ich in einem Forum einen Beitrag gefunden, dass das Problem mit NAT zusammenhängen kann, ich finde den Beitrag aber nicht wieder :-/

        1. Hi,

          ja, das wird oft als Workaroud genannt. Wenn es bei dir so klappt, dann kannst du das so lassen. HTTP/2 macht die Verbindung zum Webserver nur effizienter. Die Performance dürfte davon aber kaum betroffen sein. Darüber hinaus hat das Deaktivieren von HTTP/2 keine mir bekannten Nachteile.

          Gruß,
          Jan

          1. Hi,
            alles klar. Danke für die Info!
            Das Problem muss aber durch eines der neueren NC Updates entstanden sein. Nach der Installation über diesen Guide hatte ich das Problem über 2 Jahre nicht.

          2. Hi,

            also bekannt sind mir Änderungen dieser Art leider nicht. Aber gut zu wissen, dann kann man das mal im Hinterkopf behalten.

            Gruß,
            Jan

  10. Hallo Jan,
    weisst du wie man das abgelaufene Root Zertifikat DST Root CA X3 aus der Lets Encrypt Zertifikatskette raus bekommt? Wenn ich meine Nextcloud Webseite bei ssllabs teste, wird noch ein zusätzlicher Path #2: Not trusted Certificate Path angezeigt. Habe zwar bisher nur zwei Anfragen wegen diesem Problem bei alten Nextcloud Clients bekommen, aber es interessiert mich halt :-)
    Gruß
    Christian

    1. Hi Christian,

      dieses Zertifikat ist am 30.09. abgelaufen. Hier ist aber seit Mai 2021 ein anderes Zertifikat in der Chain. Daher sollte es hier keinerlei Probleme auf der „Server-Seite“ geben. Du könntest mal versuchen, die Zertifikate manuell neu auszustellen.
      Wenn die Zertifikate manuell auf irgendeiner Firewall/WAF installiet wurde, müssen diese dort auch erneuert werden.

      Gruß,
      Jan

  11. Hallo Jan,
    an was kann es liegen, dass mein kompletter Server so extrem langsam ist? (nutze einen XEON-Prozessor mit 16gb Ram).
    Sowohl meinedomain.de/nextcloud als auch meinedomain.de/phpmyadmin laden ewig.

    Der Nginx Error-Log spuckt folgendes aus:

    2021/11/12 21:06:54 [crit] 824#824: *12 SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking, client: 80.82.77.139, server: 0.0.0.0:443
    2021/11/12 21:06:55 [error] 824#824: *22 open() „/etc/nginx/html/robots.txt“ failed (2: No such file or directory), client: 80.82.77.139, server: meinedomain.org, request: „GET /robots.txt HTTP/1.1“, host: „11.222.33.44“
    2021/11/12 21:06:55 [error] 824#824: *23 open() „/etc/nginx/html/sitemap.xml“ failed (2: No such file or directory), client: 80.82.77.139, server: meinedomain.org, request: „GET /sitemap.xml HTTP/1.1“, host: „11.222.33.44“
    2021/11/12 21:06:56 [error] 824#824: *25 open() „/etc/nginx/html/favicon.ico“ failed (2: No such file or directory), client: 80.82.77.139, server: meinedomain.org, request: „GET /favicon.ico HTTP/1.1“, host: „11.222.33.44“
    2021/11/12 21:15:51 [error] 824#824: *254 „/etc/nginx/html/index.html“ is not found (2: No such file or directory), client: 34.140.248.32, server: meinedomain.org, request: „GET / HTTP/1.1“, host: „11.222.33.44“
    2021/11/12 21:16:05 [error] 824#824: *250 FastCGI sent in stderr: „PHP message: phpmyadmin: Failed to load /var/lib/phpmyadmin/blowfish_secret.inc.php Check group www-data has read access and open_basedir restrictions“ while reading response header from upstream, client: 11.222.33.44, server: meinedomain.org, request: „POST /phpmyadmin/index.php HTTP/2.0“, upstream: „fastcgi://unix:/run/php/php7.4-fpm.sock:“, host: „meinedomain.org“
    2021/11/12 21:16:50 [error] 824#824: *276 FastCGI sent in stderr: „PHP message: phpmyadmin: Failed to load /var/lib/phpmyadmin/blowfish_secret.inc.php Check group www-data has read access and open_basedir restrictions“ while reading response header from upstream, client: 11.222.33.44, server: meinedomain.org, request: „GET /phpmyadmin/index.php HTTP/2.0“, upstream: „fastcgi://unix:/run/php/php7.4-fpm.sock:“, host: „meinedomain.org“
    2021/11/12 21:16:50 [error] 824#824: *276 FastCGI sent in stderr: „PHP message: phpmyadmin: Failed to load /var/lib/phpmyadmin/blowfish_secret.inc.php Check group www-data has read access and open_basedir restrictions“ while reading response header from upstream, client: 11.222.33.44, server: meinedomain.org, request: „GET /phpmyadmin/phpmyadmin.css.php?nocache=4792555586ltr&server=1 HTTP/2.0“, upstream: „fastcgi://unix:/run/php/php7.4-fpm.sock:“, host: „meinedomain.org“
    2021/11/12 21:16:50 [error] 824#824: *276 FastCGI sent in stderr: „PHP message: phpmyadmin: Failed to load /var/lib/phpmyadmin/blowfish_secret.inc.php Check group www-data has read access and open_basedir restrictions“ while reading response header from upstream, client: 11.222.33.44, server: meinedomain.org, request: „GET /phpmyadmin/js/whitelist.php?v=4.9.7deb1 HTTP/2.0“, upstream: „fastcgi://unix:/run/php/php7.4-fpm.sock:“, host: „meinedomain.org“
    2021/11/12 21:16:50 [error] 824#824: *276 FastCGI sent in stderr: „PHP message: phpmyadmin: Failed to load /var/lib/phpmyadmin/blowfish_secret.inc.php Check group www-data has read access and open_basedir restrictions“ while reading response header from upstream, client: 11.222.33.44, server: meinedomain.org, request: „GET /phpmyadmin/js/messages.php?l=de&v=4.9.7deb1 HTTP/2.0“, upstream: „fastcgi://unix:/run/php/php7.4-fpm.sock:“, host: „meinedomain.org“
    2021/11/12 21:19:36 [error] 826#826: *370 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 127.0.0.1, server: 127.0.0.1, request: „GET /nextcloud/login HTTP/1.0“, upstream: „fastcgi://unix:/run/php/php7.4-fpm.sock:“, host: „meinedomain.org“
    2021/11/12 21:19:36 [error] 824#824: *381 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 127.0.0.1, server: 127.0.0.1, request: „GET /nextcloud/apps/richdocumentscode/proxy.php?req=/hosting/capabilities HTTP/1.0“, upstream: „fastcgi://unix:/run/php/php7.4-fpm.sock:“, host: „meinedomain.org“

    Irgendwie habe ich das Gefühl die fastcgi ist falsch eingerichtet. Hast du da einen Ansatz für mich?

    1. Hi Sascha,

      du hast unter dem (schon recht) alten Artikel kommentiert. Seitdem hat sich einiges geändert, daher gleiche doch bitte mal deine Konfiguration mit derjenigen aus dem neuen Artikel ab.

      Ansonsten sehe ich noch Fehler bzgl. phpMyAdmin. Hier ist vermutlich open_basedir nicht korrekt gesetzt.

      Alles in allem kann ich aber keinen Fehler erkennen, der direkt für die niedrige Performance verantwortlich sein könnte. Was sagt die allgemeine Systemauslastung?

      Gruß,
      Jan

      1. Hi Jan,
        die CPU und Memory-Auslastung leigt bei 0,1%.

        Ich habe einen Mix aus deinem neuen Artikel und deinem alten genutzt (da liegt sicherlich auch der Fehler), da ich neben Nextcloud auch Anwendungen auf meiner Domain nutzen möchte und mein DynDNS-Dienst keine Unterverzeichnisse zulässt (ich habe schon xxx.spdns.org bekommen).

        Somit habe ich versucht, deine alten Nginx-Konfigurationen (meinedomain.de/nextcloud) in deine neue Anleitung zu integrieren. Ich denke irgendwo kommt das Ganze in eine Schleife, ich weiss nur nicht wo.

        UFW ist inaktiv, NGINX logs liefern für mich keine aussagekräftigen Infos. Liegt es möglicherweise an der Datenbank?

        1. Hi Sascha,

          wenn es an der DB liegen würde, hättest du hier aber vermutlich mehr Systemlast.
          Kann es sein, dass du auf Nextcloud 22.2.1 bist? Hier gab es ein Hotfix-Release 22.2.2, welches Performance-Probleme in bestimmten Situationen beheben soll.

          Gruß,
          Jan

          1. Hi Jan,
            ja, ich habe auf 22.2.2 geupdated.

            Das Ding ist, dass nicht nur die Nextcloudumgebung, sondern auch WordPress und PHP-Myadmin extrem langsam sind.
            Beim Laden der Seiten habe ich mal über den Chromebrowser eine Netzwerkanalyse parallel laufen lassen: https://smuehl.de/nextcloud/s/LP3ddWK8zbZZYWs (Screenshot).
            Das Laden der Stylesheets und der Dokumente dauert ewig. So kann es nur an NGINX oder PHP liegen? Hast du einen Ansatz für mich, wie ich diese Performanceprobleme analysieren kann?

            Site-Topic: In den Sicherheits- & Einrichtungswarnungen bei Nexcloud zeigts mir nur die Webfingerwarnung an (bekomme da irgendwie die Nginx-Config nicht grade gezogen, da ich nicht weiss, in welchen Host – meinedomain.org bzw. meinedomain.org/nextcloud – ich die Blöcke kopieren soll).

            Danke für deine Ansätze soweit

          2. Hi Sascha,

            kannst du das mal mit einer statischen Seite o.ä. probieren? Dann könnten wir auf jeden Fall PHP aus der Gleichung nehmen. Wenn das dann immer noch langsam ist, sollte es an der nginx-Konfiguration liegen.

            Gruß,
            Jan

          3. Ich habe nun folgendes versucht.
            – PHP-Anwendung hochgeladen, mit folgendem Location Block: location ^~ /sendtexttoserver/
            – HTML-Seite hochgeladen, mit folgendem Location Block: location ^~ /test/

            Nun, beide Seiten funktionieren gar nicht. Was ich aber dabei herausgefunden habe, ist dass die Seiten alle auf WordPress verweisen. Mein Gefühl sagt mir, dass WordPress im Hintergrund die Anfragen zerstückelt. Deswegen habe ich all meine Seiten einmal eingegeben.

            Lädt super schnell:
            meine.webpage.de/netdata ==> meine.webpage.de/netdata

            Lädt super langsam, macht aber was es soll:
            https://meine.webpage.de.de/ ==> https://meine.webpage.de.de/wordpress
            https://meine.webpage.de.de/wordpress ==> https://meine.webpage.de.de/wordpress
            (WordPress soll über das root-directory laufen)

            https://meine.webpage.de.de/nextcloud/ ==> https://meine.webpage.de.de/nextcloud/
            https://meine.webpage.de.de/phpmyadmin/ ==> https://meine.webpage.de.de/phpmyadmin/

            Lädt super langsam, macht aber NICHT, was es soll:
            https://meine.webpage.de.de/pihole/ ==> https://meine.webpage.de.de/adminPH/
            (was hier wirklich lädt, ist aber die erste WordPress-Seite. Ich erreiche die pi-hole nur über die IP http://192.168.178.91:90/adminPH)

            https://meine.webpage.de.de/test/ ==> https://meine.webpage.de.de/wordpress/test/
            (was hier wirklich lädt, ist aber die erste WordPress-Seite)

            https://meine.webpage.de.de/sendtexttoserver ==> https://meine.webpage.de.de/wordpress/sendtexttoserver/
            (was hier wirklich lädt, ist aber die erste WordPress-Seite)

            Ich habe folgende Services mehrmals neugestartet:
            – service nginx restart
            – service php7.4-fpm restart
            – service mariadb restart

            Hab ich hier die NGINX-Config falsch programmiert oder bremst WordPress da im Hintergrund etwas aus? Ich hoffe ich habe das Problem verständlich formuliert, wen nicht, bitte ich schonmal um Entschuldigung.

          4. Hi Sascha,

            du hast also WordPress direkt auf der Domain „meine.webpage.de“ installiert und betreibst dann noch in Unterordnern weitere Web-Dienste (meine.webpasge.de/nextcloud). Dies würde ich auf keinen Fall empfehlen, denn die Webdienste dann auseinander zu halten in einer nginx-Config ist sehr kompliziert und fehleranfällig.
            Gerade WordPress mit seinen 1000 Plugins können mit anderen Anwendungen ins Gehege kommen.

            Besteht die Möglichkeit, dass du die Webdienste sauber trennst (z.B. über verschiedene (Sub-)Domains oder unterschiedliche Ports), damit diese nicht mehr „untereinander laufen“?

            Ich denke, dass dies der beste Ansatz sein sollte für dein Problem.

            Gruß,
            Jan

          5. Ich möchte WordPress nutzen, um eine Startseite für all meine Anwendungen zu haben (quasi eine Art Dashboard): https://smuehl.de/nextcloud/s/tXP2XXpTmdBWjtb (JPG meines Vorhabens).

            Installiert habe ich WordPress auf meine.webpage.de/wordpress. Bei der Eingabe in den Browser von meine.webpage.de soll an meine.webpage.de/wordpress weitergeleitet werden. (Befehl: return im location-Block: „location /“). D.h. die Ports sollten sich m.E. nach da eig. nicht ändern.

            Die Anwendungen nutzen meines Wissens nach verschiedene interne Ports (zumindest habe ich das nicht gendert).

            Von meinem dynDNS-Provider spdns.org habe ich schon eine Subdomain bekommen (SUBDOMAIN.spdns.org). Meines Wissens nach, ist es nicht möglich Subdomains von Subdomains zu erstellen (bspw. nextcloud.SUBDOMAIN.spdns.org), weswegen ich Unterordner der Hauptdomain zu nutzen versuche. Oder ist das möglich?

            Ich habe hier mal meine anonymisierten Gateway-Configs hochgeladen: https://smuehl.de/nextcloud/s/EPXXAm3NSBqFXct (zip-file)
            erkennst du da evtl. den Fehler? Evtl. in der WordPress oder der Nextcloud-config?

          6. Hi Sascha,

            ok, verstehe dein Vorhaben nun besser.
            Trotzdem würde ich nicht andere Webdienste „unter“ WordPress hosten. Dies ist sicherlich die Ursache für deine Probleme.
            Du brauchst auch keine Sub-Domain deiner DynDNS Sub-Domain (das bieten die meisten DynDNS-Dienste eh nicht an).
            Ich würde vorschlagen, dass du dir einfach eine Domain besorgst – die hast du ja vermutlich schon (smuehl.de). Hier legst du dir dann einfach Sub-Domains für jeden Dienst an (nextcloud.smuehl.de, netdata.smuehl.de, etc.). Auf diesen Sub-Domains lässt du dann die entsprechenden Dienste laufen. Damit bekommst du dann eine saubere Trennung hin, ohne dass irgendwelche Dienste „unter“ anderen Diensten laufen müssen.
            Für dein „Dashboard“ sollte es ja keine Rolle spielen, auf welchen Domains die Dienste letzten Endes laufen.

            Gruß,
            Jan

          7. Hallo Jan,
            ich habe den Server jetzt nochmal komplett platt gemacht und auf der neuen Version nur phpmyadmin und Nextcloud nach deiner neuen Anleitung installiert (außer die Nginx-Gateways, welche ich teilweise nach dieser Anleitung erstellt habe). Leider ist das mit der anderen Webpage keine Option, da ich über die Webpage smuehl.de keinen DynDNS-Dienst nutzen kann (mein neuer Server steht bei mir zuhause).

            Nach der Installation treten jetzt bei mir Webhook-Probleme auf (siehe untenstehende Nginx-Logs). Ich weiss nicht, wo die Nextcloud-Instanz diesen webhook her hat. PHP-MyAdmin funktioniert nach der Installation von NExtcloud auch nicht mehr.

            Weißt du, an was das liegen kann?

            Nginx-Log:
            2021/12/20 21:17:01 [error] 1022#1022: *949 open() „/etc/nginx/html/api/webhook/e25404ac2bbf869df5dd22112e4d0974b9c491adf27b661d34addecb735f50ce“ failed (2: No such file or directory), client: 78.55.110.71, server: leisa.spdns.org, request: „GET /api/webhook/e25404ac2bbf869df5dd22112e4d0974b9c491adf27b661d34addecb735f50ce HTTP/2.0“, host: „leisa.spdns.org“
            2021/12/20 21:17:15 [notice] 1020#1020: signal 15 (SIGTERM) received from 2536, exiting
            2021/12/20 21:17:15 [notice] 1021#1021: exiting
            2021/12/20 21:17:15 [notice] 1021#1021: exit
            2021/12/20 21:17:15 [notice] 1022#1022: exiting
            2021/12/20 21:17:15 [notice] 1022#1022: exit
            2021/12/20 21:17:15 [notice] 1023#1023: exiting
            2021/12/20 21:17:15 [notice] 1024#1024: exiting
            2021/12/20 21:17:15 [notice] 1023#1023: exit
            2021/12/20 21:17:15 [notice] 1024#1024: exit
            2021/12/20 21:17:15 [notice] 1020#1020: signal 15 (SIGTERM) received from 1, exiting
            2021/12/20 21:17:15 [notice] 1020#1020: signal 17 (SIGCHLD) received from 1023
            2021/12/20 21:17:15 [notice] 1020#1020: worker process 1023 exited with code 0
            2021/12/20 21:17:15 [notice] 1020#1020: signal 29 (SIGIO) received
            2021/12/20 21:17:15 [notice] 1020#1020: signal 17 (SIGCHLD) received from 1022
            2021/12/20 21:17:15 [notice] 1020#1020: worker process 1022 exited with code 0
            2021/12/20 21:17:15 [notice] 1020#1020: signal 29 (SIGIO) received
            2021/12/20 21:17:15 [notice] 1020#1020: signal 17 (SIGCHLD) received from 1021
            2021/12/20 21:17:15 [notice] 1020#1020: worker process 1021 exited with code 0
            2021/12/20 21:17:15 [notice] 1020#1020: signal 29 (SIGIO) received
            2021/12/20 21:17:15 [notice] 1020#1020: signal 17 (SIGCHLD) received from 1024
            2021/12/20 21:17:15 [notice] 1020#1020: worker process 1024 exited with code 0
            2021/12/20 21:17:15 [notice] 1020#1020: exit
            2021/12/20 21:17:15 [notice] 2537#2537: using the „epoll“ event method
            2021/12/20 21:17:15 [notice] 2537#2537: nginx/1.21.4
            2021/12/20 21:17:15 [notice] 2537#2537: built by gcc 9.3.0 (Ubuntu 9.3.0-10ubuntu2)
            2021/12/20 21:17:15 [notice] 2537#2537: OS: Linux 5.4.0-91-generic
            2021/12/20 21:17:15 [notice] 2537#2537: getrlimit(RLIMIT_NOFILE): 1024:524288
            2021/12/20 21:17:15 [notice] 2552#2552: start worker processes
            2021/12/20 21:17:15 [notice] 2552#2552: start worker process 2553
            2021/12/20 21:17:15 [notice] 2552#2552: start worker process 2554
            2021/12/20 21:17:15 [notice] 2552#2552: start worker process 2555
            2021/12/20 21:17:15 [notice] 2552#2552: start worker process 2556
            2021/12/20 21:17:17 [error] 2555#2555: *27 open() „/etc/nginx/html/api/webhook/e25404ac2bbf869df5dd22112e4d0974b9c491adf27b661d34addecb735f50ce“ failed (2: No such file or directory), client: 78.55.110.71, server: leisa.spdns.org, request: „GET /api/webhook/e25404ac2bbf869df5dd22112e4d0974b9c491adf27b661d34addecb735f50ce HTTP/2.0“, host: „leisa.spdns.org“

          8. Hi Sascha,

            zunächst wäre hier mal zu klären, was diese Webhook-URLs eigentlich aufrufen will. Bei NC sind mir beispielsweise keine solchen Webhooks bekannt.
            Kannst du dir hier einen Reim darauf machen, welche Anwendung dafür verantwortlich sein könnte?

            Gruß,
            Jan

          1. Hi Sascha,

            toll, dass du das Problem lösen konntest. Wie genau bist du darauf gekommen? Bzw. hattest du die Anweisungen im vHost (Nextcloud) für Collabora vergessen?

            Gruß,
            Jan

  12. Für alle die dieses Problem nach dem V21/V22 Update haben:
    Your web server is not properly set up to resolve “/.well-known/webfinger”.
    Your web server is not properly set up to resolve “/.well-known/nodeinfo”.

    Hier steht die Lösung in dem Kommentar von Seppl1 vom 10 April 2021.
    Ihr könnt die Zeilen 1 zu 1 tauschen! Hat bei mir ohne Probleme funktioniert und die Warnungen sind nun weg. Trotzdem Backup der Konfigdatei nicht vergessen :-).

    https://www.kodinerds.net/index.php/Thread/72550-Nextcloud-21-Konfigurationsfehler/

    1. Hi,

      du hast hier unter einen alten Artikel kommentiert. Dies hier ist der neuste Artikel zur Installation von Nextcloud. Dort sind die entsprechenden Änderungen auch schon eingepflegt, so dass diese Warnungen nicht mehr in der Admin-UI auftauchen.

      Gruß,
      Jan

      1. Moin Jan, ja ich weiß. Aber meine Nextcloud basiert auf dieser Anleitung mit der konfigurierten Gateway Konfiguration und ich hatte viele Anfragen bzgl diesem Thema in den Kommentaren gefunden. :-)

        1. Hi Christian,

          ich verweise halt immer auf den neusten Artikel, da es zu viel Aufwand bedeuten würde, alle älteren Artikel aktuell zu halten.
          Aber gut, dass du unter dem alten Artikel kommentiert hast, wo NC noch in einem Unterverzeichnis läuft. Dann finden das auch andere Leser, die das gleiche Problem haben und NC auch in einem Unterverzeichnis laufen lassen.

          Gruß,
          Jan

  13. Hallo Jan, ich bekomme bei Cotrun folgende Fehlermeldungen:

    0: ERROR:
    CONFIG ERROR: Empty cli-password, and so telnet cli interface is disabled! Please set a non empty cli-password!

    0: WARNING: I cannot support STUN CHANGE_REQUEST functionality because only one IP address is provided (Das wahrscheinlich weil ich Docker nutze und nur die lan ip vom container in der yaml gewählt habe)

    bind: Address already in use

    0: Trying to bind fd 29 to : errno=98
    Cannot bind local socket to addr: Address already in use
    0: Cannot bind TLS/TCP listener socket to addr 192.168.178.xxx:3478
    0: Trying to bind TLS/TCP listener socket to addr 192.168.178.xxx:3478, again…

    Wenn ich die Ports prüfe erhalte ich Das:
    COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
    turnserve 448230 turnserver 21u IPv4 51274928 0t0 TCP proxy.fritz.box:3478 (LISTEN)
    turnserve 448230 turnserver 26u IPv4 51272407 0t0 UDP proxy.fritz.box:3478
    turnserve 448230 turnserver 28u IPv4 51272408 0t0 UDP proxy.fritz.box:3478
    turnserve 448230 turnserver 29u IPv4 51274931 0t0 TCP proxy.fritz.box:3478 (LISTEN)
    turnserve 448230 turnserver 31u IPv4 51272409 0t0 UDP proxy.fritz.box:3478
    turnserve 448230 turnserver 32u IPv4 51274112 0t0 TCP proxy.fritz.box:3478 (LISTEN)
    turnserve 448230 turnserver 33u IPv4 51272410 0t0 UDP proxy.fritz.box:3478
    turnserve 448230 turnserver 35u IPv4 51274933 0t0 TCP proxy.fritz.box:3478 (LISTEN)

    Ich komme leider nicht weiter… hast du vielleicht mögliche Anhaltspunkte?
    Viele Grüße

    1. Hi,

      die Fehlermeldung sagt ja aus, dass der Port bereits belegt ist.
      Was sagt ein netstat -tupln | grep 3478?
      Woher kommt deine Ausgabe mit den Ports?

      Gruß,
      Jan

      1. Hi Jan, ich bekomme folgendes raus:

        netstat -tupln | grep 3478
        tcp 0 0 192.168.178.170:3478 0.0.0.0:* LISTEN 98996/turnserver
        tcp 0 0 192.168.178.170:3478 0.0.0.0:* LISTEN 98996/turnserver
        tcp 0 0 192.168.178.170:3478 0.0.0.0:* LISTEN 98996/turnserver
        tcp 0 0 192.168.178.170:3478 0.0.0.0:* LISTEN 98996/turnserver
        udp 0 0 192.168.178.170:3478 0.0.0.0:* 98996/turnserver
        udp 0 0 192.168.178.170:3478 0.0.0.0:* 98996/turnserver
        udp 0 0 192.168.178.170:3478 0.0.0.0:* 98996/turnserver
        udp 0 0 192.168.178.170:3478 0.0.0.0:* 98996/turnserver

        Ich kann jedoch nicht nachvollziehen wieso der Port belegt sein sollte, denn auf dem Port läuft kein anderer Dienst.

        Grüße.

        1. Hi,

          naja, es läuft ein coturn auf diesem Port. Kann es sein, dass du versuchst, eine zweite Instanz zu starten? Teste doch mal mit TrickleICE, ob es funktioniert.
          Empfohlen du kannst auch coturn auf Port 5349 und dann über TLS laufen lassen – dann wird eben nur ein Zertifikat benötigt, die Verbindungen sind dann aber verschlüsselt. Das wäre zumindest meine empfohlene Vorgehensweise.

          Gruß,
          Jan

          1. Morgen Jan,
            ich habe nur die eine Coturn Installation auf dem Server laufen. Wenn ich Coturn stoppe werden mir auch keine aktiven Ports angezeigt. Starte ich Coturn springen alle doppelt an. Die Installation & Konfiguration habe ich mehrmals identisch zu deiner Anleitung durchgeführt.
            Ganz kurios..

            Schönen Sonntag.

            root@proxy:~# systemctl stop coturn
            root@proxy:~# netstat -tupln | grep 3478
            root@proxy:~# systemctl start coturn
            root@proxy:~# netstat -tupln | grep 3478
            tcp 0 0 192.168.178.170:3478 0.0.0.0:* LISTEN 100457/turnserver
            tcp 0 0 192.168.178.170:3478 0.0.0.0:* LISTEN 100457/turnserver
            tcp 0 0 192.168.178.170:3478 0.0.0.0:* LISTEN 100457/turnserver
            tcp 0 0 192.168.178.170:3478 0.0.0.0:* LISTEN 100457/turnserver
            udp 0 0 192.168.178.170:3478 0.0.0.0:* 100457/turnserver
            udp 0 0 192.168.178.170:3478 0.0.0.0:* 100457/turnserver
            udp 0 0 192.168.178.170:3478 0.0.0.0:* 100457/turnserver
            udp 0 0 192.168.178.170:3478 0.0.0.0:* 100457/turnserver

          2. Hi,

            das coturn lt. netstat den gewählten Port mehrfach belegt, ist normal, aber eigentlich kommt hier nur ein Eintrag pro IP (also z.B. 192.168.178.170).
            Funktioniert der Test mittels TrickleICE? Das ist eigentlich das wichtigste.
            Wenn nicht, dann sollte man auf Fehlersuche gehen, z.B. indem man in der Config von coturn mal per „listening-ip“ oder „relay-ip“ die loakle LAN-IP der Maschine angibt.

            Gruß,
            Jan

  14. Hi Jan, folgenden Eintrag liefert mir TrickleICE:
    0.004 rtp host 0 udp 192.168.178.119 43111 126 | 31744 | 255 0 0 99f3ae99
    0.008 rtp host 3 udp 192.168.122.1 53456 126 | 32000 | 255 0 0 99f3ae99
    0.009 rtp host 6 udp 172.16.0.1 48892 126 | 32256 | 255 0 0 99f3ae99
    0.010 rtp host 9 udp fd00::ffff:ac10:1 50938 126 | 32512 | 255 0 0 99f3ae99
    0.011 rtp host 12 tcp 192.168.178.119 9 125 | 31936 | 255 0 0 99f3ae99
    0.011 rtp host 13 tcp 192.168.122.1 9 125 | 32192 | 255 0 0 99f3ae99
    0.012 rtp host 14 tcp 172.16.0.1 9 125 | 32448 | 255 0 0 99f3ae99
    0.014 rtp host 15 tcp fd00::ffff:ac10:1 9 125 | 32704 | 255 0 0 99f3ae99
    0.015 rtcp host 0 udp 192.168.178.119 37389 126 | 31744 | 254 0 0 99f3ae99
    0.016 rtcp host 3 udp 192.168.122.1 54933 126 | 32000 | 254 0 0 99f3ae99
    0.017 rtcp host 6 udp 172.16.0.1 40662 126 | 32256 | 254 0 0 99f3ae99
    0.017 rtcp host 9 udp fd00::ffff:ac10:1 50216 126 | 32512 | 254 0 0 99f3ae99
    0.030 rtcp host 12 tcp 192.168.178.119 9 125 | 31936 | 254 0 0 99f3ae99
    0.031 rtcp host 13 tcp 192.168.122.1 9 125 | 32192 | 254 0 0 99f3ae99
    0.032 rtcp host 14 tcp 172.16.0.1 9 125 | 32448 | 254 0 0 99f3ae99
    0.033 rtcp host 15 tcp fd00::ffff:ac10:1 9 125 | 32704 | 254 0 0 99f3ae99
    0.034 rtp host 0 udp 192.168.178.119 41347 126 | 31744 | 255 1 1 99f3ae99
    0.035 rtp host 3 udp 192.168.122.1 33617 126 | 32000 | 255 1 1 99f3ae99
    0.045 rtp host 6 udp 172.16.0.1 43051 126 | 32256 | 255 1 1 99f3ae99
    0.047 rtp host 9 udp fd00::ffff:ac10:1 37508 126 | 32512 | 255 1 1 99f3ae99
    0.049 rtp host 12 tcp 192.168.178.119 9 125 | 31936 | 255 1 1 99f3ae99
    0.051 rtp host 13 tcp 192.168.122.1 9 125 | 32192 | 255 1 1 99f3ae99
    0.053 rtp host 14 tcp 172.16.0.1 9 125 | 32448 | 255 1 1 99f3ae99
    0.054 rtp host 15 tcp fd00::ffff:ac10:1 9 125 | 32704 | 255 1 1 99f3ae99
    0.055 rtcp host 0 udp 192.168.178.119 48643 126 | 31744 | 254 1 1 99f3ae99
    0.056 rtcp host 3 udp 192.168.122.1 55736 126 | 32000 | 254 1 1 99f3ae99
    0.058 rtcp host 6 udp 172.16.0.1 45314 126 | 32256 | 254 1 1 99f3ae99
    0.062 rtcp host 9 udp fd00::ffff:ac10:1 42003 126 | 32512 | 254 1 1 99f3ae99
    0.063 rtcp host 12 tcp 192.168.178.119 9 125 | 31936 | 254 1 1 99f3ae99
    0.065 rtcp host 13 tcp 192.168.122.1 9 125 | 32192 | 254 1 1 99f3ae99
    0.067 rtcp host 14 tcp 172.16.0.1 9 125 | 32448 | 254 1 1 99f3ae99
    0.069 rtcp host 15 tcp fd00::ffff:ac10:1 9 125 | 32704 | 254 1 1 99f3ae99
    11.326 Not reachable?

    Mein Config:
    listening-ip=192.168.178.170
    relay-ip=192.168.178.170

    1. Hi,

      dann funktioniert das leider nicht. Es muss bei TrickleICE am Ende mindestens ein Eintrag mit „srflx“ kommen, damit man weiß, dass es funktioniert. Auch sehen bei dir die Einträge komisch aus. Es muss so aussehen wie auf dem Screenshot in diesem Abschnitt.
      Anhand der IP (192.168.178.xxx) vermute ich, dass du coturn an einem Rechner in einem privaten LAN betreibst, oder? Das ist u.U. nicht optimal (sich ändernde IPs, etc.).
      Diesen Artikel hier kennst du schon, oder? Vielleicht ist es sinnvoll, coturn nochmal zu deinstallieren und komplett von vorn zu beginnen. Das ist meist schneller als eine lange Fehlersuche.

      Gruß,
      Jan

  15. Hallo Jan,

    leider hat ein Stromausfall die Datenbank zerschossen. Sitze bereits seit zwei Tagen dran und komme nicht weiter.
    /var/log/nginx/error.log liefert:
    „…SSL_do_handshake() failed…“
    „…access forbidden by rule…“

    Da habe ich einiges Probiert. Bin aber nicht weitergekommen. Nginx läuft, da ein meet-Subdomane aufrufbar ist.
    Der Test auf SSL Labs schaut auch gut aus.
    Dann dachte ich an Nextcloud und die Datenbank.

    mysql -u root -p liefert:
    „ERROR 2002 (HY000): Can’t connect to local MySQL server through socket ‚/var/run/mysqld/mysqld.sock‘ (2 „No such file or directory“)“

    Da habe ich einige Anleitungen durchgearbeitet. Komme aber nicht zum Ziel.
    Die mysqld.sock kann ich nicht finden.
    So wie ich es verstanden habe auf https://mariadb.com/kb/en/missing-mysqldsock-file/ wird die mysqld.sock gelöscht, wenn mariaDB nicht läuft.

    Speicherplatz habe ich mit „df -h“ nachgeschaut. Müsste genügend vorhanden sein.

    Neustart mit „services mysql start“ liefert obigen Fehler.

    Habe mich unter anderem durch die Seite
    https://phoenixnap.com/kb/mysql-server-through-socket-var-run-mysqld-mysqld-sock-2
    gearbeitet. Ohne Erfolg.

    Hast du noch eine Idee wie ich die Datenbank retten kann?

    Habe die wage Vermutung, dass ich komplett neu aufsetzen muss. Zumindest haben einige User das als Lösung geschildert.

    Danke und beste Grüße
    Philipp

    1. Hallo Philipp,

      steht vielleicht genaueres in den Logs der Datenbank. Kann ja sein, dass der nicht vorhandene Socket ein Folgefehler ist, weil er den Socket auf Grund eines anderen Fehlers nicht anlegen kann.

      Mal anders herum gefragt: Existiert ein Backup der NC oder zumindest der DB? Es dürfte vermutlich viel schneller gehen, wenn man MariaDB komplett de- und wieder installiert und anschließend das Backup der DB wieder einspielt. Das wäre nun zumindest mein Ansatz bei einem solchen Fall.

      Gruß,
      Jan

      1. Hi Jan,

        danke für deine Antwort.
        Backup hatte Probleme (die mir erst jetzt aufgefallen sind). Das letzte ist mehrere Monate alt…
        In /var/log/mysql/error.log finden sich folgende Fehler:

        2022-12-30 10:47:21 139999458999424 [ERROR] InnoDB: Tried to read 65536 bytes at offset 35938816. Was only able to read 15872.
        FAILInnoDB: 1 transaction(s) which must be rolled back or cleaned up
        InnoDB: in total 1 row operations to undo
        InnoDB: Trx id counter is 1542396928

        2022-12-30 10:47:22 7f54087fe700 InnoDB: Error: Write to file ./ib_logfile1 failed at offset 35954176.
        InnoDB: 1024 bytes should have been written, only 512 were written.
        InnoDB: Operating system error number 5.
        InnoDB: Check that your OS and file system support files of this size.
        InnoDB: Check also that the disk is not full or a disk quota exceeded.
        InnoDB: Error number 5 means ‚Input/output error‘.
        InnoDB: Some operating system error numbers are described at
        InnoDB: http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html

        2022-12-30 10:47:22 7f54087fe700 InnoDB: Operating system error number 5 in a file operation.
        InnoDB: Error number 5 means ‚Input/output error‘.
        InnoDB: Some operating system error numbers are described at
        InnoDB: http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html
        InnoDB: Operation os_file_write_func to file /build/mariadb-10.1-CYSeUP/mariadb-10.1-10.1.48/storage/xtradb/os/os0file.cc and at line 5293

        2022-12-30 10:47:22 139998896580352 [ERROR] InnoDB: File ./ib_logfile1: ‚os_file_write_func‘ returned OS error 205. Cannot continue operation

        221230 10:47:22 [ERROR] mysqld got signal 6 ;
        This could be because you hit a bug. It is also possible that this binary
        or one of the libraries it was linked against is corrupt, improperly built,
        or misconfigured. This error can also be caused by malfunctioning hardware.

        Beste Grüße
        Philipp

        1. Hi Philipp,

          das sieht in der Tat nicht so gut aus. Ich würde vermutlich probieren, MariaDB vom System zu entfernen (remove, nicht purge) und neu zu installieren. Die Dateien, in der die Datenbanken selbst gespeichert sind, werden hier im Normalfall behalten. ZuR Sicherheit würde ich mir aber vorher nochmal den Ordner /var/lib/mysql wegsichern.

          Gruß,
          Jan

          1. Hi Philipp,

            ok, Glück gehabt! Danke für die Rückmeldung.
            Als nächstes solltest du aber auf jeden Fall das Thema Backups angehen. Dann bist du fürs nächste mal gut gerüstet.

            Gruß,
            Jan

  16. Hi Jan,

    danke für deine Antwort.
    Backup hatte Probleme (die mir erst jetzt aufgefallen sind). Das letzte ist mehrere Monate alt…
    In /var/log/mysql/error.log finden sich folgende Fehler:

    2022-12-30 10:47:21 139999458999424 [ERROR] InnoDB: Tried to read 65536 bytes at offset 35938816. Was only able to read 15872.
    FAILInnoDB: 1 transaction(s) which must be rolled back or cleaned up
    InnoDB: in total 1 row operations to undo
    InnoDB: Trx id counter is 1542396928

    2022-12-30 10:47:22 7f54087fe700 InnoDB: Error: Write to file ./ib_logfile1 failed at offset 35954176.
    InnoDB: 1024 bytes should have been written, only 512 were written.
    InnoDB: Operating system error number 5.
    InnoDB: Check that your OS and file system support files of this size.
    InnoDB: Check also that the disk is not full or a disk quota exceeded.
    InnoDB: Error number 5 means ‚Input/output error‘.
    InnoDB: Some operating system error numbers are described at
    InnoDB: http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html

    2022-12-30 10:47:22 7f54087fe700 InnoDB: Operating system error number 5 in a file operation.
    InnoDB: Error number 5 means ‚Input/output error‘.
    InnoDB: Some operating system error numbers are described at
    InnoDB: http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html
    InnoDB: Operation os_file_write_func to file /build/mariadb-10.1-CYSeUP/mariadb-10.1-10.1.48/storage/xtradb/os/os0file.cc and at line 5293

    2022-12-30 10:47:22 139998896580352 [ERROR] InnoDB: File ./ib_logfile1: ‚os_file_write_func‘ returned OS error 205. Cannot continue operation

    221230 10:47:22 [ERROR] mysqld got signal 6 ;
    This could be because you hit a bug. It is also possible that this binary
    or one of the libraries it was linked against is corrupt, improperly built,
    or misconfigured. This error can also be caused by malfunctioning hardware.

Kommentar verfassen

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