DecaTec https://decatec.de Programmieren, Fotografie, Home-Server und einiges mehr Sat, 14 Apr 2018 06:59:45 +0000 de-DE hourly 1 Nextcloud – Tipps & Tricks für Admins (und Benutzer) https://decatec.de/home-server/nextcloud-tipps-tricks-fuer-admins-und-benutzer/ https://decatec.de/home-server/nextcloud-tipps-tricks-fuer-admins-und-benutzer/#comments Sat, 24 Feb 2018 10:34:02 +0000 https://decatec.de/?p=3947 Nextcloud Logo

Nextcloud ist mittlerweile eine stabile und einfach einzurichtende Alternative zu anderen (kommerziellen) Cloud-Anbietern geworden. Gerade ist Version 13 erschienen, die u.a. Unterstützung für End-To-End Verschlüsselung, Anpassungen der Benutzeroberfläche und Verbesserungen in Sachen Performance mit sich bringt. Im Rahmen des Updates meiner Nextcloud-Instanz habe ich mir auch gleich mal die Zeit genommen, einige Punkte anzugehen, damit die Cloud noch mehr meinen eigenen Wünschen entspricht. Hauptsächlich sind dies bestimmte Parameter, die in der Standard-Konfiguration von Nextcloud gar nicht weiter zur Geltung kommen und deshalb leicht zu übersehen sind.

Dieser Artikel soll daher kurz und knapp ein paar Tipps und Tricks zeigen, die Nextcloud-Admins das Leben etwas leichter machen und auch für Cloud-Benutzer einen Mehrwert bieten.

Als Basis dient hier wie immer der Artikel Nextcloud auf Ubuntu Server mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban.

Vordefinierte Dateien für neue Benutzer

Jeder Benutzer, der in der Cloud neu angelegt wird, bekommt beim ersten Einloggen standardmäßig bestimmte Dateien und Verzeichnisse zur Verfügung gestellt. Dies sind im Grunde genommen nur ein paar Multimedia-Dateien (Bilder, Musik, Text) und ein Benutzerhandbuch als PDF.

Standard-Dateien für einen neuen Nextcloud-Benutzer

Standard-Dateien für einen neuen Nextcloud-Benutzer

Diese Dateien sind eher als „Demo-Dateien“ gedacht, um bestimmte Funktionen der Cloud demonstrieren zu können (z.B. die Galerie-Funktion zur Anzeige von Bildern). Im Normalfall wird ein Benutzer diese Dateien einfach löschen bevor er mit der eigentlichen Nutzung der Cloud beginnt. Das einzig Sinnvolle ist hier meiner Meinung nach nur das Manual, weil neue Benutzer hier mehr über Nextcloud und seine Funktionen erfahren können.

Der Nextcloud-Administrator kann allerdings eine eigene Verzeichnis-Struktur festlegen, die für einen neuen Benutzer angelegt werden soll. Möglich ist auch, die automatische Neuanlage von Dateien für neue Benutzer zu deaktivieren.

Die Dateien, die standardmäßig angelegt werden, sind im Verzeichnis /var/www/nextcloud/core/skeleton hinterlegt. D.h. alles, was in diesem Verzeichnis zu finden ist, wird für jeden neuen Benutzer in das eigene User-Verzeichnis kopiert.

Wichtig: Man könnte nun auf die Idee kommen, in dieses Verzeichnis eigene Dateien zu kopieren oder bestimmte Dateien zu löschen. Dies wird jedoch nicht empfohlen, da bei jedem Update von Nextcloud dieses Verzeichnis wieder mit den Standard-Dateien gefüllt wird.

Automatische Anlage von Dateien deaktivieren

Um das automatische Anlegen der Verzeichnisse/Dateien für neue Benutzer komplett zu deaktivieren, reicht es aus, eine kleine Änderung in der Konfigurations-Datei von Nextcloud vorzunehmen:

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

Hier wird am Ende der Datei (aber vor der letzten Klammer) folgendes hinzugefügt:

'skeletondirectory' => '',

Diese kleine Änderung reicht schon aus, dass ein neuer Benutzer nun ohne „Dummy-Dateien“ beginnen kann – die Files-App ist nun standardmäßig leer.

Eigene vordefinierte Dateien hinterlegen

Wenn man als Admin allerdings eigene Dateien für neue Benutzer hinterlegen möchte, sieht das Vorgehen etwas anders aus. In diesem Beispiel möchte ich die Cloud nun so konfigurieren, dass ein neuer User lediglich das Benutzerhandbuch nach dem ersten Login vorfindet.

Dazu wird zunächst einmal ein Verzeichnis außerhalb des Nextcloud-Verzeichnisses erzeugt und nur das Benutzerhandbuch aus dem entsprechenden Verzeichnis hierhin kopiert. Anschließend müssen noch die notwendigen Verzeichnisrechte gesetzt werden.

mkdir -p /var/nextcloud_defaultfiles
cp /var/www/nextcloud/core/skeleton/Nextcloud\ Manual.pdf /var/nextcloud_defaultfiles/Nextcloud\ Manual.pdf
chown -R www-data:www-data /var/nextcloud_defaultfiles/

Nun muss diese Änderung noch der Nextcloud-Installation bekannt gemacht werden. Dazu wird die Konfiguration aufgerufen:

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

Hier fügen wir weiter unten folgende Zeile ein:

'skeletondirectory' => '/var/nextcloud_defaultfiles',

Nun muss das soeben angelegte Verzeichnis noch die in die Liste der Verzeichnisse aufgenommen werden, auf die PHP Zugriff gewährt werden soll. Dazu wird der virtuelle Host von Nextcloud aufgerufen:

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

Hier wird nun das neu angelegte Verzeichnis bei open_basedir hinzugefügt:

fastcgi_param PHP_VALUE "open_basedir=/var/www:/tmp/:/var/nextcloud_data:/dev/urandom:/proc/meminfo:/var/nextcloud_defaultfiles
					upload_max_filesize = 10G
					post_max_size = 10G
					max_execution_time = 3600
					output_buffering = off";

Nachdem dies erledigt ist, wird der Webserver neu gestartet:

service nginx restart

Wenn nun ein neuer Benutzer angelegt wird, erhält dieser nach dem ersten Einloggen nur noch das Nextcloud Benutzerhandbuch angezeigt.

Imagick-Erweiterung für individuelle Favoriten-Icons

Der nächste Tipp bezieht sich auf das sog. Theming, also das Anpassen des Look and Feels der eigenen Cloud. Hier bietet Nextcloud eine eigene Benutzeroberfläche in den Admin-Einstellungen. Hier kann beispielsweise ein eigenes Farbschema oder auch ein individuelles Icon hinterlegt werden.

Theming-Einstellungen in Nextcloud

Theming-Einstellungen in Nextcloud

Allerdings fällt auf, dass sich die hier vorgenommenen Änderungen nicht auf das das sog. Favicon auswirken (das Icon, welches in der Titelleiste des Browsers angezeigt wird). Hier wird immer das Standard-Icon mit dem Nextcloud-Logo auf blauem Grund angezeigt.

Damit ein individuelles Favicon genutzt wird, sind zwei Pakete zu installieren, die diese Funktion „nachrüsten“: Zunächst einmal Imagemagick (kurz: Imagick) und zum zweiten die entsprechende PHP-Erweiterung.

apt-get update
apt-get install imagemagick php-imagick

Nach der Installation sollte der ganze Server neu gestartet werden:

reboot now

Wenn man sich nun neu in der Cloud anmeldet, wird ein individuelles Favicon in der Titelleiste des Browsers angezeigt:

Nextcloud mit Imagick-Erweiterung: Das Favoriten-Icon wird an das Theming angepasst

Nextcloud mit Imagick-Erweiterung: Das Favoriten-Icon wird an das Theming angepasst

Externer Speicher als Haupt-Speicher

Im Normalfall werden die Dateien der Nextcloud-Benutzer auf dem lokalen Speicher des Servers im Verzeichnis /var/nextcloud_data/<User>/files abgelegt. Wenn der Server nur über einen geringen Speicherplatz verfügt, z.B. bei einem Raspberry Pi (Affiliate-Link) mit nur einer kleinen SD-Karte, kann der Cloud-Speicher leicht durch externen Speicherplatz erweitert werden. Dies kann z.B. eine SMB-Freigabe auf einem NAS sein, oder auch ein beliebiger FTP-Server.

Bei Einbindung des externen Speichers (in der Admin-Oberfläche oder in den persönlichen Einstellungen des Benutzers) wird dazu ein Ordner angegeben, in dem der externe Speicher „gemountet“ wird (auf dem Bild rot markiert).

Einbinden externen FTP-Speichers

Einbinden externen FTP-Speichers

Der entsprechende Benutzer sieht dann in diesem Beispiel einen Ordner „FTP“ in der Datei-Übersicht, wohinter sich der externe FTP-Speicher verbirgt. Der Benutzer hat damit die Wahl, ob der seine Dateien lieber lokal auf dem Server speichern möchte (im „Root-Verzeichnis“ in der Files-App) oder lieber den externen Speicher verwenden möchte (im entsprechenden Unterordner).

Wenn – wie bereits erwähnt – der Speicherplatz auf dem lokalen Server sehr begrenzt ist, kann es für den Admin von Vorteil sein, den Zugriff der Benutzer auf den lokalen Speicher des Servers zu unterbinden. Dazu kann in der Admin-Oberfläche unter Verwaltung Externer Speicher beliebiger Speicher eingebunden werden. Der Trick hierbei ist nun die Angabe unter Ordnername. Wenn hier nämlich nur ein Slash („/“) angegeben wird, wird dieser externe Speicher quasi als Root-Verzeichnis der Cloud eingebunden. Der hinzugefügte externe Speicher kann an dieser Stelle auch noch gleich exklusiv für nur einen Benutzer freigegeben werden.

Dieser Benutzer sieht dann unter Dateien nur noch den externen Speicher. Für ihn besteht somit keine Möglichkeit mehr, Dateien oder Verzeichnisse auf dem lokalen Server anzulegen. So kann der Cloud-Administrator auf sehr einfache Weise den lokalen Speicherplatz schonen und die User zur Benutzung des externen Speichers „zwingen“. Trotzdem kann ein Benutzer in seinen persönlichen Einstellungen weitere externe Speicherorte hinzufügen (solange der Admin diese Option für die Benutzer freigeschaltet hat).

Vordefiniertes Verzeichnis für geteilte Dateien

Ein weiteres Detail, was mich schon immer etwas gestört hat, ist die Anzeige von Dateien, die ein Benutzer mit einem anderen User geteilt hat. Diese geteilten Dateien werden dabei nämlich einfach im das Root-Verzeichnis des jeweiligen Benutzers angezeigt (also auf oberster Datei-Ebene). Werden sehr viele Dateien geteilt, geht die Übersicht in der Files-App sehr leicht verloren.

Nextcloud bietet nun die Möglichkeit, einen speziellen Ordner anzugeben, in dem die geteilten Dateien für einen User „gesammelt“ werden. Dazu wird wieder die Konfigurations-Datei von Nextcloud bearbeitet:

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

Hier wird am Ende (aber vor der letzten Klammer) folgende Zeile hinzugefügt:

'share_folder' => '/Mit mir geteilt',

Wenn nun Dateien oder Verzeichnisse unter den Benutzern geteilt werden, landen diese (für jeden Benutzer) automatisch im Verzeichnis Mit mir geteilt. Aus User-Sicht wird mir durch diesen Trick nicht mehr das Root-Verzeichnis bei vielen File-Shares „zugemüllt“ und ich habe eine saubere Trennung zwischen den eigenen Daten und Dateien, die mit mir geteilt sind.

File-Drop Konfiguration für anonyme Uploads

Der letzte Tipp ist eigentlich kein solcher, sondern ein ganz normales Feature von Nextcloud: Anonyme Uploads über einen sog. File-Drop. Allerdings habe ich dieses Feature auch erst vor kurzem entdeckt und bin davon begeistert, daher möchte ich es euch nicht vorenthalten.

Es geht dabei um die Möglichkeit, fremden Benutzern (also Leuten ohne eigenen Account in eurer Cloud) das Hochladen von Dateien zu ermöglichen. Sinn und Zweck des Ganzen ist die Bereitstellung von Dateien für einen angemeldeten Nextcloud-Benutzer. Auf diese Weise kann braucht man beispielsweise keine E-Mails mehr mit großen Dateien im Anhang verschicken.

Um dieses Feature nutzen zu können, legt sich ein Benutzer zunächst einmal ein spezielles Verzeichnis in der Files-App an (z.B. Public Upload). Nun kann in den Details zu diesem Ordner die Teilen-Funktion aktiviert werden (Link teilen). Wählt man nun noch die Option Dateien ablegen (nur Hochladen), hat man damit ein Verzeichnis zum anonymen Hochladen von Dateien erzeugt.

Konfiguration von File-Drop über einen geteilten Link

Konfiguration von File-Drop über einen geteilten Link

Den automatisch von Nextcloud erzeugten Link kann man nun über die kleine Schaltfläche neben dem Textfeld kopieren und an Freunde oder Bekannte weitergeben.

