DecaTec https://decatec.de Programmieren, Fotografie, Home-Server und einiges mehr Fri, 10 Aug 2018 15:32:31 +0000 de-DE hourly 1 Auf dem Laufenden bleiben mit Twitter https://decatec.de/allgemein/auf-dem-laufenden-bleiben-mit-twitter/ https://decatec.de/allgemein/auf-dem-laufenden-bleiben-mit-twitter/#comments Sun, 29 Jul 2018 07:49:09 +0000 https://decatec.de/?p=4413 DecaTec Logo

Hier ein kurzer Hinweis für die Leser dieses Blogs. Die IT-Welt ist recht schnelllebig und dies merkt man besonders als Tech-Blogger. Ich versuche daher alle (auch ältere) Artikel auf einem aktuellen Stand zu halten. Wenn ich daher Änderungen an einem Artikel vornehme, pflege ich dabei immer eine Update-History, welche die vorgenommenen Änderungen an einem Artikel nachvollziehbar macht (z.B. bei neuen Programm-Versionen).

Für Leser ist dieses Vorgehen leider nicht sonderlich komfortabel. Man muss regelmäßig in meinem Blog vorbeischauen (das sehe ich natürlich gern) und dann aber noch sämtliche interessanten Artikel nach Updates durchforsten. Dies ist recht aufwändig und u.U. zeitintensiv.

Nun wurde ich schon von einigen Lesern abgesprochen, ob ich mich mal einen Newsletter einrichten könnte, mit dem ich aktiv informieren, wenn ein Artikel ein Update verpasst bekommen hat. Dank der DSGVO wäre dieses Unterfangen für mich aber leider recht aufwändig und schwer umzusetzen.

Update: Für alle, die Twitter nicht nutzen möchte, gibt es nun eine Übersichts-Seite mit allen Änderungen im Blog.

Twitter als Newsletter-Alternative

Aus diesem Grund will ich es ab nun mit Twitter als eine Art „Newsletter light“ ausprobieren. Wenn es nun ein Update gibt, werde ich dies kurz über Twitter kundtun. Dies sieht dann beispielsweise so aus:

Artikel-Update bei Twitter

Artikel-Update bei Twitter

Um nun aktiv über Änderungen in meinem Blog informiert zu werden, braucht ihr zunächst einen Twitter-Account (falls noch nicht vorhanden). Hier könnt ihr mir dann auf meinem Account @decatec_de folgen. Anschließend erscheinen Updates in regelmäßigen Abständen in eurem Twitter-Feed.

Was haltet ihr davon? Ist dies eine gute Alternative zu einem richtigen Newsletter? Hinterlasst mir dazu doch einfach einen Kommentar.

Update: Übersicht über alle Änderungen im Blog in der Update-Historie

Ich kann allerdings auch gut verstehen, wenn jemand Twitter aus verschiedenen Gründen nicht nutzen möchte.

Für diesen Fall habe ich nun eine Blog-weite Update-Historie hinzugefügt, in der zukünftig alle Änderungen und Updates des Blogs dokumentiert werden.

Die entsprechende Seite findet ihr entweder in der Header-Leiste oder unter den Direktlinks:

Update-Historie für decatec.de

Update-Historie für decatec.de

Die Leser haben nun die Wahl: Entwerder per Push-Prinzip über Twitter informiert werden, oder einfach im Pull-Prinzip regelmäßig über die Update-Seite auf dem Laufenden bleiben. So sollte für jeden etwas dabei sein.

Links

]]>
https://decatec.de/allgemein/auf-dem-laufenden-bleiben-mit-twitter/feed/ 3
Nextcloud: Online-Office mit ONLYOFFICE https://decatec.de/home-server/nextcloud-online-office-mit-onlyoffice/ https://decatec.de/home-server/nextcloud-online-office-mit-onlyoffice/#comments Fri, 29 Jun 2018 13:41:55 +0000 https://decatec.de/?p=4369 Nextcloud Logo

Ein klassisches Anwendungsgebiet für „die Cloud“ ist das Erstellen und die Bearbeitung von Office-Dokumenten. Diese können dann meistens direkt im Browser auch durch mehrere Benutzer gleichzeitig editiert werden. Nextcloud bietet dieses Feature nicht direkt out-of-the-box, allerdings kann die selbstgehostete Cloud leicht durch Apps erweitert werden. Genau hier setzt ONLYOFFICE an: Durch diese Erweiterung kann Nextcloud einfach um Online-Office-Funktionalitäten erweitert werden.

Dieser Artikel beschreibt daher die Installation und Konfiguration von ONLYOFFICE mittels Docker und das Zusammenspiel mit einer bestehenden Nextcloud-Instanz. Wie immer liegt das Augenmerk v.a. auf der Sicherheit aller beteiligten Systeme.

ONLYOFFICE vs Collabora

Bevor es an die Installation geht, noch ein Hinweis: ONLYOFFICE ist nur eine Möglichkeit, Nextcloud um Online-Office-Funktionalitäten zu erweitern. Eine Alternative dazu ist Collabora. Die Installation und Einrichtung von Collabora habe ich bereits im Artikel Nextcloud: Online-Office mit Collabora beschrieben. Nun stellt sich natürlich die Frage, auf welche Lösung man setzen sollte. Hier gibt es keine eindeutige Empfehlung: Beide Lösungen integrieren sich gut in Nextcloud und bieten ähnliche Features.

Die Unterschiede zwischen den Office-Lösungen weden in diesem Artikel detailliert beschrieben. Aber Achtung: der Vergleich wurde von ONLYOFFICE veröffentlicht, daher ist es nicht auszuschließen, dass hier eine Lösung per se besser abschneidet. Der Artikel ist aber trotzdem interessant, da er auch die Unterschiede in der technischen Umsetzung beider Lösungen beleuchtet.

Was für den Endanwender sicherlich am wichtigsten ist: Collabora kommt aus der LibreOffice-Ecke und bietet daher die beste Unterstützung für die OpenDocument-Formate. Bei der Entwicklung von ONLYOFFICE wurde von Anfang an Wert auf die OOXML-Formate (Office Open XML – die von Microsoft Office bevorzugten Formate) gelegt. Nach eigenen Angaben unterstützt ONLYOFFICE die Microsoft Office Formate zu 100%.

Daher werden Anwender, die hauptsächlich mit Microsoft Office arbeiten, wohl eher die Lösung von ONLYOFFICE bevorzugen. Wer dagegen meist LibreOffice/OpenOffice nutzt, sollte sich Collabora mal näher anschauen.

Am besten einfach mal selbst beide Lösungen ausprobieren: ONLYOFFICE und Collabora können parallel installiert werden, so dass man sich nicht sofort auf eine Office-Variante festlegen muss.

Installation und Konfiguration von ONLYOFFICE

ONLYOFFICE hat einige Abhängigkeiten, so dass eine manuelle Installation durchaus aufwändig ist. Daher beschreibt der Artikel die Installation der Office-Lösung mittels Docker. Dadurch kann ONLYOFFICE in wenigen Schritten schnell und einfach installiert werden.

Voraussetzungen

Folgende Voraussetzungen sind für den Betrieb von ONLYOFFICE zu erfüllen:

  • Ein System, auf dem Docker installiert ist. Im Rahmen des Artikels setze ich Ubuntu Server ein, allerdings sollten die Schritte auch auf andere Distributionen übertragbar sein. Wie Docker selbst installiert wird, wurde bereits im Artikel Docker auf Ubuntu Server erklärt.
  • ONLYOFFICE ist recht speicherintensiv. Daher sollte auf dem entsprechenden PC/VM mindestens 4 GB RAM verfügbar sein (besser noch 6 GB). Aus genau diesem Grund wird ONLYOFFICE auch auf einem Raspberry Pi (Affiliate-Link) nicht optimal laufen. Auch wenn es prinzipiell möglich ist, ONLYOFFICE auf einem solchen Kleinst-Rechner zu betreiben, wird die Performance hier zu wünschen übriglassen.
  • Nextcloud muss über eine gesicherte SSL-Verbindung erreichbar sein. Wer die Cloud wie im Artikel Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban beschrieben installiert hat, ist bestens vorbereitet, da hier ein SSL-Zertifikat von Let’s Encrypt zum Einsatz kommt.

Häufig liest man, dass ONLYOFFICE nicht auf demselben Rechner wie Nextcloud installiert werden sollte, da es hier zu Problemen kommen könnte. Dies trifft allerdings nur dann zu, wenn ONLYOFFICE manuell installiert wird. Wenn die Office-Lösung wie hier beschrieben über Docker läuft, dann kann ONLYOFFICE problemlos auf der gleichen Maschine wie Nextcloud betrieben werden.

Es ist aber natürlich auch möglich, ONLYOFFICE auf einem anderen Rechner (z.B. eine zweite virtuelle Maschine) zu installieren. In diesem Fall müssen nur die IP-Adressen entsprechend angepasst werden.

Vorbereitung: Zertifikat erstellen

Die Kommunikation zwischen Nextcloud und ONLYOFFICE muss über eine gesicherte SSL-Verbindung erfolgen. Hier kann der Einfachheit halber ein selbst signiertes Zertifikat zum Einsatz kommen.
Es wäre auch möglich, ein eigenes Zertifikat von Let’s Encrypt speziell für die ONLYOFFICE-Verbindung zu nutzen. Der Aufwand wäre hier allerdings etwas höher, da sämtliche Requests dann durch den nginx Gateway-Host geleitet werden oder die Zertifikate immer manuell kopiert werden müssten (Let’s Encrypt Zertifikate haben nur eine Gültigkeitsdauer von 90 Tagen).
Ein selbst signiertes Zertifikat ist hier das Mittel der Wahl, da es einfach erzeugt werden kann und die Verbindung trotzdem verschlüsselt ist. Auch muss man hier keinerlei Anpassungen am Webserver vornehmen, was eine zusätzliche Fehlerquelle wäre.

Das Zertifikat wird durch die folgenden Befehle angelegt:

mkdir -p /app/onlyoffice/DocumentServer/data/certs
cd /app/onlyoffice/DocumentServer/data/certs
openssl genrsa -out onlyoffice.key 4096
openssl req -new -key onlyoffice.key -out onlyoffice.csr
openssl x509 -req -days 3650 -in onlyoffice.csr -signkey onlyoffice.key -out onlyoffice.crt
openssl dhparam -out dhparam.pem 4096
chmod 400 onlyoffice.key
chmod 400 onlyoffice.crt
chmod 400 onlyoffice.csr
chmod 400 dhparam.pem

  • Beim Befehl openssl req -new -key onlyoffice.key -out onlyoffice.csr wird man nach dem „Common Name“ gefragt (Common Name (e.g. server FQDN or YOUR name)). Hier ist einfach die IP des lokalen Systems anzugebnen (z.B. 192.168.178.60). Ebenso kann man ein „challenge password“ angeben. Dieses kann man einfach leer lassen (einfach mit Enter bestätigen).
  • Achtung: Die Erzeugung der sog. Diffie-Hellmann-Parameter mit einer Länge von 4096 Bit (openssl dhparam -out dhparam.pem 4096) kann u.U. sehr lange dauern. Auf schwacher Hardware kann das schon einmal mehrere Stunden in Anspruch nehmen. Wer nicht so lange warten möchte, kann die Schlüssel-Länge auf 2048 Bit reduzieren (openssl dhparam -out dhparam.pem 2048).
  • Das Zertifikat hat eine Gültigkeit von 3650 Tagen (10 Jahre). Hier kann bei Bedarf auch eine andere Gültigkeitsdauer angegeben werden.

