DecaTec

Programmieren, Fotografie, Home-Server und einiges mehr

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

Nextcloud LogoDieser 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: 10.06.2018)
  • 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 LTS („Bionic Beaver“)
  • Nextcloud 13.0.4
  • nginx 1.15.0
  • MariaDB 10.3.7
  • PHP 7.2
  • Redis 4.0.9
  • Fail2ban 0.10.2

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:

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

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:

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:

Hier fügen wir folgenden Inhalt ein:

Installation nginx

Nach der Aktualisierung der Paketquellen kann der Webserver installiert werden:

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:

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

Installation MariaDB

Nun kann das Datenbanksystem installiert werden:

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:

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/Certbot

Zum Erzeugen des SSL-Zertifikats wird nun noch Let’s Encrypt benötigt. Hier gibt es mittlerweile einige Client-Implementierungen. Certbot ist ein solcher Let’s Encrypt-Client, der praktischerweise schon in den Ubuntu-Paketquellen enthalten ist. Daher reichen zur Installation folgende Befehle:

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:

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 Versions-Informationen preisgibt (z.B. auf Fehlerseiten). Daher sollte diese Option aus Sicherheitsgründen angepasst 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:

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:

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:

Folgende Anpassungen sollte man hier vornehmen:

  • user/group: Der Benutzer, unter dem PHP ausgeführt wird. Dies ist wieder unser Webserver-User, also
  • listen: Die Kommunikation zwischen Webserver und PHP soll über einen Socket ablaufen. Dazu muss hier folgendes angegeben werden:
  • 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:

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:

  • cgi.fix_pathinfo: Sorgt für eine sichere Interpretation von Pfadangaben:

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

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

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:

Folgende Einstellungen sollten an dieser Stelle angepasst werden:

  • cgi.fix_pathinfo: Wie oben beschrieben:
  • 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:

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

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:

Anlegen des Gateway-Hosts

Als erstes wird nun der Gateway-Host in einer Minimal-Ausführung hinzugefügt:

Hier reichen zunächst folgende Zeilen:

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:

Auch dieser virtuelle Host ist dabei sehr einfach aufgebaut:

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:

SSL-Zertifikat mit Let’s Encrypt/Certbot 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

Nachdem alle Voraussetzungen erfüllt sind, kann das Zertifikat erzeigt werden:

Die Generierung ist hierbei interaktiv: Zunächst wird nach einem E-Mail-Adresse gefragt. Diese wird dazu verwendet, bei bald ablaufenden Zertifikaten (Let’s Encrypt-Zertifikate haben nur eine Gültigkeitsdauer von 90 Tagen) eine Hinweis-Mail zu schicken. Anschließend müssen noch die Nutzungsbedingungen des Dienstes abgenickt werden. Ob man die eigene Mail-Adresse dann an EFF (Electronic Frontier Foundation) weitergeben möchte, muss jeder für sich entscheiden.

Nun sollte nach einigen Augenblicken das Zertifikat erfolgreich generiert worden sein:

Das SSL-Zertifikat wurde erfolgreich erzeugt

Das SSL-Zertifikat wurde erfolgreich erzeugt

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

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

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

Zugriffsberechtigungen für Zertifikat-Dateien setzen

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

Erneuerung der Zertifikate

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

Bei der hier gezeigten Installation von Certbot wird auf den meisten Systemen 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.

Ob dieser Cronjob erfolgreich eingerichtet wurde und regelmäßig ausgeführt wird, kann man einfach im dazugehörigen Logfile sehen:

Nach einer gewissen Laufzeit sollten hier Einträge wie dieser hier zu finden sein:

In diesem Fall werden die Zertifikate automatisch und ohne Zutun des Benutzers bei Bedarf neu generiert.

Falls dieser Cronjob nicht angelegt wurde, können die Zertifikate auch manuell mit folgenden Befehlen erneuert werden (spätestens nach 90 Tagen):

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

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.

Die hinzuzufügenden Abschnitte sind hier markiert:

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.

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:

Diese Datei ist mit folgendem Inhalt zu füllen:

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.
  • Die proxy_set_header Anweisungen dienen der erhöhten Sicherheit. Ohne diese Einträge werden später Warnungen im Admin-Bereich von Nextcloud angezeigt. In vielen Tutorials werden diese Header per add_header angegeben. In unserem Fall funktioniert dies nicht, da die Zugriffe über einen Proxy (Gateway-Host) ablaufen. Daher werden die Header mittels proxy_set_header angegeben.
  • Der 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:

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

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:

Nun sollten nochmals die Dateiberechtigungen gesetzt werden:

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:

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:

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, sind nun auf der linken Seite die Grundeinstellungen der Cloud zu finden. Hier sollte nun direkt nach dem Setup eine Warnung angezeigt werden, 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.

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:

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):
     
  • 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:
     
  •  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:
     
  •  Timezone für Log-Einträge: Die richtige Zeitzone (z.B. für die Timestamps der Log-Einträge) wird durch diese Variable konfiguriert:

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:

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:

Dies sorgt nun dafür, dass dieser Cronjob alle 15 Minuten automatisch ausgeführt wird. Theoretisch könnte hier auch eine andere Zeitspanne genutzt werden, allerdings ist die allgemeine Empfehlung 15 Minuten.

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

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:

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

Hier wird zunächst einmal der verwendete Zeichensatz kontrolliert:

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

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

Danach sollte nach nochmaliger Eingabe von

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

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

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

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

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:

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

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:

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:

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

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

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

Der Inhalt der Datei:

Hiermit wird ein neues Regel-Set (Jail) für Nextcloud angelegt. Folgende Einstellungen werden hier angegeben:

  • 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.
  • 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.
  • logpath: Log-Datei, die Fail2ban für dieses Jail beobachten soll. Auf diese Datei wird der oben definierte Filter angewendet.

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.

Nach einem Neustart von Fail2ban ist das Programm einsatzbereit:

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. sSMTP 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 sSMTP ausführlich erklärt.

Wenn sSMTP 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 werden einfach noch folgende Zeilen hinzugefügt:

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

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

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:

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

Mit diesem Befehl wird diese IP wieder entsperrt:

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:

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

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.

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:

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

Aktivierung von Redis in Nextcloud

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

Folgende Zeilen werden hier eingefügt:

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:

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:

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

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

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

