DecaTec https://decatec.de Home-Server | Linux | Nextcloud | Raspberry Pi | Programmierung | Fotografie Wed, 24 Apr 2019 08:48:03 +0000 de-DE hourly 1 Passwörter verwalten mit Nextcloud/KeePass https://decatec.de/home-server/passwoerter-verwalten-mit-nextcloud-keepass/ https://decatec.de/home-server/passwoerter-verwalten-mit-nextcloud-keepass/#comments Sun, 21 Apr 2019 07:39:59 +0000 https://decatec.de/?p=5399 Nextcloud KeePassXC Logo

Man liest es in letzter Zeit häufiger: Irgendein Online-Dienst wurde gehackt und es wurden Nutzerdaten entwendet. Jüngstes Beispiel ist wohl der Hack der offiziellen Server des Messenger-Dienstes Matrix.org. Die User werden dann meistens dazu aufgefordert, umgehend ihre Passwörter zu ändern.

Wenn man aber nun für mehrere Dienste immer das gleiche Passwort verwendet, dann ist nach einem solchen Hack immer die Wahrscheinlichkeit gegeben, dass die Daten für anderen Online-Dienste, Webshops, etc. missbraucht werden. Daher sollte es sich mittlerweile herumgesprochen haben, dass man für jeden Online-Dienst ein eigenes Passwort verwenden soll.

Der folgende Artikel zeigt, wie man Passwörter einfach und effizient mit KeePass und Nextcloud verwalten kann.

Passwörter mit System

Aus den o.g. Gründen sollte „Passwort-Recycling“ also vermieden werden. Folglich muss man sich aber auch immer mehr Passwörter merken, je mehr Online-Dienste genutzt werden. Hierzu gibt es verschiedene Ansätze. Einer davon ist, dass man sich einen leicht zu merkenden Satz ausdenkt: „Grillen kann man nicht nur bei schönem Wetter, sondern auch wenn es regnet“. Nun nimmt man die Anfangsbuchstaben der einzelnen Wörter und erhält somit: gkmnnbswsawer. Nun kommen noch Groß-/Kleinbuchstaben, evtl. Sonderzeichen und weitere Ersetzungen zum Einsatz: gKm2nbSws4w3R – hier wurde das „nn“ einfach durch 2n“ und ein paar Buchstaben durch Zahlen (Leetspeak) ersetzt.
„gKm2nbSws4w3R“ ist nun das Basis-Passwort, dass man nun noch mit einem „Dienst-Teil“ ergänzt (z.B. die Anfangsbuchstaben des Dienstes). Für Amazon wäre das fertige Passwort also z.B. „aMgKm2nbSws4w3R“, für eBay z.B. „eBgKm2nbSws4w3R“.

Mit einem solchen System ist man nun etwas sicherer unterwegs. Dennoch besteht die Möglichkeit, dass das System dahinter erkannt werden kann, z.B. wenn von mehreren Diensten Daten entwendet wurden. In diesem Fall ist ein solches System auch nicht mehr als sicher anzusehen.

Besser wären Passwörter in der Form „k;%([uhk[3@!o6?m’2SQ}>MLN/Bf,ngPb“ – also eine zufällige Folge aus Buchstaben/Zahlen/Sonderzeichen. Jeder Dienst bekommt dann ein eigenes Passwort, d.h. dass hier kein System dahinter steckt, dem man auf die Schliche kommen kann.
Nun hat man allerdings ein Problem: Kein Mensch kann sich solche Passwörter merken…

Passwort-Verwaltung mit KeePass

Hier kommen dann sog. Passwort-Safes wie z.B. KeePass zum Einsatz. Passwörter können hier ganz einfach mit beliebigen Zusatzinformationen gespeichert werden, z.B. Benutzernamen oder Notizen, sogar Datei-Anhänge sind möglich. Verwaltet werden diese Passwort-Einträge in einer speziellen Datei (kdbx), die komplett verschlüsselt ist. Öffnen lässt sich der Passwort-Safe dann nur mit dem Master-Passwort, einer Schlüsseldatei, oder auch weiteren Verfahren (z.B. mittels eines YubiKeys). Auch eine Kombination der Verfahren zum Entschlüsseln ist möglich, so dass man z.B. sowohl das Master-Passwort eingeben, als auch eine Schlüsseldatei bereitstellen muss.

Man muss sich nun also nur noch das Master-Passwort merken. Die Passwörter für die einzelnen Dienste werden dann nur noch über den Passwort-Manager verwaltet und können beliebig lang/komplex sein. Ebenso kann man mit KeePass Passwörter erzeugen lassen, so dass man sich nicht mal mehr eigene Passwörter ausdenken muss.

Neben dem originalen KeePass gibt es eine Reihe weiterer Programme, die mit KeePass kompatibel sind. Mein Favorit darunter ist das Programm KeePassXC, welches aus einem Fork aus KeePass hervorgegangen ist.

Geöffnete Passwort-Datenbank mit KeePassXC

Geöffnete Passwort-Datenbank mit KeePassXC

Ebenso gibt es KeePass kompatible Clients für mobile Systeme. Unter Android verwende ich hierzu gern die App Keepass2Android.

Auf der Download-Seite von KeePass findet man hierzu eine Liste an alternativen Programmen/Apps.

Ebenfalls gibt es für KeePassXC Browser-Addons (Firefox, Chrome), die Passwörter aus einer (geöffneten) kdbx-Datenbank auslesen und bei der Anmeldung im Browser automatisch ausfüllen können.

KeePass und Nextcloud

Für den Zugriff auf die eigenen Passwörter braucht man also nur die KeePass-Datenbank (kdbx-Datei) und einen KeePass-Client. Wenn man nun allerdings von mehreren Geräten Zugriff auf die Passwörter haben möchte, muss man immer erst noch die aktuelle Version der kdbx-Datei auf das jeweilige Gerät kopieren. Das ist mühselig und auch fehleranfällig: Wo liegt nun nochmal die aktuelle Version der KeePass-Datenbank? Habe ich diese zuletzt auf dem Notebook oder auf dem PC bearbeitet?

Hier kommt dann Nextcloud ins Spiel: Für eine solche Cloud-Anwendung ist das Synchronisieren von Dateien eine der leichtesten Übungen. Am besten lädt man direkt nach der Erstellung des Passwort-Safes die kdbx-Datei in die eigene Nextcloud-Instanz in einen eigenen Ordner (z.B. „Passwörter“) hoch. Ab nun liegt immer die aktuellste Version dieser Datei in der Cloud.

Ab jetzt befindet sich die aktuellste Version der KeePass-Datenbank immer in der Nextcloud

Ab jetzt befindet sich die aktuellste Version der KeePass-Datenbank immer in der Nextcloud

Nun muss man nur noch sicher stellen, dass jedes Gerät immer mit der aktuellsten Version der Datei arbeitet. Am PC/Notebook nutzt man dazu am besten den Desktop-Sync-Client von Nextcloud: Man fügt einfach für den Order „Passwörter“ eine Synchronisation hinzu:

Nextcloud-Client: Synchronisation für den Passwort-Ordner hinzufügen

Nextcloud-Client: Synchronisation für den Passwort-Ordner hinzufügen

Nun ist auf diesem Gerät die aktuellste kdbx-Datei immer im jeweiligen Sync-Order für Nextcloud vorhanden, also z.B. /home/user/Nextcloud/Passwörter/Passwörter.kdbx.
Über KeePassXC öffnet man nun einfach diese Datei. Nach dem Bearbeiten der Einträge wird die Datei gespeichert. Sofort springt der Sync-Client von Nextcloud an und lädt die veränderte Version in die Cloud.

Wichtig: Falls man die KeePass-Datenbank mit Passwort und Schlüsseldatei gesichert hat, sollte man die Schlüsseldatei natürlich nicht neben der kdbx-Datei in der Cloud bereit stellen, sondern getrennt davon abspeichern: Am besten nur auf den jeweiligen Geräten selbst, auf einem USB-Stick, etc.

Auf einem Mobilgerät (z.B. mit Keepass2Android) läuft die Sache etwas anders ab: Hier wird die KeePass-Datenbank direkt per WebDAV geöffnet. Beim Öffnen der App gibt man daher den direkten Link zur kdbx-Datei ein, also z.B. https://meinedomain.de/nextcloud/remote.php/dav/files/user/Passwörter/Passwörter.kdbx.
Gespeichert wird wiederum per WebDAV, so dass die kdbx-Datei nach der Bearbeitung direkt in der Cloud aktualisiert wird.

KeePass-Datei direkt in Nextcloud öffnen

Es geht allerdings noch komfortabler: Mit KeeWeb existiert ein weiterer KeePass-Client, der auch im Web lauffähig ist. Und genau diesen Client (in der Web-Version) gibt es auch als eigenständige Nextcloud-App:
Im Nextcloud App Store findet man dazu in der Kategorie „Werkzeuge“ die App Keeweb.

Nach der Installation aus dem App Store ist allerdings noch ein kleiner Schritt notwendig, damit die in der Cloud gespeicherten kdbx-Dateien direkt per Klick geöffnet werden können. Dazu legen wir eine neue Datei im gleichen Order an, in dem auch schon die config.php von Nextcloud enthalten ist, also z.B.:

nano /var/www/nextcloud/config/mimetypemapping.json

Hier fügen wir folgenden Inhalt ein:

{
  "kdbx": ["application/x-kdbx"]
}

Damit die Änderungen greifen, muss noch ein Datei-Scan von Nextcloud angestoßen werden:

sudo -u www-data php /var/www/nextcloud/occ files:scan --all

Nun kann die Passwort-Datei in der Nextcloud-Instanz ganz einfach per Klick geöffnet werden:

Geöffnete KeePass-Datei in Nextcloud/Keeweb

Geöffnete KeePass-Datei in Nextcloud/Keeweb

Damit kann man sich die Synchronisierung der kdbx-Datei auf die einzelnen Geräte eigentlich sparen, da man nun jederzeit direkt in der eigenen Nextcloud an die gespeicherten Passwörter kommt. Einen „echten“ Desktop-Client wie KeePassXC braucht man eigentlich nur noch, wenn man z.B. die Integration mittels Browser-Addon benötigt.

Die Alternativen

Für Nextcloud-User, die KeePass bereits nutzen, ist die Integration der bestehenden Passwort-Verwaltung in die eigenen Cloud sicherlich sinnvoll. An dieser Stelle soll allerdings auch erwähnt werden, dass es darüber hinaus noch zwei Alternativen gibt:

Im Nextcloud App Store befinden sich mit Passman und Passwords noch zwei weitere Apps, mit den Passwörter in der eigenen Nextcloud verwaltet werden können. Beide Apps speichern ihre Einträge dabei direkt in der Cloud und nicht in kdbx-Dateien, daher sind die Apps auch nicht kompatibel mit KeePass. Dennoch bieten die Apps z.T. erweiterte Features, wie z.B. das direkte Teilen von einzelnen Passwörtern mit anderen Nextcloud-Benutzern oder per Link. Mit der KeePass-Lösung kann man nur die gesamte kdbx-Datei teilen, daher gilt hier das Motto „alles oder nichts“.

Fazit

In diesem Artikel wurde gezeigt, wie man seine Passwörter ganz einfach in der eigenen Nextcloud-Instanz verwalten kann. Nutzer von KeePass oder alternativen Clients können im einfachsten Fall die Funktionen zur Datei-Synchronisierung von Nextcloud nutzen, aber auch eine direkte Integration ist per App möglich, so dass kdbx-Dateien direkt in der Cloud geöffnet und bearbeitet werden können.

Darüber hinaus gibt es mit den Apps Passman und Passwords noch Alternativen für die Passwort-Verwaltung mit Nextcloud. Welche Lösung hier die beste (oder komfortabelste) ist, muss jedoch jeder für sich selbst herausfinden. Dazu können die Apps auch erst einmal im Parallelbetrieb installiert/getestet werden.

Wenn man sich für eine Lösung entschieden hat, werden die eigenen Passwörter zukünftig in der eigenen Cloud verwaltet. Durch den Einsatz eines Online-Password-Managers muss man sich nun nie mehr komplizierte Passwörter ausdenken und schon gar nicht merken.

Ich bin zwar kein Fan von Wechsel dein Passwort-Tagen, aber vielleicht ist dieser Artikel mal ein Anreiz, den Umgang mit eigenen Passwörtern zu überdenken und ggf. anzupassen.

Was haltet ihr davon? Wie verwaltet ihr eure Passwörter? Hinterlasst mir dazu doch einfach einen Kommentar.

Weiterführende Artikel

Links

]]>
https://decatec.de/home-server/passwoerter-verwalten-mit-nextcloud-keepass/feed/ 3
RSA und ECDSA-Zertifikate mit nginx (Hybrid-Lösung) https://decatec.de/home-server/rsa-und-ecdsa-zertifikate-mit-nginx-hybrid-loesung/ https://decatec.de/home-server/rsa-und-ecdsa-zertifikate-mit-nginx-hybrid-loesung/#comments Sun, 17 Mar 2019 14:13:33 +0000 https://decatec.de/?p=5314 Let's Encrypt Logo

Wer Webdienste wie Nextcloud betreibt, der sollte auf jeden Fall sicher stellen, dass die Verbindung zum Server stets mittels HTTPS verschlüsselt ist. Damit dies funktioniert, benötigt man ein TLS-Zertifikat. Dank Let’s Encrypt kann man solche Zertifikate kostenlos beziehen und die Generierung geht leicht von der Hand.

Zum Thema TLS-Zertifikate und v.a. auch Let’s Encrypt sind hier im Blog schon einige Beiträge veröffentlicht worden. Heute soll es um eine spezielle Optimierung gehen:

RSA und ECDSA-Zertifikate im Hybrid-Betrieb mit dem Webserver nginx. Damit kommen moderne Zertifikate (ECDSA) zum Einsatz und gleichzeitig wird die Kompatibilität zu älteren Clients mittels RSA-Zertifikaten sicher gestellt.

Ein kleiner Ausflug in die Kryptografie

Zunächst soll erst einmal mit einfachen Worten geklärt werden, was sich hinter RSA bzw. ECDSA verbirgt.

Ohne nun zu weit in die Theorie abzuschweifen, sind beides asymmetrische kryptografische Verfahren, die zum Verschlüsseln, also auch zum digitalen Signieren genutzt werden. Dabei wird ein Schlüsselpaar bestehend aus einem öffentlichen und einem privaten Schlüssel genutzt. Ganz allgemein ausgedrückt können mittels des öffentlichen Schlüssels Nachrichten verschlüsselt werden, die nur mit dem privaten Key wieder entschlüsselt werden können.
Ein Anwendungsgebiet ist dabei die Kommunikation über HTTPS: Der öffentliche Schlüssel ist im Zertifikat enthalten, so dass ein Client (z.B. Browser) damit eine Nachricht verschlüsseln kann. Der private Schlüssel ist nur dem Webserver bekannt, so dass nur dieser die HTTPS-Nachrichten entschlüsseln kann.

RSA ist dabei das ältere Verfahren, welches schon in den 1970er Jahren zum Einsatz kam. Für die Sicherheit spielt hier die Schlüssellänge eine entscheidende Rolle. Momentan werden meist Schlüssellängen von 4096 empfohlen. Dennoch wird sich das vermutlich in Zukunft ändern, da immer leistungsstärkere Rechner zum Einsatz kommen, mit dem eine solche Verschlüsselung irgendwann geknackt werden kann. Hier helfen dann nur längere Schlüssel, da zum Ver- und Entschlüsseln mehr Rechenleistung benötigt wird, je länger der verwendete Schlüssel ist.

ECDSA ist ein neueres asymmetrisches Verfahren, welches auf elliptischen Kurven basiert. Der Vorteil bei ECDSA ist, dass sehr viel kürzere Schlüssellängen (bei gleicher oder gar besserer Sicherheit) zum Einsatz kommen können. So entspricht eine Schlüssellänge von 384 Bit bei ECDSA einer Schlüssellänge von 7680 bei RSA (siehe OpenSSL Wiki).

Ich möchte hier nun nicht weiter auf die technischen/mathematischen Details beider Krypto-Verfahren eingehen. Wer es genau wissen möchte, findet in den entsprechenden Artikeln bei Wikipedia genug Informationen.

Zusammengefasst kann man sagen, dass ECDSA-Zertifikate effizienter sind als RSA-Zertifikate, da durch eine kürzere Schlüssellänge weniger Rechenleistung für die Ver- und Entschlüsselung benötigt werden.

Warum sollte man nun RSA- und ECDSA-Zertifikate parallel einsetzen? Dies liegt darin begründet, dass ECDSA das neuere Verfahren ist, welches gerade von älteren Clients nicht immer unterstützt wird. Das ECDSA-Zertifikat sollte bevorzugt zum Einsatz kommen. Falls jedoch ein Client ECDSA nicht unterstützt, kommt das RSA-Zertifikat sozusagen als Fallback zum Zug.

Voraussetzungen