Installation in einem Schritt

Die Installation von ONLYOFFICE erfolgt dann dank Docker mit nur einem einzigen Befehl:

docker run --name=ONLYOFFICEDOCKER -i -t -d -p 4433:443 -e JWT_ENABLED='true' -e JWT_SECRET='geheimes-secret' --restart=always -v /app/onlyoffice/DocumentServer/data:/var/www/onlyoffice/Data onlyoffice/documentserver

Folgende Punkte gilt es hier zu beachten:

  • Da der Webserver bereits auf dem Port 443 (HTTPS) lauscht, kann der Docker-Container nicht den gleichen Port belegen. Der Parameter -p 4433:443 sorgt dafür, dass der Container selbst mit dem Port 443 (intern) arbeitet, nach außen wird jedoch der Port 4433 genutzt.
  • Die nächsten zwei Parameter (-e JWT_ENABLED=’true‘ -e JWT_SECRET=’geheimes-secret‘) sorgen dafür, dass zur Kommunikation mit dem Container ein sog. JSON Web Token benötigt wird. Im Grunde genommen handelt es sich dabei um ein Passwort („geheimes-secret“ – hier sollte man natürlich ein eigenes Passwort wählen), welches später in Nextcloud hinterlegt werden muss, damit die Verbindung zum ONLYOFFICE Container aufgebaut werden kann. Dies verhindert, dass der ONLYOFFICE-Container „unbemerkt“ von anderen Verbindungen genutzt werden kann.
  • Mit –restart=always wird angegeben, dass der Container bei jedem Systemstart hoch gefahren wird. Damit „überlebt“ der Docker-Container auch Neustarts des Systems.
  • Der letzte Parameter (-v /app/onlyoffice/DocumentServer/data:/var/www/onlyoffice/Data onlyoffice/documentserver) definiert ein sog. Volume: Alle Dateien, die im Verzeichnis /app/onlyoffice/DocumentServer/data des Hosts liegen, werden innerhalb des Containers im Verzeichnis /var/www/onlyoffice/Data onlyoffice/documentserver bereit gestellt. Diese Funktion wird benötigt, damit der Container das zuvor erzeugte Zertifikat nutzen kann.

Nun wird der ONLYOFFICE-Container heruntergeladen (ca. 650 MB), was je nach Internetverbindung ein paar Minuten dauern kann.

Installation von ONLYOFFICE mittels Docker

Installation von ONLYOFFICE mittels Docker

Ob der Container ordnungsgemäß läuft, kann man testen, indem man über den Browser eine Verbindung aufbaut (die URL dazu ist in unserem Fall https://192.168.178.60:4433). Durch den Einsatz des selbst signierten Zertifikats wird der Browser eine Warnung ausgeben, das stört uns an dieser Stelle allerdings nicht.

ONLYOFFICE läuft

ONLYOFFICE läuft

Nextcloud: ONLYOFFICE App aktivieren

Damit ONLYOFFICE nun aus Nextcloud heraus angesprochen werden kann, braucht man noch die entsprechende App. Man findet diese im App-Store von Nextcloud in der Kategorie Büro & Text.

ONLYOFFICE im Nextcloud App-Store

ONLYOFFICE im Nextcloud App-Store

Nextcloud-Konfiguration anpassen

Bevor nun die Verbindung zu ONLYOFFICE in Nextcloud hinterlegt werden kann, muss noch eine kleine Anpassung an der Konfiguration von Nextcloud erfolgen. Dazu wird die Konfiguration mit folgendem Befehl auf der Konsole geöffnet:

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

Hier wird nun am Ende der Datei (aber vor der letzten schließenden Klammer) ein Eintrag hinzugefügt:

'onlyoffice' =>
array (
    'verify_peer_off' => true,
),

Dieser Schritt ist zwingend erforderlich, da Nextcloud sonst die Verbindung zu ONLYOFFICE auf Grund des selbst signierten Zertifikats nicht zulässt.

Am Schluss sollte der ganze Rechner einmal neu gestartet werden:

reboot now

Verbindung zwischen Nextcloud und ONLYOFFICE herstellen

Der letzte Schritt zu einer Online-Office-Lösung mit Nextcloud ist nun nur noch das Hinterlegen der Verbindungs-Details zwischen der Cloud und ONLYOFFICE.

Dazu in Nextcloud einfach in die Einstellungen gehen. Unter Verwaltung > ONLYOFFICE findet man nun die entsprechenden Einstellungen:

  • Serviceadresse der Dokumentbearbeitung: Hier wird die IP-Adresse des Systems angegeben, auf dem der entsprechende Docker-Container läuft. In unserem Beispiel hat er PC die IP 192.168.178.60, daher wird hier https://192.168.178.60:4433 angegeben. Wichtig ist hier der Port, der auch beim Starten des Docker-Containers angegeben wurde (4433).
  • Geheimer Schlüssel (freilassen, um zu deaktivieren): Hier ist das JWT-Token anzugeben, welches beim Starten des Docker-Containers angegeben wurde.
  • Alle anderen Felder kann man leer lassen.
ONLYOFFICE Einstellungen in Nextcloud

ONLYOFFICE Einstellungen in Nextcloud

Nach einem Klick auf Speichern sollte eine Erfolgsmeldung kommen und die Verbindung zwischen Nextcloud und ONLYOFFICE wurde erfolgreich konfiguriert.

Online-Office im Browser

In der Datei-Ansicht von Nextcloud können nun einfach Office-Dokumente angelegt werden bzw. hochgeladen werden. Mit einem Klick werden diese nun mit ONLYOFFICE geöffnet und man kann mit der Bearbeitung beginnen.

Online-Office mit Nextcloud und ONLYOFFICE

Online-Office mit Nextcloud und ONLYOFFICE

Update von ONLYOFFICE

Von Zeit zu Zeit erscheinen nun neue Versionen des Docker-Containers von ONLYOFFICE. Um hier ein Update durchzuführen, sind nur wenige Schritte erforderlich.

Zunächst muss die ID des laufenden Containers mit folgendem Befehl ermittelt werden:

docker ps

Der Container wird gestoppt und entfernt:

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

Die neue Version des Containers wird über diesen Befehl herunter geladen:

docker pull onlyoffice/documentserver

Nun kann der aktualisierte Container wie gewohnt gestartet werden:

docker run --name=ONLYOFFICEDOCKER -i -t -d -p 4433:443 -e JWT_ENABLED='true' -e JWT_SECRET='geheimes-secret' --restart=always -v /app/onlyoffice/DocumentServer/data:/var/www/onlyoffice/Data onlyoffice/documentserver

Troubleshooting

Manchmal kann es passieren, dass die Verbindung zum ONLYOFFICE-Server nicht auf Anhieb klappen will. Die Probleme können aber meist relativ schnell aus dem Weg geräumt werden.

Fehler beim Aufruf von ONLYOFFICE über den Browser

Um zu prüfen, ob ONLYOFFICE ordnungsgemäß läuft, kann man die IP der Maschine direkt im Browser aufrufen (in diesem Beispiel: https://192.168.178.60:4433). Wenn hier nur eine Fehlermeldung erscheint, dass die Website nicht erreichbar ist, sollte der laufende Docker-Container überprüft werden.

Zunächst wird die Container-ID ermittelt:

docker ps

Anschließend kann man sich die Logs des Containers anzeigen lassen:

docker logs <Container-ID>

Hier kann es vorkommen, dass ähnliche Meldungen wie diese angezeigt werden:

* Starting PostgreSQL 9.5 database server                               [ OK ]
* Starting RabbitMQ Messaging Server rabbitmq-server                    [ OK ]
Starting redis-server: redis-server.
Starting supervisor: supervisord.
* Starting nginx nginx                                                  [ OK ]
Generating AllFonts.js, please wait...Done
onlyoffice-documentserver:docservice: stopped
onlyoffice-documentserver:docservice: started
onlyoffice-documentserver:converter: stopped
onlyoffice-documentserver:converter: started
* Reloading nginx configuration nginx                                   [ OK ]
root@35b07178f48a:/#  * Starting PostgreSQL 9.5 database server          [ OK ]
* Starting RabbitMQ Messaging Server rabbitmq-server                            * FAILED - check /var/log/rabbitmq/startup_\{log, _err\}
                                                                         [fail]
Starting redis-server: redis-server.
Waiting for connection to the localhost host on port 5672
Waiting for connection to the localhost host on port 5672
Waiting for connection to the localhost host on port 5672
Waiting for connection to the localhost host on port 5672

Hier gibt es momentan wohl noch hin und wieder Probleme (siehe GitHub-Issues hier und hier). In diesem Fall hilft es meistens, den Docker-Container oder besser noch den ganzen PC neu zu starten (zur Not auch mehrmals).

Fehlermeldung beim Einbinden von ONLYOFFICE in Nextcloud

Wenn beim Konfigurieren der Verbindung zum ONLYOFFICE-Server eine Fehlermeldung auftritt (Fehler beim Anschließen (Bad Request oder Timeout Fehlermeldung)), sollte man zunächst mal das Log von Nextcloud überprüfen. Hier sollte meinst ein Hinweis auf das konkrete Problem zu finden sein.

Folgende Log-Meldung weist z.B. auf die fehlende Anpassung der config.php von Nextcloud in Bezug auf ONLYOFFICE hin (siehe hier):

file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed at /var/www/nextcloud/apps/onlyoffice/lib/documentservice.php#351

Fazit

Dank des verfügbaren Docker-Container für ONLYOFFICE kann Nextcloud schnell und einfach um Online-Office-Funktionen ergänzt werden. Da prinzipiell auch kein zweiter PC/VM zum Einsatz kommen muss, ist dies eine sinnvolle Erweiterung jeder Nextcloud-Installation.

Ihr konntet ONLYOFFICE mit diesem Tutorial erfolgreich installieren oder hattet mit der Vorgehensweise noch Probleme? Oder bevorzugt ihr Collabora als Online-Office-Lösung für Nextcloud? Dann hinterlasst doch einfach einen Kommentar.

Weiterführende Artikel

Links

]]>
https://decatec.de/home-server/nextcloud-online-office-mit-onlyoffice/feed/ 25
Nextcloud: Web-Mail mit RainLoop https://decatec.de/home-server/nextcloud-web-mail-mit-rainloop/ https://decatec.de/home-server/nextcloud-web-mail-mit-rainloop/#comments Wed, 13 Jun 2018 14:03:42 +0000 https://decatec.de/?p=4341 Nextcloud LogoDie Cloud ist heutzutage ja der zentrale Dreh- und Angelpunkt in der digitalen Welt. Wer es mit Nextcloud geschafft hat, sich aus den Fängen der großen Cloud-Anbieter zu befreien, der möchte sicherlich möglichst viele Features auch über die eigene Cloud nutzen. Neben der Verwaltung von Dateien, Kontakten, Kalendern, u.v.m., ist es mit der App RainLoop auch möglich, die komplette E-Mail-Kommunikation in die selbstgehostete Cloud zu verlegen.