Ruft man diesen Link nun im Browser auf, kann eine Datei hochgeladen werden, die dann dem entsprechenden Benutzer der Cloud zur Verfügung gestellt wird und im extra dafür angelegten Ordner gespeichert wird.

Anonymer Upload mit File-Drop

Anonymer Upload mit File-Drop

Fazit

Der Artikel ist nun doch etwas länger geworden als ursprünglich gedacht. Trotzdem hoffe ich mal, dass ein paar Tipps für Nextcloud-Admins und/oder User dabei waren, die noch nicht hinlänglich bekannt sind.

Habt ihr weitere Tipps und Tricks, um Nextcloud besser an eure eigenen Wünsche und Nutzungsgewohnheiten anzupassen? Hinterlasst mir doch einfach einen Kommentar…

Weiterführende Artikel

Links

]]>
https://decatec.de/home-server/nextcloud-tipps-tricks-fuer-admins-und-benutzer/feed/ 8
Linux: Einfach E-Mails senden mit sSMTP https://decatec.de/home-server/linux-einfach-e-mails-senden-mit-ssmtp/ https://decatec.de/home-server/linux-einfach-e-mails-senden-mit-ssmtp/#comments Sun, 07 Jan 2018 13:10:58 +0000 https://decatec.de/?p=3890 Linux Mail Logo

Oftmals ist es sinnvoll, von einem Linux-System E-Mails zu versenden. Beispielsweise hätte man gern eine Benachrichtigung per Mail, wenn ein wichtiger Cronjob fehlgeschlagen ist, oder eine gewisse IP-Adresse auf Grund von zu vielen ungültigen Anmeldeversuchen durch Fail2Ban gebannt wurde.

Hier wäre es zunächst einmal denkbar, einen MTA (Mail Transfer Agent) wie Sendmail oder Postfix zu verwenden. Dies sind jedoch „echte“ Mail-Server, deren Einrichtung und Konfiguration alles andere als trivial ist. Ebenfalls ist es im Privatumfeld ohne feste IP-Adressen und ordentliche Zertifikate schwer, einen Mail-Server zu betreiben, da solche Server gut für Spam-Mails missbraucht werden könnten und daher von vielen „offiziellen“ Mail-Servern geblockt werden. Besser wäre daher eine leichtgewichtige Alternative zu einem „großen“ MTA.

Update-Historie
  • 08.01.2018:
    • Sicherheit: Setzen der Rechte für /etc/sstmp/ssmtp.comf.

Der einfache Ansatz: E-Mails mit sSMTP verschicken

sSMTP ist kein ausgewachsener MTA (wie eben Sendmail oder Postfix), sondern ein Programm, welches E-Mails von einem System (in diesem Fall einem Linux-PC) entgegennimmt und zu einem vorher konfigurierten „echten“ Mailserver (wie z.B. Google Mail) weiterleitet. Der große Vorteil von sSMTP ist dabei die einfache Konfiguration.

Die gezeigten Schritte für die Installation und Einrichtung von sSMTP beziehen sich auf eine Ubuntu Server Installation (siehe Ubuntu Server als Hyper-V Gastsystem installieren und optimal einrichten). Das Vorgehen ist allerdings auch leicht auf andere Systeme zu übertragen, wie z.B. einem Raspberry Pi (Affiliate Link) mit Raspbian.

Als Beispiel für die genutzte E-Mail-Adresse verwende ich ein Gmail-Konto. Hier kann aber auch ein Konto eines beliebigen anderen Mail-Providers (z.B. GMX, web.de, etc.) oder aber eines der Mail-Postfächer verwenden, die in den meisten Webhosting-Paketen enthalten sind. Ich selbst verwende dazu ein Webhosting-Paket von All-Inkl.com (Affiliate Link) und habe damit sehr gute Erfahrungen gemacht. Beim verwendeten Mail-Postfach ist dabei nur wichtig, dass der Zugriff über SMTP möglich ist (das veraltete POP3 reicht hier nicht aus). Die jeweiligen Zugangsdaten (SMTP-URLs, Ports, etc.) sind den Hilfeseiten des jeweiligen Anbieters zu entnehmen.

Generell ist es eine Überlegung wert, ein neues E-Mail-Konto einzurichten, welches fortan exklusiv für das Senden von E-Mails von dem jeweiligen System genutzt wird. Durch diese saubere Trennung bleibt der alltägliche Mail-Verkehr unbeeinträchtigt. Ebenso sollte man bedenken, dass die E-Mail-Zugangsdaten für sSMTP im Klartext in einer Datei gespeichert werden. Man kann den Zugriff auf diese Datei durch das Setzen entsprechender Berechtigungen etwas einschränken, dennoch hält sich er Schaden in Grenzen, wenn im Worst Case kein aktiv genutztes E-Mail-Konto kompromittiert wird.

Installation und Einrichtung sSMTP

Zunächst folgt erst einmal das obligatorische Update des Systems:

apt-get update && apt-get upgrade -V

Anschließend werden zwei Pakete für sSMTP installiert:

apt-get install ssmtp mailutils

Zur Konfiguration von sSMTP müssen noch Anpassungen an zwei Dateien vorgenommen werden. Zunächst die generelle Einrichtung von sSMTP:

nano /etc/ssmtp/ssmtp.conf

Hier wird das E-Mail-Konto angegeben, welches zum Senden von Mails verwendet werden soll:

# Config file for sSMTP sendmail
#
# The person who gets all mail for userids < 1000
# Make this empty to disable rewriting.
root=USER@gmail.com

# The place where the mail goes. The actual machine name is required no
# MX records are consulted. Commonly mailhosts are named mail.domain.com
mailhub=smtp.gmail.com:587

# Where will the mail seem to come from?
rewriteDomain=gmail.com

# The full hostname
hostname=USER@gmail.com

# Are users allowed to set their own From: address?
# YES - Allow the user to specify their own From: address
# NO - Use the system generated From: address
FromLineOverride=YES

AuthUser=MYUSER
AuthPass=MYPASSWORD
UseSTARTTLS=YES

Alles, was hier groß geschrieben ist (Mail-Adresse, Benutzer und Passwort) muss natürlich individuell angepasst werden. Wenn SSL für die Verbindung zum STMP-Server benötigt wird (dies ist meistens der Fall), muss zusätzlich das Attribut UseSTARTTLS=YES verwendet werden.

Als nächstes erfolgt die Konfiguration, welcher (Betriebssystem-)Benutzer welches Mail-Konto nutzen soll:

nano /etc/ssmtp/revaliases

Hier müssen sämtliche User eingerichtet werden, die nachher E-Mails verschicken sollen. Wenn also auch der Webserver-Benutzer (www-data) Mails verschicken soll, ist dieser hier ebenfalls mit aufzunehmen:

# sSMTP aliases
#
# Format:       local_account:outgoing_address:mailhub
#
# Example: root:your_login@your.domain:mailhub.your.domain[:port]
# where [:port] is an optional port number that defaults to 25.
root:USER@gmail.com:smtp.gmail.com:587
www-data:USER@gmail.com:smtp.gmail.com:587

Test-Mail senden und Verbesserungen

Um nun eine E-Mail zu senden, reicht folgender Befehl aus:

echo "Mail-Inhalt" | mail -s "Betreff" meine-mail-adresse@gmail.com

Dabei ist es egal, wo der Befehl ausgeführt wird. Zum Testen passiert dies der Einfachheit halber direkt auf der Kommandozeile, ein praxisnahes Beispiel wäre das Senden einer Mail, wenn ein Cronjob gelaufen ist. Auch können nun E-Mails in jedem Bash-Skript verschickt werden.

Etwas unschön ist nun, dass beim Empfangen der E-Mail als Absender Benutzer@Computer-Name erscheint. Um hier die richtige Mail-Adresse anzugeben, muss noch eine kleine Anpassung vorgenommen werden:

nano /etc/passwd

Hier muss die Mail-Adresse nach folgendem Schema angegeben werden: Nach dem vierten Doppelpunkt steht der „echte“ Benutzername (quasi in Langform). Hier wird nun einfach die E-Mail-Adresse eingetragen. Das ganze muss nun wieder pro Betriebssystem-Benutzer durchgeführt werden. Hier ein Beispiel für den Benutzer root:

root:x:0:0:USER@gmail.com:/root:/bin/bash

Achtung: Hier wirklich nur die Mail-Adresse nach dem vierten Doppelpunkt eintragen, ansonsten keine Änderungen vornehmen, weil dies sonst weitere Nebenwirkungen haben könnte.

Zu guter letzt setzen wir noch die entsprechenden Rechte auf die Datei ssmtp.conf, damit nicht jeder Zugriff auf die Konfiguration hat:

chown root:mail /etc/ssmtp/ssmtp.conf
chmod 640 /etc/ssmtp/ssmtp.conf

Fazit

Der Artikel hat gezeigt, wie man von einem beliebigen Linux-System einfach und unkompliziert E-Mails versenden kann, ohne einen eigenen Mail-Server aufsetzen und konfigurieren zu müssen. Für den schnellen E-Mail-Versand, z.B. als einfache Benachrichtigung bei bestimmten Ereignissen, ist die gezeigte Lösung allemal ausreichend.

Weiterführende Artikel

Links

]]>
https://decatec.de/home-server/linux-einfach-e-mails-senden-mit-ssmtp/feed/ 20
Windows Server Advanced Power Management: Nun als Open Source auf GitHub verfügbar https://decatec.de/software/windows-server-advanced-power-management-nun-als-open-source-auf-github-verfuegbar/ https://decatec.de/software/windows-server-advanced-power-management-nun-als-open-source-auf-github-verfuegbar/#respond Fri, 29 Sep 2017 16:24:01 +0000 https://decatec.de/?p=3839 Windows Server Advanced Power Management Logo

Bereits 2014 startete ich ein Projekt für erweitertes Energie-Management für Windows (Server): Windows Server Advanced Power Management

Rückblickend ist diese Software eine der Hauptgründe dafür, dass ich diesen Blog überhaupt erst ins Leben gerufen habe, da ich einen „Vertriebskanal“ für das Programm benötigt habe. Dass sich der Blog dann in eine etwas andere Richtung entwickelt hat, steht auf einem anderen Blatt…

Erweitertes Energie-Management für Windows

Wer die Software noch nicht kennen sollte: Gedacht ist das Programm für Rechner, die zwar eine zentrale Aufgabe im Heim-Netzwerk übernehmen (Datengrab, Medienserver, etc.), aber nicht 24/7 laufen sollen. Im Prinzip kann dazu in den Windows-Energieeinstellungen definiert werden, dass ein Rechner nach einer gewissen Zeit der Nichtbenutzung in den Standby wechseln soll. Nun ist dieses Wechseln in den Standby recht rigoros: Selbst, wenn beispielsweise noch aktive Zugriffe auf Netzwerkfreigaben stattfinden, wechselt der PC ohne Vorwarnung in den Standby.

Genau hier setzt das Konzept von Windows Server Advanced Power Management (WSAPM) ein: Mit Hilfe der Software können Richtlinien definiert werden, nach denen der Rechner nicht in den Standby wechseln soll (Zugriff auf Netzwerkfreigaben, CPU-/Netzwerk-Auslastung, laufende Programme, etc.).

Mit der Zeit kamen dann immer weitere Features zu dem Programm hinzu. Mehr Informationen zu Windows Server Advanced Power Management können auf der entsprechenden Projektseite gefunden werden.

WSAPM ist nun als Open Source auf GitHub verfügabr

Nachdem ich nun in einigen Projekten gute Erfahrungen mit GitHub machen konnte, habe ich mich dazu entschieden, das Projekt „Window Server Advanced Power Management“ auch als Open Source auf GitHub zur Verfügung zu stellen.

Das Projekt ist dabei in mehrere GitHub-Repositories unterteilt:

Durch die Verfügbarkeit auf GitHub kann nun jeder einen Blick auf den Sourcecode werfen und natürlich auch aktiv an dem Projekt mitwirken.

Windows Server Advanced Power Management v1.6.0

Im Rahmen der Veröffentlichung als Open Source Projekt ist auch eine neue Version von WSAPM erschienen v1.6.0. Diese Version enthält eigentlich nur einen Hinweis auf die Verfügbarkeit auf GitHub.

Am einfachsten wird das Update über die integrierte Update-Funktion im Programm heruntergeladen und installiert.

Die neue Version kann alternativ auch einfach über eine bestehende Version installiert werden. Die Einstellungen bleiben dabei erhalten.

Weitere Informationen, Download und Benutzerhandbuch:
Windows Server Advanced Power Management

Weiterführende Artikel

Links

]]>
https://decatec.de/software/windows-server-advanced-power-management-nun-als-open-source-auf-github-verfuegbar/feed/ 0
Nextcloud: Online-Office mit Collabora https://decatec.de/home-server/nextcloud-online-office-mit-collabora/ https://decatec.de/home-server/nextcloud-online-office-mit-collabora/#comments Wed, 27 Sep 2017 13:37:51 +0000 https://decatec.de/?p=3808 Nextcloud Logo