In diesem Artikel liegt der Fokus nur auf der Erzeugung der passenden Zertifikate und deren Einbindung in nginx. Damit das Ganze funktioniert, müssen ein paar Voraussetzungen erfüllt sein:

  • Es muss eine Domain vorhanden sein (Let’s Encrypt kann Zertifikat nur auf Domains, nicht jedoch auf IP-Adressen ausstellen). Im Heim-Bereich wird dies in den meisten Fällen eine DynDNS-Adresse sein, unter der der eigene Router aus dem Internet erreichbar ist. In diesem Artikel wird dazu beispielhaft die Domain meinedomain.de verwendet.
  • Der Router muss in diesem Fall so konfiguriert sein, dass ein Portweiterleitung für die Ports 80 und 443 für die Maschine eingerichtet ist, auf der der Webserver läuft.
  • Webserver: nginx (ab Version 1.11.0)
  • Ein Let’s Encrypt Client, der sowohl RSA-, als auch ECDSA-Zertifikate unterstützt. Ich empfehle hier den Client acme.sh.
  • Der Webserver muss bereits so eingerichtet sein, dass Zertifikate von Let’s Encrypt bezogen werden können. Dazu müssen Verbindungen über Port 80 zur URL http://meinedomain.de/.wellknown/acmechallenge möglich sein.

Details zur möglichen Einrichtung des Webservers und der Verwendung des Let’s Encrypt Clients acme.sh sind im Artikel Let’s Encrypt Zertifikate mit acme.sh und nginx zu finden.

Generierung der Zertifikate

Wenn alle Voraussetzungen erfüllt sind, dann kann es an die Generierung der Zertifikate gehen.

Da zwei unterschiedliche kryptografische Verfahren für die Zertifikate zum Einsatz kommen, müssen dementsprechend auch zwei Zertifikate getrennt voneinander erzeugt werden.

RSA-Zertifikate

Als erstes kümmern wir uns um das „klassische“ RSA-Zertifikat. Dieses kann mittels acme.sh durch folgenden beispielhaften Befehl erstellt werden:

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

Durch die Angabe

--keylength 4096
wird ein RSA-Zertifikat mit der Schlüssellänge von 4096 Bit erzeugt.

Wenn die Konfiguration des Webservers passt, sollte das Zertifikat nach wenigen Augenblicken generiert worden sein.

ECDSA-Zertifikate

Der zweite Schritt ist nun die Erzeugung des ECDSA-Zertifikats. Auch hier nutzen wir wieder den beispielhaften Befehl:

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

Dieser Befehl sieht eigentlich genau so aus wie der vorhergehende. Lediglich über den Parameter

--keylength ec-384
wird angegeben, dass diesmal ein ECDSA-Zertifikat (384 Bit) angefordert wird.

Zertifikate einbinden

Wenn die Zertifikate ohne Fehler erzeugt wurden, können diese anschließend in der Webserver-Konfiguration eingebunden werden. Ich lagere dabei alle SSL-spezifischen Einstellungen immer in eine gesonderte Datei aus. Dies ist kein Muss, sondern dient nur der besseren Übersichtlichkeit.

nano /etc/nginx/snippets/ssl.conf

Hier der gesamte Inhalt:

# Certificates used
# RSA
ssl_certificate /etc/letsencrypt/meinedomain.de/rsa/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/meinedomain.de/rsa/key.pem;

# ECC
ssl_certificate /etc/letsencrypt/meinedomain.de/ecc/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/meinedomain.de/ecc/key.pem;

# This should be ca.pem (certificate with the additional intermediate certificate)
# See here: https://certbot.eff.org/docs/using.html
ssl_trusted_certificate /etc/letsencrypt/meinedomain.de/ecc/ca.pem;

# Diffie-Hellman parameter, recommended 4096 bits
ssl_dhparam /etc/nginx/dhparams/dhparams.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;

# Prefer the SSL ciphers for ECDSA:
ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384';

# Use multiple curves.
# secp521r1: Not supported by Chrome
# secp384r1: Not supported by Android (DAVx5)
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 is the IP if yout DNS-Server (in most cases: your router's IP)
resolver 192.168.178.1;

# SSL session handling
ssl_session_timeout 24h;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;

Wichtig für die Kombination RSA/ECDSA-Zertifikate sind hier besonders folgende Einstellungen:

  • Zunächst werden mit ssl_certificate und ssl_certificate_key die Zertifikate eingebunden. Diese Anweisungen sind doppelt (einmal für RSA, einmal für ECDSA) aufgeführt, da wir ja auch zwei Zertifikate parallel einbinden wollen.
  • Welches Zertifikat vorzugsweise zum Einsatz kommt, wird durch die ssl_ciphers gesteuert: Dadurch, dass die Ciphers ECDHE-ECDSA-CHACHA20-POLY1305 (speziell für ECDSA) am Anfang aufgeführt sind, wird erst mal versucht, damit eine Verbindung aufzubauen. Wenn das klappt, kommt automatisch das ECDSA-Zertifikat zum Einsatz. Falls das nicht klappen sollte, kommen die anderen Ciphers (und damit das RSA-Zertifikat) zum Zug. Dadurch haben wir einen effizienten Fallback-Mechanismus, falls z.B. der Client keine ECDSA-Zertifikate unterstützt.
  • Alle anderen Einstellungen bzgl. SSL sind nicht spezifisch für RSA/ECDSA und sind hier einfach nur für maximale Sicherheit ausgelegt.

Die Datei mit den SSL-spezifischen Einstellungen kann dann in den virtuellen Hosts von nginx durch eine einzige Zeile eingebunden werden (im server-Block für den HTTPS-Server):

include /etc/nginx/snippets/ssl.conf;

Nach der Durchführung der Änderungen muss der Webserver natürlich noch neu gestartet werden:

service nginx restart

Hier sollten keine Fehler auftreten. Falls doch, liegt vermutlich in der Konfiguration noch ein Fehler vor. Um das genaue Problem zu ermitteln, hilft in diesem Fall folgender Befehl, der die genaue Zeile in den vHosts anzeigen sollte, wo die Ursache des Fehlers zu finden ist:

nginx -t

Wenn alles geklappt hat, läuft nginx im „Zerifikat-Hybrid-Betieb“ und wir können uns ansehen, wie sich das in der Praxis auswirkt.

Test der Zertifikate

Zum Testen der Zertifikate nutze ich immer gern den SSL-Test von Qualys SSL Labs. Hier sollte zunächst einmal ein A+ Rating erzielt werden können (inkl. 100% bei allen Kategorien). Das wäre aber auch mit einem reinen RSA-Zertifikat möglich. Durch das zusätzliche ECDSA-Zertifikat sollte der Test nun allerdings zwei Zertifikate anzeigen: Ein RSA-Zertifikat mit der Schlüssellänge von 4096 Bit und ein ECDSA-Zertifikat mit der Schlüssellänge von 384 Bit.

Beim SSL-Test werden zwei Zertifikate angezeigt (RSA und ECDSA)

Beim SSL-Test werden zwei Zertifikate angezeigt (RSA und ECDSA)

Falls beim SSL-Test kein A+ Rating erreicht wurde, sollten nochmals die SSL-Einstellungen des Webservers überprüft werden.

Auch im Browser (z.B. Firefox) sollte man nun bei den Details zum verwendeten Zertifikat sehen, dass ein ECDSA-Zertifikat zum Einsatz kommt.

Firefox nutzt nun automatisch das ECDSA-Zertifikat

Firefox nutzt nun automatisch das ECDSA-Zertifikat

Welches Zertifikat genutzt wird, lässt sich übrigens Client-seitig nicht festlegen. Der Client wird hier immer den ersten SSL-Cipher nehmen, mit dem er kompatibel ist. ECDSA wird hier vom Webserver bevorzugt behandelt, da die entsprechenden Ciphers am Anfang der Cipher-Liste aufgeführt sind.

Fazit

Der Artikel hat gezeigt, wie man mit dem Webserver nginx auf einfache Weise RSA- und ECDSA-Zertifikate im Hybrid-Betrieb installieren kann.

Was bringt das nun? In der Praxis wird man hier kaum einen Unterschied feststellen können, ob nun ein (traditionelles) RSA-, oder ein (moderneres) ECDSA-Zertifikat zum Einsatz kommt. Trotzdem ist bei einem ECDSA-Zertifikat weniger Rechenleistung für die Ver- und Entschlüsselung notwendig.

Durch den allgemeinen Anstieg der Leistung moderner Rechner ist zu erwarten, dass immer längere Schlüssel für TLS-Zertifikate benötigt werden – vielleicht ist hier in Zukunft ein RSA-Zertifikat mit 4096 Bit auch schon nicht mehr ausreichend. Mit dem Hybrid-Betrieb RSA/ECDSA ist man auf jeden Fall mit einem modernen Schlüsselaustausch (ECDSA) bestens für die Zukunft gerüstet, währenddessen der Einsatz von RSA die Kompatibilität mit älteren Clients sicherstellt.

Weiterführende Artikel

Links

]]>
https://decatec.de/home-server/rsa-und-ecdsa-zertifikate-mit-nginx-hybrid-loesung/feed/ 11
Linux: Einfach E-Mails versenden mit msmtp https://decatec.de/linux/linux-einfach-e-mails-versenden-mit-msmtp/ https://decatec.de/linux/linux-einfach-e-mails-versenden-mit-msmtp/#comments Wed, 27 Feb 2019 14:57:15 +0000 https://decatec.de/?p=5049 Linux Mail Logo

Oftmals macht es Sinn, wenn man von einem Linux-System direkt eine E-Mail senden kann. Anwendungsbeispiele wären z.B. der Versand einer Mail, wenn ein Cronjob fehlschlägt oder auch eine Benachrichtigung, wenn durch fail2ban eine IP auf Grund zu vieler fehlgeschlagener Anmeldeversuche gebannt wurde.

Nun könnte man einfach einen Mail Transfer Agent, wie z.B. Sendmail oder Postfix auf dem System aufsetzen. Allerdings ist es recht umständlich einen „echten“ Mail-Server zu betreiben, v.a. wenn man nur einfache Mails zur Benachrichtigung versenden will.

Hierzu gibt es dann einfache Programme, die nicht mit einem echten Mailserver zu vergleichen sind, sondern die einfach Mails an einen bereits bestehenden STMP-Server senden können – dazu braucht man einfach nur einen SMTP-Client).

Vor einiger Zeit habe ich in diesem Blog schon mal den SMTP-Client sSMTP vorgestellt. Heute will ich eine Alternative dazu vorstellen: msmtp

Auch wenn der Artikel auf Ubuntu 18.04 basiert, sollte es kein Problem sein, das gezeigte Vorgehen auf anderen Systemen/Distributionen umzusetzen.

sSMTP läuft doch problemlos – was spricht dagegen?

Ich habe mit sSMTP immer gute Erfahrungen gemacht. Jedoch wird dieses Programm nicht mehr weiterentwickelt (Quelle: Arch Wiki). Dadurch kann ich sSMTP nicht mehr ohne Einschränkungen empfehlen. Wenn beispielsweise Bugs oder Sicherheitslücken gefunden werden, ist es fraglich, ob diese noch ausgebaut werden.

Generell sollte man aus diesen Gründen Abstand von Software nehmen, die nicht mehr aktiv weiterentwickelt wird. Trotzdem soll das nun nicht heißen, dass man sSMTP ab sofort nicht mehr verwenden sollte: Wer sSMTP bereits eingerichtet hat und damit keine Probleme hat, muss sich nun nicht sofort nach einer Alternative umsehen – trotzdem sollte man über kurz oder lang über ein „Update“ zu msmtp nachdenken.

Wer aber gerade auf der Suche nach einem leichtgewichtigen SMTP-Client ist, der sollte lieber gleich zu msmtp greifen.

Installation und Konfiguration vom msmtp

Zunächst bringen wir das System wie immer auf den neusten Stand:

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

Anschließend wird msmtp installiert:

apt-get install msmtp msmtp-mta mailutils

Das Paket mailutils wird zwar nicht unbedingt benötigt, jedoch ist dies beim späteren Verwenden von Mails sehr hilfreich,.

Für die Konfiguration des Programms gibt es zwei unterschiedliche Konfigurations-Dateien:

  • Eine systemweite Konfiguration
  • Eine benutzerspezifische Konfiguration.

Wo diese unterschiedlichen Konfigurations-Dateien gespeichert sind, ermittelt man einfach mit folgendem Befehl:

msmtp --version

Für das weitere Vorgehen nutzen wir hier die systemweite Konfiguration, da E-Mails nur vom System selbst verschickt werden sollen (z.B. bei fehlgeschlagenen Cronjobs).

msmtp: Speicherort der Konfigurations-Dateien

msmtp: Speicherort der Konfigurations-Dateien

Beide Dateien sind nach einer neuen Installation nicht vorhanden (so dass man diese einfach nur auf die eigenen Bedürfnisse abändern könnte), allerdings gibt es auf der Website von msmtp eine Beispiel-Konfiguration.

Für die systemweite Konfiguration wird nun folgende Datei bearbeitet:

nano /etc/msmtprc

Der Inhalt kann beispielsweise so aussehen (hier am Beispiel eines fiktiven Mail-Accounts meinedomain.de):

# Set default values for all following accounts.
defaults

# Use the mail submission port 587 instead of the SMTP port 25.
port 587

# Always use TLS.
tls on

# Set a list of trusted CAs for TLS. The default is to use system settings, but
# you can select your own file.
tls_trust_file /etc/ssl/certs/ca-certificates.crt

# If you select your own file, you should also use the tls_crl_file command to
# check for revoked certificates, but unfortunately getting revocation lists and
# keeping them up to date is not straightforward.
#tls_crl_file ~/.tls-crls

# Mail account
# TODO: Use your own mail address
account bob@meindedomain.de

# Host name of the SMTP server
# TODO: Use the host of your own mail account
host smtp.meindedomain.de

# As an alternative to tls_trust_file/tls_crl_file, you can use tls_fingerprint
# to pin a single certificate. You have to update the fingerprint when the
# server certificate changes, but an attacker cannot trick you into accepting
# a fraudulent certificate. Get the fingerprint with
# $ msmtp --serverinfo --tls --tls-certcheck=off --host=smtp.freemail.example
#tls_fingerprint 00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33

# Envelope-from address
# TODO: Use your own mail address
from bob@meindedomain.de

# Authentication. The password is given using one of five methods, see below.
auth on

# TODO: Use your own user name fpr the mail account
user bob@meindedomain.de

# Password method 1: Add the password to the system keyring, and let msmtp get
# it automatically. To set the keyring password using Gnome's libsecret:
# $ secret-tool store --label=msmtp \
#   host smtp.freemail.example \
#   service smtp \
#   user joe.smith

# Password method 2: Store the password in an encrypted file, and tell msmtp
# which command to use to decrypt it. This is usually used with GnuPG, as in
# this example. Usually gpg-agent will ask once for the decryption password.
#passwordeval gpg2 --no-tty -q -d ~/.msmtp-password.gpg

# Password method 3: Store the password directly in this file. Usually it is not
# a good idea to store passwords in plain text files. If you do it anyway, at
# least make sure that this file can only be read by yourself.
# TODO: Use the password of your own mail account
password pAssW0Rd123

# Password method 4: Store the password in ~/.netrc. This method is probably not
# relevant anymore.

# Password method 5: Do not specify a password. Msmtp will then prompt you for
# it. This means you need to be able to type into a terminal when msmtp runs.

# Set a default account
# TODO: Use your own mail address
account default: bob@meindedomain.de

# Map local users to mail addresses (for crontab)
aliases /etc/aliases

Alle Einstellungen, die man individuell anpassen muss, sind hier mit „# TODO“ gekennzeichnet. Bitte auch die Kommentare in der Datei beachten.

Noch ein Hinweis auf die Authentifizierungs-Methode: In diesem Beispiel nutzen wird die einfachste Form der Authentifizierung, indem das Passwort des Mail-Accounts direkt in der Konfiguration gespeichert wird. msmtp unterstützt hier allerdings auch weitere Authentifizierungs-Methoden. Mehr Informationen dazu findet man in der Dokumentation zu msmtp.

Als nächstes sorgen wir dafür, dass nicht jeder Zugriff auf die Datei hat (besonders wichtig, wenn das Passwort direkt in der Konfiguration gespeichert ist):

chmod 600 /etc/msmtprc

Nach der erfolgten Konfiguration vom msmtp können E-Mails nun ganz einfach über die Kommandozeile verschickt werden:

echo "Inhalt der E-Mail" | mail -s "Betreff" test@mail.de

Am besten gleich mal ausprobieren, indem ihr euch selbst eine Test-E-Mail schickt.

Weitere Konfiguration (Conjobs, Fail2ban)

E-Mails können nun also über die Kommandozeile verschickt werden. Allerdings wird man dies auf einem Server nicht sonderlich häufig machen. Hier ist es eher wichtig, per E-Mail bei wichtigen Meldungen des Systems benachrichtigt zu werden.

Damit Mails über msmtp auch bei der Ausführung von Cronjobs oder bei einem erfolgten Ban von Fail2ban verschickt werden, sind noch ein paar wenigen Schritte notwendig.

Zunächst wird msmtp als Mail-Programm festgelegt. Dies geschieht durch folgende Datei:

nano /etc/mail.rc

Der Inhalt sieht dabei folgendermaßen aus:

set sendmail="/usr/bin/msmtp -t"

Zum Schluss wird noch ein Alias angelegt, so dass die Empfänger-Adresse des Root-Accounts bekannt ist. Dies wird in der Datei angegeben, die auch schon ganz am Ende der Konfiguration von msmtp aufgeführt wurde:

nano /etc/aliases

Hier wird nun die Empfänger-Adresse des Root-Accounts angegeben. An diese Adresse werden nun E-Mails verschickt, wenn z.B. ein Cronjob fehlschlagen sollte. Daneben wird noch eine allgemeine „Fallback-Empfänger-Adresse“ angegeben, falls System-Meldungen nicht im Kontext des Root-Accounts auftreten:

root: admin@meinedomain.de
default: admin@meinedomain.de

Fazit

Mit msmtp ist es einfach möglich, von einem Linux-System E-Mails zu versenden, ohne einen „schwergewichtigen“ Mail-Server aufsetzen zu müssen. Es wird einfach ein vorhandener Mail-Account (z.B. eines Freemailers) benutzt und die Konfiguration gestaltet sich auch sehr einfach.

Neben dem Mail-Versand von der Kommandozeile erhält man nun auch ganz komfortabel Benachrichtigungen per E-Mail, wenn beispielsweise ein Cronjob ausgeführt wurde, oder auch eine IP-Adresse von Fail2ban gebannt wurde.

Weiterführende Artikel

Links

]]>
https://decatec.de/linux/linux-einfach-e-mails-versenden-mit-msmtp/feed/ 11
Let’s Encrypt: Umstieg von Certbot auf acme.sh (nginx) https://decatec.de/linux/lets-encrypt-umstieg-von-certbot-auf-acme-sh-nginx/ https://decatec.de/linux/lets-encrypt-umstieg-von-certbot-auf-acme-sh-nginx/#comments Sat, 09 Feb 2019 14:19:10 +0000 https://decatec.de/?p=5268 Let's Encrypt Logo

Im letzten Artikel ging es um das Erstellen von TLS-Zertifikaten von Let’s Encrypt. Als Client kam hier acme.sh zum Einsatz. In meinen bisherigen Artikeln habe ich bisher immer Certbot als Client für Let’s Encrypt empfohlen. Da acme.sh meiner Meinung nach allerdings einige Vorteile bietet, wird dies vermutlich auch meine zukünftige Empfehlung zur Generierung von TLS-Zertifikaten von Let’s Encrypt sein.

Da aber etliche Leser meines Blogs wohl noch Certbot nutzen, möchte ich in diesem Artikel einen Leitfaden zum Umstieg auf acme.sh nachliefern.

Besonders wichtig dürfte die Umstellung auf acme.sh für Debian-Nutzer sein, da die in den Paketquellen enthaltene Certbot-Version nur ein Validierungsverfahren beherrscht, welches Let’s Encrypt bald nicht mehr unterstützen wird (mehr Infos dazu gibt es hier).

Wer Certbot bisher noch nicht verwendet hat: Dieser Artikel richtet sich ausschließlich an Umsteiger von Certbot zu acme.sh. Wer das erste mal TLS-Zertifikate erzeugen möchte, der sollte sich an den Artikel Let’s Encrypt Zertifikate mit acme.sh und nginx halten.

Update-Historie (letztes Update 13.02.2019)
  • 13.02.2018:
    • Hinweis für die Berechtigungen des Verzeichnisses /var/www/letsencrypt hinzugefügt.
  • 11.02.2019:
    • Hinweis auf Überschreiben der Crontab durch Installation von acme.sh hinzugefügt/Sichern der bestehenden Crontab.
  • 10.02.2019:
    • Reihenfolge der im Tutorial ausgeführten Schritte angepasst – das Umkopieren der alten Zertifikate war nicht notwendig, da diese von Certbot in einem anderen Verzeichnis gespeichert wurden.

 

Voraussetzungen

Ich gehe im Folgenden davon aus, dass die TLS-Zertifikate mit Certbot gemäß dem Artikel Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban erstellt wurden.

Im Detail heißt dies:

  • Certbot wurde installiert und der automatisch eingerichtete Cronjob zur Erneuerung der Zertifikate wurde genutzt.
  • Es wurden durch Certbot bereits Zertifikate generiert (d.h. der Webserver ist fertig eingerichtet und im Router sind die entsprechenden Port-Weiterleitungen bereits eingerichtet).
  • Die Zertifikate sind im Verzeichnis /etc/letsencrypt/live/meinedaomin.de gespeichert (meinedomain.de dient hier nur als Beispiel-Domain) und bestehen aus den Dateien cert.pem, chain.pem, fullchain.pem und privkey.pem.
  • Diffie-Hellman-Parameter sind ebenfalls bereits vorhanden (/etc/nginx/ssl/dhparams.pem).

Vorbereitungen – alte Zertifikate kopieren

Bevor die neuen Zertifikate erstellt werden können, müssen die alten Zertifikate erst einmal an eine andere Stelle kopiert werden. Dies ist notwendig, da bei der späteren Deinstallation von Certbot der komplette Order /etc/letsencrypt entfernt wird.