Achtung: Das RainLoop-Plugin für Nextcloud wird momentan nicht mehr weiter entwickelt und wird voraussichtlich unter Nextcloud 14 nicht mehr lauffähig sein (Quelle: GitHub). Falls kein neuer Maintainer für das RainLoop-Nextcloud Projekt gefunden wird, sollte man sich daher nach Alternativen umsehen.

Web-Mail mit Nextcloud: RainLoop oder Mail-App

Für das Senden und Empfangen von E-Mails stehen im Nextcloud App Store zwei unterschiedliche Apps bereit: RainLoop und die Nextcloud-eigene App Mail.

„Mail“ ist dabei (im Moment noch) ein ziemlich rudimentärer Webmailer mit einem recht geringen Funktionsumfang (beispielsweise ist es damit nicht möglich, E-Mail-Signaturen zu verwenden). Evtl. werden fehlende Funktionen in Zukunft noch nachgereicht. Im Moment taugt die App (meiner Meinung nach) allerdings noch nicht dazu, einen „richtigen“ E-Mail-Client zu ersetzen.

Einen sehr viel größeren Funktionsumfang bietet RainLoop. Dieser Webmailer ist schon seit einiger Zeit auf dem Markt und ist ursprünglich eine eigenständige Webanwendung, die (wie Nextcloud) im Normalfall selbst gehostet wird. Mit der Nextcloud-App gibt es aber nun die Möglichkeit, RainLoop innerhalb von Nextcloud zu nutzen, so dass „alles aus einem Guss wirkt“.

Welche der beiden Webmailer nun der bessere ist, kann man pauschal nicht sagen. Am besten einfach mal beide Apps ausprobieren.

In diesem Artikel soll es nun um die Installation und Konfiguration von RainLoop in Nextcloud gehen. Die Einrichtung ist zwar relativ einfach, dennoch gilt es, einige Schritte zu beachten.

Installation

RainLoop muss nicht separat installiert werden, sondern kann einfach über den Nextcloud App Store bezogen werden. Dazu einfach im App Store unter der Kategorie Kommunikation nach RainLoop suchen und aktivieren.

Nach ein paar Augenblicken sollte die App installiert worden sein und man findet in der Nextcloud-Menüleiste einen zusätzlichen Eintrag für Mail.

Konfiguration

Bevor man RainLoop nun nutzen kann, muss die Anwendung zunächst einmal konfiguriert werden. Dazu findet man in Nextcloud in den Admin-Einstellungen unter Zusätzliche Einstellungen den Punkt Go to RainLoop Webmail admin panel.

Nach einem Klick meldet man sich nun an:

  • Benutzername: admin
  • Passwort: 12345

Ja, dies ist ein Standard-Passwort, dass immer gleich ist und sofort geändert werden sollte. Dazu in das Menü Security wechseln und ein neues Passwort unter Admin Panel Access Credentials vergeben.

Nach diesem vielleicht wichtigsten Schritt können sämtliche anderen Optionen nach Bedarf gesetzt werden. Beispielsweise empfiehlt es sich, unter General Deutsch als Sprache zu wählen, damit die Benutzer eine Deutsche Oberfläche präsentiert bekommen.

Einen Punkt sollte man noch gleich mit anpassen: RainLoop präsentiert auf der Admin-Seite eine Warnung:

Warnung!

RainLoop data folder is accessible. Please configure your web server to hide the data folder from external access. Read more here: https://www.rainloop.net/docs/installation

Hintergrund ist, dass das Datenverzeichnis von RainLoop aus Sicherheitsgründen nicht direkt aus dem Internet erreichbar sein sollte, sondern nur über die Anwendung selbst.

Hier ist es notwendig, eine kleine Anpassung an der Webserver-Konfiguration vorzunehmen. Ich gehe im Folgenden davon aus, dass der Webserver wie im Artikel Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban eingerichtet wurde. Wenn ein anderer Webserver oder eine andere Konfiguration zum Einsatz kommt, müssen die folgenden Schritte evtl. noch ein wenig angepasst werden.

Die Änderung muss im vHost für Nextcloud vorgenommen werden:

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

Hier fügen wir unter dem letzten location-Block (aber noch vor der schließenden Klammer des server-Blocks) folgenden Inhalt ein:

location ^~ /nextcloud/apps/rainloop/app/data {
    deny all;
}

Durch die Änderungen am vHost muss der Webserver noch neu gestartet werden:

service nginx restart

Nun kann man wieder zu RainLoop wechseln und nach einem Refresh der Seite (STRG + F5) sollte die Warnung verschwunden sein.

Einrichtung von E-Mail-Konten

Die Einrichtung von E-Mail-Konten unterscheidet RainLoop von vielen anderen Mail-Clients. Um dem Benutzer möglichst viel Arbeit beim Hinzufügen von Accounts abzunehmen, muss der Administrator Mail-Domains vordefinieren. Die Benutzer können sich daraufhin ganz einfach mit ihrer Mail-Adresse anmelden, ohne die üblichen (technischen) Details wie IMAP/SMTP-Server-Adressen, Ports, etc. kennen zu müssen.

Dazu einfach in der Admin-Oberfläche von RainLoop den Punkt Domains wählen. Hier ist Google Mail bereits aktiv, so dass @gmail.com Adressen ohne weiteres Zutun funktionieren sollten. Wenn man nun E-Mail-Adressen von anderen Anbietern (z.B. GMX, Web.de, etc.) nutzen möchte, dann muss man diese hier als Domain konfigurieren.

Dazu einfach den Button Domain hinzufügen klicken. Wichtig ist nun, dass die komplette Domain als Name eingetragen wird. Bei GMX wäre dies also „gmx.de“ und eben nicht „gmx“, ansonsten ist eine Anmeldung an RainLoop mit einer@gmx.de Adresse nachher nicht möglich. An dieser Stelle können übrigens auch Wildcards verwendet werden: Möchte man daher sowohl Anmeldungen mit @gmx.de und @gmx.net zulassen, kann als Domain einfach „gmx.*“ eingetragen werden.
Die weitere Konfiguration (IMAP- und SMTP-Server, sowie die dazugehörigen Ports, etc.) ist abhängig vom Mail-Provider. Diese Informationen findet man häufig auf den Hilfeseiten der jeweiligen Anbieter (z.B. Serverdaten für IMAP und SMTP bei GMX).

RainLoop: Domain für GMX hinzufügen

RainLoop: Domain für GMX hinzufügen

Webmail-Oberfläche

Die Anmeldung an RainLoop ist für Benutzer dank der „Admin-Vorarbeit“ nun besonders einfach: Im Nextcloud-Menü einfach das Mail-Symbol wählen und sich mit der entsprechenden Mail-Adresse und dem Passwort des Mail-Accounts (nicht das Passwort des Nextcloud-Accounts) einloggen. Nun können sofort Mail geschrieben und empfangen werden.

Bessere Integration in Nextcloud

Leider ist RainLoop als eigenständige Webanwendung (noch) nicht so gut in Nextcloud integriert. Dies merkt man z.B., wenn man eine Mail verfassen möchte: Hier kann man nicht aus den bestehenden Kontakten aus Nextcloud wählen.

Die Integration mit Nextcloud kann daher nicht etwas verbessert werden. RainLoop kann dabei nicht direkt auf die Nextcloud-Kontakte zugreifen, sondern verwaltet diese in einer eigenen Datenbank. Diese muss dazu erst einmal auf der Kommandozeile angelegt werden:

mysql -u root -p

Nach der Eingabe des Root-Passworts kann die Datenbank für RainLoop angelegt werden:

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

Zurück in der Admin Oberfläche findet man unter dem Punkt Kontakte die Einstellungen zur Verwaltung der Kontakte.

Hier konfiguriert man zunächst einmal die Datenbank-Verbindung:

  • Typ: MySQL
  • DSN: mysql:host=localhost;port=3306;dbname=rainloop_db
  • Benutzer: rainloop_db_user
  • Passwort: Das oben vergebene Passwort

Nun sollte bei einem Klick auf Testen der Button nach ein paar Augenblicken grün werden. Das ist das Zeichen, dass die Datenbank-Verbindung erfolgreich aufgebaut werden konnte.

Zu guter Letzt aktiviert man nun weiter oben noch die Optionen Kontakte aktivieren (damit RainLoop überhaupt Kontakte unterstützt) und Kontakte-Synchronisierung erlauben (mit externem CardDAV-Server). Letzteres wird benötigt, damit die Synchronisierung mit Nextcloud funktioniert.

Nun loggt man sich wieder über Nextcloud auf einen Mail-Account bei RainLoop ein. In den Optionen des Benutzers (Zahnrad unten links) findet man nun den Menüpunkt Kontakte. Hier kann man zunächst einmal die Synchronisierung mit Nextcloud ermöglichen (Remote-Synchronisierung aktivieren).

Die CardDAV-URL findet man in der Kontakte-App von Nextcloud: Einfach beim gewünschten Adressbuch auf das Menü klicken (die drei Punkte) und den Eintrag Link kopieren wählen.

CardDAV-URL in Nextcloud ermitteln

CardDAV-URL in Nextcloud ermitteln

Diese URL kann man dann nebst Benutzername und Passwort (von Nextcloud) in den RainLoop-Kontakte-Einstellungen hinterlegen.

RainLoop: Kontakte (Einstellungen)

RainLoop: Kontakte (Einstellungen)

Die obere Option (Empfänger automatisch zu Ihrem Adressbuch hinzuzufügen) ist ein zweischneidiges Schwert: Auf der einen Seite ist es sicher praktisch, wenn Mail-Adressen automatisch nach Nextcloud synchronisiert werden, auf der anderen Seite werden kann sämtliche Empfänger-Adressen ungefragt zu Nextcloud übernommen. Wer oftmals Mails an die unterschiedlichsten Empfänger versendet, will diese Option wohl deaktivieren, da ansonsten die Kontakte-App von Nextcloud regelrecht „zugemüllt“ wird.

Nun können die Kontakte zwischen RainLoop und Nextcloud einfach über den Kontakte-Button und das erweiterte Menü (drei Balken) in RainLoop synchronisiert werden.

RainLoop: Kontakte synchronisieren

RainLoop: Kontakte synchronisieren

Fazit

RainLoop ist ein fortschrittlicher Webmailer mit einem gut durchdachten Konzept und einfacher Bedienung. Zwar merkt man hier und da, dass RainLoop als eigenständige Web-Anwendung neben Nextcloud läuft, dennoch klinkt sich der Webmailer nahtlos in die eigene Nextcloud ein.

Wer seine Mails direkt über Nextcloud verwalten möchte und keinen „schwergewichtigen“ E-Mail-Client wie Outlook oder Thunderbird nutzen möchte, der wird mit RainLoop auf jeden Fall auf seine Kosten kommen.

Weiterführende Artikel