Nextcloud bietet schon seit einiger Zeit ein Feature namens Collabora: Durch die gleichnamige Nextcloud-App ist es möglich, Office-Dokumente live in der Cloud über einen Browser zu bearbeiten – auch durch mehrere Nutzer der Cloud gleichzeitig.

Da es nicht einfach mit der Aktivierung der Collabora-App getan ist, zeigt der folgende Artikel, welche Voraussetzungen für Collabora erfüllt sein müssen und wie das Online-Office für Nextcloud installiert und konfiguriert wird.

Als Basis dient wie immer der Artikel Nextcloud auf Ubuntu Server mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban.

Update-Historie
  • 09.03.2018:
    • Hinweis auf Reboot nach Collabora-installation hinzugefügt.

Online-Office in Nextcloud integriert: Collabora

Mit Collabora Online bietet Nextcloud Online-Office-Funktionalitäten, die mancher vermutlich schon von Google Docs kennt: Office-Dateien wie doc, docx, ppt, pptx, xls, xlsx und Open Document Formate können so direkt über einen beliebigen Browser live in der Cloud bearbeitet werden.

Neben der gleichnamigen Nextcloud-App sind hier noch einige weitere Voraussetzungen zu erfüllen. Die eigentliche Arbeit übernimmt hierbei ein Docker-Container. Wer mit den Grundlagen zu Docker noch nicht vertraut ist, sollte sich dazu erst einmal den Artikel Docker auf Ubuntu Server durchlesen. Hier wird neben den Docker-Grundlagen auch die Installation auf einem Ubuntu Server erklärt.

Durch den Einsatz eines Docker-Containers muss für den Einsatz von Collabora recht wenig installiert und konfiguriert werden: Das Docker-Image bringt alle Voraussetzungen und Abhängigkeiten mit, so dass der Administrator sich hier nicht mit dem wie und warum beschäftigen muss. Der Container ist hier eine Art Blackbox, die dafür sorgt, dass das Feature Online-Office in Nextcloud ganz einfach funktioniert.

Collabora installieren und konfigurieren

Genug der Theorie, nun installieren und konfigurieren wir Collabora, so dass Nextcloud um Online-Office-Funktionalitäten erweitert werden kann.

Voraussetzungen

Um Collabora einsetzen zu können, sind einige Voraussetzungen zu erfüllen:

  • Ein System, welches Docker ausführen kann. Wie man Docker auf Ubuntu Server installiert, habe ich bereits im Artikel Docker auf Ubuntu Server erklärt.
  • Eine Subdomain, auf der Collabora später erreichbar ist. Hier reicht es aus, wenn Nextcloud über eine Subdomain (z.B. nextcloudtutorial.goip.de) erreichbar ist.
  • Nextcloud muss über eine gesicherte SSL-Verbindung (HTTPS) angesprochen werden können. Da wir für die Subdomain nextcloudtutorial.goip.de ein gültiges SSL-Zertifikat über Let’s Encrpyt erzeugt haben, ist diese Voraussetzungen in unserem Fall erfüllt.

Collabora installieren

Wenn Docker bereits auf dem System eingerichtet ist und alle Voraussetzungen für Collabora erfüllt sind, dann kann das Docker-Image heruntergeladen werden:

docker pull collabora/code

Der Download dauert eine Weile, da knapp 1 GB an Daten heruntergeladen werden müssen.

Anschließend wird der Collabora-Container gestartet:

docker run -t -d -p 127.0.0.1:9980:9980 -e 'domain=nextcloudtutorial\\.goip\\.de' --restart always --cap-add MKNOD collabora/code

Diese Anweisung sorgt dafür, dass der Collabora-Container beim Systemstart immer automatisch geladen wird. Alle Anweisungen an Port 9980 werden an den Container weitergeleitet. Wichtig ist hier auch die Subdomain, unter der Collabora später erreichbar sein soll. Wichtig: Alle Punkte müssen in der Domain mit einem doppelten Backslash escaped werden (also nextcloudtutorial.goip.de wird zu nextcloudtutorial\\.goip\\.de)

Damit der Webserver nginx Anweisungen an den Collabora-Container weiterleiten kann, müssen folgende Anweisungen in den Gateway-Host von nginx hinzugefügt werden (im server-Block für HTTPS). Hier helfen uns die Reverse-Proxy-Fähigkeiten von nginx:

#
	# Collabora
	#
	# static files
    location ^~ /loleaflet {
        proxy_pass https://localhost:9980;
        proxy_set_header Host $http_host;
    }

    # WOPI discovery URL
    location ^~ /hosting/discovery {
        proxy_pass https://localhost:9980;
        proxy_set_header Host $http_host;
    }

   # main websocket
   location ~ ^/lool/(.*)/ws$ {
       proxy_pass https://localhost:9980;
       proxy_set_header Upgrade $http_upgrade;
       proxy_set_header Connection "Upgrade";
       proxy_set_header Host $http_host;
       proxy_read_timeout 36000s;
   }
   
   # download, presentation and image upload
   location ~ ^/lool {
       proxy_pass https://localhost:9980;
       proxy_set_header Host $http_host;
   }
   
   # Admin Console websocket
   location ^~ /lool/adminws {
       proxy_pass https://localhost:9980;
       proxy_set_header Upgrade $http_upgrade;
       proxy_set_header Connection "Upgrade";
       proxy_set_header Host $http_host;
       proxy_read_timeout 36000s;
   }

Nach der Installation von Collabora sollte man das System nochmals komplett neu starten. Wenn dieser Punkt ausgelassen wird (oder nur der Webserver neu gestartet wird), dann führt dies in einigen Fällen danach zu Problemen.

reboot now

Danach ist die Installation von Collabora abgeschlossen.

Collabora in Nextcloud einrichten

Weiter geht es in Nextcloud. Einloggen als Admin und anschließend kann unter Apps Collabora Online aktiviert werden:

Collabora Online App im Nextcloud App Store

Collabora Online App im Nextcloud App Store

Bevor Collabora nun verwendet werden kann, muss die App noch konfiguriert werden. Dazu wechseln wir in den Admin-Bereich von Nextcloud. Unter Collabora Online muss hier noch die URL eingetragen werden, unter der Collabora läuft. Dies ist die gleiche URL, wie wir beim Starten des Docker-Containers angegeben haben (inklusive Protokoll, also https://nextcloudtotorial.goip.de):

Collabora Konfiguration in Nextcloud

Collabora Konfiguration in Nextcloud

Nun können Office-Dateien (z.B. docx oder xlsx) in der Dateien-App von Nextcloud geöffnet und bearbeitet werden:

Online-Office mit Collabora unter Nextcloud

Online-Office mit Collabora unter Nextcloud

Hier ist auch die gleichzeitige Bearbeitung durch mehrere Nutzer der Cloud möglich.

Collabora updaten

Von Zeit zu Zeit werden Updates für das Collabora-Image veröffentlicht (dies sollte im Nextcloud-Blog angekündigt werden). Das Update des Images wird dann folgendermaßen durchgeführt:

Zunächst wird das neue Image heruntergeladen:

docker pull collabora/code

Anschließend werden mit diesem Befehl alle laufenden Docker-Container aufgelistet:

docker ps

Hier sollte dann ein Image „collabora/code“ mit entsprechender Container-ID zu finden sein. Dies ist dann noch der alte Container. Dieser muss dann zunächst einmal gestoppt entfernt werden. Dies passiert mittels der Container-ID:

docker stop <Container-ID>
docker rm <Container-ID>

Die recht lange Container-ID muss hier übrigens nicht immer komplett eingegeben werden, meist reichen die ersten vier Zeichen der ID.

Zum Schluss wird der neue Container wie gewohnt gestartet:

docker run -t -d -p 127.0.0.1:9980:9980 -e 'domain=nextcloudtutorial\\.goip\\.de' --restart always --cap-add MKNOD collabora/code

Anschließend sollte Collabora in der neuesten Version laufen.

Fazit

Mit Collabora kann Nextcloud in wenigen Schritten um Online-Office-Funktionalitäten erweitert werden. Dadurch können Office-Dateien direkt und „live“ in der Cloud bearbeitet werden, ohne dass diese zuvor heruntergeladen werden müssen. Durch den Einsatz eines Docker-Images für Collabora geht die installation des Features schnell und einfach von der Hand.

Weiterführende Artikel

Links

]]>
https://decatec.de/home-server/nextcloud-online-office-mit-collabora/feed/ 41
Docker auf Ubuntu Server https://decatec.de/home-server/docker-auf-ubuntu-server/ https://decatec.de/home-server/docker-auf-ubuntu-server/#comments Tue, 26 Sep 2017 17:38:55 +0000 https://decatec.de/?p=3760 Docker Logo

Jeder hat bestimmt schon mal von Docker gehört. Laut Wikipedia ist Docker eine Open-Source-Software, mit deren Hilfe Anwendungen mittels Betriebssystem-Virtualisierung in Containern isoliert werden kann. Zweck des Ganzen ist hauptsächlich die vereinfachte Bereitstellung von Anwendungen. Alles klar? Der Nicht-Informatiker wird nun große Augen machen, da das Ganze doch sehr schwammig klingt.

Der folgende Artikel soll daher in einfachen Worten erklären, was Docker eigentlich ist und wofür man es einsetzen kann. Anschließend wird die Installation von Docker Schritt für Schritt auf einem Ubuntu Server erklärt.

Was ist Docker?

Zunächst soll in einfachen Worten erklärt werden, was Docker eigentlich ist. Wer Docker bereits kennt, kann diesen Abschnitt getrost überspringen und direkt zur Installation unter Ubuntu Server springen.

Vereinfacht gesagt, adressiert Docker ein altes Problem der IT: Bei der Programmierung von Software ist man immer mit gewissen Abhängigkeiten konfrontiert. So wird beispielsweise zur Ausführung eines Java-Programms die Java-Laufzeitumgebung benötigt. Ein anderes Beispiel ist PHP: Ohne einen Webserver sind PHP-Skripte nahezu nutzlos. Dem Software-Entwickler sind diese Abhängigkeiten bekannt und er hat seine Entwicklungs-Maschine entsprechend eingerichtet. Wenn die erstellte Software nun an Kollegen oder Kunden verteilt wird, kann es passieren, dass benötigte Module, Laufzeitumgebungen oder Treiber nicht auf jedem System vorhanden sind. Hier müssen die Abhängigkeiten dann mühevoll aufgelöst und die entsprechenden Module/Laufzeitumgebungen/Treiber nachinstalliert werden, was durchaus lästig sein kann.

Eine mögliche Lösung des Problems ist die Virtualisierung von Systemen. Dazu ein Praxisbeispiel: Wer meinen Blog verfolgt, dem ist sicher aufgefallen, dass ich mich auch mit virtualisierten Systemen beschäftige. Artikel wie Ubuntu Server als Hyper-V Gastsystem installieren und optimal einrichten und Nextcloud auf Ubuntu Server mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban lassen erahnen, dass ich eine virtuelle Linux-Maschine unter Windows betreibe, die für das Hosting meiner eigenen Cloud verantwortlich ist. Warum wähle ich diesen vermeintlich umständlichen Weg?
Nextcloud ist eine PHP-Anwendung. Für PHP benötige ich einen Webserver. Unter Windows gibt es im Prinzip nur IIS (ja, es gibt auch Installer für Apache oder nginx, allerdings ist das unter Windows kein Spaß, da diese Server aus dem Linux-Umfeld kommen und nicht wirklich unter Windows zu Hause sind). IIS arbeitet allerdings nur sehr schlecht mit PHP zusammen, was die Nextcloud-Entwickler dazu veranlasst hat, Windows als Server-Plattform nicht zu unterstützen. Also bestehen vereinfacht gesagt folgende Abhängigkeiten: Nextcloud > PHP > Webserver (Apache, nginx, etc.) > Linux. Um die eigenen Cloud zum Laufen zu bekommen, benötige ich also ein Linux-System, welches ich kurzerhand mittels Hyper-V unter Windows virtualisieren kann. Diese virtuelle Maschine dient dann ausschließlich zum Hosten der eigenen Cloud.

Allerdings bedeuten virtuelle Systeme einen erheblichen Aufwand. Siehe dazu folgende Abbildung, die den schematischen Aufbau eines Systems zur Virtualisierung zeugt:

Virtualisierung mittels virtueller Maschinen

Virtualisierung mittels virtueller Maschinen

Direkt auf der Server-Hardware läuft dabei das Host-Betriebssystem. Der sog. Hypervisor sorgt für die Abstraktion der eigentlichen Hardware für virtuelle Systeme. Darauf bauen dann VMs mit ihren jeweiligen Gast-Betriebssystemen auf. Auf diesen Gast-Systemen sind dann alle Abhängigkeiten (Libraries/Binaries) installiert, die die jeweiligen Anwendungen zur Ausführung benötigen.

Vorteil: Die virtuellen Maschinen sind voneinander und vom Host-Betriebssystem getrennt und können unterschiedliche Anwendungsfälle abdecken.