Kommentare: 190

  • Bodo sagt:

    Hallo,

    ich bin beim Versuch, neben Nextcloud noch andere php-Anwendungen zu hosten (phpmyadmin in diesem Fall) auf diverse Probleme gestoßen, vor allem mit open_basedir. Hat mir etwas Kopfzerbrechen bereitet…

    Ich hab zuerst in den entsprechenden php.ini-Dateien einfach die notwendigen Pfade für phpmyadmin nachgetragen. Das hatte nicht funktioniert. Schließlich ist mir aufgefallen, dass es in deiner Konfiguration für den virtuellen Host die Option „fastcgi_param PHP_VALUE“ gibt, die u.a. den open_basedir-Paremeter setzt (und wie ich das verstehe, damit die Einstellungen der php.ini überschreibt).

    Nun halte ich es für etwas schwachsinnig, die nötigen Pfade für phpmyadmin in Konfiguration des Nextcloud-vHosts einzutragen. Ich hab daher open_basedir aus dem vHost komplett rausgenommen und die Pfade in die php.ini eingetragen.

    Das funktioniert jetzt soweit. Nur frage ich mich, ob das eine saubere Lösung ist.

    Wenn ich die Problematik jetzt richtig aufgefasst habe, darf ich mir hoffentlich diese Kritik an der sonst hervorragenden Anleitung erlauben: Du weist an manchen Stellen ausdrücklich darauf hin, dass auf Basis der Anleitung noch weitere Anwendungen neben Nextcloud installiert werden können. Durch solche Sachen wie die open_basedir-Einschränkung wird aber genau das enorm erschwert, weil andere Anwendungen davon beeinflusst sind. Gibt es da vielleicht eine elegantere Lösung?

    Trotzdem danke für diese sehr ausführliche Anleitung! ;)

    • Jan sagt:

      Hi Bodo,

      ja, das mit open_basedir übersieht man mal schnell und wundert sich dann, warum irgendwas nicht sauber funktioniert.
      Mein Hintergrundgedanke bei der Aufteilung der open_basedir-Anweisungen (php.ini und PHP-location im vHost) ist folgender: Man könnte alle für PHP freigegebenen Verzeichnisse auch einfach in die php.ini mit aufnehmen. Dennoch sollte z.B. der Handler von Nextcloud keinen Zugriff auf die Verzeichnisse einer anderen Webanwendung haben. Daher überschreibe ich mit fastcgi_param PHP_VALUE "open_basedir=... die open_basedir Anweisung aus der php.ini. Und zwar für jede PHP-Anwendung einzeln.
      Du schreibst, dass du die Pfade für phpMyAdmin in den Nextcloud-vHost mit aufgnehmen musstest. Ich würde hier eher einen eigenen vHost für phpMyAdmin anlegen, in dem dann eine php-location in etwa wie folgt aussehen sollte:
      location ~ \.php$ {
      fastcgi_param PHP_VALUE "open_basedir=...";
      }

      Hier trägst du dann die Pfade ein, die phpMyAdmin benötigt. Dadurch werden die Zugriffsrechte vom PHP/Nextcloud nicht angefasst und du hast dadurch eine bessere Trennung zwischen den PHP-Anwendungen.

      Gruß,
      Jan

      • Bodo sagt:

        Danke, das hat perfekt funktioniert!
        Diese Idee hatte ich zwischenzeitlich selbst. Hatte aber befürchtet, dass dann die parallele Nutzung zweier Anwendungen nicht funktioniert, wenn diese sich gegenseitig die php-Parameter überschreiben. Ist wohl nicht so.
        Hab die Idee dann verworfen, ohne es auszuprobieren. *facepalm*

  • Christian sagt:

    Hallo Jan,

    ggf etwas off topic aber vielleicht kannst du helfen. Ich bin von meinen Odroids auf die Zotax CI327nano Kiste gewechselt (Core i3, 64b).Leider hab ich es dort nicht geschafft ein minimales Ubuntu zu installieren sondern bin bei Debian 9 (Stretch) gelandet. Wie schon bei den Raspberries kämpfe ich an der Fail2Ban Konfig.

    Bisher, alles installiert wie in deinem Walkthrough angegeben. Nextcloud läuft. Redis den Hinweis von Michael bzgl der socks berücksichtigt. Von allen Aushärtungspunkten läuft Fail2Ban nicht. Ich habe mittlerweile die jail.conf auf die jail.local kopiert (vorher auch mit leerem File versucht, gleiches Ergebnis) und Einträge für die SSH Konfiguration aktiviert:
    [ssh]
    enabled = true
    port = ssh
    filter = sshd
    logpath = /var/log/auth.log
    maxretry = 3

    Läuft. Der Service lässt sich auch (service fail2ban restart) problemlos starten. Sowie ich jedoch die nextcloud/nginx Einträge von dir einfüge:
    [nextcloud]
    enabled=true
    port=80,443
    protocol=tcp
    filter=nextcloud
    maxretry=3
    bantime=1800
    logpath=/var/nextcloud_data/nextcloud.log

    [nginx-http-auth]
    enabled = true

    wirft der ServiceRestart folgende Exception:

    — Unit fail2ban.service has finished shutting down.
    Jun 23 22:21:25 ZBOX-CI327 systemd[1]: fail2ban.service: Start request repeated too quickly.
    Jun 23 22:21:25 ZBOX-CI327 systemd[1]: Failed to start Fail2Ban Service.
    — Subject: Unit fail2ban.service has failed
    — Defined-By: systemd
    — Support: https://www.debian.org/support

    — Unit fail2ban.service has failed.

    — The result is failed.
    Jun 23 22:21:25 ZBOX-CI327 systemd[1]: fail2ban.service: Unit entered failed state.
    Jun 23 22:21:25 ZBOX-CI327 systemd[1]: fail2ban.service: Failed with result ‚exit-code‘.

    Ich bin verloren, keine Ahnung was ich hier tun kann. Ich konnte es wenigstens soweit eingrenzen, dass wenn ich die beiden Konfigs (nextcloud nginx) rausnehme (die vorher exakt so unter meiner Ubuntu Konfig schon liefen), der Fail2Ban wieder lauffähig wird.

    Kannst du mir, ggf jemand anderes der hier liest, helfen ?

    Danke,
    Christian

    • Jan sagt:

      Hi Christian,

      ja, wenn fail2ban nicht gestartet werden kann, dann kommt leider immer nur diese nichts sagende Fehlermeldung. Ich vermute hier aber igrgend eine Art von Tippfehler in einer der Config-Files.
      Daher probier doch einfach mal folgenden Befehl: journalctl -ru fail2ban
      Alternativ direkt ins Fail2ban Logfile schauen: /var/log/fail2ban.log
      Hier sollte der Fehler genauer beschrieben sein (mit genauer Angabe der fehlerhaften Datei nebst Zeilennummer).

      Gruß,
      Jan

      • Christian sagt:

        Hallo Jan,

        danke für den Tipp wie ich hier zu der aussagekräftigen Fehlermeldung komme.

        Ich bin der Fail2Ban Installationsdoku gefolgt und hab den jail.local aus einer Kopie des jail.conf erzeugt. Damit halt auch jede Menge Dubletten in den Konfigurationsargumenten erstellt. Aua.

        Ja, das Problem sitzt vor dem PC :-)

        Danke für den Tipp, ohne würde ich heute noch suchen.
        Jetzt funktioniert alles, auch unter Debian Stretch.

        Perfekt, danke (wie immer)

        Gruß
        Christian

  • Tino Soldan sagt:

    Hi Jan und Michael,

    ich melde mich nochmal zum Update der MariaDB von 10.2 auf 10.3. Dazu hatte ich ja zwei Fragen: ob man das Update einfach so drüberlaufen lassen kann (was tatsächlich so wie von Dir, Michael, beschrieben, geklappt hat) und ob man danach den Befehl mysql_secure_installation ausführen sollte.
    Wenn Ihr nichts Gegenteiliges „beweisen“ könnt, würde ich hiermit das erneute Ausführen von mysql_secure_installation zur Absicherung der Installation empfehen!
    Im Konsolen-Output war zu lesen, dass 10.2 entfernt und 10.3 hinzugefügt wurde. Auch die Tatsache, dass im Zuge der Installation ein Passwort neu gesetzt werden musste, sah eher danach aus, dass die Installation von 10.3 nicht nur ein Update, sondern eine Neu-Installation ist, so dass der Secure-Befehl im Anschluss notwendig wäre. Außerdem tut der nicht weh, da man nur 5 Fragen beantwortet, wovon man nur die Frage nach einem Passwort mit „N“ beantwortet (weil bereits bei der Installation gesetzt) und die restlichen vier mit „Y“. Das wars dann schon.

    Im Zuge des Secure-Befehls wird der anonyme User, eine Test-Datenbank und der Remote-Zugang von root entfernt. Wenn Ihr wisst, wie man prüfen kann, ob nach dem „Update“ auf 10.3 ein anonymer User und eine Testdatenbank tatsächlich installiert wurden (ich habe keine Ahnung von Datenbanken :-( , dann wäre klar, ob man den Secure-Befehl wirklich braucht.

    Gruß, Tino

    • Jan sagt:

      Hi Tino,

      danke für die ausführlichen Infos.
      Auch ich würde den Secure-Befehl auf jeden Fall nach dem Update ausführen. Wie du schon sagtest: Er schadet ja auf keinen Fall.

      Gruß,
      Jan

    • Michael sagt:

      Hallo Tino,

      ich habe es wie Du gemacht. Ich habe mysql_secure_installation auch noch einmal ausgeführt, Passwort gesetzt und die Fragen beantwortet. Alles gut! Bei mir hat der Wechsel auf 10.3 jedoch die nginx.log derbe mit Meldungen zugeknallt.

      Wie man die Sachen, die man mit dem Secure-Befehl entfernt, testen kann, weiß ich nicht. Da bin ich gerade überfragt.

      Herzliche Grüße
      Michael

  • Markus sagt:

    Super Tutorial und nach ein paar anläufen klappte es auch prima, nur habe ich seit den letzten update ein Problem mit Redis.
    Habt ihr das gleiche Problem?
    Hat jemand eine Idee?

    danke

    Max

    Redis::connect(): connect() failed: No such file or directory at /var/www/nextcloud/lib/private/RedisFactory.php#84

    • Jan sagt:

      Hi Max,

      zunächst einmal danke für das Lob.
      Du schreibst, dass du ein paar Anläufe gebraucht hast, bis alles lief. An welchen Punkten hat des denn gehakt? Kann ich das Tutorial hier vielleicht noch verbessern?

      Zu deinem Problem mit Redis: Konnte auch nach dem letzten NC-Update keine Probleme feststellen.
      Hier würde ich die „üblichen verdächtigen Stellen“ kontrollieren: In der Datei /etc/redis/redis.conf muss zwingend folgendes enthalten sein:
      port 0
      unixsocket /var/run/redis/redis-server.sock
      unixsocketperm 770

      Darüber hinaus muss der hier definierte Socket (/var/run/redis/redis-server.sock) genau so in die config.php von NC eingetragen werden. Ich vermute mal, dass genau das der Fehler ist, da der Socket hier evtl. nicht richtig eingetragen ist und der daraufhin „die Datei“ nicht findet:
      'filelocking.enabled' => 'true',
      'memcache.locking' => '\OC\Memcache\Redis',
      'redis' => array(
      'host' => '/var/run/redis/redis-server.sock',
      'port' => 0,
      'timeout' => 0.0,
      ),

      Falls das bei dir alles korrekt eingetragen ist: Gibt die Fehlermeldung noch mehr her (z.B. kompletter Stacktrace)?

      Gruß,
      Jan

  • Holger sagt:

    Tolle Anleitung, klasse *two-thumbs-up* !!! Vielleicht kannst Du mir aber an einer Stelle helfen: Der Versuch, größere Dateien (ca. 700MB) durch meine 1MBit/s-Uploadleitung auf die Nextcloud-Instanz per Webdav zu übertragen, schlägt regelmäßig und reproduzierbar fehl. Die Meldung im error.log von nginx lautet:

    „FastCGI sent in stderr: „PHP message: PHP Fatal error: Uncaught PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away in /var/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php:105“

    Bei Files um die 300MB funktioniert alles. Ich stoße hier also entweder auf eine Größenbeschränkung oder ein Timeout. In der php.ini und im Admin-Interface habe ich bereits die Limits nach oben gesetzt, scheint jedoch nicht zu helfen. Weisst Du, welche Parameter maßgeblich das Verhalten beim Upload beeinflussen?

  • Sascha sagt:

    Hallo,
    ersteinmal vielen Dank für die detallierte Dokumentation.

    Ich bleibe beim Anlegen des vHosts für Nextcloud hängen. Beim Aufrufen der Website (https://XXX.de/nextcloud) kommt folgende Meldung: „No input file specified.“

    Liegt dies an einer unzureichenden Dekleration in der PHP.ini? (Im Netz habe ich etwas gefunden, wo man „echo[s]“ entfernt und „doc_root“ definiert. Beide Lösungen funktionieren leider nicht). Oder liegt es daran, dass ich die XXX.de_nextcloud.conf einfach nur kopiert habe und es etwas an der von euch erwähnten:

    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_param PATH_INFO $fastcgi_path_info;

    Habe ich hier etwas falsch gemacht? (evtl. irgendeine Location falsch zugeordnet?) Wenn, wäre ich über einen Lösungsvorschlag sehr dankbar.

    System: VPS WebServer in Nürnberg

    Viele Grüße Sascha

    • Jan sagt:

      Hi Sascha,

      ich war mal so frei und habe den doppelten Kommentar entfernt. Ich hoffe, das geht in Ordnung.
      Zu deinem Problem: Hier kann PHP eine Datei nicht finden, die nginx zum Laden angibt. Am besten gehtst du nochmal sämtliche Einstellungen für PHP einzeln durch.

      Wichtig sind dann auch folgende Einstellungen im vHost für Nextcloud. Hier besonders auf den regulären Audruck bei fastcgi_split_path_info achten (dieser muss genau so lauten):
      fastcgi_split_path_info ^(.+\.php)(/.+)$;
      fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
      fastcgi_param PATH_INFO $fastcgi_path_info;

      Bei der Anweisung fastcgi_param PHP_VALUE „open_basedir=… musst du eben noch den Pfad mit aufnehmen, wo du Nextcloud installiert hast (falls abweichender Pfad).

      Anschließend nochnal ein chown -R /var/www/nextcloud und den Webserver und PHP neu starten (service nginx restart bzw. service php7.2-fpm restart).

      Danach sollte es eigentlich funktionieren. Ansonsten schau doch mal in die Logdatei von nginx (/var/log/nginx/error.log), ob hier genauer aufgelistet wird, welche Datei(en) er nicht finden kann.

      Gruß,
      Jan

      • Sascha sagt:

        Danke für dein Feedback,

        letztendlich lag es daran, dass die alternative Verzeichnisstruktur zum Tragen kam Der Ordner configd kommt somit nicht zum Tragen. Da lagen zu viele Dateien. Jetzt sind diese via Symlink im Sites-Enabled Ordner und alles funktioniert.

        Nächstes Problem: Nextcloud läuft zwar, ich kann aber nichts hochladen bzw. keine Dateien löschen oder verschieben. Liegt das an einer falschen Redis-Konfiguration oder an einer falschen Nutzerkonfiguration? (config.php der nextcloud: ‚filelocking.enabled‘ => ‚true‘,)

        • Jan sagt:

          Hi Sascha,

          ich denke nicht, dass es an Redis liegt. Schau mal in die Log-Files für nginx (/var/log/neginx/error.log) und Nextcloud. Hier sollte nach dem Hochladen/Löschen/Verschieben von Dateien der Fehler genauer beschrieben sein.

          Gruß,
          Jan

  • Alexander sagt:

    Hi Jan,
    wieder eine super saubere Dokumentation, klasse und Danke dafür!
    Ich bewege mich mit Linux, Nextcloud u.ä. auf Einsteiger-Niveau, ich würde gerne ein System bauen, das praktisch ein NAS mit Nextcloud ist. Momentan habe ich testweise die NC auf einem Notebook und OMV auf einem selber gebauten NAS laufen. Könnte man die beiden verquicken, passt das auch in Dein Konzept!
    Gruß, Alex

    • Jan sagt:

      Hi Alex,

      leider habe ich mit OMV keinerlei Erfahrung. Daher die (vielleicht dumme) Frage: Was bietet dir OMV, was Nextcloud nicht bieten kann? Ein NAS ist im Prinzip ja nur eine große Netzwerk-Festplatte. Das kann man auch direkt mit Nextcloud realisieren.
      Dennoch habe ich zwei Links für dich, wo beschrieben wird, woe man Nextcloud auf OMV installiert werden kann: Link 1, Link 2. Vielleicht hilft dir das ja schonmal weiter.

      Gruß,
      Jan

      • Alexander sagt:

        Hi Jan,
        OMV bietet den Vorteil, dass ich ein RAID betreiben kann. Soweit ich weiss, lässt sich das mit NC nicht direkt umsetzen.
        Mir scheint das immer eine Gratwanderung zu sein, ob ich mehr Wert auf einen NW-Speicher mit Ausfallsicherheit lege oder die typischen Cloud-Funktionen. Danke Dir für die Links, gerade Technikafffe kenne ich mittlerweile ganz gut :-)
        Viele Grüße, Alex

      • Alexander sagt:

        Hallo Jan,
        Danke für die Links, Technikaffe war mir bekannt :-)
        Vielleicht entgeht mir ja noch was, ich hätte gern die Eigenschaften eines Netzwerkspeichers, erreichbar über das interne Netz, eingebunden als Netzlaufwerk auf den Clients. Die File-Ablage soll als RAID5 laufen (2 Platten).

        Die private Cloud wiederum soll auch von extern erreichbar sein. Idealerweise habe ich darüber auch Zugriff auf die Daten auf dem Netzwerkspeicher oder auf einen bestimmten Teil davon.

        Die vorhandene Hardware ist das Basic NAS 3.0, wie von Technikaffe beschrieben.

        Und jetzt bin ich am Tüfteln, wie ich den NAS-Teil mit der private cloud im wahrsten Sinne des Wortes unter eine Haube bringe.

        Danke nochmal für deine Anmerkungen dazu.
        Viele Grüße, Alex

        • Jan sagt:

          Hi Alex,

          RAID ist so eine Sache: Würde ich persönlich im Privat-Bereich nicht mehr machen, es sei denn, ich habe ganz spezielle Gründe. Daher würde ich mich an deiner Stelle erst einmal wirklich gut in das Thema etwas einlesen. Zwei Punkte werfe ich einfach mal so in den Ring:

          1. RAID (5) würde ich nicht als Software- oder Fake-RAID betreiben. Nur mit speziellem RAID-Controller mit BBU. Hier musst du entsprechend tief in die Tasche greifen.
          2. Speziell für RAID 5: Wenn, dann nur mit Platten nicht größer als 1TB. hier habe ich mal einen interessanten Link zu dem Thema.

          Wie dem auch sei, um NAS und Cloud zu verheiraten, kannst du ja einfach Nextcloud auf dem NAS installieren. Du kannst dann ja jederzeit die Benutzer-Verzeichnisse, die sonst nur über das NAS LAN-intern zu erreichen sind, in Nextcloud als externen Speicher einbinden.

          Gruß,
          Jan

          • Alexander sagt:

            Hi Jan,
            sorry, ich hatte mich verschrieben, gemeint war ein einfaches Mirroring, müsste dann RAID 1 sein.
            Nextcloud auf einem eigenen NAS zu installieren ist schon auch etwas kniffelig, ich fuchse mich da gerade noch rein! :D
            Viele Grüße.

          • Alexander sagt:

            So, nach langer Tüftelei habe ich es hinbekommen, Nextcloud 13 unter OMV 4 grundlegend ans Laufen zu bekommen. Jetzt fehlt noch alles weitere wie SSL, fail2ban usw. Da greife ich wieder gerne auf Deine Tutorials zurück Jan :-D

            Wenn’s für Jan OK ist, kann ich gerne verlinken, welche Anleitung mir für mein Vorhaben am Besten weitergeholfen hat.

            Wollte Jan nicht auch mal ein Tutorial machen um die beiden Welten NAS und private cloud zu verheiraten, damit es mal ein perfektes Setup ist, so wie mit den anderen Anleitungen hier?

            Danke für Deine Arbeit Jan, viele Grüße.

          • Jan sagt:

            Hi Alex,

            Links kannst du hier natürlich gern posten, vielleicht ist es ja für den einen oder anderen hilfreich.

            Ich weiß nur nicht, wie ich das in ein Tutorial packen sollte. Hier gibt es einfach zu viele Möglichkeiten, wie man die beiden Themen unter einen Hut bekommen kann. Das hängt dann immer sehr von den individuellen Anforderungen ab.

            Gruß,
            Jan

          • Alexander sagt:

            Ok, gerne. Für alle Interessierten. Um Nextcloud 13 unter OMV – Open Media Vault 4 zu installieren hat mir dieses Tutoral sehr gut weitergeholfen (neben den Tips hier von Jan):
            https://forum.openmediavault.org/index.php/Thread/17738-NextCloud-Installation/
            Und ebenfalls die zugehörige Q&A unter https://forum.openmediavault.org/index.php/Thread/17418-NextCloud-Installation-Q-A/
            Aber Achtung: initial wird dort NC unter OMV 3 gezeigt, man muss das eben umsetzen bzw. sich durch die Posts durchlesen, für den der’s braucht kann es sich aber lohnen.

  • Stefan sagt:

    Hallo Jan.

    Deine Konfiguration von Nginx und Nextcloud funktioniert super.

    Hast du auch schon einmal die XMPP App (JSXC) für Nextcloud ausprobiert? Ich versuche da nämlich gerade, einen Prosody BOSH Server hinter deine Konfiguration zu klemmen. Leider scheitere ich bei einem gewissen Punkt. Vielleicht hast du ja einen Gedankenblitz. :-)

    Der Bosh-Server läuft unter http://localhost:5280/http-bind und ist so auch erreichbar (getestet). Alles, was ich nun möchte ist, dass er unter https://meinedomain/http-bind erreichbar ist. Soweit ich das verstanden habe, muss ich doch in deiner Nginx Konfiguration nur in die Config für das Gateway folgendes unter
    server {
    listen 443 ssl http2;
    server_name meinedomain.de;
    eintragen:
    .
    .
    .
    location /http-bind {
    proxy_pass http://localhost:5280/http-bind;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_buffering off;
    tcp_nodelay on;
    }
    (dieser Schnipsel kommt übrigens aus der Prosody Dokumentation).

    Leider kommt so immer nur ein 404 Fehler. Kannst du dir denken, was ich falsch mache?

    Vielen herzlichen Dank
    Stefan

    • Jan sagt:

      Hi Stefan,

      puh, Prosody BOSH sagt mir leider gar nichts. Hier wäre erst einmal wichtig herauszufinden, welche Datei er hier nicht finden kann (entweder im nginx error.log oder in irgendeinem Logfile von BOSH).
      Ansonsten habe ich hier evtl. einen Hinweis gefunden. Die Umsetzung müsste bei dir dann wie folgt lauten (beachte das proxy_set_header Host):
      location /http-bind {
      proxy_pass http://localhost:5280/http-bind;
      proxy_set_header Host localhost;
      proxy_set_header X-Forwarded-For $remote_addr;
      proxy_buffering off;
      tcp_nodelay on;
      }

      Ansonsten bin ich da nun auch etwas überfragt, sorry.

      Gruß,
      Jan

  • Holger sagt:

    ich stecke fest, klappt alles wunderbar bis zu der stelle wo das zertifikat erstellt werden soll. ubuntu läuft auf einer VM mit eigener ip XXX.XXX.XXX.111

    port 80 ist auf diese umgeleitet genauso 443, der wird mir aber nie als geöffnet angezeigt und cert sagt immer unauthorized invalid response Domain: holle88.ddns.net
    Type: unauthorized
    Detail: Invalid response from
    http://XXXXXXXX.ddns.net/.well-known/acme-challenge/P3x1G3J0P5UL9caBCjdXXfn7QV465hl1625L88p4eOQ:

    404 Not Found

    404 Not Found

    muss ich erst in dem virtuellen server (127.0.0.1:81) einen beliebigen text reinschreiben? er sucht ja anscheinend ein html das er nicht findet….

    • Jan sagt:

      Hi Holger,

      schau doch mal in das nginx Log-File (/var/log/nginx/error.log). Hier sollte man einem Request über Let’s Encrypt/certbot eine Meldung zu finden sein, welche Datei er wo sucht. Das sollte den Hinweis liefern, was an der Konfiguration noch nicht ganz passt.

      Gruß,
      Jan

  • Dirk sagt:

    Hallo Jan,
    ich bin’s mal wieder. Nach zigmaligem kompl. Neubeginn bin ich auf Grund dieser Anleitung tatsächlich bis zum Nextcloud Betrieb gekommen. Ich konnte den externen Speicher nach Deinem Tipp anlegen und habe wegen einer NC Fehlermeldung bezgl. SMB noch den php SMBClient installiert. Hat alles geklappt.
    Nun wieder der Frust: nach ein paar Stunden Pause bekam ich beim Aufruf des NC Login extern wie intern diesen Fehler gemeldet:

    Interner Serverfehler
    Der Server konnte die Anfrage nicht fertig stellen.

    Sollte dies erneut auftreten, senden Sie bitte die nachfolgenden technischen Einzelheiten an Ihren Server-Administrator.

    Weitere Details können im Server-Protokoll gefunden werden.

    Technische Details
    Entfernte Adresse: 31.***.43.***
    Anfragekennung: 5gHhHH9brqzgQWHlHjGT

    Was ist da schief gelaufen? Das Server-Protokoll kann ich irgendwie nicht finden. Ich weiß zwar, das unter www/nextcloud/data/ ein nextcloud.log ist, bekomme es aber nicht geöffnet. Kannst Du bitte weiterhelfen???

    • Michael sagt:

      Hallo Dirk,

      ich versuche es auch mal. Wenn Du die Cloud entsprechend der Anleitung aufgesetzt hast, liegt die log-Datei unter /var/nextcloud_data. Um sie auszulesen, kannst Du in der Konsole folgenden Befehl eingeben: cat /var/nextcloud_data/nextcloud.log

      Dort müsste protokolliert sein, was das Problem ist. Zur Sicherheit kannst Du ja auch mal bei ins error-log von nginx gucken (cat /var/log/nginx/error.log).

      Herzliche Grüße
      Michael

      • Jan sagt:

        Hallo Dirk und Michael,

        genau, ohne ein Log liefert die von NC angezeigte Fehlermeldung im Browser leider keinerlei Info, was hier schief gelaufen sein könnte.
        Daher wirklich mal nach dem NC-Log und dem nginx error-Log suchen.

        Gruß,
        Jan

      • Dirk sagt:

        Hallo Michael+Jan,
        danke für Eure erste Hilfe! Hier sind nun erstmal die Zeilen aus dem Nextcloud-Log:
        {„reqId“:“AaggruqV5U1jFkUPHfM4″,“level“:3,“time“:“2018-07-02T18:30:03+02:00″,“remoteAddr“:““,“user“:“–„,“app“:“PHP“,“method“:“–„,“url“:“–„,“message“:“is_dir(): open_basedir restriction in effect. File(\/media\/hdd\/nextcloud_data\/) is not within the allowed path(s): (\/var\/www\/:\/tmp\/:\/var\/nextcloud_data) at \/var\/www\/nextcloud\/lib\/private\/Files\/Storage\/Local.php#130″,“userAgent“:“–„,“version“:“13.0.4.0″}

        und hier das nginx-error Log:

        2018/07/02 04:32:55 [error] 569#569: *416 access forbidden by rule, client: 117.50.7.159, server: vpn.dl-ms.de, request: „GET / HTTP/1.0“, host: „31.150.43.246:443“
        2018/07/02 04:32:57 [error] 571#571: *417 access forbidden by rule, client: 106.75.2.81, server: vpn.dl-ms.de, request: „GET / HTTP/1.1“, host: „31.150.43.246“

        Zum nginx Log hätte ich noch die Frage, ob irgendwelche „Bösen Buben“ anklopfen. Z.B. die ersten beiden Meldungen „forbidden by rule“ meine ich. Was kann (müsste) man da speziell gegen tun? Fail2ban installieren usw?

        Erstmal danke!
        Dirk

        • Jan sagt:

          Hi Dirk,

          du hast deinen Datenpfad wohl auf einer ext. HDD, oder? Hier musst du den genauen Pfad (also /media/hdd/nextcloud_data) noch in open_basedir mit aufnehmen: Sowohl im vHost von Nextcloud, als auch in der Datei /etc/php/7.2/cli/php.ini. Danach sollte der Fehler verschwunden sein.

          Beim nginx Log sagt er ja nur, dass ein Zugriff blockiert wurde – was ja erst einmal gut ist. Um das dauerhaft zu unterbinden (mit einem teporären/dauerhaften Ban), sollte man über den Einsatz von Fail2ban nachdenken.

          Ich werde gleich mal deine Logs etwas bearbeiten, damit der Kommentar nicht so lang ist. Ich hoffe, das geht in Ordnung.

          Gruß,
          Jan

          • Dirk sagt:

            Hallo Jan,
            hier der Eintrag von Nextcloud log mit folgendem Eintrag open_basedir:

            fastcgi_param PHP_VALUE „open_basedir=/var/www:/tmp/:/var/nextcloud_data:/dev/urandom:/proc/meminfo:/media/hdd/nextcloud_data

            {„reqId“:“yQAVzOSUNPXgzTdjydD3″,“level“:3,“time“:“2018-07-03T09:30:03+02:00″,“remoteAddr“:““,“user“:“–„,“app“:“PHP“,“method“:“–„,“url“:“–„,“message“:“is_readable(): open_basedir restriction in effect. File(\/media\/hdd\/nextcloud_data\/) is not within the allowed path(s): (\/var\/www\/:\/tmp\/:\/var\/nextcloud_data) at \/var\/www\/nextcloud\/lib\/private\/Files\/Storage\/Local.php#170″,“userAgent“:“–„,“version“:“13.0.4.0″}

          • Jan sagt:

            Hi,

            ah ok, hier fehlt wohl noch der zweite Eintrag für open_basedir in der Datei /etc/php/7.2/cli/php.ini (siehe hier).

            Gruß,
            Jan

  • Dirk sagt:

    Hi Jan,
    danke für die Antwort. Egal, welche Version ich in open_basedir schreibe (mit media/hdd/nextcloud_data oder nur /var/nextcloud_data oder beides, es will nicht klappen mit dem Login. Im Gegenteil, wenn ich nur /media/hdd/nextcloud_data eingebe, „läuft“ sich der Browser tot. Habe momentan alles wieder wie vorher und habe jetzt folgendes nextcloud log

    {„reqId“:“rVhr3XSKzHhKh4NuI870″,“level“:3,“time“:“2018-07-03T08:37:45+02:00″,“remoteAddr“:“31.150.45.45″,“user“:“NCAdmin“,“app“:“PHP“,“method“:“GET“,“url“:“\/nextcloud\/apps\/files\/“,“message“:“file_exists(): open_basedir restriction in effect. File(\/media\/hdd\/nextcloud_data\/) is not within the allowed path(s): (\/var\/www:\/tmp\/:\/var\/nextcloud_data:\/dev\/urandom:\/proc\/meminfo) at \/var\/www\/nextcloud\/lib\/private\/Files\/Storage\/Local.php#178″,“userAgent“:“Mozilla\/5.0 (Windows NT 6.1; WOW64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/67.0.3396.87 Safari\/537.36 OPR\/54.0.2952.40 (Edition beta)“,“version“:“13.0.4.0″}
    {„reqId“:“rVhr3XSKzHhKh4NuI870″,“level“:3,“time“:“2018-07-03T08:37:45+02:00″,“remoteAddr“:“31.150.45.45″,“user“:“NCAdmin“,“app“:“index“,“method“:“GET“,“url“:“\/nextcloud\/apps\/files\/“,“message“:“Exception: {\“Exception\“:\“OCP\\\\Files\\\\NotFoundException\“,\“Message\“:\“\“,\“Code\“:0,\“Trace\“:\“#0 \\\/var\\\/www\\\/nextcloud\\\/apps\\\/files\\\/lib\\\/Controller\\\/ViewController.php(131): OC_Helper::getStorageInfo(‚\\\/‘, false)\\n#1 \\\/var\\\/www\\\/nextcloud\\\/apps\\\/files\\\/lib\\\/Controller\\\/ViewController.php(160): OCA\\\\Files\\\\Controller\\\\ViewController->getStorageInfo()\\n#2 [internal function]: OCA\\\\Files\\\\Controller\\\\ViewController->index(“, “, NULL, false)\\n#3 \\\/var\\\/www\\\/nextcloud\\\/lib\\\/private\\\/AppFramework\\\/Http\\\/Dispatcher.php(161): call_user_func_array(Array, Array)\\n#4 \\\/var\\\/www\\\/nextcloud\\\/lib\\\/private\\\/AppFramework\\\/Http\\\/Dispatcher.php(91): OC\\\\AppFramework\\\\Http\\\\Dispatcher->executeController(Object(OCA\\\\Files\\\\Controller\\\\ViewController), ‚index‘)\\n#5 \\\/var\\\/www\\\/nextcloud\\\/lib\\\/private\\\/AppFramework\\\/App.php(115): OC\\\\AppFramework\\\\Http\\\\Dispatcher->dispatch(Object(OCA\\\\Files\\\\Controller\\\\ViewController), ‚index‘)\\n#6 \\\/var\\\/www\\\/nextcloud\\\/lib\\\/private\\\/AppFramework\\\/Routing\\\/RouteActionHandler.php(47): OC\\\\AppFramework\\\\App::main(‚ViewController‘, ‚index‘, Object(OC\\\\AppFramework\\\\DependencyInjection\\\\DIContainer), Array)\\n#7 [internal function]: OC\\\\AppFramework\\\\Routing\\\\RouteActionHandler->__invoke(Array)\\n#8 \\\/var\\\/www\\\/nextcloud\\\/lib\\\/private\\\/Route\\\/Router.php(297): call_user_func(Object(OC\\\\AppFramework\\\\Routing\\\\RouteActionHandler), Array)\\n#9 \\\/var\\\/www\\\/nextcloud\\\/lib\\\/base.php(999): OC\\\\Route\\\\Router->match(‚\\\/apps\\\/files\\\/‘)\\n#10 \\\/var\\\/www\\\/nextcloud\\\/index.php(42): OC::handleRequest()\\n#11 {main}\“,\“File\“:\“\\\/var\\\/www\\\/nextcloud\\\/lib\\\/private\\\/legacy\\\/helper.php\“,\“Line\“:544}“,“userAgent“:“Mozilla\/5.0 (Windows NT 6.1; WOW64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/67.0.3396.87 Safari\/537.36 OPR\/54.0.2952.40 (Edition beta)“,“version“:“13.0.4.0″}

    Kann es daran liegen, das ich in nextcloud bei der Einrichtung vom externen Speicher den Pfad auf /media/hdd/nextcloud_data gelegt habe?

    Gruß, Dirk

    • Jan sagt:

      Hi Dirk,

      dein Log sagt aber nach wie vor, dass hier was in open_basedir fehlt (/media/hdd/…). Diesen Pfad musst du noch im vHost von Nextcloud hinzufügen (bei fastcgi_param PHP_VALUE „open_basedir=…). Nicht vergessen, nginx danach neu zu starten.

      Gruß,
      Jan

      • Dirk sagt:

        Guten Morgen jan,
        wie ich im letzten Post geschrieben hatte, habe ich alle Varianten ausprobiert. Mit, ohne, zusammen; keine Änderung an der Fehlermeldung. NGINX immer neu gestartet.
        LG Dirk

        • Jan sagt:

          Hi Dirk,

          ja, das ist etwas seltsam, weil dein NC-Log sagt hier was anderes.
          Wie schaut bei dir die Zeile fastcgi_param PHP_VALUE „open_basedir=… genau aus? Oder poste am besten Mal die kompletten location-Block für PHP. Irgendwas stimmt hier noch nicht ganz.

          Gruß,
          Jan

          • Dirk sagt:

            sind das die vHost datei oder die beiden PHP.ini dateien?

          • Jan sagt:

            Hi,

            das sind die php.ini Dateien. Sieht so aus, als ob der Eintrag für open_basedir für CLI (also für den Cronjob) noch angepasst werden müsste.

            Gruß,
            Jan

          • Dirk sagt:

            wie kann ich dir die php Dateien schicken? oder welchen Bereich soll ich posten?

          • Jan sagt:

            Hi Dirk,

            nein, schau einfach in die php.ini Dateien und such mal nach „open_basedir“ (suchen mit nano: STRG + W). Hier muss dein Datenverzeichnis auch gelistet sein (zumindest in der CLI-Version der php.ini).

            Gruß,
            Jan

          • Dirk sagt:

            Hi Jan,
            tausend Dank für Deine Antworten!!
            Ich habe in beide php.ini Dateien das Datenverzeichnis entsprechend eingetragen. Fehler ist aber nach wie vor da. Kann man nicht irgendwo die Nextcloud installation löschen und neu installieren? Ist vielleicht ja einfacher als alles neu aufzusetzen…
            Gruß,
            Dirk

          • Jan sagt:

            Hi Dirk,

            das sollte eigentlich auch so passen. Bevor du die Cloud neu aufsetzt, teste doch nochmal folgendes:
            sudo -u www-data touch /media/hdd/nextcloud_data/test.txt
            Wenn der Befehl durchgeht sollte danach eine Datei test.txt im Datenverzeichnis zu finden sein. Wenn nicht, dann check mal den User, unter dem nginx läuft (Datei /etc/nginx/nginx.conf – muss www-data sein).
            Das nächste, was zu kontrollieren wäre: Unter welchem User hast du den Cronjob für Nextcloud angelegt (muss unter dem User www-data angelegt sein).

            Wenn alle Stricke reißen:

            1. Nextcloud-Verzeichnis und Datenverzeichnis löschen.
            2. Datenverzeichnis neu anlegen und entsprechende Rechte setzen.
            3. Datenbank löschen:
              mysql -u root -p
              drop database nextcloud_db;
              exit;
            4. Anschließend kannst du einfach wieder nach dem Tutorial vorgehen (ab hier) . Nur der Datenbank-Benutzer muss nicht mehr angelegt werden, da dieser ja noch existiert. Als Datenverzeichnis beim NC-Setup gibst du dann gleich das Verzeichnis auf der externen HDD an.

            Teste aber erst einmal die anderen Sachen durch, bevor du komplett neu aufsetzt.

            Gruß,
            Jan

          • Dirk sagt:

            Hallo Jan,
            also der Befehl geht scheinbar nicht durch: es kommt die Fehlermeldung

            touch: ‚/media/hdd/nextcloud_data/test.txt‘ kann nicht berührt werden: Keine Berechtigung

            der eingetragene User ist www-data

            den Cron für nextcloud habe ich wie in deiner Anleitung übernommen.

            Ich gebe mich jetzt mal ans löschen und hoffe, das danach alles klappt.

          • Jan sagt:

            Hi Dirk,

            ich denke, dass das auch nach einer Neuinstallation den gleichen Fehler geben dürfte. Wenn der Benutzer www-data keine Berechtigung hat, auf die ext. HDD zu schreiben, dann wird das auch über Nextcloud nicht funktionieren.
            Probier doch mal folgendes:
            cd /media/hdd
            ls -l
            chown -R -v www-data:www-data /media/hdd/nextcloud_data
            ls -l

            Werden die Rechte korrekt gesetzt? Müsstest du eigentlich über den zweiten ls-Befehl sehen.
            Wenn nicht: Was hat die ext. HDD für ein Dateisystem? Kann Linux hier evtl. die Rechte nicht korrekt setzen?

            Gruß,
            Jan

          • Dirk sagt:

            Hi Jan,
            danke für Deinen neuen Hinweis. Hatte heute morgen schon soweit alles gelöscht und will jetzt anfangen zu installieren. Habe natürlich noch die Rechte gesetzt so wie Du geschrieben hast. Ergebnis:

            root@raspberrypi:/media/hdd# chown -R -v www-data:www-data /media/hdd/nextcloud
            der Eigentümer von ‚/media/hdd/nextcloud‘ wurde von root:plugdev in www-data:www-data geändert

            Zur Info: ich hatte mir heute morgen das nextcloudverzeichnis auf der HDD geändert, deshalb nur …nextcloud.
            Ich denke, nun sollte es funktionieren, wenn ich das Verezichnis korrekt benenne und die Rechte entsprechend setze.
            KAnn eigentlich auch das Verzeichnis nextcloud_data unter /var/ liegen und die eigentlichen Daten auf der HDD?

          • Jan sagt:

            Hi Dirk,

            klar, du kannst das „eigentliche“ Datenverzeichnis unter /var/nextcloud_data belassen und die externe HDD als externen Speicher in Nextcloud einbinden. Wenn die User der Cloud dann aber nur auf die externe HDD speichern sollen (also das eigentliche Datenverzeichnis gar nicht sehen sollen), dann kannst du wie hier beschrieben vorgehen („Externer Speicher als Haupt-Speicher“).

            Gruß,
            Jan

          • Dirk sagt:

            Ich noch mal.
            obwohl ich alles geändert habe, ist der Fehler wieder da. Und es liegt wohl tatsächlich daran, das die Rechte nicht richtig gesetzt werden. Ich hatte sie ja gesetzt, Meldung war ja auch ok, aber Kontrolle ls -l sagte etwas anderes.
            Das Laufwerk ist ntfs, meine fstab

            UID=ACB2E063B2E0338C /media/hdd/ ntfs-3g rw,noauto,users,noexec,nls=utf8,umask=007,gid=46 0 0

            vielleicht liegt es daran, das die Rechte nicht gesetzt werden können.

          • Jan sagt:

            Hi Dirk,

            ja, genau das könnte das Problem sein. Linux kann auf NTFS die Rechte nicht richtig setzen. Am besten ein Dateisystem verwenden, mit dem Linux problemlos umgehen kann, (z.B. ext4).
            Ansonsten habe ich hier noch einen Link für dich, der dir vielleicht weiter hilft. Ich selbst habe keine Erfahrungen mit NTFS unter Linux, um das Thema habe ich immer einen Bogen gemacht. Ich selbst nutze nur eine Freigabe unter Windows, um diese als ext. Speicher unter Nextcloud einzubinden. Hier verwende ich einen speziellen User auf der Windows-Maschine, der nur auf dem entsprechenden Verzeichnis alle notwendigen Rechte hat.

            Gruß,
            Jan

  • Stefan Müller sagt:

    Anmerkung zu Fail2ban: Damit missglückte Login-Versuche aufgezeichnet werden, darf das Log-Level von NextCloud nicht über 2 liegen (Konfigurationsdatei /var/www/nextcloud/config/config.php).

    • Dirk sagt:

      Hi Stefan,
      ich habe zwar Fail2ban noch nicht installiert, trotzdem frage ich schon mal:

      was bedeutet das bzw was muss ich bei der Inst beachten?

      LG Dirk

      • Jan sagt:

        Hi,

        bei der Installation musst du nichts weiter beachten. Der Loglevel ist per Default auf 2 eingestellt.
        Wenn du nun weniger loggen wollen würdest (z.B. nur schwere Fehler), dann würdest du den Loglevel in der cinfig.php auf einen Wert größer 2 stellen. In diesem Fall werden fehlgeschlagene Anmeldeversuche nicht mehr geloggt und Fail2ban „läuft ins Leere“.

        Gruß,
        Jan

  • Dirk sagt:

    Hi Jan,
    noch ne Frage: wenn ich von einem Windows Rechner auf die externe Festplatte am Raspberry zugreifen möchte, benötige ich ja Samba. Kann ich das so installieren oder muss/sollte ich dafür auch ein eigenes Verzeichnis und entsprechend einen vhost anlegen weil andere Anwendung?

    • Jan sagt:

      Hi Dirk,

      nein, das muss nicht durch nginx durchgeleitet werden. Das geht dann alles über Samba.
      Wenn du auf diese Weise auf deine Nextcloud-Dateien zugreifen willst: Das geht auch einfacher mit der Einbindung der Nextcloud mittels WebDAV in den Windows-Explorer.

      Gruß,
      Jan

      • Dirk sagt:

        Hi Jan,
        ich habe es endlich geschafft, Nextcloud mit USB Festplatte einzurichten. Ich bin Dir sehr dankbar für die Anregung hinsichtlich externer Speicher in Nextcloud. Der Zugriff scheiterte immer an den Rechten. nun habe ich alles im Lot (hoffe ich, es funktioniert auch nach einem Neustart noch alles)

        Du sagtest, der Zugriff auf diesen Speicher aus dem Windows Netzwerk heraus gehe am einfachsten mittels WebDav. Was muss ich denn anstellen, damit meine lokalen Daten auch lokal bleiben und nicht erst über das Internet geschickt werden? Ich habe versucht, in Windows über Netzlaufwerk verbinden das zu erreichen, scheitere aber an den Benutzereingaben obwohl diese richtig sind.
        Könntest Du hier bitte weiterhelfen??

        • Jan sagt:

          Hi Dirk,

          ich weiß nicht, ob das Einbinden als Netzlaufwerk klappt, wenn man über die LAN-IP geht.
          Wenn du die Two-Factor-Authentication in Nextcloud aktiviert hast, dann wirst du dafür denke ich ein spezielles App-Passwort verwenden müssen.
          Der eigentliche Grund dürfte allerdings das SSL-Zertifikat sein: Dieses ist nicht für die IP ausgestellt und daher wird der Windows-Explorer die Verbindung nicht zulassen. Um das dennoch hinzubekommen, habe ich hier eine Anleitung gefunden, vielleicht klappts ja damit.

          Gruß,
          Jan

          • Dirk sagt:

            Hallo Jan,
            ich habe keine Two-Factor Authentication aktiviert, Das mit dem SSL Zertifikat habe ich zwar gemacht, danke für den Link, aber das ist scheinbar nicht das Problem. Mir wird ja kein Zertifikatsfehler angezeigt. Ich kann mich nur nicht mit meinen Zugangsdaten von Nextcloud bei der Netzwerkverbindung herstellen anmelden.
            Gebe ich den Webdav Link aus NC im Browser direkt ein und melde mich an, kommt dieser Hinweis
            This is the WebDAV interface. It can only be accessed by WebDAV clients such as the Nextcloud desktop sync client.

            Was heißt das???

          • Jan sagt:

            Hi Dirk,

            es wird zwar kein Fehler angezeigt, aber die Verbindung kann nicht aufgebaut werden. Windows quittiert das mit einer nichts sagenden Fehlermeldung. Das Zertifikat passt eben nicht zur IP-Adresse, genau das wird hier das Problem sein.
            Ich denke, dass du hier eine Alternative nutzen musst (z.B. Cyberduck – habe ich gerade mit der lokalen IP probiert und funktioniert problemlos).

            Die Fehlermeldung, wenn du per Browser auf die WebDAV-Adresse zugreifen willst, sagt eigentlich nur aus, dass eine Verbindung mittels Browser nicht zulässig ist, sondern dass ein „echter“ WebDAV-Client genutzt werden muss.

            Edit: Was für dich sicherlich auch interessant ist: Mountain Duck. Damit solltest du das WebDAV-Verzeichis direkt in den Explorer einbinden können.

            Gruß,
            Jan

          • Dirk sagt:

            Danke Jan für die wieder einmal schnelle Hilfe!
            In Windows 10 klappt die Herstellung einer neuen Netzwerkverbindung tadellos und ohne Probleme über den normalen Weg (im WinExplorer/Dieser PC/Netzwerkverbindung hinzufügen)
            Nur Windows7 streikt! Ich bleibe am Ball.
            Liebe Grüße
            Dirk

  • Constantin Coada sagt:

    Hallo Jan,

    und vielen Dank für die Tolle Anleitung. Ich habe auf Anhieb alles hinbekommen, ich ärgere mich zur Zeit nur noch mit den „Hintergrund-Aufgaben“. Ich habe cron eingerichtet, wie beschrieben und scheint es auch zu funktionieren. Nach eine gewisser Zeit aber, bekomme ich die Meldung „Letzte Aufgaben-Ausführung lief vor x Tagen. Etwas scheint falsch zu sein.“ Ich stelle dann die Ausführung auf AJAX um und bekomme zu lesen, dass „Letzte Aufgabe ausgeführt gerade eben.“

    Nach eine Weile erscheinen in das administrativen Frontend 3 rote Zeilen, die besagen, dass die Ausführung des Cron-Jobs über die Kommandozeile nicht möglich war, das data Verzeichnis ungültig sei, ich soll sicherstellen, dass eine Datei .ocdata in das data Verzeichnis sich befindet und dass data Verzeichnis nicht erzeugt werden könnte, der web Server benötigt Schreibrechte auf das root Verzeichnis.

    Kannst Du etwas damit anfangen und mir vielleicht weiterhelfen? Oder kann ich das einfach ignorieren?

    Viele Grüße
    Constantin

    • Jan sagt:

      Hi Constantin,

      ich vermute hier mal, dass PHP (CLI) keinen Zugriff auf das Datenverzeichnis hat (Cron läuft über CLI). Kontrollier doch mal bitte, ob in der Datei /etc/php/7.2/cli/php.ini die Einträge wie hier beschreiben vorhanden sind (insbesondere open_basedir).
      Um zu „sehen“, was der Cronjob macht (oder welche Fehler erscheinen), kannst du auch den Befehl direkt in der Kommandozeile eingeben, der im Cronjob definiert ist.

      Gruß,
      Jan

  • Alex sagt:

    Hallo Jan,

    vielen Dank für diese sehr gelungene und ausführliche Anleitung!
    Ich als „Windows-Kind“ konnte auch durch Deine Kommentare zu den einzelnen Schritten tiefer in mir nicht so geläufige Welten eintauchen.

    Was mich an dem Ganzen sehr gereizt hat ist die Tatsache, Hyper-V als Host zu verwenden. Die hier angelegte VHDX bezieht sich ja auf das Nextcloud-System an sich.

    Ist es nicht auch möglich, über den Hyper-V Manager eine weitere VHDX (dynamisch erweiterbar) mit 4TB anzulegen und als Datenspeicher in der Nextcloud anzubinden?

    Grüße
    Alex

    • Jan sagt:

      Hi Alex,

      ja, das sollte ohne Probleme möglich sein. Eine weitere HDD als VHDX verhält sich ja nicht anders wie z.B. eine externe Festplatte. Hier würde ich dann nur empfehlen, die zweite Festplatte vor dem Nextcloud-Setup einzubinden und das Datenverzeichnis direkt beim Setup auf die zweite HDD zu legen. In diesem Fall bitte nicht nicht vergessen, den entsprechenden Pfad bei open_basedir mit einzutragen, ansonsten wird der Zugriff scheitern.

      Gruß,
      Jan

      • Alex sagt:

        Zu spät… Die Idee ist mir erst in den Sinn gekommen, nachdem das System fertig war. *gg*
        Dann werde ich wohl schauen, wie es nachträglich zu ändern geht.

        Danke Dir für Deine schnelle Antwort!
        VG Alex

  • Jörg sagt:

    Vielen Dank und Respekt für deine tolle Anleitung, hat alles auf Anhieb geklappt.

  • Sascha sagt:

    Hallo Jan,
    die Nextcloud mit deinen Einsellungen funktioniert. Vielen Dank dafür.

    Seit ca. 2 Wochen kann ich aber leider keine Ordner mehr erstellen („Der Ordner konnte nicht erstellt werden „xxx“) und keine Dateien löschen (Fehler beim Löschen der Datei „xxx“). Ich bin mir sicher, dass es an den Schreib- und Leserechten liegt. Diese habe ich meines Wissens nach aber nicht verändert.
    Oder liegt es an Cronjob?

    An was kann das liegen? Vielen Dank für deine Hilfe.

    VG Sascha

    • Jan sagt:

      Hi Sascha,

      ich kann mit nicht vorstellen, dass es am Cronjob liegen könnte.
      Sind im Nextcloud-Log Einträge vorhanden, die den Fehler näher beschreiben?
      Ansonsten vielleicht nochmal explizit die Rechte für das Datenverzeichnis setzen: chown -R www-data:www-data /var/nextcloud_data

      Gruß,
      Jan

      • Sascha sagt:

        Hi Jan, ich denke Redis macht Probleme (hatte eine WebDAV Verbindung im Explorer laufen). Nach dem Trennen der Verbindung und löschen aller Apps solltes es eigentlich funktionieren, was es aber nicht macht:


        :34:55+02:00″,“remoteAddr“:“84.176.144.37″,“user“:“Sascha“,“app“:“PHP“,“method“:“GET“,“url“:“\/nextcloud\/ocs\/v2.php\/apps\/notifications\/api\/v2\/notifications“,“message“:“Redis::connect(): connect() failed: Permission denied at \/var\/www\/nextcloud\/lib\/private\/RedisFactory.php#84″,“userAgent“:“Mozilla\/5.0 (Windows NT 6.3; Win64; x64; rv:61.0) Gecko\/20100101 Firefox\/61.0″,“version“:“13.0.4.0″}
        {„reqId“:“Sa8aMEZayzSV1r2ZI1wU“,“level“:3,“time“:“2018-07-23T20:35:25+02:00″,“remoteAddr“:“84.176.144.37″,“user“:“Sascha“,“app“:“PHP“,“method“:“GET“,“url“:“\/nextcloud\/ocs\/v2.php\/apps\/notifications\/api\/v2\/notifications“,“message“:“Redis::connect(): connect() failed: Permission denied at \/var\/www\/nextcloud\/lib\/private\/RedisFactory.php#84″,“userAgent“:“Mozilla\/5.0 (Windows NT 6.3; Win64; x64; rv:61.0) Gecko\/20100101 Firefox\/61.0″,“version“:“13.0.4.0″}
        {„reqId“:“nl72TuwCJmWgMY3NyyH9″,“level“:3,“time“:“2018-07-23T20:35:55+02:00″,“remoteAddr“:“84.176.144.37″,“user“:“Sascha“,“app“:“PHP“,“method“:“GET“,“url“:“\/nextcloud\/ocs\/v2.php\/apps\/notifications\/api\/v2\/notifications“,“message“:“Redis::connect(): connect() failed: Permission denied at \/var\/www\/nextcloud\/lib\/private\/RedisFactory.php#84″,“userAgent“:“Mozilla\/5.0 (Windows NT 6.3; Win64; x64; rv:61.0) Gecko\/20100101 Firefox\/61.0″,“version“:“13.0.4.0″}
        {„reqId“:“VAwgkvzBR97ad9Ls3hun“,“level“:3,“time“:“2018-07-23T20:36:25+02:00″,“remoteAddr“:“84.176.144.37″,“user“:“Sascha“,“app“:“PHP“,“method“:“GET“,“url“:“\/nextcloud\/ocs\/v2.php\/apps\/notifications\/api\/v2\/notifications“,“message“:“Redis::connect(): connect() failed: Permission denied at \/var\/www\/nextcloud\/lib\/private\/RedisFactory.php#84″,“userAgent“:“Mozilla\/5.0 (Windows NT 6.3; Win64; x64; rv:61.0) Gecko\/20100101 Firefox\/61.0″,“version“:“13.0.4.0″}

        • Jan sagt:

          Hi Sascha,

          ja, sieht so aus, als wenn etwas mit Redis nicht stimmt. Kontrollier doch bitte nochmal, ob alle Schritte genau wie hier beschrieben durchgeführt wurden (besonders der Socket-Name und die Socket-Berechtigungen). Dann nochmal den Redis-Dienst neu starten. Mit Redis ist es so, dass wenn hier eine Kleinigkeit vergessen wurde, dann funktioniert das ganze nicht mehr richtig. Zur Not kannst du natürlich auch Redis in der config.php von Nextcloud deaktivieren.

          Gruß,
          Jan

          • Sascha sagt:

            Danke Jan, sehr peinlich, ich hatte beim „unixsocketperm 770“ einen Zahlendreher drin.

          • Jan sagt:

            Hi Sascha,

            gar nicht peinlich, solche Sachen sind mir am Anfang auch ständig passiert. ;-)
            Zumindest hast du den Fehler schnell gefunden. Ich hoffe, es läuft nun alles wieerwartet.

            Gruß,
            Jan

  • Daniel sagt:

    Finde die Anleitung super. Hab auch schon einiges an Erfahrung mit Linux. Würde es jedoch gern nicht als Subdomain haben sondern direkt im Root und scheitere dabei mit der Umsetzung. Hast du eventuell einen kleinen Tipp wie ich das umsetzen kann?

    • Jan sagt:

      Hi Daniel,

      wenn du Nextcloud direkt im Webroot betreiben möchtest, dann ist das ganze Konstrukt mit Gateway-Host und einzelnen vHost pro Webanwendung eigentlich überflüssig. In diesem Fall kannst du dann einen vereinfachten vHost nehmen. Ein guter Ausgangspunkt ist eine Konfiguration wie im Nextcloud Admin Manual beschrieben („Nextcloud in the webroot of nginx“).

      Gruß,
      Jan

  • Frank sagt:

    Vielen Dank für das tolle Tutorial. Hatte schon nach dem alten alles eingerichtet und nun bei einem Serverumzug auch nach dem neuen alles hin bekommen.

    Ich will nun als Snap Wekan (https://wekan.github.io/) installieren. Kann mir jemand bei der Konfiguration von Nginx helfen? Wie müsste ich die Konfiguration anpassen damit Wekan wie Nextcloud lokal lauscht und alles umgeleitet bekommt.

    • Jan sagt:

      Hi Frank,

      mit Snap habe ich leider bisher noch keine Erfahrungen, aber diese Seite sollte deine erste Anlaufstelle sein. Um das auf das Konstrukt mit Gateway-Host umzusetzen, würde ich mal mit folgenden Ergänzugen im Gateway-Host anfangen:

      Das hier im Gateway-Host ganz oben, da wo auch der php-handler definiert wird.
      map $http_upgrade $connection_upgrade {
      default upgrade;
      '' close;
      }

      Und weiter unten (wo scho der proxy pass für Nextcloud definiert ist):
      location /wekan {
      proxy_pass http://127.0.0.1:3000;
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade; # allow websockets
      proxy_set_header Connection $connection_upgrade;
      proxy_set_header X-Forwarded-For $remote_addr; # preserve client IP

      # this setting allows the browser to cache the application in a way compatible with Meteor
      # on every applicaiton update the name of CSS and JS file is different, so they can be cache infinitely (here: 30 days)
      # the root path (/) MUST NOT be cached
      #if ($uri != '/wekan') {
      # expires 30d;
      #}
      }

      ginx neu starten und ausprobieren. Wenn es nicht klappt, dann die nginx Logs checken und evtl. in der Developer Console des Browsers nachsehen, was mit dem Request genau passiert, bzw. wo es hakt.

      Gruß,
      Jan

  • Marcus sagt:

    Hallo,
    erstmal ein Danke für das tolle Tutorial, allerdings bekommen ich den Nginx-Server mit folgender Meldung nicht mehr gestartet, nachdem der Gateway-Host angelegt wurde. Bis dahin ist alles identisch wie in eurem Tutorial beschrieben.

    ubuntu-server nginx[25062]: nginx: [emerg] „location“ directive is not allowed here in /etc/nginx/conf.d/mydomain.ddnss.de.conf:17
    Aug 05 16:39:28 ubuntu-server systemd[1]: nginx.service: Control process exited, code=exited status=1
    Aug 05 16:39:28 ubuntu-server systemd[1]: Failed to start nginx – high performance web server.

    Ich schätz mal das die „17“ die Zeilennummer in der .conf ist. Dort beginnt die „location“-Sektion:

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

    server {
    listen 80 default_server;
    server_name mydomain.ddnss.de 192.168.178.35;

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

    # Use this if you also want to access the server by local IP:
    #return 301 https://$server_addr$request_uri;
    }
    }

    Aber warum will er die Sektion nicht?

    Gruß Marcus

    • Jan sagt:

      Hallo Marcus,

      ich denke, dass da nach dem proxy_redirect off; eine geschweifte Klammer zu viel ist. Daher hängt der anschließende Block location / im „luftleeren Raum“. Einfach weiter oben eine Klammer entfernen, dann sollte es passen.

      Gruß,
      Jan

      • Marcus sagt:

        Hallo Jan,

        ich hatte es heute nochmal ganz von vorne begonnen und dabei meinen Fehler gefunden. Copy&Paste sollte man vielleicht doch nicht nur ausführen, sondern auch schauen, das man keine Klammern vergisst, bzw. in meinem Fall verschiebt.
        Danke für den Tipp :D

        • Jan sagt:

          Hi Marcus,

          ja, Copy&Paste Fehler schleichen sich leider mal sehr schnell ein und man muss dann erst einmal immer den eigentlichen Fehler suchen.
          Das ist mir aber am Anfang auch immer passiert. Aber irgendwann macht man es sich zur Angewohnheit, über kopierte Teile nochmal drüber zu schauen, dann fallen solche Kleinigkeiten meist doch schnell auf.
          Naja, hauptsache, dass es bei dir nun funktioniert.

          Gruß,
          Jan

          • Marcus sagt:

            Hi Jan,

            noch eine Frage: Ich weiß nicht, seit wann PHP für NC in /dev/urandom Leserechte benötigt, wird jedenfalls jetzt als Warnung angezeigt. In welcher .ini muss das Verzeichnis eintragen, damit das funktioniert? In der CLI-Datei habe ich es schon nachgetragen, als auch bei fpm und in dem Gateway-Host. Aber auch wenn es in allen 3 Dateien steht, wird diese Meldung angezeigt.

          • Jan sagt:

            Hi Marcus,

            genau, das sind die drei Stellen, an den man dies konfigurieren kann: CLI-ini, FPM-ini und die „direkten Anweisungen“ im Gateway-Host. Ich vermute das Problem im Gateway-Host: Bitte nochmal genau kontrollieren und evtl, ein „/“ am Ende anhängen. Anschließend den Webserver neu starten.

            Gruß,
            Jan

  • Dirk sagt:

    Hi Jan,
    mal ne ganz blöde Frage: was muss ich denn wohl machen, damit ich per Filezilla etwas auf den Server schieben kann?
    Irgendwie will das nicht klappen…

    Danke für einen Hinweis.
    Dirk

    • Jan sagt:

      Hi Dirk,

      ich denke mal, es geht dir hier nicht um den Datenaustausch per FTP über das Internet.
      Um nur mal schnell was auf den Server zu schieben, kannst du einfach SFTP (FTP über SSH) nutzen. Das funktioniert mit einem FTP-Client (z.B. FileZilla) out-of-the-box über Port 22 (genau so wie SSH/PuTTY). Der verwendete User braucht in den entsprechenden Verzeichnissen lediglich Schreibrechte.

      Gruß,
      Jan

      • Dirk sagt:

        So dachte ich auch. Ich gehe mit Filezilla (user pi) auf den Server und schiebe rüber. Geht aber nicht. ich hatte dann versucht, den User pi der Gruppe www-data zuzuordnen mit useradd -G www-data pi, user ist schon vorhanden. Und nun bin ich wieder mit meinem Latein am Ende…
        Weißt Du weiter?
        LG Dirk

        • Jan sagt:

          Hi Dirk,

          am schnellsten geht es wohl so, dass du als User pi ein temporäres Verzeichnis anlegst (z.B. mkdir -p /var/temp). In dieses Verzeichnis überträgst du dann die Dateien per SFTP. Anschließend kannst du diese dann auf der Konsole in das richtige Verzeichnis kopieren/verschieben. Am Ende musst du dann evtl. noch die Rechte für den www-data User anpassen (chown -R …).

          Gruß,
          Jan

          • dirk sagt:

            Hallo nochmals,
            könntest Du mir bitte den vollständigen Rechte code schreiben?
            Danke!
            LG Dirk

          • Jan sagt:

            Hi Dirk,

            angenommen, eine Datei (myfile.txt) wurde per SFTP nach /var/tmp kopiert. Dann ganz einfach:
            mv /var/tmp/myfile.txt /var/www/irgendwas/myfile.txt
            chown -R www-data:www-data /var/www/irgendwas/myfile.txt

            Oder wenn alle Dateien eh die gleichen Rechte brauchen:
            chown -R www-data:www-data /var/www/irgendwas

            Gruß,
            Jan

          • dirk sagt:

            Also das Problem ist, das ich die Dateien garnicht hochgeladen bekomme, da scheinbar die Verzeichnisse nicht angelegt werden können.

          • Jan sagt:

            Hi Dirk,

            das Verzeichnis, in das per STFP hineinkopiert werden soll, musst du vorher in der Konsole mit dem entsprechenden User (pi) anlegen. Also:
            mkdir -p /var/tmp
            chown -R pi:pi /var/tmp

            Zumindest auf Ubuntu funktioniert das dann problemlos.

            Gruß,
            Jan

          • Dirk sagt:

            Guten Morgen Jan,
            das Verzeichnis hatte ich schon angelegt. Was fehlte waren die Rechte. Wieder einmal Danke für den Hinweis!!!!

            Liebe Grüße
            Dirk

  • Mike sagt:

    Hallo,
    erstmal ein großes Lob und vielen Dank für dieses Tutorial. Habe Ubuntu 16.04 mit Nextcloud momentan noch laufen und will schon mal parallel auf 18.04 upgraden. Installation von Ubuntu und installtion bis MariaDB hat alles funktioniert, allerdings funktioniert die Installation von PHP7.2 nicht.

    Folgendes bekomme ich ausgegeben:
    root@ubuntuserver1804lts:~# apt-get install php7.2-fpm php7.2-gd php7.2-mysql php7.2-curl php7.2-xml php7.2-zip php7.2-intl php7.2-mbstring php7.2-bz2 php7.2-json php-apcu
    Paketlisten werden gelesen… Fertig
    Abhängigkeitsbaum wird aufgebaut.
    Statusinformationen werden eingelesen…. Fertig
    Paket php-apcu ist nicht verfügbar, wird aber von einem anderen Paket
    referenziert. Das kann heißen, dass das Paket fehlt, dass es abgelöst
    wurde oder nur aus einer anderen Quelle verfügbar ist.

    Paket php7.2-fpm ist nicht verfügbar, wird aber von einem anderen Paket
    referenziert. Das kann heißen, dass das Paket fehlt, dass es abgelöst
    wurde oder nur aus einer anderen Quelle verfügbar ist.

    E: Für Paket »php7.2-fpm« existiert kein Installationskandidat.
    E: Paket php7.2-zip kann nicht gefunden werden.
    E: Mittels des Musters »php7.2-zip« konnte kein Paket gefunden werden.
    E: Mittels regulärem Ausdruck »php7.2-zip« konnte kein Paket gefunden werden.
    E: Paket php7.2-intl kann nicht gefunden werden.
    E: Mittels des Musters »php7.2-intl« konnte kein Paket gefunden werden.
    E: Mittels regulärem Ausdruck »php7.2-intl« konnte kein Paket gefunden werden.
    E: Paket php7.2-mbstring kann nicht gefunden werden.
    E: Mittels des Musters »php7.2-mbstring« konnte kein Paket gefunden werden.
    E: Mittels regulärem Ausdruck »php7.2-mbstring« konnte kein Paket gefunden werden.
    E: Paket php7.2-bz2 kann nicht gefunden werden.
    E: Mittels des Musters »php7.2-bz2« konnte kein Paket gefunden werden.
    E: Mittels regulärem Ausdruck »php7.2-bz2« konnte kein Paket gefunden werden.
    E: Für Paket »php-apcu« existiert kein Installationskandidat.

    Habe auch schon in den Ubuntu Archiv geschaut und anscheinend gibt es einige der Module nicht mehr?
    Kannst du mir dazu eine Lösung nennen?

    Gruß Mike

    • Jan sagt:

      Hi Mike,

      ich habe das soeben nochmal bei mir auf einer Test-VM ausprobiert, hier funktioniert die Installation mit dem exakten Befehl aus dem Artikel:
      apt-get install php7.2-fpm php7.2-gd php7.2-mysql php7.2-curl php7.2-xml php7.2-zip php7.2-intl php7.2-mbstring php7.2-bz2 php7.2-json php-apcu

      Du könntest hier vermutlich auch überall das „7.2“ weglassen, unter 18.04 sind die Pakete „php-fpm“ und „php7.2-fpm“ identisch.
      Hast du evtl. deine sources.list auf irgendeine Art modifiziert, welches diesen Fehler erklären könnte?

      Gruß,
      Jan

      • Mike sagt:

        Nabend Jan,

        lediglich die zuvor hinzugefügten MariaDB und nginx, ansonsten war das System frisch aus dem ei geschlüpft.
        Allerdings bin ich bei der Installation von Ubuntu18.04LTS nach einer Webadresse für den download von updates gefragt worde, was bei deinem Tutorial nicht drin stand. Das habe ich allerdings auf der standardeinstellung gelassen. glaube archive.ubuntu.com/ubunto oder so war das.

        Inhalt der Sources.list:

        deb http://archive.ubuntu.com/ubuntu bionic main
        deb http://archive.ubuntu.com/ubuntu bionic-security main
        deb http://archive.ubuntu.com/ubuntu bionic-updates main

        • Jan sagt:

          Hi Mike,

          hm, da scheint aber irgendwas an deiner sources.list zu fehlen. Auf meinen Maschinen sieht die sehr viel umfangreicher aus.
          Mach mal ein Backup der Datei und passe sie dann wie hier beschrieben an.

          Gruß,
          Jan

          • Mike sagt:

            Wunderbar, jetzt läufts. Nur merkwürdig, Install lief genau nach deiner Anleitung ab. Einzig, dass er bei der Ubuntu-Installation mehr dinge abgefragt hat als beschrieben.

          • Jan sagt:

            Hi Mike,

            danke für den Hinweis. Ich werde den mal nachgehen und die Tage mal eine frische Testmaschine augsetzen um zu sehen, ob sich am Installationsprozess etwas geändert hat.

            Gruß,
            Jan

          • Jan sagt:

            Hi Mike,

            tatsächlich, bei Ubuntu 18.04.1 hat sich das Setup hier und da geändert. Ich habe den Artikel entsprechend angepasst und auch einen Hinweis auf das manuelle „Nachrüsten“ der Paketquellen hinzugefügt.

            Gruß,
            Jan

  • Dirk sagt:

    Hi Jan,
    vielleicht kannst Du mir hierbei helfen:
    ich möchte eine Anwendung neben NC auf dem Webserver laufen lassen. Sie arbeitet wohl PHP orientiert und benötigt SQL Datenbank. Da ich momentan noch nicht weiß, ob spezielle Anforderungen nötig sind, würde ich gerne mit dem „minimalsten“ anfangen. Was muss ich für diese Minimalistik in einem vhost anlegen und was muss im Gateway ergänzt werden? Es handelt sich um eine Genealogieanwendung The Next Generation of Genealogy Sitebuilding, kurz TNG in Version 12. Hier mal ein Link zur Installationsanleitung http://www.robinrichmond.com/family/readme.html

    Vielleicht kannst Du mir ja ergänzende Tips geben, damit ich nach Deiner Anleitung hier fortfahren kann.

    Tausend Dank!!
    Dirk

    • Jan sagt:

      Hi Dirk,

      also die minimale Erweiterung im Gateway-Host müsste in etwa so aussehen:
      location ^~ /tng/ {
      proxy_set_header Host $host;
      proxy_set_header X-Forwarded-Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
      proxy_pass http://127.0.0.1:85;
      proxy_redirect off;
      }

      Dann einen neuen vHost für TNG (wenn die Dateien von TNG unter /var/www/tng zu finden sind):
      server {
      server_name 127.0.0.1;
      listen 127.0.0.1:85;
      root /var/www/;

      location ^~ /tng{
      index index.php;

      location /tng {
      try_files $uri $uri/ /tng/index.php$args;
      }

      location ~ \.php$ {
      try_files $uri =404;
      fastcgi_split_path_info ^(.+\.php)(/.+)$;
      include fastcgi_params;
      fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
      fastcgi_param PATH_INFO $fastcgi_path_info;
      fastcgi_pass php-handler;
      fastcgi_connect_timeout 60;
      fastcgi_index index.php;
      fastcgi_param PHP_VALUE "open_basedir=/var/www/tng:/tmp/
      upload_max_filesize = 1G
      post_max_size = 1G
      max_execution_time = 3600";
      }
      }
      }

      Allerdings sagt mir die Software so gar nichts und mal eben testen kann ich das nicht, da wohl kostenpflichtig.
      Aber ich hoffe mal, dass das für dich ein guter Einstiegspunkt ist.

      Gruß,
      Jan

      • Dirk sagt:

        Guten Morgen Jan,
        super! Ich kann schon mal die readme.html erreichen! Müßen jetzt eigentlich noch spezielle Rechte auf dem Server vergeben werden, damit bei der Abarbeitung der Installation alles klappt? Wenn ja, wie müßte das aussehen?
        Ganz herzlichen Dank!

        Gruß
        Dirk

        • Jan sagt:

          Hi Dirk,

          Nun, der Webserver-User (www-data) wird die Rechte auf das entsprechende Verzeichnis brauchen (chown -R www-data:www-data /var/www/tng).
          Allerdings kann ich dir nicht sagen, ob TNG irgendwelche speziellen Verzeichnisse/Konfigurationen benötigt (z.B. wie bei Nextcloud /nextcloud/.well-known/caldav). Hier kannst du dich vermutlich mit der Developer Console des Browsers (welche URLs werden angefragt) und evtl. auftretenden Fehlern im nginx Log langsam vorarbeiten.

          Gruß,
          Jan

          • Dirk sagt:

            Tausend Dank für Deine unermüdliche Hilfestellung! Ich werde mal am Wochenende, wenn es denn in Strömen regnet, alles probieren.
            LG Dirk

          • Dirk sagt:

            Guten Morgen Jan,
            Hurra, dank Deiner Hilfe und den richtigen Hinweisen klappt bis jetzt alles prima. Nun hätte ich noch ne blöde Frage die Du vielleicht beantworten kannst:
            kann man eine neu einzurichtende Domain, sagen wir „genealogie.de“ auf die jetzige Startseite des Programms, sagen wir „genealogie.test.de/genealogie/index.php“, weiterleiten? Hätte den Vorteil, das jeder viel schneller am Ziel wäre.

            Danke und liebe Grüße
            Dirk

          • Dirk sagt:

            hallo Jan,
            das mit der Weiterleitung einer neuen Domain hat funktioniert. Habe es einfach probiert. Nun dazu folgende Frage: wer diesen Domainnamen eingibt, wird ja entsprechend weitergeleitet. Danach wird ja in der Adressleiste des Browsers die eigentliche Domain bzw Adresse angezeigt. Kann man das irgendwie verhindern, ändern oder so???
            Viele Grüße
            Dirk

          • Jan sagt:

            Hi Dirk,

            jein, du machst wohl einen Redirect, d.h. der Browser wird nun auf eine andere URL verwiesen.
            Damit in der Adressleiste des Browsers auch genealogie.de stehen bleibt, muss dein Server
            1. Auf diese Domain „hören“. Da du ja schon eine Domain für NC hast, geht das nur über einen sog. CNAME-Eintrag. Diesen kannst du dann auf deine NC-Domain setzen. Hier kann ich allerdings nicht sonderlich viel mehr sagen, da dies in der Verwaltungs-UI deines Domain-Providers erledigt werden muss.
            2. Einen zweiten vHost haben, der dann auf die Domain genealogie.de lauscht. Auf diese Weise kannst du die Requests (NC und genealogie.de) auseinanderhalten.

            Das Vorgehen ist etwas komplizierter, wenn es also nicht unbedingt sein muss, würde ich erst einmal bei deiner jetzigen Lösung bleiben.

            Gruß,
            Jan

          • Dirk sagt:

            Guten Morgen Jan,
            vielen Dank für diese einleuchtende Erklärung. Dann bleibt erstmal alles wie es ist. Geht ja auch…
            Liebe Grüße
            Dirk

  • Vinz sagt:

    Hallo Jan
    Vielen Dank für deine tolle Anleitung
    hat mich schon viel weiter gebracht.

    Ich habe jetzt folgendes Problem…
    Ich erhalte einen 403 Fehler

    Ich will statt muster.com/cloud auf cloud.muster gehen.
    den Server hab ich erreicht über die url.

    Ich habe die conf datei bereits ein wenig angepasst, aber bis jetzt ohne erfolg.
    Kann ich dir mein file mal zustellen um es kurz zu überprüfen ?

    Gruss und vielen Dank
    Vinz

    • Jan sagt:

      Hi Vinz,

      weil du in diesem Fall ja nicht über ein Unterverzeichnis am Webserver gehst, kannst du vermutlich die nginx Konfiguration aus dem Nextcloud Admin Manual übernehmen („Nextcloud in the webroot of nginx“).
      Falls das nicht klappt, kannst du mir ja mal deine vHost(s) per Mail schicken, dann schaue ich da mal drüber.

      Gruß,
      Jan

  • Nick sagt:

    Hallo Jan,

    vielen Dank für die wirklich sehr ausführliche und fachlich perfekte Anleitung! Durch deine Erklärungen sind Rückfragen direkt geklärt und ich finde vielen Lesern wird durch das Aufsetzen einer eigenen Cloud und des Servers, Datenbank, etc. erstmal bewusst was wir täglich im Internet nutzen.
    Ich finde der Großteil der Bevölkerung inklusive mir, weiß trotz der täglichen Nutzung viel zu wenig darüber.
    Danke für die „Aufklärungsarbeit“ :D

    Meine Cloud läuft mithilfe deiner Anleitung und ein paar Tipps aus der Anleitung von C-Rieger (https://www.c-rieger.de/nextcloud-installation-guide-debian-stretch/) mittlerweile einwandfrei.

    Ich habe noch einen Tipp bzw. Hinweis für dich mit dem du diese Anleitung eventuell noch verbessern kannst:
    Unter dem offiziellen Repository von NextCloud auf GitHub gibt es mittlereweile ja auch das NextCloudPi Projekt. Mithilfe eines einzigen Befehls (curl) kann auf einem RaspberryPi (oder anderen Boards) direkt NextCloud mit allen benötigten Einstellungen, Datenbank etc. installiert werden. (Wenn auch nicht komplett an die eigenen Bedürfnisse angepasst)

    Auch die Hardenings mit fail2ban, ufw, HTTPS by default, HSTS, ModSecurity WAF, und strong Ciphers sind sehr gut, sodass die Ergebnisse von https://scan.nextcloud.com
    https://www.ssllabs.com/ssltest
    https://securityheaders.io/
    https://observatory.mozilla.org/
    alle sehr gut sind und keine Sicherheitslücken aufweisen.

    Das Installationsskript für NextCloudPi befindet sich in:

    https://raw.githubusercontent.com/nextcloud/nextcloudpi/master/install.sh

    verweist auf:

    https://raw.githubusercontent.com/nextcloud/nextcloudpi/master/lamp.sh

    und auf:

    https://raw.githubusercontent.com/nextcloud/nextcloudpi/master/etc/ncp-config.d/nc-nextcloud.sh

    Dort sind einige interessante Code-Zeilen, die hier vielleicht noch ein paar zusätzliche Tipps und Features einbringen können. (Vielleicht kannst du dir davon noch etwas abschauen).

    Ich würde mich freuen!

    Viele Grüße,
    Nick

    • Jan sagt:

      Hallo Nick,

      danke für das Lob und für den ausführlichen Kommentar mit den Links.
      Ich finde solche Skripts auch immer interessant, die alles, was ich mühsam „per Hand“ beschreibe, einfach automatisch durchführen. Trotzdem bekommt der User hier nur alles „vorgekaut“, wenn es mal irgendwo haken sollte, dann ist guter Rat teuer. Genau deshalb bin ich meiner Linie bisher treu geblieben, alles ausführlich und Schritt für Schritt zu erklären. Jemand, der nicht nur alle Befehle per Copy&Paste übernimmt, hat dabei denke ich noch einen großen Lerneffekt. Genau das ist es ja, was ich mit meinen Artikeln erreichen möchte.
      Trotzdem werde ich mir mal die Skripts anschauen und mit meinen Anleitungen abgleichen, vielleicht ist ja noch was Interessantes dabei. Beim ersten Überfliegen sollten allerdings keine großen Abweichungen dabei sein, außer dass Apache als Webserver verwendet wird. Auf einem RasPi würde ich persönlich immer erst zu nginx greifen, aber das ist sicherlich Geschmacksache.

      Gruß,
      Jan

1 2

Schreibe einen Kommentar

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