Links

]]>
https://decatec.de/home-server/nextcloud-web-mail-mit-rainloop/feed/ 4
Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban https://decatec.de/home-server/nextcloud-auf-ubuntu-server-18-04-lts-mit-nginx-mariadb-php-lets-encrypt-redis-und-fail2ban/ https://decatec.de/home-server/nextcloud-auf-ubuntu-server-18-04-lts-mit-nginx-mariadb-php-lets-encrypt-redis-und-fail2ban/#comments Wed, 30 May 2018 14:04:49 +0000 https://decatec.de/?p=4137 Nextcloud LogoDieser Artikel beschreibt die Installation und Konfiguration von Nextcloud auf Ubuntu Server 18.04 LTS („Bionic Beaver“) mit nginx, MariaDB, PHP und Let’s Encrypt. Zur Verbesserung der Sicherheit und Performance wird ebenfalls die Einrichtung von Redis, Fail2ban und ufw behandelt.

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

Update-Historie (letztes Update: 10.06.2018)
  • 31.05.2018:
    • SSL-Konfiguration im Gateway-Host geändert: unter ssl_trusted_certificate wird nun die Datei chain.pem angegeben.
  • 02.06.2018:
    • Anleitung zum Aktivieren von 4-Byte-Support der Nextcloud-Datenbank hinzugefügt.
  • 07.06.2018:
    • Anleitung für nginx 1.15 überarbeitet (Achtung: veränderte Verzeichnisstruktur).
  • 08.06.2018:
    • Gateway-Host: Anpassung von ssl_ciphers und ssl_ecdh_curve.
    • Der SSL-Test sollte nun A+ (100%) ergeben.
  • 10.06.2018:
    • Warnung für die Aktivierung vom 4-Byte-Support hinzugefügt, da dies auf manchen Systemen zu Problemen führen kann.
  • 13.06.2018:
    • Hinweis für Internet-Anschlüsse mittels DS-Lite hinzugefügt. Um die Schritte dieses Tutorials durchzuführen, wird ein „echter“ IPv4-Anschlus benötigt.
    • Hinweis auf Zertifikat-Erneuerung durch Certbot überarbeitet, da bei der Installation automatisch ein Cronjob eingerichtet wird.

 

Motivation, Voraussetzungen und Konzept des Artikels

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

Ziele

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

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

Zeitaufwand und Programm-Versionen

Zeitaufwand: ca. 3 Stunden

Eingesetzte Programm-Versionen:

  • Ubuntu Server 18.04 LTS („Bionic Beaver“)
  • Nextcloud 13.0.4
  • nginx 1.15.0
  • MariaDB 10.3.7
  • PHP 7.2
  • Redis 4.0.9
  • Fail2ban 0.10.2

Voraussetzungen

Betriebssystem und Hardware

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

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

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

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

Zugriff per SSH

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

DynDNS

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

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

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

Internet-Anschluss

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

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

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

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

Root-Rechte auf dem Server

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

Konzept

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

LEMP-Stack statt LAMP-Stack

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

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

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

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

Virtuelle Hosts und Konfigurations-Dateien von nginx

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

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

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

Hinweis bei abweichender Verzeichnisstruktur bei nginx

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

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

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

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

Die Aufteilung in mehrere virtuelle Hosts

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

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

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

    Schematische Darstellung: Einzelner vHost für mehrere Webanwendungen

    Schematische Darstellung: Einzelner vHost für mehrere Webanwendungen

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

    Schematische Darstellung: Ein vHost pro Webanwendung (Eindeutigkeit durch unterschiedliche Ports)

    Schematische Darstellung: Ein vHost pro Webanwendung (Eindeutigkeit durch unterschiedliche Ports)

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

    Schematische Darstellung: Gateway-Host und einzelne vHosts pro Webanwendung

    Schematische Darstellung: Gateway-Host und einzelne vHosts pro Webanwendung

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

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

Installation und Konfiguration aller benötigten Programme

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

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

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

Betriebssystem-Updates

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

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

Programm-Installation

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

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

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

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

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

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

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

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

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

nginx

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

Paketquellen hinzufügen

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

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

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

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

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

Hier fügen wir folgenden Inhalt ein:

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

Installation nginx

Nach der Aktualisierung der Paketquellen kann der Webserver installiert werden:

apt-get update
apt-get install nginx

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

Der Webserver läuft

Der Webserver läuft

MariaDB

Also nächstes wird das Datenbank-System installiert.

Paketquellen hinzufügen

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

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

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

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

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

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

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

Installation MariaDB

Nun kann das Datenbanksystem installiert werden:

apt-get update
apt-get install mariadb-server

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

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

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

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

PHP

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

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

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

Let’s Encrypt/Certbot

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

apt-get update
apt-get install certbot

Konfiguration Programme/Server

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

Konfiguration nginx

Zunächst wird die globale Konfiguration von nginx angepasst:

nano /etc/nginx/nginx.conf

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

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

Default-Seite deaktivieren

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

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

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

Konfiguration MariaDB

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

mysql_secure_installation

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

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

Konfiguration PHP

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

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

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

Folgende Anpassungen sollte man hier vornehmen:

  • user/group: Der Benutzer, unter dem PHP ausgeführt wird. Dies ist wieder unser Webserver-User, also
    user = www-data
    group = www-data
  • listen: Die Kommunikation zwischen Webserver und PHP soll über einen Socket ablaufen. Dazu muss hier folgendes angegeben werden:
    listen = /run/php/php7.2-fpm.sock
  • Umgebungs-Variablen: Umgebungs-Variablen werden von PHP standardmäßig nicht veräußert, diese sind aber für den Betrieb von Nextcloud zwingend erforderlich. Dazu suchen wir nach dem Eintrag  Pass environment variables like LD_LIBRARY_PATH. ALL $VARIABLES are taken from the current environment (Shortcut für die Suche in nano: STRG + W). Alle Einträge, die hier mit env beginnen, sind hier auskommentiert. Durch das Entfernen der Semikola am Zeilenanfang werden die Kommentare entfernt und die Weitergabe der Umgebungs-Variablen aktiviert:
    env[HOSTNAME] = $HOSTNAME
    env[PATH] = /usr/local/bin:/usr/bin:/bin
    env[TMP] = /tmp
    env[TMPDIR] = /tmp
    env[TEMP] = /tmp

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

Folgende Werte sollten in der php.ini angepasst werden:

nano /etc/php/7.2/fpm/php.ini

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

    cgi.fix_pathinfo = 0

  • open_basedir: Schränkt den Zugriff von PHP auf das Webroot- und das temporäre Verzeichnis ein. Dadurch kann PHP aus Sicherheitsgründen auf sonst keine Dateien des Systems zugreifen oder diese verändern.

    open_basedir = /var/www/:/tmp/

  • opcache: Dies sind die Werte zum Konfigurieren des PHP OPcache (erhöht die Performance durch das Ablegen vorkompilierten Bytecodes in den Arbeitsspeicher). Diese Einträge sollten in der php.ini bereits vorhanden sein (allerdings auskommentiert). Eine Suche in der Datei sollte einiges an Tipparbeit sparen. Folgende Werte sind hier anzugeben:

    opcache.enable = 1
    opcache.enable_cli = 1
    opcache.memory_consumption = 128
    opcache.interned_strings_buffer = 8
    opcache.max_accelerated_files = 10000
    opcache.revalidate_freq = 1
    opcache.save_comments = 1

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

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

Folgende Einstellungen sollten an dieser Stelle angepasst werden:

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

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

service php7.2-fpm restart

Verzeichnisstruktur vorbereiten

Als nächstes werden die für die folgenden Schritte benötigten Verzeichnisse angelegt. Die Besitzrechte sollten dabei beim Webserver-User (www-data) liegen:

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

Anlegen des Gateway-Hosts

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

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

Hier reichen zunächst folgende Zeilen:

server {
	listen 80 default_server;
	server_name meinedomain.de 192.168.178.60;
 
	root /var/www;
	
	location ^~ /.well-known/acme-challenge {
		proxy_pass http://127.0.0.1:81;
		proxy_redirect off;
	}		
}

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

Anlegen des virtuellen Hosts für Let’s Encrypt

Damit auch ein Ziel für die Weiterleitung vorhanden ist, wird nun der vHost für Let’s Encrypt angelegt:

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

Auch dieser virtuelle Host ist dabei sehr einfach aufgebaut:

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

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

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

service nginx restart

SSL-Zertifikat mit Let’s Encrypt/Certbot erzeugen

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

Port-Forwarding und DynDNS einrichten

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

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

Generierung des SSL-Zertifikats

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

certbot certonly --webroot -w /var/www/letsencrypt -d meinedomain.de --rsa-key-size 4096

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

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

Das SSL-Zertifikat wurde erfolgreich erzeugt

Das SSL-Zertifikat wurde erfolgreich erzeugt

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

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

Diffie-Hellman-Parameter

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

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

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

Zugriffsberechtigungen für Zertifikat-Dateien setzen

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

find /etc/letsencrypt/live/ -name "*.pem" -exec chmod 600 {} \;
chmod 600 /etc/nginx/ssl/dhparams.pem

Erneuerung der Zertifikate

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

Bei der hier gezeigten Installation von Certbot wird auf den meisten Systemen ein Cronjob eingerichtet, der die Erneuerung der Zertifikate automatisch vornimmt. Hier muss man sich dann nicht mehr selbst um die Erneuerung der Zertifikate kümmern.

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

nano /var/log/letsencrypt/letsencrypt.log

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

2018-06-11 18:11:38,847:DEBUG:certbot.main:certbot version: 0.23.0
2018-06-11 18:11:38,848:DEBUG:certbot.main:Arguments: ['-q']
2018-06-11 18:11:38,849:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#manual,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2018-06-11 18:11:38,874:DEBUG:certbot.log:Root logging level set at 30
2018-06-11 18:11:38,875:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2018-06-11 18:11:38,896:DEBUG:certbot.plugins.selection:Requested authenticator <certbot.cli._Default object at 0x7f362dc45748> and installer <certbot.cli._Default object at 0x7f362dc45748>
2018-06-11 18:11:38,919:INFO:certbot.renewal:Cert not yet due for renewal
2018-06-11 18:11:38,921:DEBUG:certbot.renewal:no renewal failures

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

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

certbot renew
service nginx restart

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

Gateway-Host für Nextcloud/SSL vorbereiten

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

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

Die hinzuzufügenden Abschnitte sind hier markiert:

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

server {
	listen 80 default_server;
	server_name meinedomain.de 192.168.178.60;

	root /var/www;
	
	location ^~ /.well-known/acme-challenge {
		proxy_pass http://127.0.0.1:81;
		proxy_redirect off;
	}
	
	location / {
		# Enforce HTTPS
		# Use this if you always want to redirect to the DynDNS address (no local access).
		return 301 https://$server_name$request_uri;
		
		# Use this if you also want to access the server by local IP:
		#return 301 https://$server_addr$request_uri;
    }		
}