Nachteil: Der Betrieb von (mehreren) virtuellen Maschinen ist ressourcenintensiv. Auch wenn leistungsstarke Hardware zum Einsatz kommt und die VMs auf SSDs laufen, dauert es eine Zeit lang, bis eine virtuelle Maschine gebootet wurde und ihren Aufgaben nachgehen kann. Darüber hinaus ist ein erhöhter administrativer Aufwand notwendig, da neben dem Host-Betriebssystem auch die virtuellen Maschinen getrennt voneinander verwaltet werden müssen (z.B. Versorgung mit Updates).

Docker ist auch eine Art Virtualisierung, dennoch ist der Grundgedanke hier ein anderer: Software mitsamt allen Abhängigkeiten wird hier in einem „Container“ zusammengefasst. Einen Container kann man sich dabei wie eine Zip-Datei vorstellen, in der alles enthalten ist, was zur Ausführung der Software benötigt wird. Allerdings müssen die Inhalte nicht entpackt und installiert werden, sondern der Container kann als Einheit verwendet werden, der seine Aufgaben durch die Ausführung mit Docker einfach erledigen kann.

Folgende Abbildung zeigt schematisch den Einsatz von Containern:

Virtualisierung mittels Containern

Virtualisierung mittels Containern

Wie man sieht, sind hier weniger Komponenten im Einsatz: Es wird beispielsweise kein Hypervisor benötigt, da die Container direkt auf dem Host-Betriebssystem ausgeführt werden. Dies macht auch den Einsatz von Gast-Betriebssystemen überflüssig.

Vorteile: Ein Container ist sehr leichtgewichtig, da dieser direkt auf dem unterliegenden Betriebssystem ausgeführt wird. Lediglich alle Abhängigkeiten und die benötigten Anwendungen selbst sind in den Containern enthalten. Dies macht sich u.a. bemerkbar, dass Container nach dem Start über Docker sofort (innerhalb weniger Sekunden) einsatzbereit sind. Dennoch sind die einzelnen Container voneinander getrennt (Sandboxing).

Das ist eigentlich alles, was sich hinter der „Magie“ hinter Docker verbirgt. Am Ende des theoretischen Teils des Artikels sollen noch einige Begrifflichkeiten aus der Docker-Welt erklärt werden, auch die man immer wieder stoßen wird, wenn man sich mit dem Thema beschäftigt:

  • Image: Ein Image stellt eine Art Template dar. Dieses Template beinhaltet alle Abhängigkeiten der Software, die später ausgeführt werden soll. Dies könnte beispielsweise ein Betriebssystem mitsamt Webserver, PHP und WordPress sein. Ein Image ist vergleichbar mit einem ISO-Image einer DVD.
  • Dockerfile: Ein Dockerfile ist zunächst eine reine Textdatei, die deklarativ beschreibt, was in einem Docker-Image enthalten ist. Mehr Informationen zu Dockerfiles sind in der Dockerfile reference zu finden. Beispiele für Dockerfiles kann man sich in diesem GitHub-Repository ansehen.
  • Container: Ein Container ist eine lauffähige Instanz eines Images, oder besser gesagt ein Image, welches gerade ausgeführt wird. Dies ist vergleichbar mit einer DVD, die aus einem ISO-Image gebrannt wurde und in ein DVD-Laufwerk eingelegt wurde.
  • Docker Hub:  Ein Webdienst, der vorgefertigte Docker-Images enthält. Diese Images können später ganz einfach durch Docker heruntergeladen und ausgeführt werden.

Installation von Docker auf Ubuntu Server

Nun geht es an die Praxis: Die Installation von Docker unter Ubuntu Server. Als Basis dienst hier Ubuntu Server 16.04 LTS.

Docker ist zunächst in zwei Ausprägungen erhältlich: Die kostenlose Community Edition (CE) und die kostenpflichtige Enterprise Edition (EE). Wir beschäftigen uns hier mit der Community Edition.

Wenn alte Versionen von Docker bereits installiert sind, sollten diese zunächst entfernt werden:

apt-get remove docker docker-engine docker.io

Die empfohlene Vorgehensweise ist die Installation aus dem offiziellen Docker-Repositories. Dazu wird das System erst einmal auf den aktuellen Stand gebracht:

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

Als nächstes werden die Pakete installiert, die für den weiteren Verlauf benötigt werden:

apt-get install apt-transport-https ca-certificates curl software-properties-common

Nun wird der GPG-Key von Docker dem System bekannt gemacht:

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

Anschließend wird das Docker-Repository für apt-get hinzugefügt. Zu beachten ist hier die Architektur des Systems. Der folgende Befehl fügt das Repository für 64 Bit Systeme hinzu. Wenn eine andere System-Architektur zum Einsatz kommt (z.B. bei einen Raspberry Pi), dann muss hier ein anderes Repository angegeben werden (siehe Get Docker CE for Ubuntu). Wir verwenden hier auch den Stable-Release, damit nur stabile Versionen von Docker zum Einsatz kommen:

add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"

Nach dem Hinzufügen des Repositories muss noch ein Update der Paketquellen durchgeführt werden:

apt-get update

Anschließend kann Docker in der Community Edition installiert werden:

apt-get install docker-ce

Nach diesen Schritten ist Docker einsatzbereit. Testen kann man die Installation durch das Ausführen eines Test-Images, welches lediglich eine Statusmeldung über Docker ausgibt:

docker run hello-world

Docker ist einsatzbereit

Docker ist einsatzbereit

An dieser Stelle noch ein Hinweis: Wenn Docker Images heruntergeladen und ausgeführt werden, findet man diese im Verzeichnis /var/lib/docker. Auch wenn Docker später wieder deinstalliert werden sollte, bleiben auf dem System bereit gestellte Container in diesem Verzeichnis bestehen.

Fazit

In diesem Artikel wurden zunächst einmal die Grundlagen von Docker ermittelt. Anschließend wurde gezeigt, wie man Docker mit wenigen Schritten unter Ubuntu Server installieren kann.

Nach der Docker-Installation kann das System nun eingesetzt werden. In einem bald folgenden Artikel wird ein praktisches Beispiel folgen, wie Docker verwendet werden kann, um Nextcloud um sinnvolle Funktionen zu erweitern (Stichwort: Collabora).

Weiterführende Artikel

Links

]]>
https://decatec.de/home-server/docker-auf-ubuntu-server/feed/ 4
Nextcloud: Updates richtig durchführen https://decatec.de/home-server/nextcloud-updates-richtig-durchfuehren/ https://decatec.de/home-server/nextcloud-updates-richtig-durchfuehren/#comments Wed, 20 Sep 2017 13:46:56 +0000 https://decatec.de/?p=3637 Nextcloud Logo

Wer seine private Cloud mit Nextcloud betreibt, muss sich natürlich auch um Updates der Cloud-Software kümmern. Der folgende Artikel zeigt, welche Möglichkeiten es gibt, die eigene Cloud zu aktualisieren und welche Methode in welcher Situation gewählt werden sollte.

Als Grundlage dient der Artikel Nextcloud auf Ubuntu Server mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban (gerade bzgl. der Angabe von Dateipfaden). Doch auch bei anderen Konfigurationen (z.B. Apache als Webserver) ist das Vorgehen hier nahezu identisch.

Update-Historie
  • 23.09.2017:
    • Hinweis auf Anpassung der Verzeichnis-Berechtigungen entfernt. Dies wird seitens der Nextcloud-Dokumentation nicht mehr empfohlen (siehe hier).
    • Anleitung für manuelles Update von Nextcloud-Apps entfernt: Benötigte App-Updates werden im Rahmen des Nextcloud-Updates automatisch ausgeführt.

Nextcloud Release Channels – oder: wann sind Updates verfügbar?

Nextcloud verteilt die Updates der Cloud-Software über Release Channels. Dabei kann der Administrator der Cloud in den Einstellungen festlegen, welcher Entwicklungsstand zum Einsatz kommen soll. Hier gibt es folgende Möglichkeiten:

  • Production: Stabilster Entwicklungszweig, der weitgehend fehlerfrei laufen sollte. Neuerungen werden hier nur nach ausgiebigem Test und Verfügbarkeit in den anderen Release Channels zur Verfügung gestellt. Dies bedeutet auch, dass Versionen im Production Channel bereits etwas älter sein können. Dieser Channel wird für Produktiv-Umgebungen empfohlen, wo Stabilität eine der wichtigsten Anforderungen an die Cloud darstellt.
  • Stable: Stabile Versionen, die sich bereits im Beta-Test bewährt haben. In diesem Channel befinden sich im Allgemeinen die Versionen, die auch auf der Nextcloud Download-Seite zu finden sind. Dies ist der empfohlene Channel für die meisten Benutzer.
  • Beta: Über diesen Channel werden Beta-Versionen und Release Candidates verteilt. Hier sind Fehler in der Software nicht auszuschließen. Nur empfohlen für Leute, die einen Blick auf zukünftige Versionen werfen wollen, bzw. aktiv testen und ggf. Bugs erfassen möchten.
  • Daily: Dieser Channel stellt sog. Daily-Builds bereit, dies sind also immer tagesaktuelle Versionen von Nextcloud. Dieser Channel ist eher für Entwickler gedacht uns sollte daher nicht von normalen Benutzern verwendet werden.

Für den Heimgebrauch ist der Stable Release Channel meist die richtige Wahl. Dieser ist nach einer frischen Nextcloud-Installation auch direkt aktiv. Wenn nun ein neues Update verfügbar ist, wird dies in der Admin-Oberfläche der Cloud angezeigt.

Hinweis: Bei einem Update einer Hauptversion (z.B. Nextcloud 11 auf Nextcloud 12) kann es eine Weile dauern, bis das Update als verfügbar angezeigt wird, auch wenn die neue Version bereits offiziell veröffentlicht wurde.

Backup

Bevor ein Update von Nextcloud durchgeführt wird, sollte ein Backup der kompletten Cloud angefertigt werden. Somit ist man immer auf der sicheren Seite, selbst wenn beim Update etwas schiefgehen sollte.

Wie man Nextcloud am besten sichern (und im Falle des Falles auch wiederherstellen kann), beschreibt der Artikel Nextcloud: Backups erstellen und wiederherstellen – manuell oder per Skript: Neben der manuellen Ausführung von Backups mit wenigen Befehlen auf der Kommandozeile wird hier ebenso die automatische Sicherung (oder Wiederherstellung) per Bash-Skript beschrieben.

Auch wenn das Anfertigen von Backups eher eine lästige Aufgabe zu sein scheint, sollte man diesen Schritt nicht auslassen! Besser, man hat ein Backup zu viel gemacht, als im Ernstfall ohne jegliches Backup dazustehen.

Update durchführen

Es gibt generell drei Möglichkeiten, ein Update der eigenen Cloud durchzuführen. Die einfachste Lösung ist hier, einfach den Web-basierten Updater zu verwenden. Der Updater kann ebenfalls über die Kommandozeile ausgeführt werden. Nur in Situationen, in den der Updater nicht verwendet werden kann, sollte man ein manuelles Update in Betracht ziehen.

Updates mit dem Web-basierten Updater

Der Updater ist direkt in Nextcloud integriert und übernimmt alle Aufgaben, um ein Update durchzuführen. Diesen ruft man über die Admin-Oberfläche „Verwaltung“ auf (über die Schaltfläche Updater öffnen).

Ein Update für Nextcloud ist verfügbar

Ein Update für Nextcloud ist verfügbar

Hier werden zunächst ein paar Informationen angezeigt (aktuell installierte Version, Update-Version und Link zum Update-Archiv). Angestoßen wird das Update durch den Button Start update.

Das Update auf die neue Version kann durchgeführt werden

Das Update auf die neue Version kann durchgeführt werden

Der Updater prüft daraufhin alle Voraussetzungen und lädt das Update herunter.

Hinweis: Sollte bei diesem Schritt eine Fehlermeldung angezeigt werden, dass Schreibrechte auf bestimmte Verzeichnisse/Dateien fehlen, dann stimmen die Verzeichnis-Berechtigungen nicht. Falls dies der Fall ist, müssen diese nochmals explizit gesetzt werden:

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

Am Ende wird man gefragt, ob der Maintenance-Mode aktiv bleiben soll. Da wir das Update direkt in der Weboberfläche durchführen, kann der Maintenance-Mode hier gleich deaktiviert werden (No (for usage of the web based updater)).

Nachdem der Updater seine Arbeit verrichtet hat, wird man nach einem Klick auf die Schaltfläche Go back to your Nextcloud instance to finish the update auf die eigene Nextcloud-Seite weitergeleitet. Hier wird durch den Button Aktualisierung starten das eigentliche Update durchgeführt.

Nach dem Updater kann die Aktualisierung gestartet werden

Nach dem Updater kann die Aktualisierung gestartet werden

Nach einer kleinen Wartezeit sollte alles erledigt sein und man wird automatisch auf die vertraute Nextcloud-Weboberfläche weitergeleitet.

Den Updater über die Kommandozeile verwenden

Die zweite Möglichkeit besteht darin, den Updater über die Kommandozeile auszuführen. Im Grunde genommen sind die Schritte hier identisch zum Web-basierten Updater.