mkdir -p /etc/certs-temp
cp -r /etc/letsencrypt/* /etc/certs-temp

Damit diese Kopie der Zertifikate (temporär) vom Webserver verwendet wird, sind die SSL-Einstellungen im Gateway-Host zu bearbeiten:

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

Hier sind die Verzeichnis-Angaben für die Zertifikat-Dateien anzupassen:

ssl_certificate /etc/certs-temp/live/meinedomain.de/fullchain.pem;
ssl_certificate_key /etc/certs-temp/live/meinedomain.de/privkey.pem;
ssl_trusted_certificate /etc/certs-temp/live/meinedomain.de/chain.pem;

Ein Neustart von nginx sollte dann problemlos verlaufen und die (temporären) Zertifikate werden genutzt:

service nginx restart

Certbot deinstallieren

Nun kann Certbot komplett vom System entfernt werden. Mit der Installation von Certbot wurden nicht nur die Programm-Dateien installiert, sondern es wurde darüber hinaus noch ein Cronjob eingerichtet, der für die automatische Erneuerung der Zertifikate sorgt. Diesen Cronjob kann man mit folgendem Befehl ermitteln:

systemctl list-timers

In der Auflistung sollte dann der Cronjob von Certbot auftauchen:

systemctl list-timers listet den Cronjob von Certbot

systemctl list-timers listet den Cronjob von Certbot

Als erstes sollte Certbot deinstalliert werden. Dies geschieht über folgenden Befehl:

apt-get purge certbot

Dies deinstalliert neben den Programm-Dateien auch noch sämtliche Konfigurationen, Abhängigkeiten und auch die alten Zertifikate.

Anschließend sollte ein systemctl list-timers den Cronjob für Certbot nicht mehr aufführen und Certbot ist restlos vom System entfernt worden.

Neue Zertifikate generieren

Der Einfachheit halber werden am besten gleich ganz neue Zertifikate über acme.sh erstellt. Das sollte kein Problem darstellen, wenn man die alten Zertifikate nicht ein paar Tage zuvor mit Certbot erstellt hat – Let’s Encrypt hat gewisse „Rate Limits“, d.h. man kann in einem bestimmten Zeitraum nur eine gewisse Anzahl an Zertifikaten beantragen (siehe hier).

Details zu dem Vorgehen und zur „Installation“ von acme.sh sind im Artikel Let’s Encrypt Zertifikate mit acme.sh und nginx zu finden, daher hier im Schnelldurchlauf.

Wichtig: Falls bereits Cronjobs (für den Root-User) eingerichtet sind, dann solltet ihr euch vorher die aktuelle Crontab sichern, da acme.sh diese bei der Installation ungefragt überschreibt:

crontab -l > crontab.bak

Nach der Installation von acme.sh können mittels dieser Datei die „alten“ Cronjobs wieder mit contab -e hinzugefügt werden.

Nun legen wir zunächst das Verzeichnis an, in dem später die Zertifikate gespeichert werden:

mkdir -p /etc/letsencrypt/meinedomain.de

Bevor wir nun die Zertifikate erzeugen, stellen wir zunächst noch sicher, dass beim Verzeichnis /var/www/letsencrypt die korrekten Besitzrechte gesetzt sind:

chown -R www-data:www-data /var/www/letsencrypt

Die Generierung der Zertifikate erfolgt dann über einen Befehl:

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

Da wird am Webserver ansonsten nichts bzgl. Let’s Encrypt geändert haben, sollte die Generierung der Zertifikate erfolgreich abgeschlossen werden können.

Die Diffie-Hellman-Parameter müssen nicht neu generiert werden, sondern können wiederverwendet werden. Dennoch kopieren wir die Datei an einen anderen Speicherort, somit ist das Vorgehen zum vorherigen Artikel identisch:

mkdir -p /etc/nginx/dhparams
cp /etc/nginx/ssl/dhparams.pem /etc/nginx/dhparams/dhparams.pem

Einbinden der neuen Zertifikate

Nun können die neu Generierten Zertifikate auch schon eingebunden werden. Für eine bessere Übersichtlichkeit lagern wir dazu aber auch noch sämtliche Webserver-Einstellungen bzgl. SSL in eine eigene Datei aus.

Wichtig: Diese Datei darf nicht in dem Verzeichnis gespeichert werden, in dem nginx die virtuellen Hosts erwartet (also /etc/nginx/conf.d).

mkdir -p /etc/nginx/snippets
nano /etc/nginx/snippets/ssl.conf

Hier werden nun die folgenden Anweisungen aufgenommen:

# Certificates used
ssl_certificate /etc/letsencrypt/meinedomain.de/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/meinedomain.de/key.pem;

# This should be ca.pem (certificate with the additional intermediate certificate)
# See here: https://certbot.eff.org/docs/using.html
ssl_trusted_certificate /etc/letsencrypt/meinedomain.de/ca.pem;

# Diffie-Hellman parameter, recommended 4096 bits
ssl_dhparam /etc/nginx/dhparams/dhparams.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';

# Use multiple curves.
# secp521r1: Not supported by Chrome
# secp384r1: Not supported by Android (DAVx5)
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;

resolver 192.168.178.1;

# SSL session handling
ssl_session_timeout 24h;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;

Die markierten Zeilen betreffen die neuen Zertifikat-Dateien, alle anderen Anweisungen sind identisch zu den Anweisungen im Gateway-Host.

Damit die SSL-Einstellungen nur noch aus der Datei ssl.conf gezogen werden, muss der Gateway-Host angepasst werden:

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

Sämtliche Einstellungen, die schon in der ssl.conf aufgeführt werden, sind aus dem Gateway-Host zu entfernen. Diese werden dann durch eine einzige Zeile ersetzt (am besten direkt nach der Direktive server_name):

include /etc/nginx/snippets/ssl.conf;

Ein Neustart des Webservers bindet nun die neuen Zertifikate ein und sollte ohne Fehlermeldung ablaufen. Falls hier dennoch Fehler auftreten, sind vermutlich noch ein paar SSL-Anweisungen doppelt vorhanden (im Gateway-Host und in der ssl.conf). Welche Anweisungen zum Fehler führen, kann man einfach mit folgendem Befehl herausfinden:

nginx -t

Abschlussarbeiten

Zum Schluss können noch die (kopierten) alten Zertifikate und Diffie-Hellman-Parameter entfernt werden:

rm -r /etc/certs-temp
rm -r /etc/nginx/ssl

Überprüfung der neuen Zertifikate

Zum Schluss können die neuen Zertifikate noch getestet werden. Hierzu ist der SSL Server Test von Qualys SSL Labs gut geeignet. Hier sollte ein Rating mit A+ und 100% in allen Kategorien erreicht werden können:

Ergebnis des SSL-Tests

Ergebnis des SSL-Tests

Falls die Bewertung schlechter ausfällt, sollten sollten nochmals die Einstellungen des Webservers kontrolliert werden, v.a. die Anweisungen in der ssl.conf.

Erneuerung der Zertifikate

Die Zertifikate von Let’s Encrypt nur eine begrenzte Gültigkeit von 90 Tagen (Begründung siehe hier), danach müssen sie erneuert werden.

acme.sh hat aber bereits bei der Installation einen Cronjob eingerichtet, der sich um die automatische Erneuerung der Zertifikate kümmert – hier ist also nach dem ersten Generieren der Zertifikate nichts weiter zu tun.

Die Gültigkeitsdauer der installierten Zertifikate kann übrigens mit folgendem Befehl ermittelt werden:

acme.sh --list

Fazit

Der Artikel hat gezeigt, wie man von Certbot auf acme.sh für die Generierung von Let’s Encrypt Zertifikaten umsteigen kann. Darüber hinaus wurde die Verwaltung der SSL-Einstellungen am Webserver vereinfacht, indem die entsprechenden Anweisungen in eine eigene Datei ausgelagert wurden.

Nach Erfolgreicher Umstellung sollte man nur mal nach ca. 90 Tagen (Gültigkeitsdauer der Let’s Encrypt Zertifikate) kontrollieren, ob die Zertifikate auch automatisch erneuert wurden. Ist dies der Fall, kann man sich entspannt zurück lehnen und muss sich nicht mehr manuell um die Zertifikate oder deren Erneuerung kümmern.

Weiterführende Artikel

Links

]]>
https://decatec.de/linux/lets-encrypt-umstieg-von-certbot-auf-acme-sh-nginx/feed/ 32
Let’s Encrypt Zertifikate mit acme.sh und nginx https://decatec.de/linux/lets-encrypt-zertifikate-mit-acme-sh-und-nginx/ https://decatec.de/linux/lets-encrypt-zertifikate-mit-acme-sh-und-nginx/#comments Wed, 30 Jan 2019 14:36:40 +0000 https://decatec.de/?p=5213 Let's Encrypt Logo

Wer eine eigene Website oder auch eine Nextcloud-Instanz betreibt, der sollte auch großen Wert auf Sicherheit legen. In der heutigen Zeit gehört dabei HTTPS zum Sicherheits-Standard, wenn es um die verschlüsselte Übertragung von Daten im Internet geht.

Um die eigene Seite mittels HTTPS abzusichern, ist zunächst einmal ein SSL-Zertifikat notwendig. Früher musste man sich ein solches Zertifikat von einer Zertifizierungsstelle für viel Geld kaufen. Im Jahr 2015 trat jedoch Let’s Encrypt auf den Plan – eine Zertifizierungsstelle, die kostenlos Zertifikate für TLS anbietet, um damit verschlüsselte Verbindungen im Web zum Standard zu machen. Gerade im privaten Bereich hat sich Let’s Encrypt zu einem de-facto Standard entwickelt.

Seitdem kann sich jedermann selbst Zertifikate für HTTPS ausstellen lassen. Dazu wird lediglich ein Let’s Encrypt Client benötigt, der die eigentliche Generierung der Zertifikate übernimmt. In meinen Tutorials habe ich bisher immer Certbot als Client für Let’s Encrypt empfohlen, da dieses Programm in den Paketquellen fast aller Distributionen enthalten ist. Dennoch könnte sich genau dieser Umstand als Nachteil erweisen. So schaltet Let’s Encrypt aus Sicherheitsgründen das Validierungsverfahren „TLS-SNI-01“ bald ab. Nutzer von Debian laufen bald Gefahr, dass die Zertifikate nicht mehr erneuert werden können, da die Version von Certbot in Debian Stable zu alt ist und keine anderen Validierungsmethoden unterstützt (siehe hier).

Ein alternativer Let’s Encrypt Client ist acme.sh. Wie der Name bereits vermuten lässt, handelt es sich hierbei um ein reines Shell-Skript, welches die Generierung der Zertifikate übernimmt. Man ist damit nicht mehr von Programmen in den Paketquellen der Linux-Distributionen abhängig. Darüber hinaus ist acme.sh ein sehr fortschrittlicher Client, der bisher alle Features von Let’s Encrypt unterstützt. Grund genug, die diesen Let’s Encrypt Client einmal genauer anzusehen.

Der Artikel basiert dabei auf Ubuntu Server 18.04 LTS, alle gezeigten Schritte sollten sich aber auch auf anderen Distributionen umsetzen lassen. Als Webserver kommt nginx zum Einsatz.

Update-Historie (letztes Update 18.02.2019)
  • 18.02.2019:
    • Hinweis für Meldung „-bash: /home/user/.acme.sh/acme.sh.env: Permission denied“ hinzugefügt.
  • 13.02.2019:
    • Hinweis für die Berechtigungen des Verzeichnisses /var/www/letsencrypt hinzugefügt.
  • 11.02.2019:
    • Anleitung zum Upgrade von acme.sh hinzugefügt.
    • Hinweis auf Überschreiben der Crontab durch Installation von acme.sh hinzugefügt/Sichern der bestehenden Crontab.
  • 09.02.2019:
    • Hinweis auf neuen Artikel zum Umstieg von Certbot auf acme.sh hinzugefügt.

 

Installation von acme.sh

Es handelt sich bei acme.sh nur um ein Skript, jedoch kann es in gewisser Art installiert werden. Die Installation beinhaltet hauptsächlich die Einrichtung eines Cronjobs zur automatischen Erneuerung ausgestellter Zertifikate.

Alle folgenden Befehle werden mit Root-Rechten ausgeführt:

sudo -s

Wichtig: Falls bereits Cronjobs (für den Root-User) eingerichtet sind, dann solltet ihr euch vorher die aktuelle Crontab sichern, da acme.sh diese bei der Installation ungefragt überschreibt:

crontab -l > crontab.bak

Nach der Installation von acme.sh können mittels dieser Datei die „alten“ Cronjobs wieder mit contab -e hinzugefügt werden.

Diese Installation besteht eigentlich nur in der Ausführung des Skripts mit bestimmten Parametern und gestaltet sich recht einfach. Dazu gibt es eine spezielle Seite, die das Skript zur Installation beinhaltet: https://get.acme.sh.

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

Hinweis: Es ist immer gefährlich, eine unbekannte Quelle direkt in die Shell zu pipen, da man nie so genau weiß, was diese Quelle (in diesem Fall das Skript genau ausführt). Man sollte sich die Quelle (in diesem Fall https://get.acme.sh) vor der Ausführung des Befehle genau ansehen und überprüfen, ob hier nichts verdächtiges passiert. Für wen das Pipen auf die Shell nicht in Frage kommt, der findet noch ein paar alternative Installationsmöglichkeiten auf der Wiki-Seite des GitHub-Projekts.

Die "Installation" von acme.sh

Die „Installation“ von acme.sh

Nach der Installation muss das Terminal einmal geschlossen und wieder geöffnet werden. Alternativ kann man den Rechner auch einfach neu starten.

Hinweis: Es kann sein, dass nach dem Login auf der Konsole mit einem (non-Root) User eine Fehlermeldung erscheint:

-bash: /home/user/.acme.sh/acme.sh.env: Permission denied

Während der Installation wurde hier ein Alias für acme.sh konfiguriert, so dass das Skript einfach nur mit „acme.sh“ aufgerufen werden kann (ohne Angabe des vollständigen Pfades). Da die Installation im Kontext des Root-Users vorgenommen wurde, kann acme.sh für einen normalen User so nicht aufgerufen werden. Aus diesem Grund erscheint auch die Meldung beim Login. Allerdings schränkt dies dies nicht die Funktionsfähigkeit von acme.sh ein. Daher kann diese Meldung einfach ignoriert werden.

Damit ist die Installation bereits abgeschlossen. Als nächstes wird das System auf die Verwendung von SSL-Zertifikaten vorbereitet.

Vorbereitung des Systems

Zunächst richten wir dazu das Verzeichnis ein, in dem später die Zertifikate gespeichert werden:

mkdir -p /etc/letsencrypt/meinedomain.de

Ich nutze hier immer einen Unterordner, der mit der Domain übereinstimmt, für welche die Zertifikate ausgestellt werden sollen (in diesem Beispiel einfach meinedomain.de).

Als nächstes muss der Webserver in der Lage sein, über HTTP (Port 80) im Unterverzeichnis /.wellknown/acmechallenge für Let’s Encrypt erreichbar zu sein. Im virtuellen Host für die entsprechende Domain könnte dies dann folgendermaßen aussehen:

server {
	listen 80 default_server;
    listen [::]:80 default_server;
	server_name meinedomain.de 192.168.178.60;
 
	root /var/www;
	
	location ^~ /.well-known/acme-challenge {
		default_type text/plain;
		root /var/www/letsencrypt;
	}		
}

Falls noch nicht geschehen, wird noch das Verzeichnis für Let’s Encrypt angelegt und der Webserver-User wird als Owner festgelegt:

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

Zertifikate mit acme.sh erzeugen

Nach den Vorbereitungen sind wir nun soweit, dass wir Zertifikate über acme.sh ausstellen lassen können.

Ich gehe im folgenden davon aus, dass auf dem System bereits nginx als Webserver installiert und eingerichtet wurde. Für die Generierung der Zertifikate wird daher der sog. Webroot-Modus genutzt. acme.sh unterstützt allerdings auch andere Modi (z.B. einen Standalone-Modus, wenn kein Webserver auf dem System läuft). Es gibt auch einen speziellen Modus für nginx, allerdings werden hier die virtuellen Hosts vom Webserver bei der Generierung/Erneuerung der Zertifikate kurzzeitig verändert/ausgetauscht. Da ich meine vHosts lieber unangetastet lassen möchte, nutze ich daher immer nur den Webroot-Modus.

Ein Zertifikat wird durch einen einzigen Befehl erzeugt:

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

Mit den Parametern werden die Details zu Generierung der Zertifikate angegeben:

  • Mit 
    -d meinedomain.de
      wird die Domain angegeben, für die das Zertifikat erzeugt werden soll.
  • --keylength 4096
      gibt die Schlüssellänge des RSA-Zertifikats an. Standardmäßig werden hier 2048 Bit verwendet. Das ist in der Regel ausreichend, jedoch sollte man für erhöhte Sicherheit auf eine Schlüssellänge von 4096 Bit setzen.
  • Mit
    -w /var/www/letsencrypt
      wird das Verzeichnis angegeben, in dem die Challenge-Dateien gespeichert werden. Dies muss das Verzeichnis sein, welches bei nginx als root Verzeichnis für /.well-known/acme-challenge angegeben wurde (im jeweiligen virtuellen Host).
  • acme.sh speichert die Zertifikat-Dateien im Verzeichnis ~/.acme.sh/meinedomain.de. Es wird davon abgeraten, diese Dateien direkt in den virtuellen Hosts des Webservers zu referenzieren. Aus diesem Grund wird mit den Parametern
    --key-file
    ,
    --ca-file
    ,
    --cert-file
      und
    --fullchain-file
      die Speicherorte der Dateien angegeben, wo die entsprechenden Dateien „installiert“ werden sollen. Nur diese Dateien werden dann später in den vHosts von nginx eingebunden.
  • --reloadcmd
      gibt den Befehl an, der nach erfolgreicher Ausstellung/Erneuerung der Zertifikate ausgeführt werden soll. Damit der Webserver die neuen Zertifikate korrekt einbinden kann, wird nginx hier einfach kurz neu gestartet. Wenn hier mehrere Befehle ausgeführt werden sollen, sind diese durch ein Semikolon zu trennen.

Nach dem Generieren können alle von acme.sh ausgestellten Zertifikate auf dem System durch folgenden Befehl angezeigt werden:

acme.sh --list

Ebenfalls wird durch diesen Befehl die Gültigkeitsdauer der Zertifikate angezeigt (dazu später mehr).

Diffie-Hellman-Parameter erzeugen

Die Zertifikate selbst sind der wichtigste Punkt, wenn es um die Verschlüsselung der Verbindung über HTTPS geht. Um die Sicherheit noch weiter zu erhöhen, sollten noch sog. Diffie-Hellman-Parameter genutzt werden. Ohne nun die technischen Details zu beleuchten, geht es um einen sicheren Schlüsselaustausch bei Verbindungsaufbau. Die Generierung des Schlüssels muss dabei nur einmal erfolgen.

Achtung: Die Erzeugung der Diffie-Hellman-Parameter dauert gerade auf schwächerer Hardware sehr lange. Hier muss man bis zur Fertigstellung u.U. mehrere Stunden warten. In diesem Fall kann auch eine Schlüssel mit „nur“ 2048 Bit berechnet werden (die Zahl des zweiten Befehls gibt hierbei die Länge des Schlüssels in Bit an). Auf stärkerer Hardware ist allerdings eine Schlüssellänge von 4096 Bit empfehlenswert.

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

Einbinden der Zertifikate in nginx

Die Zertifikate können nun einfach mit nginx verwendet werden. Ich beschränke mich hier auf das reine Einbinden der Zertifikate und der entsprechenden SSL-Einstellungen.

Damit das Ganze übersichtlich bleibt, lagere ich die SSL-Settings immer in eine spezielle Datei aus, die dann später in die virtuellen Hosts eingebunden wird. Auf diese Weise sind alle Einstellungen bzgl. SSL nur an einem Ort zu finden.

Dazu legen wir zunächst eine neue Datei an:

mkdir -p /etc/nginx/snippets
nano /etc/nginx/snippets/ssl.conf

Hier werden dann ausschließlich die Anweisungen für SSL aufgeführt:

# Certificates used
ssl_certificate /etc/letsencrypt/meinedomain.de/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/meinedomain.de/key.pem;

# This should be ca.pem (certificate with the additional intermediate certificate)
# See here: https://certbot.eff.org/docs/using.html
ssl_trusted_certificate /etc/letsencrypt/meinedomain.de/ca.pem;

# Diffie-Hellman parameter, recommended 4096 bits
ssl_dhparam /etc/nginx/dhparams/dhparams.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';

# Use multiple curves.
# secp521r1: Not supported by Chrome
# secp384r1: Not supported by Android (DAVx5)
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;

resolver 192.168.178.1;

# SSL session handling
ssl_session_timeout 24h;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;

Neben dem Einbinden der eigentlichen Zertifikate dienen alle weiteren Anweisung ebenso der Sicherheit/Verschlüsselung. Daher bitte auch die Kommentare in der Datei beachten.

Im jeweiligen virtuellen Host für HTTPS ist dann einfach diese ssl.conf einzubinden:

server {
	listen 443 ssl http2;
	listen [::]:443 ssl http2;
	server_name meinedomain.de 192.168.178.60;
	
	include /etc/nginx/snippets/ssl.conf;	
	
	#
	# Here you would add the statements for some web applications, e.g. Nextcloud.
	#
}

Wichtig: Die SSL-Anweisungen dürfen nicht doppelt im server-Block für HTTPS aufgeführt werden. Wenn hier bereits Optionen angegeben sind, die ebenfalls in der Datei ssl.conf aufgeführt sind, dann sind diese im server-Block für HTTPS zu entfernen.

Nach einem Neustart des Webservers sollten die Zertifikate korrekt eingebunden worden sein:

service nginx restart

Überprüfung der Zertifikate

Abschließend lohnt eine Überprüfung der Zertifikate. Hierzu ist der SSL Server Test von Qualys SSL Labs gut geeignet. Mit der gezeigten Konfiguration sollte ein Rating mit A+ und 100% in allen Kategorien erreicht werden:

Ergebnis des SSL-Tests

Ergebnis des SSL-Tests

Falls hier eine niedrigere Bewertung angezeigt werden sollte, liegt dies vermutlich an der SSL-Konfiguration des Webservers. In diesem Fall sollten die entsprechenden Anweisungen der Datei ssl.conf nochmals kontrolliert werden.

Erneuerung der Zertifikate

Die Zertifikate von Let’s Encrypt sind nur für die Dauer von 90 Tagen gültig (Begründung siehe hier) und müssen anschließend erneuert werden.

Bei der Installation von acme.sh wurde ein Cronjob angelegt, der regelmäßig prüft, ob Zertifikate erneuert werden müssen und diese Erneuerung dann ggf. automatisch ausführt. Im Grunde genommen muss man sich daher gar nicht weiter um die Zertifikate kümmern.

Dennoch sollte man nach dem initialen Ausstellen der Zertifikate und Ablauf der 90 Tage kontrollieren, ob die automatische Erneuerung auch wirklich durchgeführt wurde.

Die Gültigkeitsdauer der installierten Zertifikate kann wieder mit folgendem Befehl ermittelt werden:

acme.sh --list

Upgrade von acme.sh

Für acme.sh werden regelmäßig auch Updates veröffentlicht (siehe GitHub Release-Page). In diesem Fall kann das Skript mit nur einem Befehl auf den neusten Stand gebracht werden:

acme.sh --upgrade

Das Reizvolle daran ist nun, dass man diese Updates komplett ohne Abhängigkeiten von den Paketquellen der jeweiligen Distributionen einspielen kann.

Fazit

acme.sh macht als Let’s Encrypt Client einen sehr soliden Eindruck. Die Bedienung gestaltet sich recht einfach und da es sich um ein reines Shell Skript handelt, ist man unabhängig von Programmversionen in den Paketquellen einzelner Linux-Distributionen. Ebenfalls wird automatisch ein Cronjob für die Erneuerung der Zertifikate angelegt, so dass man sich nach der ersten Generierung der Zertifikate nicht mehr um deren Erneuerung kümmern muss. Aus genau diesen Gründen werde ich in Zukunft auch acme.sh als Let’s Encrypt Client empfehlen.

Abschließend noch ein Hinweis für Webserver-Admins, die noch einen anderen Let’s Encrypt Client verwenden und auf acme.sh umsteigen wollen: Der nächste Artikel hier im Blog wird den Umstieg zu acme.sh im Detail beleuchten…

Update: Der Artikel zum Umstieg von Certbot auf acme.sh ist online: Let’s Encrypt: Umstieg von Certbot auf acme.sh (nginx)

Weiterführende Artikel

Links

]]>
https://decatec.de/linux/lets-encrypt-zertifikate-mit-acme-sh-und-nginx/feed/ 17
Nextcloud: Direkter Zugriff auf Dateien über das Dateisystem https://decatec.de/home-server/nextcloud-direkter-zugriff-auf-dateien-ueber-das-dateisystem/ https://decatec.de/home-server/nextcloud-direkter-zugriff-auf-dateien-ueber-das-dateisystem/#comments Tue, 15 Jan 2019 17:10:40 +0000 https://decatec.de/?p=5062 Nextcloud Logo

Heute gibt es einen praktischen Tipp für Nextcloud: Der Artikel zeigt, wie man einen direkten Zugriff auf Cloud-Dateien direkt über das Dateisystem realisieren kann, ohne den Umweg über die Weboberfläche von Nextcloud oder WebDAV nehmen zu müssen.

Das Datenverzeichnis von Nextcloud

Bei der Installation von Nextcloud wird während des Setups das Datenverzeichnis der Cloud angegeben. Das ist ein lokales Verzeichnis, in dem u.a. die Daten gespeichert werden, die die Benutzer in die Cloud hochladen.

Der Zugriff die diese Dateien erfolgt dann üblicherweise über die Weboberfläche von Nextcloud. Alternativ kann auch per WebDAV auf die Cloud-Dateien zugegriffen werden, indem z.B. ein WebDAV-Netzlaufwerk unter Windows eingebunden wird.

Eine Anforderung könnte nun sein, dass ein direkter Zugriff auf die Nextcloud-Daten über das Dateisystem möglich sein soll. Auch wenn man nicht direkt Dateien auf dem Server kopieren/verschieben wird, ist diese Szenario durchaus relevant: Eine Freigabe per Samba oder FTP ist relativ schnell eingerichtet, da könnte man auf die Idee kommen, einfach das Nextcloud-Datenverzeichnis auf diese Art zugänglich zu machen. Anschließend könnte man nun Daten z.B. per Netzwerkfreigabe oder FTP ins Datenverzeichnis von Nextcloud transferieren. Diese sollten dann auch automatisch in der Weboberfläche von Nextcloud auftauchen, oder?

Leider ist die Sache nicht ganz so einfach. Wenn man versucht, Dateien auf diese Art Nextcloud „unterzujubeln“, dann wird man diese in der Weboberfläche nicht zu sehen bekommen. Die Begründung dafür ist recht einfach: Jede Datei und jedes Verzeichnis besteht nicht nur aus einem Eintrag im Dateisystem, sondern auch aus einem Eintrag in der Datenbank von Nextcloud. Ist die Datei nun auf dem Dateisystem vorhanden, aber es existiert kein Eintrag in der Datenbank, dann ist diese Datei für Nextcloud quasi nicht vorhanden.

Da dies nicht automatisch funktioniert, muss man nun Nextcloud veranlassen, das ganze Datenverzeichnis nach neuen und geänderten Dateien zu durchsuchen. Dazu bemühen wir einfach occ:

sudo -u www-data php /var/www/nextcloud occ files:scan --all

Je nach Umfang der Cloud kann dieser Befehl einige Zeit in Anspruch nehmen, aber nach dem Scan sind nun auch Dateien sichtbar, die man einfach manuell über das Dateisystem zum Datenverzeichnis hinzugefügt hat.

Für die Praxis ist dies leider keine gute Lösung, da man nun den Scan-Vorgang immer wieder anwerfen muss, wenn Dateien „hinten rum“ in das Datenverzeichnis kopiert wurden.

Die bessere Lösung: Verwendung von externem lokalem Speicher

Nextcloud überwacht sein Datenverzeichnis als nicht von selbst auf geänderte Dateien. Diese Option ist allerdings bei externem Speicher verfügbar. Hier kann man Nextcloud anweisen, bei jedem aktiven Zugriff auf neue und geänderte Dateien zu achten. Genau diese Option machen wir uns nun zu Nutze, damit man Dateien auch direkt über das Dateisystem der eigenen Cloud hinzufügen kann.

Lokalen externen Speicher einbinden

Zum Einbinden von lokalem externen Speicher benötigen wir erst einmal ein Verzeichnis auf dem lokalen Dateisystem, auf das Nextcloud (d.h. der Webserver-Benutzer) zugreifen kann:

mkdir -p /var/nextcloud_external_data
chown -R www-data:www-data /var/nextcloud_external_data

Auch PHP braucht natürlich Zugriff auf dieses Verzeichnis, so dass wir noch die Variable open_basedir anpassen müssen.

Für PHP FPM muss dazu der virtuelle Host für Nextcloud (siehe hier) modifiziert werden. Das soeben angelegte Verzeichnis wird bei fastcgi_param PHP_VALUE einfach bei open_basedir hinzugefügt. Der komplette Block kann dann z.B. so aussehen.

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

Damit auch der Cronjob von Nextcloud Zugriff auf das Verzeichnis hat, wird dieses ebenfalls in der entsprechenden php.ini Datei unter open_basedir hinzugefügt:

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

Der Eintrag kann hier z.B. dann so aussehen:

open_basedir = /var/www/:/tmp/:/var/nextcloud_data/:/var/nextcloud_external_data/

In den Einstellungen von Nextcloud kann dieses Verzeichnis nun als externer lokaler Speicher eingebunden werden. Dies kann jedoch nur in den Admin-Einstellungen erfolgen, da Benutzer nicht selbst externen lokalen Speicher einbinden können.

Nextcloud: Lokalen externen Speicher einbinden

Nextcloud: Lokalen externen Speicher einbinden

Folgende Optionen sind hier wichtig:

  • Ordnername: Kann beliebig vergeben werden. In der Dateiübersicht von Nextcloud erscheint der externe Speicher dann unter diesem Namen.
  • Konfiguration: Hier ist der Order auf dem lokalen Dateisystem anzugeben. In diesem Beispiel also /var/nextcloud_external_data.
  • Verfügbar für: Hier werden die Benutzer/Gruppen hinterlegt, für die der externe Speicher zugänglich sein soll.
  • Auf Änderungen prüfen: Diese Einstellung verbirgt sich in den erweiterten Optionen (Menü mit drei Punkten). Wichtig ist hier die Angabe Einmal bei jedem Direktzugriff.

Nach dem Speichern der Einstellungen sollte der externe Speicher erfolgreich eingebunden worden sein.

Hinzufügen von Dateien direkt über das Dateisystem

Durch die Option, dass Nextcloud den soeben eingebundenen externen Speicher bei jedem Zugriff auf Änderungen durchsuchen soll, können nun einfach Dateien über das Dateisystem hinzugefügt werden. Für einen schnellen Test legen wir einfach eine einfache Textdatei an:

nano /var/nextcloud_external_data/test.txt

Der Inhalt spielt für den Funktionstest keine Rolle, daher einfach irgendwas eingeben und die Datei speichern.

Wenn man nun wieder über die Nextcloud-Oberfläche im Browser das Verzeichnis des externen Speichers öffnet, wird die neu erzeugte Datei von Nextcloud erkannt und kann auch direkt bearbeitet werden.

Der nächste Schritt würde nun darin bestehen, einen „Direktzugriff“ auf das Verzeichnis des externen Speichers zu legen, beispielsweise per Samba-Freigabe oder auch per FTP.

Anschließend hat man einen direkten Zugriff auf die Dateien von Nextcloud (zumindest auf jene, die auf dem externen lokalen Speicher liegen).

Aus der Praxis – OCR von gescannten Dokumenten

Nun fragt sich der eine oder andere sicher: „Was bringt mir das?“

In der Praxis hat sich bei mir das gezeigte Vorgehen bei der Verwaltung von (gescannten) Dokumenten bewährt.

Dazu habe ich zwei lokale externe Speicher eingebunden: Scan Eingang und Dokumente Eingang. In das Verzeichnis Scan Eingang werden nun Dokumente oder Bilder gespeichert, die vom Scanner erfasst wurden (z.B. als PDF). Diese Dokumente besitzen noch keinen Text-Layer (OCR).

Um diesen Text-Layer hinzuzufügen nutze ich nun das Script OCRmyFiles. Details zu diesem Script habe ich bereits im Artikel Linux: OCR-Texterkennung für PDF-Dateien und Bilder beschrieben. Dieses Script wird nun regelmäßig per Cronjob aufgerufen (z.B. alle 30 Minuten). Das Script ist so konfiguriert, dass es als Eingangs-Verzeichnis den Order /var/nextcloud_external_data/scan_eingang nutzt (Eingebunden als Order Scan Eingang in Nextcloud). Als Ausgabeordner nutze ich /var/nextcloud_external_data/dokumente_eingang (In Nextcloud als Dokumente Eingang eingebunden).

Nun sorgt das Script dafür, dass Dokumente ohne Text-Layer erfasst werden, per OCR mit Text versehen werden und anschließend in den Order Dokumente Eingang in der eigenen Cloud verschoben werden.

Das ganze wäre nicht möglich, wenn die OCR-Dokumente direkt in das Nextcloud-Datenverzeichnis verschoben werden würden. Erst durch die Nutzung von lokalem externen Speicher bekommt Nextcloud mit, dass im Ordner Dokumente Eingang neue gescannte Dokumente mit Text-Layer verfügbar sind.

Zu guter Letzt werden die Dokumente dann vom Ordner Scan Eingang dann in den jeweils passenden Order verschoben (über die Weboberfläche von Nextcloud).

Fazit

Der direkte Zugriff auf Nextcloud-Dateien über das Dateisystem mag zunächst nicht sonderlich aufregend klingen. In der Praxis merkt man allerdings schnell, dass das Nextcloud-Datenverzeichnis nicht aktiv auf Änderungen überwacht wird.

Der kleine Umweg über lokalen externen Speicher lohnt allemal: Damit wird es zum einen möglich, dass Benutzer Dateien direkt über eine Samba-Freigabe oder auch FTP der Cloud hinzufügen können. Zum anderen eröffnen sich dadurch auch weitere Möglichkeiten, die Cloud-Infrastruktur durch Scripte, o.ä. für Automatisierungen zu nutzen.

Weiterführende Artikel

Links

]]>
https://decatec.de/home-server/nextcloud-direkter-zugriff-auf-dateien-ueber-das-dateisystem/feed/ 9
Nextcloud: Lesezeichen synchronisieren mit Chrome/Firefox https://decatec.de/home-server/nextcloud-lesezeichen-synchronisieren-mit-chrome-firefox/ https://decatec.de/home-server/nextcloud-lesezeichen-synchronisieren-mit-chrome-firefox/#comments Sat, 05 Jan 2019 13:42:08 +0000 https://decatec.de/?p=4706 Logo Nextcloud Bookmarks

Mit Nextcloud kann jedermann seine persönliche Cloud betreiben, ohne dabei von den großen Cloud-Anbietern abhängig zu sein. Beim Thema Cloud denken viele zunächst einmal an eine Datei-Ablage, die von überall aus erreichbar ist. Doch Nextcloud hat hier deutlich mehr zu bieten. Die eigene Cloud kann nach Belieben mit Apps erweitert werden. Nicht nur eine Verwaltung von Kontakten und Kalendern ist hier möglich, sondern auch das Speichern der eigenen Browser-Lesezeichen.

Der folgende Artikel zeigt, wie Lesezeichen in der eigenen Nextcloud gespeichert werden und mit Chrome/Chromium und Firefox synchronisiert werden können.

Voraussetzung für dieses Tutorial ist die Verwendung der Nextcloud-App „Bookmarks“ ab der Version 0.14. Ältere Versionen der App sind nicht empfehlenswert, da hier noch keine Ordnerstruktur bei der Verwaltung von Lesezeichen unterstützt wurde.

Bookmarks-App in Nextcloud aktivieren

Damit Nextcloud Lesezeichen verwalten kann, ist zunächst einmal die App „Bookmarks“ notwendig. Diese ist schnell in der eigenen Cloud installiert. Im Nextcloud App Store findet man die App unter der Kategorie Organisation:

Die Bookmarks App in Nextcloud App Store

Die Bookmarks App in Nextcloud App Store

Nach einem Klick auf Herunterladen und aktivieren und einem Refresh der Seite sollte man in der oberen App-Leiste die Bookmarks-App finden (der Stern).

Überblick über die Bookmarks-App

Die App macht zunächst, was man auch erwarten würde: Lesezeichen speichern. Das Ganze gestaltet sich recht intuitiv, daher gibt es bei der App auch wenige Einstellungen.

Die Bookmarks-App ist recht intuitiv zu bedienen

Die Bookmarks-App ist recht intuitiv zu bedienen

Lesezeichen können dabei auf mehrere Arten hinzugefügt werden:

  • Durch die Schaltfläche oben links (+ Lesezeichen hinzufügen) und direkte Eingabe der URL.
  • Mit einem sog. Bookmarklet: Dazu einfach die Einstellungen der App öffnen (siehe Pfeil im oberen Screenshot). Anschließend kann man den Button Hinzufügen zu Nextcloud z.B. in die Lesezeichen Symbolleiste ziehen. Wenn man nun eine interessante Webseite gefunden hat, kann man nun einfach auf die Schaltfläche Hinzufügen zu Nextcloud (Pfeil im unteren Screenshot) klicken. Es öffnet sich ein Popup, in dem man weitere Daten angeben kann (z.B. Titel des Lesezeichens) und den Bookmark in die Cloud übernehmen kann.
  • Wenn man Bookmarks als HTML aus einem Browser exportiert hat, kann man diese hier über die Schaltfläche Import in der Bookmarks-App importieren.
Hinzufügen eines Lesezeichens mit dem "Bookmarklet"

Hinzufügen eines Lesezeichens mit dem „Bookmarklet“

Die angelegten Lesezeichen können nun einfach durch einen Klick aufgerufen werden.

Seit der Version 0.14 unterstützt die Bookmarks App das Verwalten der Lesezeichen in einer Ordnerstruktur. Neue Ordner können dabei auf der linken Seite einfach angelegt werden.

Ebenso kann man Lesezeichen Tags zuweisen, um diese leichter zu kategorisieren.

Synchronisierung mit Chrome/Firefox

Lesezeichen werden eigentlich direkt im Browser gespeichert, damit man diese beim Surfen immer schnell und unkompliziert aufrufen kann. Der Umweg über die Web-Oberfläche von Nextcloud zum Aufrufen von Lesezeichen ist hier etwas umständlich.

Daher sollen die Lesezeichen im nächsten Schritt mit dem Browser synchronisiert werden. Ich beschränke mich hier auf die populärsten Browser: Chrome und Firefox. Für diese beiden Browser gibt es jeweils das Add-On floccus, mit dem diese Aufgabe realisiert werden kann.

Vorbereitung für die Lesezeichen-Synchronisierung mit floccus

Bevor wir das Add-On nun installieren und die Synchronisierung mit Nextcloud einrichten, sollen noch einige Vorbereitungen getroffen werden.

Im Browser vorhandene Lesezeichen werden am besten erst einmal als HTML-Datei exportiert. In Chrome geschieht dies über den Lesezeichen-Manager, bei Firefox über die Option Lesezeichen verwalten. Diese exportieren Lesezeichen können dann später auch in der Nextcloud Bookmarks-App importiert werden.

Den Export sollte man in jedem Fall ausführen: Zum einen können dann keine Lesezeichen verloren gehen, sollte bei der ersten Synchronisierung etwas schief laufen. Zum anderen können die Lesezeichen dann später in einem Rutsch per Browser nach Nextcloud übernommen werden.

Lesezeichen-Export in Firefox

Lesezeichen-Export in Firefox

Wer seine Lesezeichen vorher immer über den Mozilla- bzw. Google-Account synchronisiert hat, kann dieses Feature nun ausschalten, da die Lesezeichen ab nun ausschließlich mit der eigenen Cloud synchronisiert werden sollen. Da werden alle Lesezeichen zunächst einmal gelöscht, damit diese dann beim nächsten Sync aus den Clouds von Mozilla bzw. Google verschwinden.

Anschließend wird die Lesezeichen-Synchronisierung im Browser deaktiviert. Bei Firefox kann man diese Option unter den Einstellungen bei Firefox-Konto finden. Hier einfach unter den Sync-Einstellungen die Option Lesezeichen deaktivieren.

Firefox: Lesezeichen-Synchronisierung ausschalten

Firefox: Lesezeichen-Synchronisierung ausschalten

Da die Synchronisierung nun nicht mehr über das Firefox-Konto bzw. die Google-Cloud läuft, können die als HTML-Datei exportierten Lesezeichen wieder im Browser importiert werden. Diese sind dann für den Moment nur lokal im Browser verfügbar, aber das ändern wir gleich im Anschluss.

Installation und Einrichtung von floccus

Das Add-On kann einfach im Chrome Web-Store bzw. im Firefox Add-ons dem jeweiligen Browser hinzugefügt werden. Beispielhaft beschreibe ich hier die Vorgehensweise für Firefox, unter Chrome läuft die Einrichtung allerdings analog ab.

In der Add-On-Verwaltung von Firefox sucht man dazu einfach nach „floccus“ und installiert die Erweiterung einfach über die Schaltfläche Zu Firefox hinzufügen.

floccus bei Firefox Add-ons

floccus bei Firefox Add-ons

Direkt nach der Installation des Add-Ons macht sich floccus mit einem Icon in der Browser-Toolbar bemerkbar, mit dem Accounts hinzugefügt werden können.

floccus in der Toolbar von Firefox

floccus in der Toolbar von Firefox

Beim Klick auf dieses Icon öffnet sich ein Menü, in dem man einen Account über die Schaltfläche Add Account hinzufügen kann. Für Nextcloud stehen hier zwei Auswahlmöglichkeiten zur Verfügung: Einmal Nextcloud Bookmarks (legacy) – dies ist die richtige Option, wenn noch eine ältere Version der Bookmarks-App verwendet werden soll. Für diese Anleitung ist die Option Nextcloud Bookmarks (with folders) die richtige.

Nach einem Klick auf die Schaltfläche Add Account gibt man nun einfach die URL der eigenen Nextcloud (z.B. https://meinedomain.de/nextcloud) und Benutzername/Passwort an.

Hinweis für Firefox unter Linux: Momentan gibt es hier manchmal ein Problem mit floccus unter Linux. Hier stürzt das Add-On ab, wenn man hier die Passwort-Textbox aktivieren will. Hier kann man den Account nur an anderer Stelle hinzufügen. Dazu einfach über das Firefox-Menü den Punkt Add-ons aufrufen. Anschließend gibt es hier neben floccus den Button Einstellungen. An dieser Stelle können nun Accounts hinzugefügt werden, ohne dass das Add-On abstürzt.

Wenn man den Account nun mit den Standard-Einstellungen hinzufügt, ist das Ergebnis vermutlich nicht wie erwartet. floccus fügt dann nämlich im Lesezeichen-Menü einfach einen Ordner für diesen Account an und synchronisiert alle Lesezeichen einfach in diesen Ordner. Wenn man Lesezeichen nicht unbedingt über mehrere Nextcloud-Instanzen verteilt, dies sicher nicht das gewünschte Verhalten. Daher…

floccus-Tipp: Lesezeichen im Lesezeichen-Menü bzw. der Lesezeichen-Symbolleiste

Damit die Lesezeichen genau so verhalten, als hätte man diese direkt über den Sync-Mechanismus des Browsers synchronisiert hätte, ist noch ein kleiner zusätzlicher Schritt notwendig.

Hier bedarf es zunächst einmal einer Trennung zwischen den normalen Lesezeichen (die dann im Lesezeichen-Menü des Browsers zu finden sein sollen) und den Lesezeichen, die dann in der Lesezeichen-Symbolleiste angezeigt werden sollen. Dazu legen wir uns in der Nextcloud Bookmarks App einfach zwei Ordner an, z.B. Lesezeichen für die normalen Lesezeichen und FavBar für die Lesezeichen-Symbolleiste.

Vorbereitung der Browser-Synchronisierung

Vorbereitung der Browser-Synchronisierung

Der eigentliche Trick ist nun, einfach zwei Accounts für die Lesezeichen-Synchronisierung hinzuzufügen: Einen für die normalen Bookmarks und einen weiteren extra für die Lesezeichen-Symbolleiste.

Für die normalen Lesezeichen wählt man beim Hinzufügen eines Accounts einfach das Lesezeichenmenü als Local folder:

  • Bei Firefox heißt der Ordner „Lesezeichen-Menü“.
  • Bei Chrome muss man hier „Weitere Lesezeichen“ wählen.

Unter Server folder ist hier das Verzeichnis der Nextcloud Bookmarks App anzugeben, welches man zuvor angelegt hat. In diesem Beispiel ist dies einfach /Lesezeichen (man beachte den Slash am Anfang). Die Option Run sync in parallel kann man an dieser Stelle auch noch gleich aktivieren, dann werden sämtliche Sync-Vorgänge parallel ausgeführt.

floccus: Sync-Einstellungen für Firefox (Lesezeichen-Menü)

floccus: Sync-Einstellungen für Firefox (Lesezeichen-Menü)

Für die Lesezeichen der Lesezeichen-Symbolleiste fügt man nun einen zweiten Account mit folgenden Daten hinzu:

  • Firefox:
    • Local folder: Lesezeichen-Symbolleiste
    • Server folder: /FavBar (wichtig ist hier der Slash am Anfang).
  • Chrome:
    • Local folder: Lesezeichenleiste
    • Server folder: /FavBar (wichtig ist hier der Slash am Anfang).
floccus: Sync-Einstellungen für Firefox (Lesezeichen-Symbolleiste)

floccus: Sync-Einstellungen für Firefox (Lesezeichen-Symbolleiste)

Wenn man die beiden Sync-Einstellungen festgelegt hat, muss man diese noch aktivieren (Option enabled):

floccus: Synchronisierung einschalten

Erstbestückung der Nextcloud-Lesezeichen mit dem Browser

Wenn die Einrichtung von floccus wie beschrieben durchgeführt wurde, können nun sämtliche Lesezeichen, die wir zuvor als HMTL-Datei exportiert haben, in einem Rutsch in die Cloud übernommen werden.

Dazu sorgen wir zunächst einmal dafür, dass in der Cloud keine Lesezeichen mehr gespeichert sind. Dazu nutzen wir in der Nextcloud Bookmarks-App einfach den Button Lesezeichen löschen.

Im nächsten Schritt importieren wir die HTML-Datei mit unseren Lesezeichen in den Browser (nicht in die Bookmarks-App). Bei der nächsten Synchronisierung mit floccus landen die Lesezeichen in der Nextcloud Bookmarks-App.

Zukünftig wird man neue Lesezeichen nun nicht in der Nextcloud Bookmarks-App, sondern wie gewohnt im Browser hinzufügen. Das Ganze verhält sich dann analog zum eingebauten Sync-Mechanismus von Chrome/Firefox. Der große Unterschied ist nun, dass die Lesezeichen nicht auf den Servern von Google oder Mozilla landen, sondern nur noch in der persönlichen Cloud gespeichert sind.

Bookmark-App für Smartphones

Einen Nachteil hat diese Lösung dennoch: Die Synchronisierung funktioniert nicht für die mobilen Varianten von Chrome/Firefox. Chrome lässt in der Mobil-Version keine Installation von Add-Ons zu. Bei Firefox wäre dies zwar kein Problem, jedoch funktioniert hier floccus (noch) nicht.

Zumindest für Android gibt es jedoch eine App speziell für Lesezeichen in der eigenen Cloud: Nextcloud Bookmarks

Diese ist im Google Play Store oder bei F-Droid (hier sogar kostenlos) erhältlich.

Die Nextcloud Bookmarks App unter Android

Die Nextcloud Bookmarks App unter Android

Leider ist mir momentan keine Lösung bekannt, um Nextcloud Bookmarks mit iOS-Geräten zu synchronisieren. Kennt ihr hier eine Möglichkeit? Hinterlasst mir dazu doch einfach einen Kommentar, ggf. werde ich den Artikel dann erweitern.

Fazit

Nach der einmaligen Einrichtung der Lesezeichen-Verwaltung mit der Nextcloud Bookmarks App, ist die Lesezeichen-Synchronisierung über die eigene Cloud genau so einfach und intuitiv wie die integrierte Lesezeichen-Synchronisierung in Chrome/Firefox. Anschließend kann man die Lesezeichen zwischen verschiedenen Browsern/Betriebssystemen synchronisieren. Dabei hat man das gute Gefühl, dass keine Daten in den Clouds von Google bzw. Mozilla gespeichert werden, sondern ausschließlich in der eigenen Cloud.

Synchronisiert ihr eure Lesezeichen bereits über die eigene Nextcloud? Nutzt ihr dafür auch die Browser-Erweiterung floccus, oder habt ihr eine bessere Alternative gefunden? Hinterlasst mir dazu doch einfach einen Kommentar.

Weiterführende Artikel

Links

]]>
https://decatec.de/home-server/nextcloud-lesezeichen-synchronisieren-mit-chrome-firefox/feed/ 7
phpMyAdmin neben Nextcloud installieren (nginx) https://decatec.de/home-server/phpmyadmin-neben-nextcloud-installieren-nginx/ https://decatec.de/home-server/phpmyadmin-neben-nextcloud-installieren-nginx/#comments Sat, 15 Dec 2018 09:49:16 +0000 https://decatec.de/?p=4894 phpMyAdmin Logo

phpMyAdmin ist eine Webanwendung zur Administration von MySQL-Datenbanken. Zwar kann eine Datenbank auch über den Befehl mysql auf der Kommandozeile direkt administriert werden, jedoch ist die grafische Benutzeroberfläche von phpMyAdmin weitaus intuitiver zu bedienen, als SQL-Befehle direkt in der Kommandozeile einzutippen.

Dies Artikel zeigt daher, wie man phpMyAdmin auf einem Ubuntu Server 18.04.1 in Verbindung mit nginx als Webserver installieren und einrichten kann. In dieser Konfiguration sind nach der Installation noch einige Optimierungen für phpMyAdmin notwendig. Als Grundlage dienen hier zwei bereits bekannte Artikel:

Ich gehe daher im Folgenden davon aus, dass Nextcloud mit MariaDB/MySQL bereits auf dem System installiert ist. Für die verschlüsselte Verbindung über HTTPS sollte ein gültiges SSL-Zertifikat ebenso bereits vorhanden sein.

Update-Historie (letztes Update 13.01.2019)
  • 13.01.2019:
    • Anweisungen für PHP_VALUE  und client_max_body_size angepasst, so dass nun auch größere SQL-Dumps verarbeitet werden können.

 

Installation phpMyAdmin

Zunächst bringen wir das System auf den neusten Stand:

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

Anschließend kann phpMyAdmin durch folgenden Befehl installiert werden:

apt-get install phpmyadmin

Der Installer läuft dabei interaktiv ab, so dass eine Grundkonfiguration bereits nach der Installation des Paketes gegeben ist.

In einem ersten Schritt folgt die automatische Konfiguration des Webservers. Hier werden leider nur die Optionen apache2 und lighttpd angeboten – nginx befindet sich nicht in der Auswahl.

phpMyAdmin Setup: Auswahl des Webservers

phpMyAdmin Setup: Auswahl des Webservers

Daher wird hier keine Option ausgewählt, sondern der Schritt einfach mit Enter übersprungen.

Die Installation wird nun fortgesetzt und nach einer kurzen Zeit erscheint ein Hinweis, dass für den Betrieb von phpMyAdmin eine Datenbank installiert und konfiguriert sein muss.

phpMyAdmin Setup: Konfiguration mittels dbconfig-common

phpMyAdmin Setup: Konfiguration mittels dbconfig-common

Achtung: Die Datenbank (MariaDB) wurde bereits beim Setup von Nextcloud installiert und aufgesetzt (siehe hier bzw. hier). Falls man hier nun Yes wählt, erhält man im nächsten Schritt einen Fehler. Daher muss an dieser Stelle No gewählt werden.

Nach wenigen Augenblicken ist die Installation von phpMyAdmin dann auch schon abgeschlossen.

Konfiguration nginx für phpMyAdmin

Während der Installation von phpMyAdmin stand nginx als Webserver leider nicht zur Auswahl, daher muss der Webserver nach dem Setup noch manuell angepasst werden.

Der richtige Ort für die Änderungen ist dabei der Gateway-Host:

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

Hier fügen wir nun ganz am Ende (aber vor der letzten schließenden Klammer) folgenden Inhalt ein:

location /phpmyadmin {
	root /usr/share/;
	index index.php index.html index.htm;

	client_max_body_size 100M;
	
	location ~ ^/phpmyadmin/(.+\.php)$ {
		try_files $uri =404;
		root /usr/share/;
		fastcgi_pass php-handler;
		fastcgi_index index.php;
		fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
		include /etc/nginx/fastcgi_params;
		fastcgi_param PHP_VALUE "open_basedir=/var/www:/tmp/:/usr/share/phpmyadmin:/usr/share/php:/etc/phpmyadmin/
			upload_max_filesize = 100M
			post_max_size = 100M
			max_execution_time = 3600";
    }
	
	location ~* ^/phpmyadmin/(.+\.(jpg|jpeg|gif|css|png|js|ico|html|xml|txt))$ {
	   root /usr/share/;
	}
}

Am Ende wird der Webserver noch neu gestartet, damit die Änderungen wirksam werden:

service nginx restart

Optimierung der phpMyAdmin-Installation

Da nun alle Vorbereitungen getroffen wurden, kann man sich nun mit folgender URL bei phpMyAdmin anmelden:

https://meinedomain.de/phpmyadmin

Es erscheint eine Anmeldemaske, mit der man sich nun als User root an der Datenbank anmelden kann. Das Root-Passwort wurde bei der ursprünglichen Installation von MariaDB angelegt (siehe hier). Eine Anmeldung mit Root ist notwendig, da man ansonsten nicht die erforderlichen Rechte an der Datenbank besitzt, um umfangreiche Änderungen durchzuführen.

phpMyAdmin: Anmeldung mit Root-Account

phpMyAdmin: Anmeldung mit Root-Account

Direkt nach dem Login wird man mit zwei Warnungen konfrontiert. Um die Einrichtung von phpMyAdmin abzuschließen ist leider noch etwas Handarbeit notwendig.

phpMyAdmin: Fehler nach erstem Login

phpMyAdmin: Fehler nach erstem Login

Passwort zur Verschlüsselung generieren

Zunächst kümmern wir uns um die untere Fehlermeldung („blowfish_secret“). Dabei handelt es sich um ein Sicherheits-Feature, bei dem ein Passwort zur Verschlüsselung der Verbindung in einer Konfigurations-Datei von phpMyAdmin hinterlegt werden muss.

Dieses Passwort muss genau 32 Zeichen lang sein. Am einfachsten kann man ein entsprechendes Passwort (oder besser gesagt den entsprechenden Hash-Wert) über die Seite Blowfish password hash generator generieren lassen.

Blowfish password hash generator

Blowfish password hash generator

Dazu gibt man in das entsprechende Eingabefeld einfach ein möglichst komplexes Passwort ein. Einfacher geht es über die Schaltfläche zur automatischen Generierung eines Passwortes (roter Pfeil). Dieses Passwort muss man sich dabei nicht merken, daher kann es eine beliebige Zeichenfolge (am besten mit Sonderzeichen) sein. Anschließend wird der Hash-Wert über den Button Generate erzeugt. Dieses Hash-Wert muss man nun kopieren.

Nachfolgend wird folgende Datei bearbeitet:

nano /etc/phpmyadmin/config.inc.php

Ganz am Ende der Datei wird nun folgende Zeile mit dem soeben kopierten Hash-Wert eingefügt:

$cfg['blowfish_secret'] = '$2a$07$ZHGuhpP7Gl3913T9GOMDk.EbFoBpbGBkuNesqXPvM0NTufx0BCAmm';

Verwaltungsdatenbank für phpMyAdmin anlegen

Wenn man die phpMyAdmin-Seite neu lädt, sollte nun nur noch eine Fehlermeldung zu sehen sein: Es muss noch eine Verwaltungsdatenbank für phpMyAdmin angelegt werden. Dazu klickt man einfach auf den Link Finden Sie heraus warum in der Meldung.

Anschließend klickt wiederum auf den Link anlegen auf der erscheinenden Seite.

Nach einem kurzen Moment sollte die neue Datenbank erfolgreich angelegt worden sein.

phpMyAdmin: Die Verwaltungs-Datenbank wurde erfolgreich angelegt

phpMyAdmin: Die Verwaltungs-Datenbank wurde erfolgreich angelegt

Fehler beim Öffnen von Tabellen

Auf der Übersichts-Seite von phpMyAdmin sollten nun keine Fehlermeldungen mehr angezeigt werden. Man wird beim Arbeiten mit phpMyAdmin jedoch auf ein weiteres Problem stoßen, wenn man eine Tabelle in einer Datenbank öffnen möchte.

Hier wird dann die Meldung count(): Parameter must be an array or an object that implements countable angezeigt:

phpMyAdmin: Fehler nach dem Öffnen einer Tabelle

phpMyAdmin: Fehler nach dem Öffnen einer Tabelle

Hierbei handelt es sich um einen Fehler im Quellcode des phpMyAdmin-Paketes, welches in den Ubuntu Paketquellen enthalten ist. Hier muss noch eine kleine Änderung am Sourcecode vorgenommen werden.

Dazu öffnen wir folgende Datei:

nano /usr/share/phpmyadmin/libraries/sql.lib.php

Anschließend suchen wir nach folgender Zeile (am besten folgende Zeile kopieren und in nano mittels STRG + W danach suchen):

|| (count($analyzed_sql_results['select_expr'] == 1)

Diese eine Zeile (und nur diese!) wird dann gelöscht und durch folgende Zeile ersetzt:

|| ((count($analyzed_sql_results['select_expr']) == 1)

Nach dieser kleinen Änderung sollte kein Fehler mehr beim Öffnen einer Tabelle erscheinen.

Fehler beim Importieren/Exportieren von Datenbanken

Das nächste Problem wird man bemerken, wenn man Datenbanken importieren oder exportieren möchte. In beiden Fällen wird man folgende Fehlermeldung bekommen:

Warning in ./libraries/plugin_interface.lib.php#551
count(): Parameter must be an array or an object that implements Countable

Auch hier muss man den Code modifizieren, so dass meine Fehlermeldungen mehr erscheinen.

Dazu öffnen wir die betroffene Datei:

nano /usr/share/phpmyadmin/libraries/plugin_interface.lib.php

Anschließend wird die betroffene Code-Zeile gesucht (STRG + W):

if ($options != null && count($options) > 0) {

Die komplette Zeile wird nun durch Folgendes ersetzt:

if ($options != null) {

Nach dem Speichern der Datei wird der Fehler beim Importieren/Exportieren nicht mehr erscheinen.

Optional: Zugriff auf phpMyAdmin nur über das lokale Netzwerk

Der Zugriff auf die Datenbankverwaltung ist mit dem gezeigten Setup von überall aus möglich – auch aus dem Internet. Aus Gründen der Sicherheit ist es hier eine Überlegung wert, ob man den Zugriff auf phpMyAdmin auf das lokale Netzwerk (LAN) beschränken möchte.

In diesem Fall müssen nochmals die Anweisungen für phpMyAdmin im Gateway-Host angepasst werden:

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

Ganz oben im location-Block für phpMyAdmin fügen wir nun folgende Anweisungen ein:

allow 192.168.178.0/24;
deny all;

Nach einem Neustart des Webserver ist phpMyAdmin nur noch im lokalen Netzwerk (192.168.178.xxx) erreichbar. Beim Zugriff über das Internet erscheint dann nur ein Fehler HTTP 403 (Forbidden).

Fazit

Die Installation von phpMyAdmin ist schnell erledigt, jedoch sind hier und da noch einige Nacharbeiten notwendig, bis das Datenbankverwaltungs-Tool einwandfrei funktioniert.

Jedoch lohnt sich hier der Aufwand, da man nun die Datenbanken auf dem System komfortabel mit einer grafischen Oberfläche bearbeiten kann. Das ist viel intuitiver, als mit dem Tool mysql die Datenbanken auf der Kommandoziele zu bearbeiten.

Trotzdem sollte man immer beachten, dass man mit phpMyAdmin Admin-Zugriff auf alle Datenbanken hat (zumindest, wenn man sich mit dem User ‚root‘ einloggt). Beim Bearbeiten der Datenbanken sollte man Vorsicht walten lassen – eine falsche Bearbeitung von Tabellen kann hier dazu führen, dass die auf der Datenbank basierende Anwendung nicht mehr wie erwartet funktioniert.

Weiterführende Artikel

Links

]]>
https://decatec.de/home-server/phpmyadmin-neben-nextcloud-installieren-nginx/feed/ 18
Nextcloud Talk mit eigenem TURN-Server (coturn) https://decatec.de/home-server/nextcloud-talk-mit-eigenem-turn-server-coturn/ https://decatec.de/home-server/nextcloud-talk-mit-eigenem-turn-server-coturn/#comments Wed, 21 Nov 2018 15:12:55 +0000 https://decatec.de/?p=4930 Nextcloud Talk Logo

Für Nextcloud ist schon seit einiger Zeit eine Erweiterung als App verfügbar, mit der Chats und (Video-)Telefonate über die eigene Cloud geführt werden können: Nextcloud Talk.

Im Normalfall muss man dafür einfach die App im Nextcloud App Store herunterladen und kann sofort loslegen, mit anderen Nutzern der Cloud zu kommunizieren. Dank der Verfügbarkeit von mobilen Apps für Android und auch iOS kann diese Lösung auch als Alternative zu den bekannten Kommunikation-Apps (wie z.B. WhatsApp) genutzt werden. Das Hauptargument für Nextcloud Talk ist dabei sicherlich, dass Chats und (Video-)Telefonate komplett verschlüsselt über die eigene Nextcloud-Instanz ablaufen und so vor den neugierigen Blicken von Konzernen geschützt sind.

Dennoch treten bei Nextcloud Talk oftmals Probleme auf, wenn sich die genutzten Endgeräte nicht im selben Netzwerk befinden. Hier können dann keine (Video-)Telefonate geführt werden, da sich die Geräte einfach nicht finden können.

Damit über Nextcloud Talk jederzeit problemlos kommuniziert werden kann, ist ein eigener TURN-Server notwendig. Mit coturn ist ein solcher auch unter Ubuntu verfügbar. Dieser Artikel beschreibt daher die Installation und Konfiguration von coturn, um optimal mit Nextcloud Talk zusammen zu arbeiten.

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

Probleme mit Nextcloud Talk mit eigenem STUN/TURN-Server lösen

Nextcloud Talk basiert auf WebRTC. Die bei der Kommunikation beteiligten Endgeräte bauen dabei eine direkte Peer-to-Peer-Verbindung auf.

Im gleichen Netzwerk (LAN) ist dies kein Problem, hier müssen alle Endgeräte lediglich WebRTC unterstützen.

Wenn sich die Geräte in unterschiedlichen Netzwerken befinden, müssen die Geräte sowohl ihre interne, also auch ihre externe IP-Adresse kennen. Diese Umsetzung ist die Aufgabe eines STUN-Servers (Session Traversal Utilities for NAT). Für Nextcloud Talk ist ein eigener STUN-Server verfügbar (stun.nextcloud.com:443), daher sollte dies auch kein Problem darstellen.

Wenn nun allerdings Firewalls mit im Spiel sind, kann der STUN-Server die „Übersetzung“ der Adressen nicht mehr leisten. In diesen Fällen spricht man von einem Symmetric NAT: Hier wird durch die Firewall verhindert, dass von außen (d.h. aus dem Internet) initiierte Verbindungen in das lokale Netzwerk möglich sind. In diesem Szenario ist dann ein TURN-Server (Traversal Using Relays around NAT) notwendig, über den sämtliche Verbindungen geleitet werden.

Diese Thematik ist durchaus komplex, aber vereinfacht kann man sagen, dass man einen TURN-Server benötigt, wenn die Verbindung zwischen Geräten in unterschiedlichen Netzwerken nicht aufgebaut werden kann (z.B. PC im Heimnetzwerk, Smartphone in Mobilfunknetz). Im Heimnetzwerk-Bereich ist dies vermutlich immer der Fall.

Unter Ubuntu ist coturn als quelloffene Implementierung eines STUN/TURN-Servers verfügbar.

Installation und Konfiguration coturn

coturn kann ganz einfach auf dem gleichen System installiert werden, auf dem auch schon Nextcloud läuft.

Zunächst bringen wir das System auf den neusten Stand:

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

Anschließend kann coturn auch schon installiert werden, da es bereits Teil der Ubuntu-Paketquellen ist:

apt-get install coturn

Nach der Installation muss coturn nun nur noch konfiguriert werden, damit eine optimale Zusammenarbeit mit Nextcloud Talk gewährleistet ist.

Dazu wird coturn erst einmal aktiviert. Dies geschieht in folgender Datei:

nano /etc/default/coturn

Hier muss folgende Zeile eingefügt werden. Diese ist nach der Installation bereits vorhanden, ist allerdings auskommentiert. Daher entfernen wird einfach das Zeichen ‚#‘ am Anfang der Zeile:

TURNSERVER_ENABLED=1

Als nächstes werden die Einstellungen von coturn bearbeitet.
Diese befinden sich in folgender Datei:

nano /etc/turnserver.conf

Hier müssen die folgenden Werte angepasst werden. Die meisten Werte sind hier bereits vorhanden, allerdings auskommentiert. Auch hier entfernen wir die Raute (‚#‘) vor der entsprechenden Zeile.

  • tls-listening-port=5349
  • fingerprint
  • lt-cred-mech
  • use-auth-secret
  • static-auth-secret=<secret>
  • realm=meinedomain.de
  • total-quota=100
  • bps-capacity=0
  • stale-nonce=600
  • cert=/etc/letsencrypt/live/meinedomain.de/cert.pem
  • pkey=/etc/letsencrypt/live/meindomain.de/privkey.pem
  • cipher-list=“ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384″
  • no-loopback-peers
  • no-multicast-peers
  • dh-file=/etc/nginx/ssl/dhparams.pem
  • no-tlsv1
  • no-tlsv1_1
  • no-stdout-log

Zu den angegebenen Werten hier noch ein paar Erklärungen:

  • tls-listening-port: Hier verwende ich den Standard-Port für TLS-Verbindungen zu coturn (5349). Hier könnte man auch einen anderen Port angeben. Diesen sollte man sich merken, da man diesen nachher in der Firewall freischalten muss.
  • static-auth-secret: Dies ist ein Passwort, welches zur Nutzung des TURN-Servers benötigt wird. Dies ist ein Sicherheitsmerkmal, so dass kein Dritter ohne Kenntnis dieses Passwortes den TURN-Server verwenden kann. Dieses Passwort muss man sich nicht merken und wird später nur in den Nextcloud-Einstellungen hinterlegt, daher lässt man sich dies am besten einfach durch folgenden Befehl generieren: openssl rand -hex 32
  • cert/pkey/dh-file: Dies sind die SSL-Zertifikate bzw. Diffie-Hellman-Parameter, die für die verschlüsselte Verbindung über TLS benötigt werden. Hierzu verwenden wir einfach die bereits vorhandenen Zertifikate für die eigene Domain (siehe hier und hier).
  • cipher-list: Legt die Cipher-Suite für die TLS-Verbindung zum TURN-Server fest. Hier kann die Cipher-Suite angegeben werden, die auch schon der Webserver nginx verwendet (hier heißt die Variable ssl_ciphers, siehe hier).

Nach der Anpassung der Konfiguration von coturn wird das Programm neu gestartet, damit die Änderungen übernommen werden.

service coturn restart

Portfreigaben einrichten

Nach der Einrichtung des TURN-Servers muss nun noch eine Portfreigabe eingerichtet werden, damit coturn auch „von außen“ erreichbar ist.

Wichtig ist hier der Port, der bei der Variable tls-listening-port in der coturn-Konfiguration angegeben wurde. In diesem Beispiel verwende ich dazu den Standard-Port 5349.

Zunächst muss hier eine entsprechende Portweiterleitung im Router eingerichtet werden. Das genaue Vorgehen unterscheidet sich hier von Router zu Router, daher kann an dieser Stelle keine detaillierte Anleitung erfolgen. Hier sollte man aber alle notwendigen Informationen auf den Hersteller-Seiten finden (so z.B. auf den AVM Hilfeseiten, wenn man eine FritzBox im Einsatz hat). Wichtig ist hier, dass die Freigabe für die beiden Protokolle TCP und UDP angelegt werden. Dazu ist meistens das Anlegen von zwei Freigaben notwendig, hier am Beispiel einer FritzBox:

Portfreigaben für cotun (FritzBox)

Portfreigaben für cotun (FritzBox)

Wenn darüber hinaus auch noch eine Firewall auf dem System installiert ist, auf dem coturn eingerichtet wurde, so muss auch hier eine Freigabe erfolgen. Auf vielen Systemen wird wohl ufw (uncomplicated firewall) eingerichtet sein. Hier erfolgt die Freigabe dann über folgende Befehle:

ufw allow 5349/tcp
ufw allow 5349/udp

Nextcloud Talk mit eigenem STUN/TURN-Server

Nun kann Nextcloud Talk mit dem eigenen STUN bzw. TURN-Server betrieben werden.

Zunächst muss – falls noch nicht geschehen – die App Talk aus dem Nextcloud App Store heruntergeladen werden. Diese befindet sich in der Kategorie Kommunikation.

Talk im Nextcloud App Store

Talk im Nextcloud App Store

Nach der Installation der App muss diese noch konfiguriert werden, damit diese coturn als STUN bzw. TURN-Server nutzt. Die dazugehörigen Optionen findet man in den Admin-Einstellungen von Nextcloud unter dem Punkt Talk.

Nextcloud Talk: Einstellungen für eigenen STUN/TURN-Server

Nextcloud Talk: Einstellungen für eigenen STUN/TURN-Server

Zunächst fügen wir mit der Plus-Schaltfläche einen zusätzlichen STUN-Server hinzu:

meinedomain.de:5349

Die Einstellungen für den TURN-Server sehen dann folgendermaßen aus:

  • URI: meinedomain.de:5349: Der Port wurde zuvor in der coturn-Konfiguration (tls-listening-port) hinterlegt.
  • Gemeinsames Geheimnis: Hier muss das Passwort angegeben werden, welches bei der Konfiguration von coturn als Variable static-auth-secret hinterlegt wurde.
  • UDP und TCP: Nextcloud Talk soll hier für maximale Kompatibilität sowohl TCP- als auch UDP-Verbindungen nutzen.

Unter Signalisierungsserver sind keine Eingaben notwendig.

Die Konfiguration kann nun ganz einfach mit der entsprechenden Schaltfläche getestet werden (siehe Pfeil oberes Bild). Hier sollte dann nach einem kurzen Augenblick auch eine Erfolgsmeldung erscheinen:

TURN-Server ist richtig konfiguriert

TURN-Server ist richtig konfiguriert

Chats und (Video-)Telefonie über die eigene Nextcloud

Ab sofort können über Nextcloud Talk Chats, Telefonate und auch Video-Telefonate geführt werden. Dies ist auf den verschiedensten Endgeräten möglich: Zum einen kann Nextcloud Talk ganz einfach im Browser verwendet werden. Dazu in der oberen Menüleiste einfach auf das Talk-Symbol klicken. Nun noch den passenden (Nextcloud-)Kontakt auswählen und schon kann es losgehen.

Nextcloud Talk in Aktion

Nextcloud Talk in Aktion

Richtig interessant wird die Sache allerdings mit mobilen Geräten, wie z.B. Smartphones. Hier stehen App sowohl für iOS, als auch für Android bereit:

Nextcloud Talk (Kostenlos, Google Play) →

Nextcloud Talk (Kostenlos, App Store) →

Der Funktionstest des eigenen TURN-Servers erfolgt am besten mit einem Smartphone: Wenn dieses nicht mit dem Heimnetzwerk, sondern mit dem Mobilfunknetz verbunden ist, sollten sowohl Chats, auch als (Video-)Telefonate mit einem Gerät im Heimnetzwerk problemlos möglich sein.

Troubleshooting

Falls Probleme mit Nextcloud Talk auftreten, sollte zunächst einmal die grundsätzliche Konfiguration durch die entsprechende Schaltfläche in den Admin-Einstellungen zu Talk überprüft werden (siehe Screenshot weiter oben). Anschließend kann es auch sinnvoll sein, die Nextcloud-Logs zu überprüfen. Diese findet man in der Admin-Oberfläche von Nextcloud unter dem Punkt Protokollierung.

Wenn im Nextcloud-Log keine Einträge vorhanden sind, die sich mit Talk in Verbindung bringen lassen, sollte die Funktion von coturn überprüft werden. Die Log-Dateien von coturn befinden sich im Verzeichnis /var/log. Die gesuchten Log-Dateien beginnen alle mit turn_ und beinhalten eine Datumsangabe im Dateinamen, z.B. turn_1352_2018-11-08.log. In diesen Log-Dateien sollte dann zumindest ein Hinweis zu finden sein, warum es zu Problemen gekommen ist.

Fazit

Im Heim-Bereich funktioniert Nextcloud Talk leider nicht immer out-of-the-box – mit dem Aktivieren der App ist es hier meistens nicht getan. Allerdings kann mit coturn recht einfach ein eigener STUN/TURN-Server in Betrieb genommen werden. Der entsprechende Konfigurations-Aufwand hält sich hierfür auch in Grenzen.

Mit Hilfe des eigenen TURN-Servers ist es nun aber möglich, über die eigene Cloud Chats und (Video-)Telefonate zu führen. Dieses Konzept ist im Vergleich zu den bekannten Apps (wie z.B. WhatsApp) besonders interessant, da die Kommunikation ausschließlich verschlüsselt über die persönliche Cloud abläuft, ohne dass hier Konzerne wie Google oder Facebook „mitlesen“ können.

Weiterführende Artikel

Links

]]>
https://decatec.de/home-server/nextcloud-talk-mit-eigenem-turn-server-coturn/feed/ 31
Nextcloud: Online-Office mit ONLYOFFICE (mit eigener Subdomain) https://decatec.de/home-server/nextcloud-online-office-mit-onlyoffice-mit-eigener-subdomain/ https://decatec.de/home-server/nextcloud-online-office-mit-onlyoffice-mit-eigener-subdomain/#comments Fri, 09 Nov 2018 15:06:37 +0000 https://decatec.de/?p=4850 Nextcloud OnlyOffice Logo

Nextcloud bietet neben dem Speichern von Dateien auch noch erweiterte Funktionen wie z.B. die Verwaltung von Kontakten und Kalendern. Ebenso sind Online-Office-Funktionalitäten mit der eigenen Cloud-Lösung möglich: Hier gibt es die Alternativen ONLYOFFICE und Collabora. Für welche Lösung man sich hier entscheidet, ist zunächst einmal Geschmackssache.

Zum Thema ONLYOFFICE gab es bereits einen Artikel in diesem Blog. Die hier gezeigte Lösung hatte allerdings einen entscheidenden Nachteil: Die Office-Funktionalitäten waren nur verfügbar, wenn man über das lokale Netzwerk (LAN) auf die eigene Cloud zugegriffen hat. Das Bearbeiten von Dokumenten über das Internet war auf diese Art und Weise nicht möglich, da beim Bearbeiten von Dokumenten immer direkt auf die IP zugegriffen wurde, auf der ONLYOFFICE installiert wurde. Diese LAN-IP war über das Internet natürlich nicht erreichbar.

In diesem Artikel soll es daher wieder mal um die Einrichtung von ONLYOFFICE mittels Docker unter Nextcloud gehen. Dieses Mal sollen jedoch keine Einschränkungen für die Benutzung des Online-Office gelten: Somit ist dann der Zugriff sowohl über das lokale Netzwerk, also auch über das Internet möglich.

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

Update-Historie (letztes Update 23.12.2018)
  • 23.12.2018:
    • Zeilenangaben für das Übertragen der SSL-Einstellungen in die ssl.conf hinzugefügt.
  • 19.12.2018:
    • Die SSL-Konfiguration wird nun in das Verzeichnis /etc/nginx/snippets/ssl.conf ausgelagert, ansonsten kam es z.T. zu Problemen mit den Setzen der HTTP-Header.
  • 12.11.2018:
    • Die SSL-Konfiguration wird nun unter /etc/nginx/conf.d/ssl.conf gespeichert/ausgelagert.

 

Zweite (Sub-)Domain für ONLYOFFICE

Ich gehe in diesem Artikel davon aus, dass der eigene Server, auf dem Nextcloud bereits läuft, über die DynDNS-Domain meindomain.de erreichbar ist. DynDNS sorgt hier dafür, dass die öffentliche IP-Adresse des Routers auf eine Domain gemappt wird. Im Router wird die Domain dazu in den DynDNS-Einstellungen hinterlegt. Leider unterscheidet sich das Vorgehen von Router zu Router, daher würde eine detaillierte Anleitung für verschiedene Router-Modelle dem Umfang des Artikels sprengen.

Voraussetzung für ONLYOFFICE ist nun eine zweite (Sub-)Domain, über die der Dokumenten-Server später erreichbar sein wird. Als Beispiel nehme ich hier einfach die Domain onlyoffice.meinedomain.de. Diese zweite Domain muss dabei ebenfalls auf die öffentliche IP-Adresse des Routers „zeigen“, ist sozusagen auch eine zweite (oder besser gesagt alternative) DynDNS-Domain.

Mehrere DynDNS-Domains mittels CNAME

Und genau das ist hier das Problem. In fast allen Router-Modellen kann nur ein DynDNS-Anschluss mit nur einer Domain festgelegt werden. Die Lösung für dieses Problem stellt ein sog. CNAME-Eintrag für eine zweite (Sub-)Domain dar. Mittels CNAME wird einfach ausgedrückt ein alternativer Name für eine Domain hinterlegt: Der CNAME-Eintrag der Office-Domain muss daher die bereits vorhandene DynDNS-Domain sein.

Wo kann man diesen CNAME-Eintrag nun hinterlegen? Dies passiert normalerweise in der Domain-Verwaltung des Webspace-Providers. Auch hier unterscheidet sich das Vorgehen von Anbieter zu Anbieter, gute Erfahrungen konnte ich hier allerdings mit All-Inkl.com (Affiliate-Link) machen.

Hier loggt man sich zunächst im Kundenportal (KAS) ein und legt eine neue Subdomain an. Dazu findet man im Menü den Eintrag Subdomain. Über den Punkt Neue Subdomain anlegen kann hier eine neue Subdomain beantragt werden. Hier kann man alle Einstellungen einfach übernehmen, da diese Domain später nicht auf den Webspace, sondern die öffentliche IP-Adresse des eigenen Routers zeigen wird.

All-Inkl.com: Neue Subdomain anlegen

All-Inkl.com: Neue Subdomain anlegen

Um nun noch den CNAME-Eintrag für die neue Subdomain hinzuzufügen, muss man die Domain-Einstellungen unter Tools > DNS-Einstellungen bearbeiten. Hier sieht man dann die eigene Domain, über die auch der DynDNS-Anschluss läuft (meinedomain.de). Mit einem Klick auf Bearbeiten kann diese Domain modifiziert werden. Hier klickt man dann auf den Punkt neuen DNS Eintrag erstellen. Folgende Einstellungen sind hier vorzunehmen:

  • Name: Der Name der Subdomain (hier also onlyoffice.meinedomain.de).
  • Typ/Prio.: CNAME
  • Data: Hier wird die eigentliche DynDNS-Domain eingetragen (also meinedomain.de).
All-Inkl.com: CNAME-Eintrag für Subdomain erstellen

All-Inkl.com: CNAME-Eintrag für Subdomain erstellen

Nach einem Klick auf Speichern werden die Änderungen übernommen.

SSL-Zertifikat für die neue Domain hinzufügen

Damit die Verbindung zu ONLYOFFICE stets verschlüsselt, also über HTTPS abläuft, muss für die neue Subdomain noch ein SSL-Zertifikat über Let’s Encrypt erzeugt werden. Dazu wird das bereits für Nextcloud verwendete Zertifikat modifiziert, indem wir dieses Zertifikat um eine weitere (Sub-)Domain erweitern. Hierfür sind keine Änderungen an den virtuellen Hosts von nginx erforderlich, es reicht einfach folgender Befehl auf der Kommandozeile:

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

Wichtig ist hier die Angabe aller (Sub-)Domains mit dem Parameter -d. Nach diesem Befehl werden die Zertifikats-Dateien unter /etc/letsencrypt/live/meinedaomin.de erneuert. Nicht wundern, hier wird nicht für jede (Sub-)Domain ein Zertifikat erzeugt, sondern nur ein Zertifikat, welches für mehrere Domains ausgestellt ist.

Die Diffie-Hellman-Parameter (siehe Beschreibung) müssen nicht neu erzeugt werden können aus der bestehenden Installation übernommen werden.

Auslagern der SSL-Einstellungen aus dem virtuellen Host für Nextcloud

Für die neue Domain muss nun natürlich ein neuer virtueller Host angelegt werden. Dieser zielt wieder auf SSL ab, daher sind hier auch sämtliche SSL-Einstellungen wie ssl_certificate, ssl_protocols, ssl_ciphers, etc. notwendig. Damit wir diese nicht doppelt pflegen müssen (im Gateway-Host und im virtuellen Host für ONLYOFFICE), lagern wir diese Anweisungen für SSL einfach aus.

Vorher sollten alle virtuellen Hosts gesichert werden, falls beim Umzug etwas schief gehen sollte.

Dazu erstellen wir zunächst einen neuen Ordner, in dem die SSL-Einstellungen gespeichert werden sollen:

mkdir /etc/nginx/snippets

In diesem Ordner erstellen wir anschließend eine neue Datei speziell für allgemeine SSL-Einstellungen, die für alle (Sub-)Domains gelten sollen.

Hinweis: Diese ausgelagerten Einstellungen dürfen nicht im selben Ordner wie die restlichen vHosts (/etc/nginx/conf.d) gespeichert werden, da es ansonsten Probleme mit dem Setzen der HTTP-Header gibt.

In diese Datei werden nun die Anweisungen übernommen, die für die SSL- und Header-Einstellungen zuständig sind. In diesem konkreten Beispiel (siehe hier) sind die Zeilen 32-95 im Gateway-Host betroffen. Dieser Block wird nun aus dem Gateway-Host kopiert und in die ssl.conf eingefügt.

nano /etc/nginx/snippets/ssl.conf

In diesem Beispiel sind es die folgenden Inhalte.

# 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; preload;";
add_header X-Content-Type-Options "nosniff";	
add_header Referrer-Policy "no-referrer";	
add_header X-XSS-Protection "1; mode=block";
add_header X-Robots-Tag none;
add_header X-Download-Options noopen;
add_header X-Permitted-Cross-Domain-Policies none;

# Remove X-Powered-By, which is an information leak
fastcgi_hide_header X-Powered-By;

Im nächsten Schritt werden nun diese SSL-Einstellungen aus dem Gateway-Host entfernt. Beispielweise also wieder die Zeilen 32-95. Damit die SSL-Einstellungen nun auch für den Gateway-Host gelten, wird nun statt dem entfernten Block einfach folgende Zeile mit übernommen:

include /etc/nginx/snippets/ssl.conf;

Wichtig ist hier v.a., dass die Anweisungen nicht doppelt aufgeführt sind (einmal im Gateway-Host direkt und einmal durch den Include). Daher müsen die eigentlichen SSL-Anweisungen auch aus dem Gateway-Host entfernt werden.

Anschließend starten wir den Webserver neu:

service nginx restart

Nun sollte man zunächst einmal testen, ob alle vorhandenen Web-Anwendungen (wie z.B. Nextcloud) noch wie erwartet funktionieren. Erst wenn diese Überprüfung erfolgreich war, sollte man hier weitermachen.

Virtuellen Host für ONLYOFFICE hinzufügen

Alles funktioniert noch? Gut! Dann weiter…

Im nächsten Schritt wird für die neue Subdomain ein eigener vHost hinzugefügt:

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

Der Inhalt ist hier recht übersichtlich:

server {
        listen 443 ssl http2;
        server_name onlyoffice.meinedomain.de;

        # Include SSL configuration
        include /etc/nginx/snippets/ssl.conf;

        #
        # Configuration for OnlyOffice
        #
        location / {
                proxy_pass https://192.168.178.60:4433;
                proxy_redirect off;
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Host $server_name;
                proxy_set_header X-Forwarded-Proto $scheme;
        }
}

Die SSL-Einstellungen haben wird ja zuvor ausgelagert, so dass diese nun in diesem zweiten vHost einfach wiederverwendet werden können.

Wichtig bei der Angabe des proxy_pass:

  • Für die Verbindung zur Maschine, auf der später ONLYOFFICE laufen wird, nutzen wir ebenfalls HTTPS. Wenn dies der gleiche Rechner ist, auf dem auch Nextcloud schon läuft, könnte man hier auch einfach auf HTTP setzen, da die Kommunikation dann nur Rechner-intern abläuft (dazu später mehr).
  • Die IP ist hier die lokale IP-Adresse des Rechners, auf dem ONLYOFFICE später laufen wird. Dies kann also die IP der Maschine sein, auf der auch der Webserver (und z.B. Nextcloud) läuft, oder auch eine andere Maschine im LAN.
  • Als Port habe ich hier 4433 angegeben. Dies ist besonders wichtig, wenn ONLYOFFICE auf dem gleichen Rechner installiert wird, auf dem auch der Webserver/Nextcloud läuft. Der Standard-Port für HTTPS 443 wäre hier schon (durch den Gateway-Host) belegt, also muss man auf einen anderen Port ausweichen.

Installation und Einrichtung ONLYOFFICE

Nachdem nun sämtliche Voraussetzungen erfüllt sind, kann es an die Installation von ONLYOFFICE gehen. Ich bevorzuge hier den Weg über Docker, da eine komplett manuelle Installation sehr aufwendig ist. Hier ist es auch egal, auf welcher Maschine ONLYOFFICE installiert wird. Entweder man installiert das Online-Office direkt auf dem Rechner, auf dem auch Nextcloud bereits läuft, oder man nimmt eine zweite Maschine (oder VM), auf der dann nur ONLYOFFICE betrieben wird.

Docker sollte auf jeden Fall bereits installiert sein. Fall nicht, sollte dieser Schritt wie im Artikel Docker auf Ubuntu Server nun nachgeholt werden.

Alle folgenden Schritte müssen auf der Maschine ausgeführt werden, auf der ONLYOFFICE installiert werden soll.

Vorbereitungen für die Installation

Die Verbindung zu ONLYOFFICE sollte aus Sicherheitsgründen immer verschlüsselt, also über HTTPS ablaufen. Durch den vHost für ONLYOFFICE ist die Verbindung über das Internet auch bereits verschlüsselt. Bleibt nur der Verbindungsweg vom Webserver auf die Maschine, auf der das Online-Office später laufen wird (also die Verbindung im lokalen Netzwerk). Diese Verbindung sollte ebenfalls verschlüsselt werden, damit auch LAN-intern stets sichere Verbindungen aufgebaut wird.

Wenn ONLYOFFICE auf dem gleichen Rechner gehostet wird, auf dem schon Nextcloud und der Webserver laufen, ist dieser Schritt eigentlich optional, da hier nur eine Rechner-interne Verbindung zustande kommt. Trotzdem empfehle ich diese Schritte auszuführen, besonders wenn die Office-Lösung und der Webserver/Nextcloud auf unterschiedlichen Maschinen installiert werden.

Da wir hier ja nur mit einer IP-Adresse arbeiten (die beim proxy_pass angegeben wird), können wir hierfür kein Let’s Encrypt Zertifikat erstellen, da diese Zertifikate nicht auf IP-Adressen, sondern nur auf Domains ausgestellt werden können. Daher greifen wir hier auf ein selbst signiertes Zertifikat zurück.

Dieses wird mit folgenden Befehlen erzeugt:

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 anzugeben (in diesem Fall 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 ONLYOFFICE

Die Installation beschränkt sich dann dank Docker auf einen 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

Hier gilt es folgende Punkte zu beachten:

  • Den Container nennen wir hier ONLYOFFICEDOCKER, damit dieser später über diesen Namen und nicht über eine kryptische ID angesprochen werden kann.
  • Da bereits der Webserver auf Port 443 lauscht (wenn ONLYOFFICE auf dem gleichen Rechner gestartet wird), müssen wird hier auf einen alternativen Port ausweichen. Der Parameter -p 4433:443 sorgt hier dafür, dass der Port 4433 des Docker-Hosts auf den Port 443 innerhalb des Docker-Containers gemappt wird. Wichtig ist hier, dass dieser Port (4433) mit demjenigen übereinstimmt, der beim proxy_pass im vHost für ONLYOFFICE angegeben wurde.
  • Die nächsten zwei Parameter (-e JWT_ENABLED=’true‘ -e JWT_SECRET=’geheimes-secret‘) erhöhen die Sicherheit, da zur Kommunikation mit dem Container ein sog. JSON Web Token benötigt wird. Im Grunde genommen handelt es sich dabei um ein Passwort (geheimes-secrethier sollte man natürlich ein eigenes Passwort wählen), welches später in Nextcloud hinterlegt werden muss, damit die Verbindung zu ONLYOFFICE aufgebaut werden kann. Dies verhindert, dass der ONLYOFFICE-Container „unbemerkt“ von anderen Verbindungen genutzt werden kann.
  • Mit —restart=always wird der Container bei jedem Systemstart automatisch gestartet.
  • Mit dem letzten Parameter (-v /app/onlyoffice/DocumentServer/data:/var/www/onlyoffice/Data onlyoffice/documentserver) wird ein sog. Volume definiert: Alle Dateien, die im Verzeichnis /app/onlyoffice/DocumentServer/data des Hosts liegen, werden innerhalb des Containers im Verzeichnis /var/www/onlyoffice/Data onlyoffice/documentserver bereitgestellt. Diese Funktion wird benötigt, damit der Container das zuvor erzeugte Zertifikat finden und nutzen kann.

Nun wird das entsprechende Docker-Image heruntergeladen und auch gleich gestartet.

Installation von ONLYOFFICE mittels Docker

Installation von ONLYOFFICE mittels Docker

Nach dem Starten des Containers läuft ONLYOFFICE bereits. Wenn man nun im Browser die Domain onlyoffice.meinedomain.de oder die IP-Adresse der jeweiligen Maschine (dann aber mit dem alternativen Port 4433) aufruft, sollte folgende Seite erscheinen:

ONLYOFFICE läuft

ONLYOFFICE läuft

Einbinden von ONLYOFFICE in Nextcloud

Nachdem ONLYOFFICE läuft, geht es nun mit der eigenen Nextcloud weiter, damit hier Online-Office-Funktionalitäten hinzugefügt werden können.

Die passende App findet man dabei im Nextcloud App Store in der Kategorie Büro & Text:

ONLYOFFICE im Nextcloud App-Store

ONLYOFFICE im Nextcloud App-Store

Wenn die App aktiviert wurde, können die Einstellungen nun in der Admin-Oberfläche von Nextcloud unter dem Punkt ONLYOFFICE angepasst werden (damit alle Einstellungen angezeigt werden, muss man auf den Punkt Erweiterte Servereinstellungen klicken).

Nextcloud: ONLYOFFICE-Einstellungen in der Admin-Oberfläche

Nextcloud: ONLYOFFICE-Einstellungen in der Admin-Oberfläche

  • Serviceadresse der Dokumentbearbeitung: Hier wird die Subdomain angegeben, die wir extra für ONLYOFFICE angelegt habe, in diesem Beispiel also https://onlyoffice.meinedomain.de.
  • Geheimer Schlüssel (freilassen, um zu deaktivieren): Hier ist das JWT-Token anzugeben, welches beim Starten des Docker-Containers angegeben wurde (geheimes-secret).
  • Alle anderen Felder kann man leer lassen.

Nach einem Klick auf Speichern sollte eine Meldung erscheinen, dass die Einstellungen erfolgreich übernommen wurden.

Anschließend können Office-Dokumente ganz einfach direkt in der Cloud bearbeitet werden:

Online-Office mit Nextcloud und ONLYOFFICE

Online-Office mit Nextcloud und ONLYOFFICE

Update von ONLYOFFICE

Von Zeit zu Zeit erscheint ein neues Docker-Image für ONLYOFFICE. Leider ist es etwas umständlich herauszufinden, welche Version gerade installiert ist und ob es eine neue Container-Version gibt.

Um zu ermitteln, welche Version aktuell installiert ist, öffnet man am besten ein beliebiges Office-Dokument. Mit der Info-Schaltfläche wird die installierte Version von ONLYOFFICE angezeigt:

Über die Info-Schaltfläche kann die installierte Version ermittelt werden

Über die Info-Schaltfläche kann die installierte Version ermittelt werden

Die Version des aktuellsten Images kann nun über Docker Hub (eine Art Suche für Docker-Images) ermittelt werden. Dazu sucht man einfach nach onlyoffice und lässt sich dann die Tags anzeigen. Schneller geht es über diesen Direktlink. Hier werden dann alle Versionen des Images angezeigt:

Die aktuelle Version im Docker Hub

Die aktuelle Version im Docker Hub

Zwar werden in der ONLYOFFICE-Hilfe nur drei Versionsnummern angezeigt, allerdings sollte man auch anhand des Datums sehen können, wenn eine neue Version des Containers bereitsteht.

Das Update selbst kann man dann in wenigen Schritten durchführen:

Zunächst wird der aktuelle Container gestoppt und entfernt:

docker stop ONLYOFFICEDOCKER
docker rm ONLYOFFICEDOCKER

ONLYOFFICEDOCKER ist hier der Name des Containers, den wir beim ersten Start angegeben haben. Hier könnte man auch die ID des Containers angeben (kann man mit docker ps ermitteln).

Optional: Bei der Arbeit mit Docker bleiben oft Reste auf dem System zurück (z.B. alte, ungenutzte Container). Gerade wenn auf dem System ausschließlich ONLYOFFICE per Docker betrieben wird, empfiehlt es sich, das komplette Docker-System zu bereinigen. Dazu werden einfach folgende Befehle ausgeführt:

docker system prune -a
docker image prune -a
docker container prune

Anschließend wird die neuste Version des Containers heruntergeladen und über den bekannten Befehl gestartet:

docker pull onlyoffice/documentserver
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

Beim zweiten Befehl ist hier nur wichtig, dass genau das gleiche JWT_SECRET wie schon beim Start des Containers angegeben wird, ansonsten kann nach dem Update keine Verbindung mehr von Nextcloud hergestellt werden.

Troubleshooting

Manchmal kann es vorkommen, dass ONLYOFFICE nicht wie erwartet funktioniert. Bei dem System sind ziemlich viele Komponenten beteiligt (Webserver, Nextcloud, Docker-Container), so dass man zunächst einmal das Problem eingrenzen sollte.

Zunächst sollte immer erst die Subdomain für ONLYOFFICE aufgerufen werden: onlyoffice.meinedomain.de

Erscheint hier nicht die Übersichtsseite von ONLYOFFICE, dann tritt das Problem wohl auf dem Verbindungsweg vom Internet zum Webserver auf. Dann sollten zunächst einmal die Logs des Webservers kontrolliert werden (auf der Maschine, wo der Gateway-Host zu finden ist und auch Nextcloud installiert ist).

nano /var/log/nginx/error.log

Hier sollten dann Fehlermeldungen zu finden sein, mit den man das Problem weiter eingrenzen kann.

Wenn die Seite erreichbar ist, aber ONLYOFFICE trotzdem nicht funktioniert, sollte in diesem Fall zunächst einmal das Nextcloud-Log überprüft werden (in der Admin-Oberfläche von Nextcloud unter Protokollierung).

Falls hier auch nichts auffälliges zu sehen ist, sollten die Logs des Docker-Containers überprüft werden:

docker logs ONLYOFFICEDOCKER

Hier sind dann u.U. Hinweise zu finden, dass ein benötigter Dienst nicht gestartet werden konnte. In diesem Fall hilft es meistens, den Rechner, auf dem ONLYOFFICE läuft, einfach mal neu zu starten.

Erst wenn dies auch zu keinen neuen Erkenntnissen führt, kann man sich auch auf die Kommandozeile des Containers selbst einloggen. Dazu einfach auf der Docker-Maschine folgenden Befehl ausführen:

sudo docker exec -it ONLYOFFICEDOCKER bash

Auf der Kommandozeile des Containers kann dann eine detaillierte Fehlersuche stattfinden. Mit folgendem Befehl kann man beispielsweise die Webserver-Logs einzusehen:

nano /var/log/nginx/error.log

Um die Kommandozeile des Containers wieder zu verlassen, reicht folgender Befehl:

exit

Fazit

Es sind schon einige Schritte notwendig, um ONLYOFFICE in Verbindung mit Nextcloud zum Laufen zu kriegen. Dennoch lohnt es sich, da man nun direkt in der eigenen Cloud ein Online-Office nutzen kann. Wer vorher beispielsweise Google Docs verwendet hat, wird sich auch bei ONLYOFFICE sehr schnell zurechtfinden – und das ohne die neugierigen Blicke von Google & Co, da alle Daten sicher in der eigenen Nextcloud gespeichert sind.

Weiterführende Artikel

Links

 

]]>
https://decatec.de/home-server/nextcloud-online-office-mit-onlyoffice-mit-eigener-subdomain/feed/ 54