server {
	listen 443 ssl http2;
	server_name meinedomain.de 192.168.178.60;
  
	# Certificates used
	ssl_certificate /etc/letsencrypt/live/meinedomain.de/fullchain.pem;
	ssl_certificate_key /etc/letsencrypt/live/meinedomain.de/privkey.pem;
  
	# Not using TLSv1 will break:
	#	Android <= 4.4.40
	#	IE <= 10
	#	IE mobile <=10
	# Removing TLSv1.1 breaks nothing else!
	# TLSv1.3 is not supported by most clients, but it should be enabled.
	ssl_protocols TLSv1.2 TLSv1.3;
	
	# Cipher suite from https://cipherli.st/
	# Max. security, but lower compatibility 
	ssl_ciphers 'ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384';

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

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

	# Diffie-Hellman parameter for DHE ciphersuites, recommended 4096 bits
	ssl_dhparam /etc/nginx/ssl/dhparams.pem;
  
	# Use multiple curves.
	# secp521r1: Not supported by Chrome
	# secp384r1: Not supported by Android (DAVdroid)
	ssl_ecdh_curve secp521r1:secp384r1: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;
	
	# This should be chain.pem
	# See here: https://certbot.eff.org/docs/using.html
	ssl_trusted_certificate /etc/letsencrypt/live/meinedomain.de/chain.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-Frame-Options "SAMEORIGIN" 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, otherwise nginx will show the default site here.
		deny all;
        }	

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

Folgende Änderungen wurden nun durchgeführt:

  • Ein Handler für PHP wurde hinzugefügt. Durch die Platzierung im Gateway-Host ist dieser Handler auch für alle anderen vHosts verfügbar (notwendig, falls mehrere PHP-Anwendungen gehostet werden sollen).
  • Die für Let’s Encrypt benötigten Anweisungen (HTTP) wurden nicht verändert.
  • Anweisungen für die Verwendung des SSL-Zertifikats und weitere Anweisungen bzgl. SSL wurden hinzugefügt. Hintergrund ist, dass nur der Gateway-Host das SSL-Handling übernehmen soll. Alle virtuellen Hosts, die „darunter“ liegen, sollten von der Verwendung von SSL nicht mitbekommen. Auf diese Weise sind alle SSL-Einstellungen an einer Stelle zu finden.
  • Am Ende der Datei wurde eine Weiterleitung an den Nextcloud-vHost angelegt. Wie schon beim vHost für Let’s Encrypt läuft die Kommunikation hier rein Server-intern ab (also über die IP 127.0.0.1). Zu beachten, ist hier die Änderung des Ports: Da der virtuelle Host für Let’s Encrypt bereits auf Port 81 lauscht, nutzen wir hier einen abweichenden Port (82). Dieser ist später für den Nextcloud-vHost wichtig.

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

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

Virtuellen Host für Nextcloud anlegen

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

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

Diese Datei ist mit folgendem Inhalt zu füllen:

server {
    listen 127.0.0.1:82;
    server_name 127.0.0.1;

    # 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 = /nextcloud/.well-known/carddav { 
		return 301 $scheme://$host/nextcloud/remote.php/dav; 
	}
	
    location = /nextcloud/.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;
			
			# Important: disable HTTPS, otherwise no log in will be possible!
            #fastcgi_param HTTPS on;

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

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

        location ~ ^/nextcloud/(?:updater|ocs-provider)(?:$|/) {
            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=15778463";
            # 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;
        }
    }
}

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

  • Es wird nur ein server für HTTP (nicht HTTPS) definiert, da die HTTPS-Kommunikation nur vom Gateway-Host übernommen wird. Die Weiterleitung eines Requests an den Nextcloud-vHost findet nur Server-intern statt, daher reicht hier HTTP aus.
  • Gelauscht wird hier dazu auf der lokalen IP 127.0.0.1, daher ist es nicht möglich, eine Verbindung zum Nextcloud-vHost aufzubauen, ohne vorher den Gateway-Host passiert zu haben.
  • Der Port ist diesmal 82, da Port 81 bereits vom virtuellen Host für Let’s Encrypt belegt wird. Dieser Port muss mit dem Port der Weiterleitung (proxy_pass) für Nextcloud im Gateway-Host übereinstimmen.
  • Die proxy_set_header Anweisungen dienen der erhöhten Sicherheit. Ohne diese Einträge werden später Warnungen im Admin-Bereich von Nextcloud angezeigt. In vielen Tutorials werden diese Header per add_header angegeben. In unserem Fall funktioniert dies nicht, da die Zugriffe über einen Proxy (Gateway-Host) ablaufen. Daher werden die Header mittels proxy_set_header angegeben.
  • Der vHost für Nextcloud soll mit ein paar speziellen Einstellungen für PHP arbeiten. Daher werden per fastcgi_param PHP_VALUE die Einstellungen aus der php.ini (FPM) überschrieben. Dabei darf nur eine fastcgi_param PHP_VALUE Anweisung existieren, da sich diese ansonsten gegenseitig überschreiben. Wenn mehrere Parameter an PHP übergeben werden sollen (wie hier der Fall), müssen diese einfach durch einen Zeilenumbruch getrennt werden. Besonders wichtig ist hier die Direktive open_basedir, da PHP ansonsten keinen Zugriff auf das Datenverzeichnis von Nextcloud hat.
    Falls später z.B. eine externe Festplatte als externer Speicher eingebunden werden soll, muss auch das Verzeichnis dieses Laufwerks in die open_basedir Anweisung mit aufgenommen werden.
  • Auch hier bitte wieder auf die Kommentare in der Datei achten. Hier sind auch wieder Hinweise zu finden, um den virtuellen Host an die eigenen Bedürfnisse anzupassen.

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

service nginx restart

Installation Nextcloud

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

Download

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

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

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

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

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

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

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

Nun sollten nochmals die Dateiberechtigungen gesetzt werden:

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

Datenbank für Nextcloud anlegen

Bevor nun das Setup von Nextcloud aufgerufen werden kann, ist es notwendig, dass eine Datenbank für die Cloud angelegt wurde. Dies geschieht am einfachsten mit der MySQL-Kommandozeile, die mit Root-Rechten aufgerufen wird:

mysql -u root -p

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

create 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 kann auch schon das Setup der Cloud-Software über die URL https://meinedomain.de/nextcloud aufgerufen werden.

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

Beim Setup der Cloud werden nun drei Dinge angegeben:

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

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

Nextcloud-Setup

Nextcloud-Setup

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

Warnungen im Admin-Bereich

Nach erfolgreicher Installation sollte man gleich einen Blick in den Admin-Bereich der Cloud werden (oben rechts auf das Symbol für den Benutzer Klicken und dann Einstellungen wählen). Weil der erste angelegte Benutzer Admin-Rechte hat, sind nun auf der linken Seite die Grundeinstellungen der Cloud zu finden. Hier sollte nun direkt nach dem Setup eine Warnung angezeigt werden, dass kein PHP-Memory-Cache konfiguriert ist.

Nextcloud: Warnung im Admin-Bereich

Nextcloud: Warnung im Admin-Bereich

Diese spezielle Warnung ist hierbei nicht als Fehler zu verstehen, sondern lediglich als Hinweis, dass die Performance der Cloud durch den Einsatz eines PHP-Memorycaches optimiert werden könnte.

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

Anpassen der Nextcloud-Konfiguration

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

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

Folgende Änderung werden hier durchgeführt:

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

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

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

Cronjob für Nextcloud einrichten

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

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

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

crontab -u www-data -e

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

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

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

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

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

Nextcloud: Ausführung von Hintergrund-Aufgaben per Cron

Nextcloud: Ausführung von Hintergrund-Aufgaben per Cron

4-Byte-Support aktivieren

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

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

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

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

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

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

mysql -u root -p

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

use nextcloud_db;

Hier wird zunächst einmal der verwendete Zeichensatz kontrolliert:

show variables like "character_set_database";

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

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

ALTER DATABASE nextcloud_db CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

Danach sollte nach nochmaliger Eingabe von

show variables like "character_set_database";

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

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

cd /var/www/nextcloud

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

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

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

sudo -u www-data php occ maintenance:repair

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

Weitere Konfiguration Nextcloud

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

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

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

Optimierungen der Server-Umgebung für Nextcloud

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

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

Fail2ban

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

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

Konfigurations-Dateien von Fail2ban

Bevor es um die Einrichtung von Fail2ban geht, ein Hinweis zu den Konfigurations-Dateien dieses Programms: Hier gibt es zwei Arten von Konfigurations-Dateien: *.conf und *.local. Die conf-Dateien kommen bei der Installation von Fail2ban mit. Wenn Änderungen an der Konfiguration vorgenommen werden sollen, dann sollte man die conf-Dateien nie direkt bearbeiten, da diese bei einem Update von Fail2ban jederzeit überschrieben werden können. Dafür kann man hier eine Datei mit dem gleichen Namen, aber mit der Dateiendung .local anlegen. Die local-Dateien werden dabei „on top“ auf die conf-Dateien geladen und überschreiben so die Standard-Einstellungen. Wenn nun bei einem Update von Fail2ban die conf-Dateien geändert werden, sind die individuellen Anpassungen in den local-Dateien davon nicht betroffen. Dadurch ist es nicht möglich, dass durch ein Update von Fail2ban unbeabsichtigt die Konfiguration geändert wird.

Konfiguration/Deaktivieren Nextcloud Brute-Force-Schutz

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

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

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

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

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

'logtimezone' => 'Europe/Berlin',

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

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

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

Einrichtung Fail2ban

Anschließend kann Fail2ban installiert werden:

apt-get update 
apt-get install fail2ban

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

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

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

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

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

nano /etc/fail2ban/jail.local

Der Inhalt der Datei:

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

[nginx-http-auth]
enabled = true

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

  • enabled: Aktivierung dieser Regel. Falls das Jail später (temporär) deaktiviert werden soll, kann dies einfach durch diese Option erfolgen.
  • port: Möglicher Port, hier nur 80 (HTTP) und 443 (HTTPS).
  • protocol: Das verwendete Protokoll.
  • filter: Name des Filters aus gleichnamiger Datei unter /etc/fail2ban/filter.d. Den Filter für Nextcloud haben wir ja bereits vorher angelegt.
  • maxretry: Anzahl der Fehlversuche, bevor Fail2ban eine IP sperrt.
  • bantime: Zeitraum in Sekunden, für den eine IP gesperrt werden soll. Wird hier ein negativer Wert angegeben (-1), handelt es sich um eine permanente Sperre. Ansonsten wird eine IP nach dem Ablauf dieser Zeitspanne wieder automatisch entsperrt.
  • logpath: Log-Datei, die Fail2ban für dieses Jail beobachten soll. Auf diese Datei wird der oben definierte Filter angewendet.

Die Anweisung unter nginx-http-auth aktiviert daneben noch die Überwachung der Logs des Webservers. Dieses Jail ist bereits in den Standard-Jails (/etc/fail2ban/jail.conf) definiert und wird an dieser Stelle lediglich scharf geschaltet. Dies sorgt für eine Überwachung bei anderen Webanwendungen, bei den eine HTTP-Basic-Authentifizierung zum Einsatz kommt.

Nach einem Neustart von Fail2ban ist das Programm einsatzbereit:

service fail2ban restart

E-Mail-Versand durch Fail2ban

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

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

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

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

Nun bekommt man bei allen Aktionen, die Fail2ban vornimmt, automatisch eine E-Mail geschickt. Unschön dabei: Auch wenn ein „Jail“ gestoppt oder geladen wurde, wird eine E-Mail versendet. Startet einfach mal Fail2ban neu (service fail2ban restart) und wundert euch über die „Mail-Flut“. Eigentlich interessiert uns hier ja nur, wenn Fail2ban tatsächlich eine IP gebannt hat. Damit nur noch bei diesem Ereignis eine E-Mail zu erhalten, müssen noch ein paar Anpassungen vorgenommen werden. Die betroffenen conf-Dateien im Verzeichnis /etc/fail2ban/action.d werden dabei durch entsprechende local-Dateien ergänzt:

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