Dazu wechselt man in das entsprechende Verzeichnis und führt den Updater mit dem Webserver-User (www-data) aus:

cd /var/www/nextcloud/updater
sudo -u www-data php updater.phar

Wieder wird die aktuell installierte Version und das verfügbare Update angezeigt.

Nextcloud Updater über die Kommandozeile

Nextcloud Updater über die Kommandozeile

Mit der Bestätigung mit „y“ beginnt der Updater mit dem Download und der Überprüfung der Voraussetzungen. Anschließend wird gefragt, ob man das Update direkt ausführen möchte (Should the „occ upgrade“ command be executed?). Dies kann wieder mit „y“ bestätigt werden.

Am Ende erfolgt noch die Frage, ob der Wartungsmodus aktiviert bleiben soll. In diesem Fall sollte man mit „n“ den Maintenance-Mode deaktivieren, damit die Cloud nach dem Update wieder direkt einsatzbereit ist.

Deaktivierung des Wartungsmodus nach erfolgreichem Update

Deaktivierung des Wartungsmodus nach erfolgreichem Update

Manuelles Update

Wenn der Einsatz der Updater-App nicht möglich sein sollte, dann bleibt als letzte Möglichkeit immer das komplett manuelle Update. Dies muss auch durchgeführt werden, wenn man Updates sofort erhalten möchte, ohne auf die Freigabe in den entsprechenden Release-Channels warten zu müssen.

  1. Wartungsmodus aktivieren: Zunächst wird die Cloud in den Maintenance-Modus versetzt. Dies sorgt dafür, dass während des Updates kein Benutzer mehr aktiv auf der Nextcloud arbeiten kann:
    cd /var/www/nextcloud
    sudo -u www-data php occ maintenance:mode --on
  2. Webserver stoppen: Als nächstes wird der Webserver gestoppt:
    service nginx stop
  3. Nextcloud-Verzeichnis umbenennen: Damit keine „Altlasten“ von der aktuellen Version mitgenommen werden, wird das alte Nextcloud-Verzeichnis umbenannt (damit diese später einfach gelöscht werden kann). Diesen Ordner bitte nicht sofort löschen, da bestimmte enthaltene Dateien nachher noch benötigt werden!
    cd /var/www
    mv nextcloud nextcloud_alt
  4. Neue Version herunterladen und entpacken: Als nächstes wird die neuste Nextcloud-Version heruntergeladen. Den konkreten Download-Link erhält man über die Nextcloud-Homepage:
    Download-Link für Nextcloud

    Download-Link für Nextcloud

    Für die folgenden Befehle müssen dann der entsprechende Link und Dateiname verwendet werden:

    cd ~
    wget https://download.nextcloud.com/server/releases/nextcloud-12.0.2.tar.bz2
    tar -xjf nextcloud-12.0.2.tar.bz2 -C /var/www
    rm nextcloud-12.0.2.tar.bz2

  5. Übernehmen der Konfigurations-Datei: Nun wird noch die Konfigurations-Datei aus der alten Nextcloud-Installation übernommen:

    cp /var/www/nextcloud_alt/config/config.php /var/www/nextcloud/config/config.php

  6. Webserver starten: Anschließend kann der Webserver wieder gestartet werden:

    service nginx start

  7. Verzeichnisrechte setzen: Vor dem Ausführen des eigentlichen Updates sollten die Verzeichnisrechte noch einmal explizit gesetzt werden:

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

  8. Update durchführen: Das Update wird nun über den OCC-Befehl im Kontext des Webserver-Users gestartet:

    cd /var/www/nextcloud
    sudo -u www-data php occ upgrade

  9. Wartungsmodus deaktivieren: Anschließend kann der Maintenance-Mode wieder deaktiviert werden:

    cd /var/www/nextcloud
    sudo -u www-data php occ maintenance:mode --off

  10. Alte Installation entfernen: Wenn alles geklappt hat, kann man die alten Nextcloud-Dateien entfernen:

    rm -r /var/www/nextcloud_alt

Abschließende Tätigkeiten

Nachdem das Update erfolgreich durchgeführt worden ist, sollte man sich nochmal mit dem Administrator-Account in die Cloud einloggen und im Bereich „Verwaltung“ kontrollieren, ob hier Warnungen oder Fehler angezeigt werden.

Ebenfalls sollte kontrolliert werden, ob während des Update-Vorgangs einige Nextcloud-Apps deaktiviert worden sind. Wenn dies der Fall ist, können diese von Cloud-Admin wieder aktiviert werden.

Nach diesen Schritten ist das Update fertig und Nextcloud kann wieder wie gewohnt genutzt werden.

Weiterführende Artikel

Links

]]>
https://decatec.de/home-server/nextcloud-updates-richtig-durchfuehren/feed/ 8
Nextcloud: Backups erstellen und wiederherstellen – manuell oder per Skript https://decatec.de/home-server/nextcloud-backups-erstellen-und-wiederherstellen-manuell-oder-per-skript/ https://decatec.de/home-server/nextcloud-backups-erstellen-und-wiederherstellen-manuell-oder-per-skript/#comments Tue, 12 Sep 2017 17:55:31 +0000 https://decatec.de/?p=3667 Nextcloud Logo

Mit dem Betreiben der eigenen Nextcloud gehen natürlich auch einige administrativen Pflichten einher. So sollte sowohl das Betriebssystem, als auch die Cloud-Software auf dem aktuellsten Stand gehalten werden.

Ein weiterer wichtiger Punkt, den man nicht außer Acht lassen sollte, sind Backups der eigenen Cloud. Leider gibt es hier kein fertiges Skript oder Plugin, welches alles automatisch erledigt – hier ist also etwas Handarbeit gefragt.

Der folgende Artikel zeigt Schritt für Schritt, wie sowohl Backups angefertigt, als auch wieder zurückgespielt werden können. Die Nextcloud-Dokumentation liefert bereits eine recht detaillierte Anleitung für das Anfertigen von Backups, als auch für die Wiederherstellung. Dennoch lässt sich das Vorgehen hier und da noch etwas optimieren und v.a. auch (per Skript) automatisieren.

Ausgangspunkt ist wie immer die im Tutorial Nextcloud auf Ubuntu Server mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban gezeigte Konfiguration.

Update-Historie
  • 23.09.2017:
    • Hinweis auf Anpassung der Verzeichnis-Berechtigungen entfernt. Dies wird seitens der Nextcloud-Dokumentation nicht mehr empfohlen (siehe hier).
  • 26.03.2018:
    • Hinweis für Debian, wenn sudo -u www-data nicht klappt.

Grundsätzliches Vorgehen

Eine komplette Nextcloud-Instanz besteht immer aus drei Teilen:

  • Das Web-Verzeichnis von Nextcloud (z.B. /var/www/nextcloud)
  • Das Daten-Verzeichnis (z.B. /var/nextcloud_data)
  • Die Nextcloud-Datenbank

Wenn Backups der eigenen Cloud angefertigt werden sollen, dann sind immer diese drei Teile zu berücksichtigen.

Mit welchen Mitteln das Backup angefertigt wird, ist dabei zunächst einmal egal. Im Rahmen des Artikels werden aber nur Programme verwendet, die auf einer normalen Installation eines Ubuntu Servers verfügbar sind.

Man sollte sich im Vorfeld nur Gedanken über den Speicherort des Backups machen. Hier macht es wenig Sinn, das Backup auf der gleichen Festplatte zu speichern, auf der auch Nextcloud installiert ist. Im Falle eines Festplatten-Ausfalls ist sowohl die Nextcloud-Instanz, als auch das Backup verloren.

Besser ist hier die Verwendung einer externen Festplatte oder eines Netzlaufwerks (z.B. auf einem NAS). Im Rahmen des Artikels gehe ich davon aus, dass das Verzeichnis der Backups /mnt/Share/NextcloudBackup lautet.

Hinweis für Debian: Wenn bei Befehlen die unter einem anderen User ausgeführt werden sollen (Webserver-User, www-data), könnte unter Debian das Problem auftauchen, dass dies mit sudo -u www-data <Befehl> nicht funktioniert. Hier erscheint dann eine Meldung wie „www-data ist unavailable“. In diesem Fall wurde bei der Installation von Debian ein Passwort für den Benutzer root vergeben und in Folge dessen das Programm sudo gar nicht installiert. Wenn man daher sudo nicht verwenden kann oder will, dann kann man einen Befehl aber auch auf andere Weise unter einem anderen User ausführen. In diesem Fall verwendet man anstatt sudo -u www-data <Befehl> einfach folgendes: su -s /bin/sh www-data -c „<Befehl>“

Backup erstellen

Um ein Backup zu erstellen, sollte die Nextcloud-Instanz zunächst in dem Maintenance-Mode versetzt werden. Das sorgt dafür, dass kein Benutzer aktiv auf der Cloud arbeiten kann.

cd /var/www/nextcloud
sudo -u www-data php occ maintenance:mode --on

Als nächstes müssen das Hauptverzeichnis von Nextcloud gesichert werden. Dies ist im Normalfall unter /var/www/nextcloud zu finden (bitte den Punkt am Ende der Zeile beachten):

tar -cpzf /mnt/Share/Backups/Nextcloud/NextcloudBackup_FileDir_`date +"%Y%m%d"`.tar.gz -C /var/www/nextcloud .

Neben dem Nextcloud-Verzeichnis muss auch das Datenverzeichnis von Nextcloud mit in das Backup einfließen. Dieses sollte idealerweise außerhalb des Web-Verzeichnisses liegen (z.B. unter /var/nextcloud_data). Auch hist wieder ein Punkt am Ende des Befehls:

tar -cpzf /mnt/Share/Backups/Nextcloud/NextcloudBackup_DataDir_`date +"%Y%m%d"`.tar.gz -C /var/nextcloud_data .

Nun muss nur noch die Datenbank der Nextcloud-Installation gesichert werden. Dies geschieht mit folgendem Befehl:

mysqldump --single-transaction -h localhost -u nextcloud_db_user -p nextcloud_db > /mnt/Share/Backups/Nextcloud/NextcloudBackup_DB_`date +"%Y%m%d"`.sql

Nun ist das Backup komplett, so dass Benutzer wieder mit der Cloud arbeiten können. Daher wird der Maintenance-Modus wieder beendet:

cd /var/www/nextcloud
sudo -u www-data php occ maintenance:mode --off

Backup zurückspielen

Ein Backup anzufertigen ist natürlich nur eine Seite der Medaille. Im Falle des Falles muss das Backup auch zurückgespielt werden können.

Vor der Wiederherstellung versetzen wir Nextcloud wie gewohnt in den Maintenance-Mode:

cd /var/www/nextcloud
sudo -u www-data php occ maintenance:mode --on

Da wir hier ein komplettes Backup wieder einspielen, sollte der Webserver zunächst ein mal gestoppt werden:

service nginx stop

Vor der Wiederherstellung der Dateien der Cloud werden als erstes die entsprechenden Verzeichnisse gelöscht und neu angelegt. Dies sorgt dafür, dass keine Dateien aus dem Zustand vor dem Backup übrigleiben:

rm -r /var/www/nextcloud/
rm -r /var/nextcloud_data/

mkdir -p /var/www/nextcloud/
mkdir -p /var/nextcloud_data/

Nun gilt es zunächst das Nextcloud-Verzeichnis aus dem Backup wiederherzustellen. Da das Datum als Zeitstempel für das Backup diente, muss bei den folgenden Befehlen immer das korrekte Datum verwendet werden:

tar -xpzf /mnt/Share/Backups/Nextcloud/NextcloudBackup_FileDir_20170912.tar.gz -C /var/www/nextcloud/

Das gleiche wird mit dem Datenverzeichnis von Nextcloud durchgeführt:

tar -xpzf /mnt/Share/Backups/Nextcloud/NextcloudBackup_DataDir_20170912.tar.gz -C /var/nextcloud_data/

Anschließend werden die Verzeichnis-Berechtigungen noch einmal explizit gesetzt:

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

Zum Schluss wird noch die Datenbank wiederhergestellt. Dazu wird zunächst die Datenbank entfernt und neu angelegt (für die Ausführung der Befehle muss das Passwort des Nextcloud-Datenbankusers angegeben werden):

mysql -h localhost -u nextcloud_db_user -p -e "DROP DATABASE nextcloud_db"
mysql -h localhost -u nextcloud_db_user -p -e "CREATE DATABASE nextcloud_db"

Das Einspielen des Backups geschieht durch folgenden Befehl:

mysql -h localhost -u nextcloud_db_user -p nextcloud_db < /mnt/Share/Backups/Nextcloud/NextcloudBackup_DB_20170912.sql

Nun wird der Webserver wieder gestartet:

service nginx start

Zum Schluss muss noch ein Befehl abgesetzt werden, damit Nextcloud-Clients mitbekommen können, dass sich hier etwas durch das Wiederherstellen eines Backups verändert hat:

cd /var/www/nextcloud
sudo -u www-data php occ maintenance:data-fingerprint

Zum Schluss wird Nextcloud wieder aus dem Maintenance-Mode geholt.

cd /var/www/nextcloud
sudo -u www-data php occ maintenance:mode --off

Nach diesen Schritten wurde ein Backup von Nextcloud wiederhergestellt und es kann wieder mit der Cloud gearbeitet werden.

Backup/Restore mit Bash-Skript

Ein Backup kann mit diesen Schritten jederzeit manuell ausgeführt oder wiederhergestellt werden. Mehr Komfort erhält man jedoch, wenn man die auszuführenden Befehle in einem Skript zusammenfasst.

Auf diese Weise können Backups mit nur einem Befehl automatisiert angefertigt oder wiederhergestellt werden.

Zu diesem Zweck habe ich ein GitHub Repository erstellt, welches die notwendigen Bash-Skripte enthält: 

Nextcloud-Backup-Restore @ GitHub

Hinweis: Ich habe die Skript-Dateien als Open Source auf GitHub zur Verfügung gestellt. Damit sind diese frei verfügbar und können auch von jedermann angepasst und verbessert werden. Ich übernehme allerdings keinerlei Haftung für den Einsatz dieser Skripte. Diese sollen lediglich als Basis für die Erstellung eigener Backup-Skripte für eure Nextcloud-Instanz dienen.

Zunächst werden die Skript-Dateien heruntergeladen. Durch die Anmeldung als root-Benutzer werden die Skripte im Home-Verzeichnis von root gespeichert. Dies macht Sinn, da für die Ausführung der Skripts root-Rechte benötigt werden:

sudo -s
wget https://raw.githubusercontent.com/DecaTec/Nextcloud-Backup-Restore/master/NextcloudBackup.sh
wget https://raw.githubusercontent.com/DecaTec/Nextcloud-Backup-Restore/master/NextcloudRestore.sh

Mit folgenden Befehlen werden die Dateirechte angepasst, so dass nur der Benutzer root Zugriff auf diese Dateien hat und diese auch ausführen kann:

chown root NextcloudBackup.sh
chown root NextcloudRestore.sh
chmod 700 NextcloudBackup.sh
chmod 700 NextcloudRestore.sh
Wichtig: Die Skripte sind nicht direkt ausführbar, sondern erfordern noch Anpassungen an die konkrete Server-Umgebung (Pfade, Benutzernamen, etc.)! Hinweise dazu sind auch in den Skript-Dateien hinterlegt.

Bitte führt diese Skripte nicht „blind“ auf eurem System aus, sondern versucht, die ausgeführten Befehle zu verstehen und entsprechend eurer Nextcloud-Installation anzupassen.

Wenn die Skripte angepasst wurden, können diese direkt ausgeführt werden:

./NextcloudBackup.sh

Das Backup wird automatisch im entsprechenden Verzeichnis, welches im Backup-Skript angegeben wurde, gespeichert (z.B. /mnt/Share/NextcloudBackups/20170912_073953).

Wiederhergestellt werden kann ein Backup durch das Restore-Skript. Dieses erwartet den Zeitstempel eines vorhandenen Backups als Parameter:

./NextcloudRestore.sh 20170912_073953

Die Skripts sind so konzipiert, dass diese keine Benutzereingaben erfordern. Dadurch kann die Ausführung von Backups auch einfach automatisiert werden. Per Cronjob ist es beispielsweise denkbar, dass täglich nachts um 03:00 automatisch ein Backup der Nextcloud-Instanz auf einem NAS gespeichert wird.

Fazit

Auf den ersten Blick ist das Anfertigen von Backups und ggf. die Wiederherstellung nicht weiter kompliziert. Trotzdem ist es wichtig, alle auszuführenden Schritte zu verstehen und genau zu befolgen.

Am Ende noch der wichtigste Tipp: Nichts ist ärgerlicher, als regelmäßig angefertigte Backups, die aber im Ernstfall nicht wiederhergestellt werden können! Daher sollte das ganze Vorgehen (Backups anfertigen und auch wieder zurückspielen) mindestens einmal durchgespielt werden – und das Ganze am besten, bevor eure private Cloud in den produktiven Betrieb übergeht.

Der Aufwand lohnt sicher aber: Wenn ihr sichergehen könnt, dass euer Vorgehen zum Erstellen und Wiederherstellen von Nextcloud-Backups im Ernstfall funktioniert, könnt ihr auch ruhigen Gewissens weitere Benutzer auf eure Cloud loslassen.

Weiterführende Artikel

Links

]]>
https://decatec.de/home-server/nextcloud-backups-erstellen-und-wiederherstellen-manuell-oder-per-skript/feed/ 30
Nextcloud auf Ubuntu Server mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban https://decatec.de/home-server/nextcloud-auf-ubuntu-server-mit-nginx-mariadb-php-lets-encrypt-redis-und-fail2ban/ https://decatec.de/home-server/nextcloud-auf-ubuntu-server-mit-nginx-mariadb-php-lets-encrypt-redis-und-fail2ban/#comments Wed, 23 Aug 2017 16:00:33 +0000 https://decatec.de/?p=3477 Nextcloud Logo

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

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

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

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

Update-Historie
  • 25.08.2017:
    • Troubleshooting: Hinweis auf apc.enable_cli hinzugefügt, wenn es bei der Ausführung des Cronjobs zu Fehlern mit APCu kommt.
  • 30.08.2017:
    • Variable overwriteprotocol in Nextcloud config.php sollte auf https gesetzt werden.
  • 07.09.2017:
    • Fail2ban: Jail für Nextcloud wird in die Datei /etc/fail2ban/jail.local eingetragen.
  • 23.09.2017:
    • Hinweis auf Anpassung der Verzeichnis-Berechtigungen entfernt. Dies wird seitens der Nextcloud-Dokumentation nicht mehr empfohlen (siehe hier).
  • 22.102.107:
    • Fail2ban: Attribut für Login-Versuche heißt maxretry und nicht maxentry.
  • 07.01.2018:
    • Fail2ban: Erklärung zum Unterschied zwischen verschiedenen Konfigurations-Dateien (*.conf und *.local) hinzugefügt.
    • Fail2ban: Ergänzungen zum E-Mail-Versand bei Ban hinzugefügt.
  • 19.01.2018:
    • Gateway-Host: proxy_request_buffering off; hinzugefügt, damit Requests nicht mehr gepuffert werden.
  • 22.01.2018:
    • Genaueren Hinweis auf die langsame Generierung von Diffie-Hellman-Parameter auf schwacher Hardware hinzugefügt.
  • 14.04.2018:
    • Listen-Direktive für Nextcloud-vHost geändert, so dass nur noch lokal (127.0.0.1) auf Port 82 gelauscht wird.

 

Motivation, Voraussetzungen und Konzept

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

Ziele und Aufwand

Der Artikel hat folgende Zielsetzungen:

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

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

Folgende Versionen kommen dabei zum Einsatz:

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

Zeitaufwand: ca. 3 Stunden.

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

Voraussetzungen

Betriebssystem und Hardware

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

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

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

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

Zugriff per SSH

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

DynDNS

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

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

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

Arbeiten mit Root-Rechten

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

Konzept

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

Warum die Kombination nginx/MariaDB?

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

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

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

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

Virtuelle Hosts und Konfigurations-Dateien von nginx

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

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

Bei nginx können – ähnlich wie beim Webserver Apache – virtuelle Hosts definiert werden. Ein virtueller Host (vHost) stellt dabei eine genau definierte Konfiguration für eine Website/Webanwendung dar. Dabei spielen folgende Dateien und Verzeichnisse eine entscheidende Rolle:

  • /etc/nginx/nginx.conf: Globale Konfigurations-Datei von nginx. Hier werden die globalen Einstellungen definiert.
  • /etc/nginx/conf.d: In diesem Verzeichnis werden die virtuellen Hosts gespeichert. Pro Host wird dazu eine Datei mit der Endung .conf angelegt. Alle Dateien mit einer anderen Dateiendung werden dabei ignoriert.

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

Aufteilung in mehrere virtuelle Hosts mit nginx

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

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

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

  • Ein einzelner virtueller Host: Hierbei werden alle Webanwendungen über den gleichen virtuellen Host konfiguriert. Diese Lösung mag auf den ersten Blick die einfachste sein, jedoch wird die Konfigurations-Datei (des einzigen vHosts) auf die Dauer sehr unübersichtlich. Ebenso besteht hier das Risiko, dass durch einen kleinen Fehler im einzigen vHost gleich alle Webanwendungen lahmgelegt werden. Ebenso kann eine Webanwendung nicht „mal eben schnell“ deaktiviert werden, da dazu große Teile des virtuellen Hosts entfernt oder auskommentiert werden müssten.
  • Ein virtueller Host pro Webanwendung: Bei diesem Ansatz gibt es einen virtuellen Host pro Webanwendung. Durch die strikte Trennung ist diese Lösung deutlich flexibler und weniger fehleranfällig.
    Dennoch gibt es ein Problem: Ein virtueller Host wird durch einen Server-Namen (die URL) und einen Port definiert. Diese Kombination muss sich dabei von allen anderen virtuellen Hosts unterscheiden. In unserem Fall wird aber immer die gleiche URL (die DynDNS-Adresse) verwendet, da die meisten Router keine Möglichkeit bieten, sich zeitgleich über mehrere DynDNS-Adressen anzumelden. Aus diesem Grund müssten alle Webanwendungen auf unterschiedlichen Ports laufen. Das macht diesen Ansatz aber wieder recht unkomfortabel, da zum einen mehrere Ports in der Firewall des Routers geöffnet werden müssen (Sicherheitsrisiko), zum anderen müssen alle Clients die richtigen Ports verwenden (in jeder URL-Eingabe muss der konkrete Port spezifiziert werden).
  • Mehrere virtuelle Hosts + Reverse-Proxy: Es gibt allerdings auch einen weiteren Ansatz, der die Flexibilität von getrennten virtuellen Hosts bietet, die oben angesprochenen Nachteile jedoch vermeidet. Dabei dient ein zentraler virtueller Host als Gateway (mit der DynDNS-Adresse und den Standard-Ports 80 und 443). Dieser „Gateway-Host“ bedient sich nun den Reverse-Proxy-Fähigkeiten von nginx, um eine Anfrage eines Clients gezielt an weitere virtuelle Hosts weiter zu leiten. Die Hosts der einzelnen Webanwendungen laufen mit dem gleichen Server-Namen (die lokale IP) und auf getrennten Ports. Da dies aber alles lokal auf dem Webserver geschieht, müssen keine weiteren Ports nach außen hin geöffnet werden, der Gateway-Host ist die einzige direkte Schnittstelle „nach außen“. Alle Client-Anfragen kommen auf diesem Weg zunächst beim Gateway-Host an, der diese dann gezielt an andere vHosts weiterleitet.

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

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

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

Installation und Einrichtung Nextcloud

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

Updates

Zunächst erfolgt das obligatorische Update des Systems:

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

Statische IP zuweisen

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

Dazu wird folgende Datei bearbeitet:

nano /etc/network/interfaces

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

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

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

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

Programm-Installation

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

Installation nginx

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

Hinweis für Raspberry Pi Benutzer

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

apt-get update
apt-get install nginx

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

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

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

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

nano /etc/apt/sources.list

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

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

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

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

Nach der Aktualisierung der Paketquellen kann der Webserver installiert werden:

apt-get update
apt-get install nginx

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

Erster Aufruf - der Webserver läuft

Erster Aufruf – der Webserver läuft

Installation MariaDB

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

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

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

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

Anschließend werden die Paketquellen hinzugefügt:

nano /etc/apt/sources.list

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

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

Nun kann die Datenbank installiert werden:

apt-get update
apt-get install mariadb-server

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

Root-Passwort für MariaDB vergeben

Root-Passwort für MariaDB vergeben

Installation PHP

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

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

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

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

Server Konfiguration

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

Konfiguration PHP

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

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

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

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

user = www-data
group = www-data

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

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

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

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

Hier ändern wir also nur wenige Werte ab:

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

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

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

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

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

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

service php7.0-fpm restart

Konfiguration MariaDB

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

mysql_secure_installation

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

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

service mysql restart

Allgemeine nginx-Konfiguration

Zunächst wir die globale Konfiguration von nginx angepasst:

nano /etc/nginx/nginx.conf

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

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

Default-Seite deaktivieren

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

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

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

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

Vorbereiten der Verzeichnisstruktur

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

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

Anlegen des Gateway-Hosts

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

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

Hier fügen wir nun folgenden Inhalt ein:

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

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

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

Anlegen des virtuellen Hosts für Let’s Encrypt

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

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

Dieser Host ist dabei sehr einfach aufgebaut:

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

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

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

service nginx restart

SSL-Zertifikat mit Let’s Encrypt erzeugen

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

Port-Forwarding und DynDNS einrichten

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

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

Generierung des SSL-Zertifikats

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

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

apt-get install letsencrypt

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

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

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

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

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

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

Das SSL-Zertifikat ist der wichtigste Schritt, damit die Verbindungen zur Cloud nachher verschlüsselt ablaufen. Man kann die Sicherheit noch weiter erhöhen, indem man zusätzlich sog. Diffie-Hellman-Parameter generiert. Dieses Thema ist reichlich komplex, sorgt aber einfach ausgedrückt für einen sicheren Schlüsselaustausch beim Verbindungsaufbau.

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

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

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

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