Die o.g. Dateien werde dazu einfach neu angelegt und mit folgendem Inhalt gefüllt:

[Definition]

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

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

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

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

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

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

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

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

fail2ban-client status nextcloud

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

Mit diesem Befehl wird diese IP wieder entsperrt:

fail2ban-client set nextcloud unbanip 48.128.36.83

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

Redis

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

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

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

Installation und Konfiguration Redis

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

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

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

nano /etc/redis/redis.conf

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

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

Hiermit werden folgende Optionen gesetzt:

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

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

usermod -a -G redis www-data

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

service redis-server restart

Aktivierung von Redis in Nextcloud

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

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

Folgende Zeilen werden hier eingefügt:

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

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

ufw

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

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

apt-get update
apt-get install ufw

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

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

Mit folgenden Befehlen werden diese Regeln umgesetzt:

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

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

ufw status

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

Überprüfung der Sicherheit

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

Qualys SSL Labs

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

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

Ergebnis des SSL-Test

Ergebnis des SSL-Test

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

Nextcloud Security Scan

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

Nextcloud Security Scan

Nextcloud Security Scan

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

Troubleshooting

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

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

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

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

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

Nextcloud: Ein sicherer Ort für all deine Daten

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

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

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

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

Weiterführende Artikel

Links

]]>
https://decatec.de/home-server/nextcloud-auf-ubuntu-server-18-04-lts-mit-nginx-mariadb-php-lets-encrypt-redis-und-fail2ban/feed/ 190
Ubuntu Server 18.04 LTS als Hyper-V Gastsystem installieren und optimal einrichten https://decatec.de/home-server/ubuntu-server-18-04-lts-als-hyper-v-gastsystem-installieren-und-optimal-einrichten/ https://decatec.de/home-server/ubuntu-server-18-04-lts-als-hyper-v-gastsystem-installieren-und-optimal-einrichten/#comments Tue, 01 May 2018 08:34:26 +0000 https://decatec.de/?p=4030 Ubuntu 18.04 + Windows

Mit der Veröffentlichung von Ubuntu 18.04 („Bionic Beaver“) ist eine neue LTS-Version der beliebten Linux-Distribution erschienen. Im folgenden Artikel wird die Installation von Ubuntu Server 18.04.1 als Gastsystem in einer Hyper-V-Umgebung beschrieben. Neben der Konfiguration der virtuellen Maschine und der Installation von Ubuntu Server geht es ebenfalls die Optimierung des Gastsystems, so dass es optimal in einer virtualisierten Umgebung laufen kann. Als Grundlage dient der schon vor einiger Zeit entstandene Artikel Ubuntu Server als Hyper-V Gastsystem installieren und optimal einrichten, in dem die Einrichtung von Ubuntu Server 16.04 gezeigt wurde. Da sich bei Ubuntu Server 18.04 einiges an der Installations-Routine geändert hat, ist es an der Zeit, dem Thema einen neuen Artikel zu gönnen.

Spezielle Linux-Kenntnisse sind dabei nicht erforderlich, wenn auch nicht hinderlich. Wer seinerzeit mit dem vorherigen Artikel eine Ubuntu-VM aufgesetzt hat, wird sich sicherlich sofort zurechtfinden.

Update-Historie (letztes Update: 10.08.2018)
  • 09.05.2018:
    • IP-Konfiguration: Hinweise für die nachträgliche Änderung der IP-Adresse hinzugefügt.
  • 01.06.2018:
    • Hinweis zum Einstellen der richtigen Zeitzone hinzugefügt.
  • 10.08.2018:
    • Angepasst an Ubuntu Server 18.04.1 (Setup-Prozess).
    • Manuelle Anpassung der Paketquellen nach der Installation.

 

Ubuntu: Virtualisierung mittels Hyper-V

Dieser Artikel ist fokussiert auf Ubuntu Server als Gast-Betriebssystem und Hyper-V als Virtualisierungs-Lösung. Warum nun genau diese Kombination?

Hyper-V

Wenn es um Virtualisierungs-Lösungen geht, kann man zwischen zwei Arten der Virtualisierung unterscheiden: Bei einem sog. Typ-1-Hypervisor läuft das Gast-Betriebssystem direkt auf der Hardware des Hosts. Dagegen setzt ein Typ-2-Hypervisor auf dem Host-Betriebssystem („eine Schicht weiter oben“) auf. Durch den Wegfall dieser Zwischenschicht läuft ein Typ-1-Hypervisor immer effizienter als ein Typ-2-Hypervisor.

Im Gegensatz zum populären VirtualBox ist Hyper-V dabei ein reiner Typ-1-Hypervisor. Daher fiel die Wahl bei diesem Artikel auf die Virtualisierungs-Lösung aus dem Hause Microsoft.

Allerdings kann dieses Tutorial auch mit jeder anderen Virtualisierungs-Software angegangen werden. Die Schritte zur Konfiguration des Gastsystems sind überall identisch.

Ubuntu Server

Microsoft öffnet sich ja zunehmend der Linux-Welt, was beispielsweise das Windows Subsystem for Linux deutlich macht. Auch die Unterstützung von Ubuntu auf Hyper-V ist mittlerweile weit vorangeschritten, wie dieser TechNet-Artikel zeigt. Prinzipiell kann hier auch eine andere Linux-Distribution zum Einsatz kommen, allerdings unterscheiden sich dann u.U. die Schritte zur Konfiguration des Gast-Betriebssystems.

Ubuntu Server herunterladen

Zunächst benötigt man ein ISO-Image des Gastsystems, welches man auf der Ubuntu-Homepage herunterladen kann. Die aktuellste Version ist dabei momentan 18.04 LTS („Bionic Beaver“). Da es sich um eine LTS-Version handelt (Long Term Support), wird diese Version ganze vier Jahre lang unterstützt.

Virtuelle Maschine erstellen

Zunächst muss die Hyper-V-Maschine erstellt werden. Als Hyper-V-Host dient dabei Windows Server 2016. Die gezeigten Schritte gelten aber auch für ältere Versionen von Windows Server bzw. Windows 10.

Virtuelle Festplatte erzeugen

Bevor die VM im Hyper-V-Manager angelegt wird, sollte die virtuelle Festplatte (vhdx) manuell mittels PowerShell erzeugt werden. Dieser Microsoft-Artikel erklärt dabei die Hintergründe: Für Linux-VMs sollte eine Block Size von 1 MB verwendet werden, da ansonsten mehr Speicherplatz auf dem Host-Betriebssystem belegt wird. Da beim Hyper-V-Manager keine benutzerdefinierte Block Size bei der Erstellung von virtuellen Festplatten angegeben werden kann, ist hier der kleine Umweg über die PowerShell notwendig.

Dazu die PowerShell mit Admin-Rechten starten. Folgender Befehl legt dann die virtuelle Festplatte mit einer Größe von 20 GB an:

New-VHD -Path "D:\Hyper-V\UbuntuServer1804\Virtual Hard Disks\UbuntuServer1804.vhdx" -SizeBytes 20GB -Dynamic -BlockSizeBytes 1MB

Virtuelle Festplatte mit PowerShell anlegen

Virtuelle Festplatte mit PowerShell anlegen

Laut den Systemanforderungen von Ubuntu Server würde zwar schon eine Festplatte mit 1,5 GB ausreichen, dennoch sollte man die Festplatte gleich etwas größer anlegen, um nachher mehr Spielraum zu haben. Durch das Erzeugen als dynamische Festplatte werden auch keine 20 GB belegt. Es wird nur so viel Speicherplatz benötigt wie die auf der Festplatte gespeicherten Daten einnehmen.

Anlegen der virtuellen Maschine

Nachdem die Festplatte schon vorbereitet wurde, geht es nun im Hyper-V-Manager an das Erzeugen der virtuellen Maschine. Dazu den Assistenten über Aktion > Neu > Virtueller Computer… aufrufen.

Name und Pfad angeben: Nach den Vorbemerkungen zum Assistenten wird der Name der virtuellen Maschine angegeben. Ebenfalls kann der Speicherort der VM konfiguriert werden. In diesem Fall gebe ich das Verzeichnis an, in dem alle Hyper-V-Maschinen gespeichert werden. Auch wenn es nicht so aussieht, sollte man den Pfad hier explizit angeben (die Option Virtuellen Computer an einem anderen Speicherort speichern muss dazu aktiviert werden), da ansonsten keine Verzeichnisstruktur erstellt wird, in der sämtliche Dateien der virtuellen Maschine unter einem Ordner gespeichert werden.

Name und Pfad der virtuellen Maschine

Name und Pfad der virtuellen Maschine

Generation angeben: Die Wahl der „Generation“ hängt vom zu installierenden Gast-Betriebssystem ab. Generation 2 ist dabei die modernere Variante und bietet mehr Virtualisierungs-Features. Da Ubuntu ab Version 14.04 Generation 2 unterstützt, wählen wir hier die entsprechende Option (siehe Microsoft-Artikel).

Generation der VM festlegen

Generation der VM festlegen

Speicher zuweisen: Als nächstes wird festgelegt, wie viel Speicher der virtuellen Maschine zur Verfügung stehen soll. 1024 MB (= 1 GB) sollte dabei vollkommen ausreichen. Hier sollte auch die Option Dynamischen Arbeitsspeicher für diesen virtuellen Computer verwenden aktiviert werden, so dass die VM nur so viel Arbeitsspeicher in Anspruch nimmt, die eben gerade benötigt wird.

Zuweisen von Arbeitsspeicher

Zuweisen von Arbeitsspeicher

Netzwerk konfigurieren: Da die VM nachher auch Netzwerkzugang benötigt, wird hier ein Netzwerkadapter angegeben. Dabei handelt es sich um einen sog. virtuellen Switch. Falls hier keine Option gewählt werden kann, muss ein solcher vermutlich erst noch angelegt werden. In diesem Artikel wird dazu die genaue Vorgehensweise erklärt.

Netzwerkkonfiguration der VM

Netzwerkkonfiguration der VM

Virtuelle Festplatte verbinden: Hier wird nun die virtuelle Festplatte der VM angegeben. Da die HDD bereits zuvor mittels PowerShell erzeugt wurde, wählen wir hier die Option Vorhandene virtuelle Festplatte verwenden und geben die entsprechende vhdx-Datei an.

Virtuelle Festplatte hinzufügen

Virtuelle Festplatte hinzufügen

Der letzte Schritt des Assistenten fasst nochmals alle gewählten Optionen zusammen. Passt alles, wird mit einem Klick auf Fertig stellen der Assistent abgeschlossen.

Einstellungen der virtuellen Maschine anpassen

Direkt nach der Erzeugung und vor dem ersten Start der virtuellen Maschine werden direkt noch einige Einstellungen vorgenommen/optimiert (Rechtsklick auf VM > Einstellungen…)

Sicherheit: Hier wird die Option Sicheren Start aktivieren eingeschaltet. Als Vorlage muss hier Microsoft UEFI-Zertifizierungsstelle gewählt werden, da die virtuelle Maschine später sonst nicht gestartet werden kann.

VM-Einstellungen: Sicherheit

VM-Einstellungen: Sicherheit

Arbeitsspeicher: Die Einstellungen für den (dynamischen) Arbeitsspeicher werden hier nochmals genauer spezifiziert. Damit die VM nicht beliebig viel Speicher beanspruchen kann, wird hier einfach das Maximum von 2048 MB (= 2 GB) angegeben.

VM-Einstellungen: Arbeitsspeicher

VM-Einstellungen: Arbeitsspeicher

Prozessor: Damit die VM auch alle zur Verfügung stehenden Prozessor-Kerne nutzen kann, wird die Anzahl der virtuellen Prozessoren soweit erhöht, dass unter Anteil der Gesamtsystemressourcen in % bei 100 steht. Falls die virtuelle Maschine nicht „so viel Dampf“ braucht, kann man hier aber auch einen kleineren Wert angeben. Dennoch ist es empfehlenswert, der VM mindestens zwei Prozessoren zuzuweisen.

VM-Einstellungen: Prozessor

VM-Einstellungen: Prozessor

SCSI-Controller: Da die erzeugte virtuelle Maschine standardmäßig kein DVD-Laufwerk besitzt, wird hier ein solches hinzugefügt. Dazu einfach den Eintrag DVD-Laufwerk markieren und auf Hinzufügen klicken. Daraufhin kann gleich die zuvor heruntergeladene ISO-Datei angegeben werden, so dass sich diese beim ersten Start der VM „im Laufwerk befindet“.

VM-Einstellungen: DVD-Laufwerk

VM-Einstellungen: DVD-Laufwerk

Firmware: Anschließend kommt noch ein kleiner Abstecher in den Menüpunkt Firmware. Hier wird einfach das soeben hinzugefügte DVD-Laufwerk als erste Startoption festgelegt.

VM-Einstellungen: Firmware

VM-Einstellungen: Firmware

Alle anderen Optionen in den Einstellungen für die virtuelle Maschine können auf Standard-Werten belassen oder nach eigenem Ermessen eingestellt werden. Ebenfalls können sämtliche Einstellungen auch noch nach der Installation des Gast-Betriebssystems geändert werden (wenn man beispielsweise doch einmal mehr Arbeitsspeicher benötigen sollte).

Installation Ubuntu Server 18.04

Die Einrichtung der VM auf dem Host-System ist nun abgeschlossen. Bevor wir die virtuelle Maschine das erste Mal starten, sollte noch ein Prüfpunkt angelegt werden (Rechtsklick auf die VM > Prüfpunkt). Falls bei der Installation etwas schief gehen sollte, kann man die virtuelle Maschine wieder den Ursprungszustand versetzen (über Rechtsklick auf den Prüfpunkt > Anwenden).

Nach einem Rechtsklick auf die VM und Verbinden…, kann die virtuelle Maschine mit Aktion > Starten (oder STRG+S) zum ersten Mal gestartet werden.

Zunächst wird die Sprache des Betriebssystems gewählt – in diesem Fall Deutsch:

Ubuntu Server Setup: Sprache

Ubuntu Server Setup: Sprache

Das Tastatur-Layout wird leider nicht automatisch angepasst, so dass im nächsten Schritt das passende Tastatur-Layout gewählt werden muss:

Ubuntu Server Setup: Tastatur-Layout

Ubuntu Server Setup: Tastatur-Layout

Anschließend wird die Installations-Methode gewählt. Hier ist die erste Option (Install Ubuntu) die passende:

Ubuntu Server Setup: Installationsart

Ubuntu Server Setup: Installationsart

Der nächste Schritt ist bei Ubuntu 18.04 ganz neu: Hier wird die Netzwerk-Konfiguration im Rahmen des Setups vorgenommen (bei älteren Versionen des Betriebssystems musste das immer erst nach dem Setup manuell vorgenommen werden). Standardmäßig wird hier DHCP verwendet, so dass die VM eine dynamische IP-Adresse vom Router zugewiesen bekommt.

Für einen Server ist es aber besser, wenn dieser eine statische IP-Adresse hat. Dazu wird das entsprechende Interface (meist eth0) gewählt. Mit der Enter-Taste kann wählt man nun den Eintrag Edit IPv4 und ruft so den Dialog zum Bearbeiten der Konfiguration auf.

Ubuntu Server Setup: Netzwerk-Konfiguration

Ubuntu Server Setup: Netzwerk-Konfiguration

Im folgenden Dialog ist die Option Automatic (DHCP) eingestellt. Hier wählen wir nun Manual. Die anschließende Konfiguration für die statische IP-Adresse ist von eurer Netzwerk-Konfiguration abhängig.

Ubuntu Server Setup: Netzwerkkonfiguration (statische IP)

Ubuntu Server Setup: Netzwerkkonfiguration (statische IP)

  • Subnet: Im Heim-Bereich kommt meist ein 24er-Subnet zum Einsatz: Wenn euer Router also beispielsweise die IP 192.168.178.1 hat, muss hier vermutlich 192.168.178.0/24 angegeben werden (entspricht dem Subnet 255.255.255.0).
  • Address: Dies ist die statische IP-Adresse des Gast-Betriebssystems. In diesem Beispiel soll die virtuelle Maschine die statische IP 192.168.178.60 bekommen.
  • Gateway: Dies ist einfach die IP-Adresse eures Routers, also z.B. 192.168.178.1.
  • Name servers: Dies ist die IP des DNS-Nameservers in eurem Netzwerk. In den meisten Fällen wird dies auch die IP des Routers sein (also beispielsweise 192.168.178.1).

Nach der Bestätigung mit Save werden die Einstellungen für IPv4 übernommen. Hier sollten nun noch die Einstellung für IPv6 überprüft werden: Dies sollte auf Disabled stehen. Damit nutzt die virtuelle Maschine nur IPv4 und kein IPv6.

Wenn die Netzwerk-Konfiguration abgeschlossen ist, wird mit Done das Setup fortgeführt.

Wie die IP-Konfiguration nachträglich noch geändert werden kann, wird am Ende des Artikels auch nochmals kurz erklärt. Die hier vorgenommenen Einstellungen sind also nicht „in Stein gemeißelt“.

Als nächstes erfolgt die Abfrage eines Proxy-Servers. Falls kein Proxy zum Einsatz kommt, den Schritt einfach mit Done überspringen.