Zugriffsberechtigungen für Zertifikat-Dateien setzen

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

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

Erneuerung der Zertifikate nach 90 Tagen

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

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

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

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

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

Gateway-Host für Nextcloud vorbereiten

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

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

Die hinzugefügten Abschnitte sind markiert:

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

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

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

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

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

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

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

	location = / {
		# Disable access to the web root, the Nextcloud subdir should be used instead.
		deny all;
		
		# If you want to be able to access the cloud using the webroot only, use the following command instead:
		# rewrite ^ /nextcloud;
	}	
	
	#
	# Nextcloud
	#
	location ^~ /nextcloud {
		# Set max. size of a request (important for uploads to Nextcloud)
		client_max_body_size 10G;
		# Besides the timeout values have to be raised in nginx' Nextcloud config, these values have to be raised for the proxy as well
		proxy_connect_timeout 3600;
		proxy_send_timeout 3600;
		proxy_read_timeout 3600;
		send_timeout 3600;
		proxy_buffering off;
		proxy_request_buffering off;
		proxy_max_temp_file_size 10240m;
		proxy_set_header Host $host;
		proxy_set_header X-Real-IP $remote_addr;
		proxy_pass http://127.0.0.1:82;
		proxy_redirect off;
	}	
}

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

Virtuellen Host für Nextcloud anlegen

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

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

Hier der komplette Inhalt der Datei:

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

server {
    listen 127.0.0.1:82;
    server_name 127.0.0.1;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Es wird nur ein HTTP-Server definiert (kein HTTPS). Die HTTPS-Verbindung wird über den Gateway-Host sichergestellt.
  • Gelauscht wird wieder über die Adresse 127.0.0.1. Zusammen mit dem entsprechenden server_name kann auch hier keine direkte Verbindung zu diesem virtuellen Host aufgebaut werden (ohne den Gateway-Host zu passieren).
  • Der Port ist diesmal 82, da Port 81 bereits vom Let’s Encrypt vHost „belegt“ ist. Eine Eindeutigkeit (server_name/Port) wird hier über einen anderen Port erreicht.
  • Die proxy_set_header Anweisungen dienen der erhöhten Sicherheit. Ohne diese Einträge werden später Warnungen im Admin-Bereich von Nextcloud angezeigt. In vielen Tutorials werden diese Header per add_header angegeben. In unserem Fall funktioniert dies nicht, da die Zugriffe über einen Proxy (Gateway-Host) ablaufen. Daher werden die Header mittels proxy_set_header angegeben.
  • Der PHP-Handler (der in diesem Fall nur für Nextcloud zuständig ist) beinhaltet neben den Nextcloud-spezifischen Anweisungen auch noch weitere Parameter, die bestimmte Variablen in der php.ini überschreiben (fastcgi_param PHP_VALUE). Dabei darf nur eine fastcgi_param PHP_VALUE Anweisung existieren, da sich diese ansonsten gegenseitig überschreiben. Wenn mehrere Parameter an PHP übergeben werden sollen (wie hier der Fall), müssen diese einfach durch einen Zeilenumbruch getrennt werden. Besonders wichtig ist hier die Direktive open_basedir, da PHP ansonsten keinen Zugriff auf das Datenverzeichnis von Nextcloud hat.
    Falls später z.B. eine externe Festplatte als externer Speicher eingebunden werden soll, muss auch das Verzeichnis dieses Laufwerks in die open_basedir Anweisung mit aufgenommen werden.

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

nginx -t
service nginx restart

Installation Nextcloud

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

Download

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

Download-Link für Nextcloud

Download-Link für Nextcloud

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

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

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

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

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

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

Datenbank für Nextcloud anlegen

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

mysql -u root -p

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

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

Nextcloud-Setup

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

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

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

Nextcloud Setup

Nextcloud Setup

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

Warnungen im Admin-Bereich

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

Warnungen im Admin-Bereich

Warnungen im Admin-Bereich

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

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

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

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

Anpassung der Nextcloud-Konfiguration

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

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

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

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

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

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

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

'overwriteprotocol' => 'https',

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

'logtimezone' => 'Europe/Berlin',

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

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

Cronjob für Nextcloud einrichten

Nextcloud führt in regelmäßigen Abständen Hintergrund-Aufgaben aus (z.B. Aufräum-Arbeiten). Dies wird in der Standard-Einstellung über AJAX realisiert. Dies ist zwar die einfachste Möglichkeit, jedoch gibt es hier zwei Nachteile: Zum einen kann ein Hintergrund-Job nur dann ausgeführt werden, wenn ein Benutzer angemeldet ist und eine Seite geladen wird. Wenn nun über längere Zeit kein Benutzer aktiv ist, wird der Hintergrund-Job einfach nicht mehr ausgeführt. Zum anderen ist diese Art der Job-Ausführung weniger performant.

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

Um diesen Cronjob anzulegen, muss zunächst ein neuer Job für den Webserver-Benutzer angelegt werden:

crontab -u www-data -e

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

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

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

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

Umstellung von AJAX auf Cron

Umstellung von AJAX auf Cron

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

Weitere Konfiguration der Cloud

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

Folgende Punkte sind auf jeden Fall einen Blick Wert:

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

Optimierung von Nextcloud

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

Fail2ban

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

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

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

Installation und Einrichtung Fail2ban

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

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

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

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

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

'logtimezone' => 'Europe/Berlin',

Anschließend kann Fail2ban installiert werden:

apt-get update 
apt-get install fail2ban

Nun wird ein spezieller Filter für Nextcloud angelegt:

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

Die Datei wird nun mit folgendem Inhalt gefüllt:

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

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

nano /etc/fail2ban/jail.local

Diese Datei hat folgenden Inhalt:

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

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

Nach einem Neustart ist Fail2ban einsatzbereit:

service fail2ban restart

E-Mail-Versand durch Fail2ban

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

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

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

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

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

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

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

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

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

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

[Definition]

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

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

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

Fail2ban Staus und Sperren entfernen

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

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

fail2ban-client status nextcloud

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

fail2ban-client set nextcloud unbanip 48.128.36.83

Redis

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

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

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

Die Installation von Redis erfolgt mit den Befehlen:

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

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

nano /etc/redis/redis.conf

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

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

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

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

usermod -a -G redis www-data

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

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

Folgende Zeilen hier einzufügen:

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

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

service redis-server restart

ufw einrichten

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

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

apt-get update
apt-get install ufw

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

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

Dies kann mit folgenden Befehlen erreicht werden:

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

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

ufw status

Überprüfung der Sicherheit

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

Qualys SSL Labs

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

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

SSL-Test der Nextcloud-Installation

SSL-Test der Nextcloud-Installation

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

Nextcloud Security Scan

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

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

Troubleshooting

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

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

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

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

Bekannte Probleme und Lösungen

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

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

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

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

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

Folgender Wert muss hier noch hinzugefügt werden:

apc.enable_cli = 1

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

Abschließende Worte

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

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

Weiterführende Artikel

Links

]]>
https://decatec.de/home-server/nextcloud-auf-ubuntu-server-mit-nginx-mariadb-php-lets-encrypt-redis-und-fail2ban/feed/ 382
Nextcloud auf anderen Rechner umziehen https://decatec.de/home-server/nextcloud-auf-anderen-rechner-umziehen/ https://decatec.de/home-server/nextcloud-auf-anderen-rechner-umziehen/#comments Wed, 19 Apr 2017 17:17:33 +0000 https://decatec.de/?p=3384 Nextcloud Logo

In diesem Tutorial soll es um den Umzug einer Nextcloud-Instanz auf einen anderen Rechner gehen. Dies kann beispielsweise notwendig sein, wenn man die eigene Cloud zunächst einmal auf einem Raspberry Pi (Affiliate Link) betrieben hat und nach einiger Zeit eine etwas performantere Lösung – z.B. einen Intel NUC (Affiliate Link) – bevorzugen würde.

Das wichtigste bei diesem Vorhaben sollte sein, dass es beim Umzug zu keinem Datenverlust kommt, d.h. dass alle Daten aus der alten Cloud verlustfrei in die neue Installation übernommen werden. Für die Nutzer der Cloud ist nichts ärgerlicher, als ein Datenverlust auf Grund von administrativen Tätigkeiten!
Daher sollte ein Umzug vom Admin sorgfältig geplant und ausgeführt werden.

Vorbereitung

Um einen Umzug vornehmen zu können, sind natürlich erst einmal zwei Rechner (oder auch virtuelle Maschinen) notwendig. Um eine mögliche Fehlerquelle ausschließen zu können, sollten beide Maschinen auch möglichst identisch konfiguriert werden.

Neben der eigentlichen Cloud-Anwendung müssen hier meistens auch weitere Programme bzw. Konfigurationen umgezogen werden. Beispiele hierfür sind:

  • Webserver (bzw. die virtuellen Hosts)
  • Evtl. vorhandene SSL-Zertifikate (z.B. Let’s Encrypt)
  • Redis-Server (für das Transactional File Locking)
  • fail2ban
  • Evtl. weitere Webanwendungen, die neben Nextcloud ausgeführt werden

Über diese „Seiteneffekte“ des Umzugs sollte man sich am besten bereits vorher Gedanken machen. An dieser Stelle soll es aber nur um den Umzug von Nextcloud gehen. Eine vollständige Beschreibung für alle Programme/Konfigurationen würde den Rahmen des Artikels sprengen.

Zum einfachen Datenaustausch zwischen den verschiedenen Rechnern bietet sich ein Netzlaufwerk (z.B. auf einem NAS) an. Diese wird dann einfach auf beiden PCs gemountet und wird zum „Zwischenlagern“ der Dateien verwendet. In dieser Anleitung ist dieses Netzlaufwerk beispielhaft unter /mnt/Share gemountet (sowohl am Ausgangs-, als auch am Ziel-Rechner).

Der Umzug

Der eigentliche Umzug unterteilt sich in verschiedene Schritte. Bevor man beginnt, sollte man auf jeden Fall ein Backup der laufenden Nextcloud-Instanz anfertigen. Damit ist man immer auf der sicheren Seite, falls etwas schiefgehen sollte.

Ausgangs-Rechner

Folgende Schritte sind auf dem Rechner auszuführen, auf dem die Cloud bisher betrieben wurde.

Maintenance-Modus/Webserver stoppen

Zunächst wird Nextcloud in den sog. Maintenance-Mode versetzt:

cd /var/www/nextcloud
sudo -u www-data php occ maintenance:mode –-on

Dies sorgt dafür, dass keine Verbindungen mehr zu Nextcloud möglich sind. Falls die Cloud von vielen Usern genutzt wird, sollte man erst ein paar Minuten warten, damit sichergestellt ist, das kein aktiver Benutzer mehr an der Cloud angemeldet ist.

Anschließend wird der Webserver gestoppt:

service nginx stop

Sichern der Nextcloud-Dateien

Nun müssen alle Daten gesichert werden, die für den Betrieb von Nextcloud benötigt werden. Dazu gehören immer:

  • Die Konfiguration von Nextcloud (config.php), bzw. das komplette Cloud-Webverzeichnis (/var/www/nextcloud)
  • Das Datenverzeichnis der Cloud (/var/nextcloud_data)
  • Die Nextcloud-Datenbank

Am einfachsten wird das komplette Nextcloud-Verzeichnis umgezogen, dann spart man sich auf dem Ziel-Rechner die manuelle Installation von Nextcloud. Dazu wird das ganze Verzeichnis auf das Netzlaufwerk kopiert:

cd /var/www/
cp -rv nextcloud /mnt/Share/nextcloud

Das gleiche wird mit dem Datenverzeichnis gemacht:

cd /var
cp -rv nextcloud_data /mnt/Share/nextcloud_data

Anschließend wird ein kompletter Dump der Datenbank gezogen:

cd /mnt/Share
mysqldump --single-transaction -h localhost -u nextcloud_db_user -p nextcloud_db > nextcloud_db_backup.bak

Nun haben wir alle benötigten Daten der alten Cloud-Instanz gesichert und können auf den anderen Rechner wechseln.

Die Maschine, auf der Nextcloud bisher lief, kann nun heruntergefahren werden.

Ziel-Rechner

Nun geht es auf dem Ziel-Rechner weiter, d.h. dem PC, auf dem die Cloud in Zukunft betrieben werden soll.

Achtung: Bevor nicht alle Schritte durchgeführt wurden, sollte nicht versucht werden, auf die Cloud zuzugreifen, da es ansonsten zu Fehlern kommen kann.

Webserver stoppen

Auch auf dem Ziel-Rechner sollte zunächst einmal der Webserver getoppt werden, um einen unbeabsichtigten Zugriff auf die Cloud auszuschließen:

service nginx stop

Wiederherstellen der Nextcloud-Dateien

Dann wird die gesicherte Nextcloud-Installation auf dem Ziel-Rechner wiederhergestellt. Da wir zuvor das komplette Nextcloud-Verzeichnis gesichert haben, kann einfach der komplette Dateibestand auf den Ziel-Rechner kopiert werden:

mkdir -p /var/www
cd /var/www/
cp -rv /mnt/Share/nextcloud nextcloud

Um einen komplett sauberen Stand zu erhalten, kann man auch eine „frische“ Nextcloud-Installation vornehmen – analog zum Vorgehen im entsprechenden Tutorial (Abschnitt Einrichtung ownCloud). In diesem Fall muss anschließend nur die Konfigurations-Datei (config.php) aus der alten Cloud-Installation übernommen werden (wichtig!).

Das Datenverzeichnis wird mit folgendem Befehl kopiert:

cd /var
cp -rv /mnt/Share/nextcloud_data nextcloud_data

Die Datenbank muss auf dem Ziel-Rechner zunächst neu erstellt werden. Dies geschieht über die MariaDB-Kommandozeile:

mysql -u root -p

Anschließend wird eine leere Datenbank wie gewohnt angelegt. Wichtig an dieser Stelle ist, dass der DB-User und das Passwort die gleichen wie auch dem Ausgangs-Rechner sind.

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

Der letzte Schritt an dieser Stelle ist das Zurückspielen des Datenbank-Dumps in die neu angelegte Datenbank:

cd /mnt/Share
mysql -h localhost -u nextcloud_db_user -p nextcloud_db < nextcloud_db_backup.bak

Vor dem „Scharfschalten“ der neuen Cloud sollten die Rechte der entsprechenden Verzeichnisse wieder wie gewohnt gesetzt werden:

find /var/www/nextcloud/ -type f -print0 | xargs -0 chmod 0640
find /var/www/nextcloud/ -type d -print0 | xargs -0 chmod 0750
chown -R root:www-data /var/www/nextcloud/
chown -R www-data:www-data /var/www/nextcloud/apps/
chown -R www-data:www-data /var/www/nextcloud/config/
chown -R www-data:www-data /var/www/nextcloud/themes/
chown -R www-data:www-data /var/nextcloud_data/
chown root:www-data /var/www/nextcloud/.htaccess
chown root:www-data /var/nextcloud_data/.htaccess
chmod 0644 /var/www/nextcloud/.htaccess
chmod 0644 /var/nextcloud_data/.htaccess

Aktivieren der neuen Nextcloud-Instanz

Nun ist es an der Zeit, die neue Cloud in Betrieb zu nehmen.

Erst einmal wird der Webserver gestartet:

service nginx start

Anschließend kann der Wartungsmodus deaktiviert werden:

cd /var/www/nextcloud
sudo -u www-data php occ maintenance:mode –-off

Ein Einloggen mit dem Admin-Account sollte nun problemlos möglich sein. Hier sollte man nochmals kontrollieren, ob alle Daten, Plugins und Einstellungen wie gewünscht übernommen wurden und keine Warnungen in der Administrator-Oberfläche erscheinen. Falls doch, fehlt vermutlich ein Programm, welches auf dem alten Rechner installiert war und auf der neuen Maschine noch fehlt (z.B. bestimmte PHP-Pakete oder auch Redis). Hier sollte es helfen, die fehlenden Programme bzw. Konfigurationen auf dem neuen Rechner nach zu installieren.

Abschlussarbeiten

In einigen Fällen könnten noch Abschlussarbeiten notwendig sein, damit die neue Cloud-Instanz genau so läuft wie die alte Nextcloud-Installation. Dazu gehören beispielsweise:

Die neue Cloud ist fertig

Nach diesen Schritten kann die neue Cloud-Instanz wieder wie gewohnt genutzt werden. Durch den Komplett-Umzug sollten alle Dateien und Daten (Kontakte, Kalender, etc.) übernommen worden sein. Für die Nutzer der Cloud sollte der Umzug (bis auf eine kleine Downtime) vollkommen unbemerkt vonstattengegangen sein.

 Weiterführende Artikel

Links

]]>
https://decatec.de/home-server/nextcloud-auf-anderen-rechner-umziehen/feed/ 6
Let’s Encrypt Zertifikate per Cron automatisch erneuern https://decatec.de/home-server/lets-encrypt-zertifikate-per-cron-automatisch-erneuern/ https://decatec.de/home-server/lets-encrypt-zertifikate-per-cron-automatisch-erneuern/#comments Tue, 07 Mar 2017 17:20:21 +0000 https://decatec.de/?p=3287 Let's Encrypt Logo

In meinen Tutorials zu Nextcloud/ownCloud verweise ich ja gerne auf SSL-Zertifikate von Let’s Encrypt. Mit dieser Zertifizierungsstelle können auf einfache Weise TLS-/SSL-Zertifikate erzeugt werden. Auch wenn im privaten Umfeld ein sog. selbst signiertes Zertifikat ausreichen würde, bieten Zertifikate von Let’s Encrypt einen entscheidenden Vorteil: Es handelt sich hierbei um „trusted“ Zertifikate, d.h. dass alle gängigen Browser/Clients stufen diese als vertrauenswürdig ein.

Auch wenn die Erzeugung eines Zertifikats über Let’s Encrypt einfach und schnell von der Hand geht, wird als Kritikpunkt häufig die begrenzte Gültigkeitsdauer aufgeführt: Diese Zertifikate sind aus Sicherheitsgründen nur für einen Zeitraum von 90 Tagen gültig und müssen danach neu generiert werden.

Der folgende Artikel zeigt eine einfache Möglichkeit, wie die Erneuerung von Let’s Encrypt Zertifikaten ganz einfach automatisiert per Cron durchgeführt werden kann.

Update-Historie
  • 08.01.2018:
    • Der Output des Befehls zum Neustarten des Webservers im Cronjob wird nach > /dev/null 2>&1 weitergeleitet, so dass keine E-Mails mehr verschickt werden, wenn ein MTA auf dem System eingerichtet ist.

Warum kein selbst signiertes Zertifikat verwenden?

Selbst signierte Zertifikate haben zwei entscheidende Vorteile:

  • Kostenlos, da die Zertifikat-Dateien selbst erzeugt werden können, z.B. mittels OpenSSL (Zertifizierungsstellen lassen sich ihre Dienste immer fürstlich bezahlen).
  • Den Gültigkeitszeitraum kann man dabei selbst bestimmen (z.B. 10 Jahre). Einmal generiert, muss man sich in der Regel nicht mehr um das Zertifikat kümmern.

Allerdings gibt es hier immer auch einen massiven Nachteil: Selbst signierte Zertifikate werden von Client-Anwendungen nicht als vertrauenswürdig eingestuft, weil ja kein Dritter (die Zertifizierungsstelle) die Echtheit der Website bestätigen kann. Folglich zeigen Browser hier beispielsweise immer eine sehr deutliche Warnung an:

Zertifikat-Warnung im Internet Explorer

Zertifikat-Warnung im Internet Explorer

Andere Clients (z.B. Windows Smartphones bei der Synchronisierung von CardDAV/CalDAV) versagen bei selbst signierten Zertifikaten ihren Dienst.

Diesen Nachteil kann man relativ einfach umgehen: Man installiert das selbst signierte Zertifikat einfach auf sämtlichen Clients. Wie dies z.B. unter Windows bewerkstelligt werden kann, zeigt der Artikel ownCloud auf Ubuntu Server mit nginx, MariaDB und PHP (Abschnitt Zertifikat installieren (nur bei selbst signierten Zertifikaten)).
Dies ist in den meisten Fällen allerdings einfacher gesagt als getan: Solange z.B. für eine selbst gehostete Cloud-Anwendung die Anzahl der Clients überschaubar ist, hält sich der Aufwand hierfür in Grenzen. Aber spätestens wenn viele Clients zum Einsatz kommen, auf die man als Administrator keinen direkten Zugriff hat, wird die Sache kompliziert.

Trotz alledem ist die Verwendung eines selbst signierten Zertifikats nicht unsicher. Solange das Zertifikat richtig erzeugt und eingebunden wurde, ist die Verbindung verschlüsselt (und genau darum geht es ja primär im privaten Umfeld).

Zertifikate mit Let’s Encrypt

Mit einem Zertifikat von Let’s Encrypt hat man die oben genannten Probleme nicht. Wie diese Zertifikate erzeugt werden und beim Webserver nginx eingebunden werden, habe ich bereits im Artikel ownCloud 9 auf Ubuntu Server 16.04 LTS mit nginx, MariaDB, PHP 7 und Let’s Encrypt ausführlich erklärt. Hier nochmal im Schnelldurchgang, ohne auf die genaue Konfiguration des Webservers einzugehen (diese wurde detailliert im oben genannten Artikel erläutert):

Der Webserver muss auf Port 80 erreichbar sein und über eine Domain angesprochen werden können. Hier reicht auch eine DynDNS-Adresse. Ich verwende hier beispielhaft die Adresse meineseite.goip.de (wer auf der Suche nach einem guten, kostlosen DynDNS-Anbieter ist, sollte mal bei GoIP vorbei schauen). Eine IP ist für den Zertifizierungsvorgang übrigens nicht ausreichend.

Zunächst installiert man Let’s Encrypt. Unter Ubuntu Server 16.04 LTS verwendet man dazu folgende Befehle:

apt-get update && apt-get upgrade -V
apt-get install letsencrypt

Anschließend kann das Zertifikat erzeugt werden:

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

Die Zertifikat-Dateien sind dann im Verzeichnis /etc/letsencrypt/live/meineseite.goip.de zu finden.

Das generierte Zertifikat hat eine Gültigkeitsdauer von 90 Tagen. Spätestens vor dem Ablauf dieser Frist muss das Zertifikat erneuert werden. Dazu ist folgender Befehl ausreichend, damit sämtliche bekannten Zertifikate erneuert werden:

letsencrypt renew

Dies ist zwar nur ein Befehl auf der Kommandozeile und geht recht schnell, aber man sollte dies auf keinen Fall vergessen: Wenn das Zertifikat ungültig wird, werden wieder die Warnungen im Browser angezeigt und man hat wieder die gleichen Probleme wie mit einem selbst signierten Zertifikat.

Automatisierung mit Cron

Diese wichtige Aufgabe kann allerdings auch mittels Cron automatisiert werden. Dazu nutzen wir crontab:

sudo -s
crontab -e

Durch das sudo -s ist sicher gestellt, dass der folgende Befehl mit Root-Rechten ausgeführt wird.

Die zu öffnende Datei wird anschließend mit nano (oder jedem anderen beliebigen Texteditor) bearbeitet und folgender Inhalt eingetragen:

40 3 * * 0 letsencrypt renew >> /var/log/letsencrypt-renew.log && /etc/init.d/nginx reload > /dev/null 2>&1

Dieser Befehl sorgt für die Erneuerung der Let’s Encrypt Zertifikate um 03:40 jeden Sonntag. Im Zweiten Schritt wird dann nginx anschließend neu geladen (damit das neue Zertifikat auch korrekt eingebunden wird). Der Zeitpunkt des Cronjobs ist hier willkürlich gewählt. Praktischerweise sollte man einen Zeitpunkt wählen, zu dem der Webserver nicht gerade unter last steht.

Der Output der Zertifikat-Erneuerung wird in der Datei /var/log/letsencrypt-renew.log ausgegeben. Hier kann dann kontrolliert werden, ob der Befehl richtig ausgeführt wurde und ob tatsächlich Zertifikate erneuert wurden (dies ist in der Regel abhängig vom Alter der bestehenden Zertifikate – normalerweise werden Zertifikate erst erneuert, wenn die Gültigkeitsdauer weniger als 30 Tage beträgt).

Die neuen Zertifikate sind anschließend im Verzeichnis /etc/letsencrypt/live zu finden. Von dieser Stelle werden sie auch von nginx eingebunden, daher reicht auch ein reload des Webservers nach dem Aufruf von letsencrypt. Damit für das Neustarten des Webservers keine E-Mail versendet wird – dies passiert automatisch, wenn ein passender MTA (Mail Transfer Agent) konfiguriert ist – wird der Output dieses Befehl mitttels > /dev/null 2>&1 ins „Nirvana“ weitergeleitet.
Die alten Zertifikate werden in den Ordner /etc/letsencrypt/archive verschoben. Werden die archivierten Zertifikate nicht mehr benötigt, kann man diese problemlos löschen.

Trusted Zertifikat mit praktisch unbegrenzter Gültigkeitsdauer

Der Artikel hat gezeigt, wie man mit wenig Aufwand die Erneuerung von Let’s Encrypt Zertifikaten automatisieren kann. Damit hat man immer ein As im Ärmel: ein Zertifikat, welches von allen Clients als vertrauenswürdig eingestuft wird und praktisch eine unbegrenzte Gültigkeitsdauer hat.

Daher nach wie vor mein Tipp: Bevor ihr einfach auf selbst signierte Zertifikate setzt, gebt Let’s Encrypt eine Chance. Ihr werdet damit als Administrator weniger Verwaltungsaufwand haben und die Clients, die auf eure Web-Anwendung zugreifen, werden es euch danken.

Weiterführende Artikel

Links

]]>
https://decatec.de/home-server/lets-encrypt-zertifikate-per-cron-automatisch-erneuern/feed/ 17