Nun wird ein Mirror für die Paketquellen angegeben. Hier kann man die Standard-Adresse einfach übernehmen (http://archive.ubuntu.com/ubuntu) übernehmen.

Ubuntu Server Setup: Auswahl des Mirrors für Paketquellen

Ubuntu Server Setup: Auswahl des Mirrors für Paketquellen

Es folgt die Einrichtung des Dateisystems. Hier wird einfach die Option Use An Entire Disk gewählt, wenn man die komplette Festplatte für Ubuntu verwenden möchte.

Ubuntu Server Setup: Dateisystem

Ubuntu Server Setup: Dateisystem

Falls man eine Unterteilung in mehrere Partitionen vornehmen möchte, ist hier die Option Manual zu wählen.

Nun wird die einzurichtende Festplatte ausgewählt. Da die virtuelle Maschine nur eine Festplatte zugewiesen bekommen hat, sollte sich die Auswahl auf eine einzelne Festplatte beschränken.

Anschließend erfolgt auch hier eine Zusammenfassung der Dateisystem-Einrichtung. Wenn alles passt, wird das Setup mit Done und der Bestätigung, dass die komplette Festplatte formatiert wird, fortgesetzt.

Ubuntu Server Setup: Dateisystem (Zusammenfassung)

Ubuntu Server Setup: Dateisystem (Zusammenfassung)

Nun wird der erste Benutzer des Systems angelegt.

Ubuntu Server Setup: User anlegen

Ubuntu Server Setup: User anlegen

Nun können noch Snap Apps ausgewählt werden, die im Rahmen des Setups gleich mit installiert werden sollen. Snap soll hier nicht Thema des Artikels sein, daher wird dieser Schritt mit Done übersprungen.

Am Ende wird das System an sich installiert. Nach einer kurzen Wartezeit sollte oben die Meldung Finished install! kommen und man kann das System mit der Option Reboot now neu starten.

Ubuntu Server Setup: Installation abgeschlossen

Ubuntu Server Setup: Installation abgeschlossen

Beim Reboot erscheint dann irgendwann die Meldung Please remove installation medium, then press ENTER. Es kann nun vorkommen, dass das ISO-Image nicht mehr gemountet ist (Medien > DVD-Laufwerk > Auswerfen), aber bei der Bestätigung mit Enter nichts passiert. In diesem Fall einfach die VM ausschalten (Aktion > Ausschalten) und neu starten.

Optimierung der VM-Einstellungen

Ubuntu Server ist anschließend fertig installiert. Für den optimalen Betrieb sollte nun noch eine Änderung an den VM-Einstellungen vorgenommen werden (Rechtsklick auf die virtuelle Maschine > Einstellungen…): Unter Netzwerkkarte > Erweiterte Features sollte nun eine statische MAC-Adresse vergeben werden. Dazu kann einfach die Option Statisch gewählt werden, die MAC-Adresse, die nun vorgeschlagen wird, muss nicht mehr verändert werden.

VM-Einstellungen: Netzwerkkarte

VM-Einstellungen: Netzwerkkarte

Diese Einstellung ist nicht zwingend notwendig, beugt allerdings bestimmten Netzwerk-Problemen mit der virtuellen Maschine vor.

Nach diesen Schritten sollte erst einmal wieder ein Prüfpunkt der VM angelegt werden, der das installierte Grundsystem beinhaltet.

Einrichtung Ubuntu Server 18.04

Nun folgt die Konfiguration des Gastsystems, damit dieses optimal in der virtualisierten Umgebung läuft. Dazu meldet man sich einfach mit dem soeben erstellen Benutzer an und verschafft sich mittels sudo Root-Rechte. Das Konzept hinter sudo wurde an dieser Stelle schon einmal genauer erklärt.

Systemupdates

Als erstes bringen wir das System auf den neusten Stand. Dazu werden erst einmal die Paketquellen aktualisiert:

apt-get update

Anschließend werden evtl. vorhandene Updates abgerufen:

apt-get upgrade

Beide Befehle kann man auch in einem Rutsch durchführen:

apt-get update && apt-get upgrade

Um auch evtl. vorhandene System-Upgrades zu erhalten, wird noch folgender Befehl ausgeführt:

apt-get dist-upgrade

Falls hier Upgrades gefunden und installiert werden, können nicht mehr benötigte Pakete automatisch entfernt werden:

apt-get autoremove

Nach den Updates sollte die virtuelle Maschine neu gestartet werden:

reboot now

Optimierung für virtuelle Umgebung

Um das System noch bessern an die virtualisierte Umgebung anzupassen, werden nun noch die dafür vorgesehenen Kernel-Module installiert:

apt-get update
apt-get install --install-recommends linux-virtual
apt-get install linux-tools-virtual linux-cloud-tools-virtual
reboot now

Optimierung des I/O-Schedulers

Ein modernes Betriebssystem ist darauf ausgelegt, möglichst viele I/O-Operationen parallel auszuführen. Der Linux-Kernel kennt dazu verschiedene Scheduling-Modi. Hier soll nicht weiter auf die Details eingegangen werden, allerdings sollte der zu Grunde liegende Hypervisor diese I/O-Operationen optimieren und nicht das Gast-Betriebssystem selbst.

Um diese Einstellung einzurichten, muss der Bootloader optimiert werden. nano ist in diesem Fall ein einfacher Text-Editor unter Linux:

nano /etc/default/grub

Hier suchen wir nun nach der folgenden Zeile

GRUB_CMDLINE_LINUX_DEFAULT=""

und ändern diese zu:

GRUB_CMDLINE_LINUX_DEFAULT="elevator=noop"

Mit dieser Einstellung weisen wir die virtuelle Maschine an, sämtliche I/O-Operationen an den darunter liegenden Hyper-V-Hypervisor zu übergeben, der dann für einen optimierten Ablauf sorgt. Dadurch sollte sich die Performance der virtuellen Maschine geringfügig verbessern.

Die Datei wird in nano durch die Tastenkombination STRG+O gespeichert. Anschließend kann der Texteditor durch STRG+X verlassen werden.

Damit die Änderungen wirken, muss der Bootloader neu geladen und das System neu gestartet werden:

update-grub
reboot now

Nach diesem Reboot ist unser Ubuntu Server nun für den Betrieb in einer virtualisierten Umgebung optimiert.

Am Ende solte man noch die Systemzeit überprüfen:

date

Falls die angezeigte Zeit nicht stimmen sollte, muss man noch die passende Zeitzone einstellen:

timedatectl set-timezone Europe/Berlin

Anschließend sollte mit dem Befehl date Zeit zurückgeliefert werden.
Dieser Schritt ist wichtig, da bei einer falsch eingestellten Systemzeit sämtliche Zeitangaben (z.B. in Log-Files) falsch sein könnten.

Konfigurieren der Paketquellen

Die Pakete sind bei Ubuntu schon immer in mehrere Repositories unterteilt:

  • Main: Von Canonical gepflegte Open Source Software.
  • Universe: Von der Community gepflegte Open Source Software.
  • Resticted: Proprietäre Treiber für Geräte.
  • Multiverse: Software, die lizenzrechtlichen Einschränkungen unterliegt.

Hintergrundinformationen zu den einzelnen Paketquellen findet man in der Ubuntu-Dokumentation.

Seit Ubuntu Server 18.04.1 sind die Paketquellen nach der Installation des Betriebssystems so konfiguriert, dass nur noch das Main-Repository eingerichtet ist. Auf diese Weise soll sichergestellt werden, dass möglichst nur qualitativ hochwertige Software auf dem System installiert wird.

Das bringt jedoch einen Nachteil mit sich: Viele Pakete, die üblicherweise auf einem Server installiert werden, sind nicht im Main-Repository enthalten. In welchem Repository ein gesuchtes Paket enthalten ist, kann man einfach über die Ubuntu-Paketsuche ermitteln. Als Beispiel sei hier das Paket php7.2-fpm genannt, welches auf dem meisten Webservern zum Einsatz kommen dürfte. Wenn man dieses nun per apt-get install php7.2-fpm installieren will, erhält man eine Meldung, dass dieses Paket nicht gefunden werden kann (da das Paket nur im Universe-Repository enthalten ist).

Wenn solche Pakete benötigt werden, kann man diese einfach in die Liste der Repositories mit aufnehmen. Mit folgendem Befehl wird z.B. das Universe-Repository mit eingebunden:

sudo add-apt-repository universe

Kontrollieren (und erweitern) kann man die eingebundenen Repositories auch anhand der Datei /etc/apt/sources.list. Hier sind beispielsweise die Repositories Main, Universe, Multiverse und Restricted eingebunden (die Standard-Einstellung unter Ubuntu 18.04):

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

Hier gilt es immer abzuwägen, in wie weit man das System für weitere Software öffnen will, bei der Canonical nicht beteiligt ist.

Zugriff auf die virtuelle Maschine mit SSH/PuTTY

Bisher haben wir uns immer über die Hyper-V-Konsole auf die virtuelle Maschine verbunden. Im Normalfall wird man sich diesen Umweg sparen und eine Verbindung einfach über SSH aufbauen wollen.

Das bekannteste Programm dazu ist sicherlich PuTTY. Hier wird einfach die IP-Adresse unserer virtuellen Maschine (in diesem Beispiel 192.168.178.60) und der Port 22 angegeben:

PuTTY: Verbindung zum Ubuntu Server herstellen

PuTTY: Verbindung zum Ubuntu Server herstellen

Nach einem Klick auf Open erscheint beim ersten Verbindungsaufbau die Hinweismeldung, dass der Ziel-Rechner unbekannt ist. Durch die Bestätigung mit Ja wird diese Meldung zukünftig für diesen Rechner nicht mehr erscheinen.

Nachdem die Verbindung nun aufgebaut wurde, befindet man sich wieder ganz normal im Terminal des Ubuntu Servers und kann wie gewohnt arbeiten.

Erweiterung: IP-Konfiguration nachträglich ändern

Die Einstellungen bzgl. der IP-Adresse des Servers werden bei Ubuntu 18.04 bereits im Rahmen des Setups festgelegt. Normalerweise wird man die Einstellungen gleich im Setup durchführen und muss sich daraufhin nicht mehr weiter darum kümmern. Trotzdem soll noch kurz die Vorgehensweise zur IP-Konfiguration beleuchtet werden, falls man zu einem späteren Zeitpunkt die IP-Einstellungen nochmal ändern möchte.

Seit Ubuntu 17.10 werden die Netzwerkeinstellungen nicht mehr wie früher unter /etc/network/interfaces konfiguriert, sondern über Netplan. Netplan ist dabei als Konfigurations-Backend für die Netzwerkeinstellungen zu verstehen. Die gewünschten Einstellungen werden nun deklarativ im YAML-Dateiformat hinterlegt. Beim Aktivieren der Einstellungen übergibt Netplan die Kontrolle an einen sog. Renderer: Bei der Desktop-Version von Ubuntu ist dies der NetworkManager, bei der Server-Variante kommt systemd-networkd (Netzwerkdaemon) zum Einsatz.

Die eigentliche Netzwerk-Konfiguration findet man unter /etc/netplan. Hier befindet sich im Normalfall nur eine YAML-Datei (hier z.B. 50-cloud-init.yaml – die Datei kann ggf. aber auch anders heißen). Diese kann mit einem beliebigen Editor bearbeitet werden:

nano /etc/netplan/50-cloud-init.yaml

Durch die Konfiguration im Rahmen des Setups sieht die Datei dann meist so aus und spiegelt die vorgenommenen Einstellungen wider:

network:
    ethernets:
        eth0:
            addresses:
            - 192.168.178.60/24
            gateway4: 192.168.178.1
            nameservers:
                addresses:
                - 192.168.178.1
                search: []
            optional: true
    version: 2

Hier sind folgende Informationen hinterlegt:

  • eth0: Name der Netzwerk-Schnittstelle.
  • addresses: Statische IP-Adressen (IPv4 und ggf. IPv6).
  • gateway4: IPv4-Adresse des Standard-Gateways (IP des Routers).
  • nameservers: Liste der IP-Adressen der zu verwendenden Nameserver (DNS). search gibt evtl. vorhandene Such-Domains an.
  • optional: Markiert das Netzwerk-Interface als optional für den Bootvorgang (nur bei networkd als Renderer). Wenn auf false gesetzt, wartet networkd beim Booten, bis das Gerät verfügbar ist.
  • version: YAML-Version (immer 2).
  • renderer: Gibt den zu verwendenden Renderer an. Wenn wie hier nicht angegeben, wird standardmäßig networkd verwendet.

Wenn also nun die IP von 192.168.178.60 auf 192.168.178.100 geändert werden soll, muss hier also nur die Zeile unter addresses modifiziert werden:

- 192.168.178.100/24

Um die IP-Konfiguration über DHCP vorzunehmen, sieht der komplette Dateiinhalt folgendermaßen aus (für einen Server nicht empfehlenswert):

network:
    ethernets:
        eth0:
            dhcp4: yes
            dhcp6: yes
            optional: true
    version: 2

Wenn an der Konfiguration etwas geändert wurde, dann müssen die Einstellungen noch übernommen werden. Dazu wird die YAML-Datei zunächst einmal gespeichert und anschließend wird die Konfiguration mit folgendem Befehl angewendet:

netplan apply

Nicht wundern: Die Änderungen sind nach diesem Befehl sofort „live“, so dass eine SSH-Verbindung danach erst einmal abbricht. Einfach nochmals mit der neuen IP verbinden.

Fazit

Nach diesen Schritten haben wir einen Ubuntu Server 18.04 fertig eingerichtet und für die virtualisierte Umgebung optimiert. Am besten erstellt man nun erst einmal noch einen Prüfpunkt der virtuellen Maschine mit der abgeschlossenen Konfiguration (die zuvor angelegten Prüfpunkte können nun gelöscht werden).

Nun kann das System für weitere Aufgaben genutzt werden: Beispielsweise kann mit Nextcloud eine eigene Cloud eingerichtet werden (siehe Nextcloud auf Ubuntu Server mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban).

Weiterführende Artikel

Links

]]>
https://decatec.de/home-server/ubuntu-server-18-04-lts-als-hyper-v-gastsystem-installieren-und-optimal-einrichten/feed/ 3
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.

Update-Historie (letztes Update: 29.07.2018)
  • 29.07.2018:
    • Um anonyme Uploads möglichst komfortabel zu handhaben, sollten die entsprechenden Einstellungen in den Admin-Settings unter Teilen gesetzt werden.

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.

Hier sollten zunächst einmal die Einstellungen unter Teilen in den Admin-Einstellungen der Cloud kontrolliert werden. Für den maximalen Komfort sind dabei zwei Optionen von Bedeutung:

  • Öffentliches Hochladen erlauben: Diese Option muss gesetzt sein, damit ein anonymer Upload überhaupt möglich ist.
  • Passwortschutz erzwingen: Wenn diese Option gesetzt ist, wird beim Zugriff auf das Upload-Verzeichnis immer nach einem Passwort gefragt. Wenn man es externen Benutzern möglichst einfach machen will, dann kann man diese Option deaktivieren und das Verzeichnis für den anonymen Upload ohne Passwort freigeben.
Einstellungen für Teilen in den Admin-Settings

Einstellungen für Teilen in den Admin-Settings

Um dieses Feature nun 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/ 14
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/ 30
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 ((letztes Update 16.06.2018)
  • 09.03.2018:
    • Hinweis auf Reboot nach Collabora-installation hinzugefügt.
  • 16.06.2018:
    • Hinweis auf den Parameter overwriteprotocol in der config.php von Nextcloud 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.

Im Zusammenhang mit dem letzten Punkt ist noch zu beachten, dass der Parameter overwriteprotocol in der Konfiguration von Nextcloud gesetzt ist:

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

Hier muss folgender Eintrag zu finden sein:

'overwriteprotocol' => 'https',

Falls diese Einstellung nicht zu finden ist, dann sollte diese vor der Installation von Collabora noch vorgenommen werden.

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