DecaTec

Home-Server | Linux | Nextcloud | Raspberry Pi | Programmierung | Fotografie

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

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

Kommentare: 142

  • Thorsten sagt:

    Hallo Jan,
    heute gehe ich Dein Tutorial ein weiteres Mal für eine Neuinstallation durch.
    Beim Matrix Federation Tester bekomme ich allerdings nur einen connection report, nämlich den für 443.
    Allerdings hast Du ja auch nur 443 in /etc/nginx/conf.d/matrix.meinedomain.de.conf angelegt. Was sollte der zweite Report zeigen?
    Vielen Dank!
    Thorsten

    • Jan sagt:

      Hi Thorsten,

      nicht wundern: Der Test wird einmal mit IPv4 und einmal mit IPv6 gemacht. Wenn du nur IPv4 konfiguriert hast, ist es normal, dass du hier nur ein Testergebnis angezeigt bekommst.

      Gruß,
      Jan

  • Sam sagt:

    Hallo, das Telefonieren/Videoanruf über mein eigenes Netzwerk funktioniert leider nicht. Es erscheint die Meldung “debug: event typ m.call.select answer”. in der App & bleibt auf “Verbindungsaufbau…”. Der Matrix Fed. Test hat mir die Fehlermeldung “MatchingServerName” gegeben. Liegt es eventuell daran? ansonsten scheint alles andere problemlos zu funktionieren… auch der SSL Server Test sieht gut aus.

    Coturn habe ich bereits auch eingerichtet, jedoch funktioniert es auch nicht. Bitte um Unterstützung.

    Vielen Dank für die Mühen!

    • Jan sagt:

      Hi Sam,

      es kann durchaus damit zusammen hängen, wenn es einen Fehler bei “MatchingServerName” gibt. In diesem Fall kann es sein, dass der Hostname nicht zu jedem passt, auf den das TLS-Zertifikat ausgestellt wurde.
      Wichtig in diesem Zusammenhang ist, dass die SSL-Terminierung nur am nginx stattfindet. Matrix Synapse selbst weiß gar nichts von Zertifikaten o.ä.

      Kann es sein, dass du den lokalen Traffic bei dir über die lokale IP des Servers leitest und nicht über die externe (Internet-)IP?

      Gruß,
      Jan

      • Sam sagt:

        Ich betreibe einen lxc Container durch Proxmox & habe folgende Einstellungen :

        Dns Domain & Server = verwende werte vom Host
        Unprivilegierter Container = ja
        Nesting = ja
        Ip = dhcp
        Brindge = vmbr0
        Firewall = ja

        Bei der Conf. Von Matrix-synapse hatte ich eine Störung mit Nginx, es standen Server Port 80 Einstellungen in default mit der in der Anletung in Konflikt. Die hatte ich dann unlinked per grap. Ansonsten hätte ich keine weiteren Anhaltspunkte mehr… der Server ist aus dem Internet erreichbar.

        Grüße.

        • Jan sagt:

          Hi,

          diese Infos bringen mich leider nicht wirklich weiter. Was erscheint bei dir, wenn du in der Kommandozeile folgendes eingibst? curl https:// -v

          Gruß,
          Jan

          • Sam sagt:

            Hallo,

            * Expire in 0 ms for 6 (transfer 0x5591e995dfb0)
            * Closing connection -1
            curl: (3) URL using bad/illegal format or missing URL

          • Jan sagt:

            Hi Sam,

            oh, da wurde wohl der Befehl vom Kommentar-System verhunzt. Soll natürlich so lauten: curl https://matrix.domain.de -v
            matrix.meinedomain.de bitte durch deine Domain ersetzen.

            Gruß,
            Jan

          • Jan sagt:

            Hi Sam,

            der richtige Output ist nun im Spam-Ordner gelandet. Ich lasse den da auch mal, da es sonst ein zu langer Kommentar wird. Deine Matrix-Domain ist erreichbar.
            Aber es geht ja um Anrufe, oder? Hast du einen eigenen coturn installiert und wenn ja, wie ist dieser eingerichtet? Passen dort die Zertifikate?

            Gruß,
            Jan

  • Sam sagt:

    Ja coturn habe ich installiert, die Zertifikate sollten eigentlich passen… wenn nicht wie könnte ich es am besten überprüfen? Die Anrufe funktionieren ja auch im eigenen Netzwerk nicht, werden die Anrufe in dem Fall auch durch coturn geleitet? Grüße.

  • Sam sagt:

    Folgendes ist mir aufgefallen:

    – Ich habe Coturn deaktiviert, das Anrufen auf dem eigenen Netzwerk hat trotzdem nicht funktioniert.

    – Sobald ich den vorgegebenen Inhalt in die Datei HttpGateway.conf kopiere lässt sich nginx nicht mehr starten, lösche ich es funktioniert ngnix wieder. Im Verzeichnis /etc/nginx/conf.d/ habe ich noch die Datei meinedomain.conf mit dem vorgegebenen Inhalt.

    – ciphers, secret & uis habe ich geprüft ua.untereinander verglichen ( Synapse Conf. & turnserver conf.) alles scheint i.o

    ‘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’;

    Grüße.

    • Jan sagt:

      Hi,

      Sobald ich den vorgegebenen Inhalt in die Datei HttpGateway.conf kopiere lässt sich nginx nicht mehr starten

      Dieser vHost sorgt eigentlich nur dafür, dass die Zertifikats-Generierung über Let’s Encrypt funktioniert. Sämtlicher andere Traffic wird automatisch nach HTTPS umgeleitet.

      Ich würde mich an dieser Stelle eher fragen, was an Routing in deinem lokalen Netzwerk anders ist, als wenn du “über das Internet” gehst. Schau mal, ob du in einem Router eine Einstellung “Rebind Schutz” hast und trage hier mal deine Domains ein.

      Gruß,
      Jan

      • Sam sagt:

        Guten Abend,

        ich habe den „Rebind Schutz“ für meine Domain in meinem Router deaktiviert & es hat geklappt :)

        Vielen Dank für die riesige Unterstützung & ein schönes Wochenende :)

  • Yunus sagt:

    Hallo Jan,

    vielen Dank für all deine Beiträge. Sie erleichtern ungemein das Installien der Produkte. Ich habe leider hier das Problem, das sich Marix Synapse zwar installieren und ausführen lässt, jedoch versandte Nachrichten bei anderen Benutzern nicht erscheinen. Hast du vielleicht einen Tipp woran das liegen kann?

    Viele Grüße

    Yunus

    • Jan sagt:

      Hi Yunus,

      ohne genaue Fehlerbeschreibung wird es hier schwierig. Sind in den Server-Logs irgendwelche Meldungen, die auf einen Fehler hinweisen? Ansonsten: Kommen Meldungen an, wenn die anderen auf deinem Server registriert sind, oder nur, wenn hier ein anderer Matrix-Server zum Einsatz kommt (Federation)?

      Gruß,
      Jan

      • Yunus sagt:

        Hallo Jan,

        beim Matrix Federation Tester gab es folgende Fehler mit dem MatchingServerName + No SRV Records. Auch das Anhängsel bei den Namen entsprach nicht matrix.meinedomäne.de sonder matrix.nc-meine-domäne.de. Die Nachrichten wurden vom Web-Clients von Element von zwei User testweise hin und her geschickt. Ich kann gerade nicht auf die Logs schauen, da ich im Eifer des Gefechts meinen letzten Prüfpunkt der VM gelöscht habe und inzwischen zu viele Requests an LetsEncrypt […]. Ich melde mich erneut, sobald ich beim davorrigen Stand bin um auch mal in die Logs schauen zu können.

        Viele Grüße

        Yunus

        • Jan sagt:

          Hi Yunus,

          dann passt irgend etwas mit der Domain nicht – er scheint ja “matrix.nc-meine-domäne.de” anzunehmen, die aber nicht passt. Hier würde ich den Hostnamen in der Matrix-Konfiguration und ebenfalls den entsprechenden nginx vHost checken, ob hier alles von der Domäne her zusammen passt.

          Gruß,
          Jan

          • Yunus sagt:

            Hallo Jan,
            ich bin etwas schlauer geworden. Ich bin die Einleitung komplett durch, ich habe inzwischen auch eine neue Subdomäne erstellt unter der die Instanz läuft. Die Werte in den Konfigurationen bezüglich der Domänen habe ich überprüft, diese sind soweit identisch. Beim Federation Tester schlägt der Test für MatchingServerName fehl, das Ergebnis da sieht so aus: <<<<>>

            Wenn ich Benutzer anlege, so werden die nicht als z.B. @tester:synapse.meinedomain.de sondern als @tester:matrix angelegt, egal ob über die Web-Ui oder lokal über die Konsole. Das Anmelden auf dem Homeserver funktioniert dann auch nicht mit@tester:synapse.meinedomain.de, sondern nur mit dem Benutzernamen tester. Ein Blick im Profil im Web Element gibt an, das als Identitätsserver vector.im genutzt wird.

            Sollte die Identitätsprüfung nicht auch auf dem Homeserver passieren? Falls ja, wie ändere ich diese Einstellung?

            Log von nginx:
            2021/08/28 11:52:20 [alert] 2235#2235: *1056 open socket #14 left in connection>
            2021/08/28 11:52:20 [alert] 2235#2235: *1057 open socket #15 left in connection>
            2021/08/28 11:52:20 [alert] 2235#2235: *1061 open socket #17 left in connection>
            2021/08/28 11:52:20 [alert] 2235#2235: *1060 open socket #16 left in connection>
            2021/08/28 11:52:20 [alert] 2235#2235: aborting

            Im Matrix log unter /var/logs/matrix-synapse sind lauter Info Meldungen wie z.B.:
            2021-08-28 12:17:27,986 – synapse.storage.databases.main.event_push_actions – 537 – INFO – event_push_action_stream_orderings-1 – Searching for stream ordering 1 month ago
            2021-08-28 12:17:27,993 – synapse.storage.databases.main.event_push_actions – 541 – INFO – event_push_action_stream_orderings-1 – Found stream ordering 1 month ago: it’s 2
            2021-08-28 12:17:27,993 – synapse.storage.databases.main.event_push_actions – 544 – INFO – event_push_action_stream_orderings-1 – Searching for stream ordering 1 day ago
            2021-08-28 12:17:28,000 – synapse.storage.databases.main.event_push_actions – 548 – INFO – event_push_action_stream_orderings-1 – Found stream ordering 1 day ago: it’s 2
            2021-08-28 12:17:28,072 – synapse.handlers.presence – 755 – INFO – persist_presence_changes-18 – Persisting 2 unpersisted presence updates
            2021-08-28 12:17:28,193 – synapse.storage.databases.main.metrics – 463 – INFO – generate_user_daily_visits-3 – Calling _generate_user_daily_visits
            2021-08-28 12:17:41,686 – synapse.access.http.8008 – 389 – INFO – GET-422 – 192.168.0.48 – 8008 – {@matrixmin:matrix} Processed request: 30.004sec/-0.000sec (0.001sec, 0.000sec) (0.001sec/0.001sec/1) 94B 200 “GET /_matrix/client/r0/sync?filter=0&timeout=30000&since=s24_121_0_3_19_1_4_29_1 HTTP/1.0” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0” [0 dbevts]
            2021-08-28 12:17:41,721 – synapse.access.http.8008 – 389 – INFO – GET-426 – 192.168.0.48 – 8008 – {@matrixmin:matrix} Processed request: 0.007sec/-0.000sec (0.003sec, 0.003sec) (0.001sec/0.001sec/1) 245B 200 “GET /_matrix/client/r0/sync?filter=0&timeout=30000&since=s24_121_0_3_19_1_4_29_1 HTTP/1.0” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0” [0 dbevts]
            2021-08-28 12:17:55,602 – synapse.access.http.8008 – 389 – INFO – GET-424 – 192.168.0.48 – 8008 – {@testmin3:matrix} Processed request: 30.004sec/-0.000sec (0.001sec, 0.000sec) (0.001sec/0.001sec/1) 94B 200 “GET /_matrix/client/r0/sync?filter=0&timeout=30000&since=s24_121_0_3_19_1_4_29_1 HTTP/1.0” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0” [0 dbevts]
            2021-08-28 12:17:55,672 – synapse.access.http.8008 – 389 – INFO – GET-430 – 192.168.0.48 – 8008 – {@testmin3:matrix} Processed request: 0.007sec/-0.000sec (0.002sec, 0.000sec) (0.001sec/0.001sec/1) 244B 200 “GET /_matrix/client/r0/sync?filter=0&timeout=30000&since=s24_121_0_3_19_1_4_29_1 HTTP/1.0” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0” [0 dbevts]
            2021-08-28 12:18:11,751 – synapse.access.http.8008 – 389 – INFO – GET-428 – 192.168.0.48 – 8008 – {@matrixmin:matrix} Processed request: 30.003sec/-0.000sec (0.002sec, 0.000sec) (0.001sec/0.001sec/1) 94B 200 “GET /_matrix/client/r0/sync?filter=0&timeout=30000&since=s24_123_0_3_19_1_4_29_1 HTTP/1.0” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0” [0 dbevts]
            2021-08-28 12:18:25,756 – synapse.access.http.8008 – 389 – INFO – GET-432 – 192.168.0.48 – 8008 – {@testmin3:matrix} Processed request: 30.004sec/-0.000sec (0.002sec, 0.000sec) (0.001sec/0.001sec/1) 94B 200 “GET /_matrix/client/r0/sync?filter=0&timeout=30000&since=s24_123_0_3_19_1_4_29_1 HTTP/1.0” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0” [0 dbevts]
            2021-08-28 12:18:28,072 – synapse.handlers.presence – 755 – INFO – persist_presence_changes-19 – Persisting 2 unpersisted presence updates

          • Jan sagt:

            Hi,

            wie gesagt, da wird irgend etwas mit der Domain nicht passen. Entweder bei der Verbindung “Internet -> Matrix” oder lokal auf dem Matrix-Server. Das kann zum einen an der nginx-Config liegen, oder aber auch an der homeserver.yaml.
            Denn der “full qualified” Benutzer-Name wird ja implizit durch die Matrix-Instanz vergeben.
            Aus den Logs selbst kann ich gerade nichts sinnvolles herauslesen.

            Gruß,
            Jan

  • Kemo sagt:

    Hallo, ich habe auf meinem Homeserver bereits lxc Container in Einsatz die vom Internet erreichbar sind. Ich möchte Matrixsynapse mit meinem externen lxc Nginx proxy Manager vom Internet erreichbar machen anstatt es direkt mit zu installieren denn ich kann auf meinem Router den traffic nur von einer Stelle raus schicken… Wie könnte ich den traffic am besten auf den externen Nginx leiten? Grüße.

  • Kemo sagt:

    Hallo, wenn ich nginx nach der Anleitung auf einen externen Container einrichte erhalte ich bei /.well-known/acme-challenge/test.txt eine 404 Fehlermeldung. Wenn ich die Domain jedoch direkt aufrufe sehe ich die Nginx Startseite. Woran kann es liegen? Grüße.

    • Jan sagt:

      Hi,

      das liegt vermutlich an einem Fehler im nginx vHost. Wenn du den Zugriff über die test.txt aufrufst und den 404er bekommst, schau mal ins nginx error- bzw. access.log: Hier sollte dann drin stehen, wo er nach dieser Datei sucht.

      Gruß,
      Jan

      • Kemo sagt:

        Ich habe folgendes in der Logdatei stehen:

        47.xxx.xxx.55 – – [05/Sep/2021:12:22:51 +0000] “GET /.well-known/acme-challenge/test.txt HTTP/1.1” 404 193 $
        155.xxx.xxx.00 – – [05/Sep/2021:12:22:51 +0000] “GET /favicon.ico HTTP/1.1” 404 193 “http://m.0vn.de/.well-k$
        155.xxx.xxx.00 – – [05/Sep/2021:12:22:56 +0000] “GET /.well-known/acme-challenge/test.txt HTTP/1.1” 404 193 $
        155.xxx.xxx.00 – – [05/Sep/2021:12:22:57 +0000] “GET /.well-known/acme-challenge/test.txt HTTP/1.1” 404 193 $
        155.xxx.xxx.00 – – [05/Sep/2021:12:23:28 +0000] “GET / HTTP/1.1” 200 396 “-” “Mozilla/5.0 (Windows NT 10.0; $
        155.xxx.xxx.00 – – [05/Sep/2021:12:25:18 +0000] “GET / HTTP/1.1” 304 0 “-” “Mozilla/5.0 (Windows NT 10.0; Wi$
        155.xxx.xxx.00 – – [05/Sep/2021:12:25:30 +0000] “GET /.well-known/acme-challenge/test.txt HTTP/1.1” 404 193 $
        155.xxx.xxx.00 – – [05/Sep/2021:12:25:32 +0000] “GET /.well-known/acme-challenge/test.txt HTTP/1.1” 404 193 $
        155.xxx.xxx.00 – – [05/Sep/2021:12:25:41 +0000] “GET /.well-known/acme-challenge/test.txt HTTP/1.1” 404 193 $
        155.xxx.xxx.00 – – [05/Sep/2021:12:25:42 +0000] “GET /.well-known/acme-challenge/test.txt HTTP/1.1” 404 193 $
        155.xxx.xxx.00 – – [05/Sep/2021:12:25:42 +0000] “GET /.well-known/acme-challenge/test.txt HTTP/1.1” 404 193 $
        155.xxx.xxx.00 – – [05/Sep/2021:12:26:49 +0000] “GET /.well-known/acme-challenge/ HTTP/1.1” 404 193 “-” “Moz$
        155.xxx.xxx.00 – – [05/Sep/2021:12:26:55 +0000] “GET /.well-known/acme-challenge/test.txt HTTP/1.1” 404 193 $
        23.xxx.xx.345 – – [05/Sep/2021:12:27:54 +0000] “GET /boaform/admin/formLogin?username=user&psd=user HTTP/1.0$
        155.xxx.xxx.00 – – [05/Sep/2021:12:29:17 +0000] “GET /.well-known/acme-challenge/test.txt HTTP/1.1” 404 193 $
        155.xxx.xxx.00 – – [05/Sep/2021:12:29:18 +0000] “GET /.well-known/acme-challenge/test.txt HTTP/1.1” 404 193 $
        155.xxx.xxx.00 – – [05/Sep/2021:12:29:19 +0000] “GET /.well-known/acme-challenge/test.txt HTTP/1.1” 404 193 $
        155.xxx.xxx.00 – – [05/Sep/2021:12:29:21 +0000] “GET / HTTP/1.1” 304 0 “-” “Mozilla/5.0 (Windows NT 10.0; Wi$
        155.xxx.xxx.00 – – [05/Sep/2021:12:30:39 +0000] “GET / HTTP/1.1” 304 0 “-” “Mozilla/5.0 (Windows NT 10.0; Wi$
        155.xxx.xxx.00 – – [05/Sep/2021:12:30:54 +0000] “GET /.well-known/acme-challenge/test.txt HTTP/1.1” 404 193 $

  • Kemo sagt:

    2021/09/05 12:18:22 [emerg] 11433#11433: a duplicate default server for 0.0.0.0:80 in /etc/nginx/sites-enabled/default:22
    2021/09/06 09:37:20 [alert] 11457#11457: *109 open socket #12 left in connection 6
    2021/09/06 09:37:20 [alert] 11457#11457: aborting
    2021/09/06 09:37:20 [emerg] 11908#11908: “server_name” directive is not allowed here in /etc/nginx/sites-enabled/default:46
    2021/09/06 09:38:04 [emerg] 11920#11920: a duplicate default server for 0.0.0.0:80 in /etc/nginx/sites-enabled/default:22
    2021/09/06 09:38:06 [emerg] 11926#11926: a duplicate default server for 0.0.0.0:80 in /etc/nginx/sites-enabled/default:22
    2021/09/06 09:38:07 [emerg] 11932#11932: a duplicate default server for 0.0.0.0:80 in /etc/nginx/sites-enabled/default:22
    2021/09/06 09:38:13 [emerg] 11953#11953: a duplicate default server for 0.0.0.0:80 in /etc/nginx/sites-enabled/default:22

    • Jan sagt:

      Hi,

      hier gibt es anscheinend einen doppelten vHost, der auf Port 80 lauschen will. Bitte mal den default-vHost löschen (/etc/nginx/sites-enabled/default), nginx neu starten und das ganze nochmal ausprobieren.

      Gruß,
      Jan

  • Kemo sagt:

    Hallo,
    ich habe die Datei gelöscht und nginx neu gestartet.
    Statusabfrage von Nginx: aktiv.
    Aber jetzt ist die Url nicht mehr erreichbar. (auch erscheint die Nginx Startseite. nicht mehr)

    Folgendes steht im error.log:
    2021/09/08 13:36:04 [alert] 12691#12691: *1 open socket #11 left in connection 3
    2021/09/08 13:36:04 [alert] 12691#12691: aborting

    Viele Grüße & vielen Dank.

    • Jan sagt:

      Hi,

      der Fehler sagt mir erst einmal gar nichts.
      Was sagt der Befehl nginx -t?
      Dass die Startseite nicht mehr funktioniert ist klar, da dies ja durch den Default-vHost realisiert wurde.

      Gruß,
      Jan

  • Kemo sagt:

    Die Meldung lautet:

    nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
    nginx: configuration file /etc/nginx/nginx.conf test is successful

    Grüße.

    • Jan sagt:

      Hi,

      OK, das sagt schon mal aus, das die vHost syntakitsch korrekt sind.
      Wie wurde nginx installiert?
      Wird SPDy genutzt? Wenn ja, dann mal deaktivieren.

      Gruß,
      Jan

      • Kemo sagt:

        Hi, über die interne Ip erscheint die Nginx Startseite leider auch nicht. Daher vermute ich, dass es an was anderem liegt statt spdy. Ich habe alles identisch nach Anleitung durchgeführt bis auf das ich Debian 10 statt ubuntu für den Nginx Server angelegt habe. Grüße.

        • Jan sagt:

          Hi,

          läuft nginx denn überhaupt (service nginx status)? Wenn ja, welche Ports werden von nginx belegt (netstat -tulpn)? Wenn hier dann 80 und 443 für nginx aufgelistet werden, dann vermute ich noch einen Fehler in einem der vHosts.

          Gruß,
          Jan

          • Kemo sagt:

            Hallo, nginx Status:

            nginx.service – A high performance web server and a reverse proxy server
            Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
            Drop-In: /etc/systemd/system/nginx.service.d
            `-override.conf
            Active: active (running) since Thu 2021-09-09 10:36:30 UTC; 2 days ago
            Docs: man:nginx(8)
            Process: 380 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=
            Process: 381 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS
            Process: 385 ExecStartPost=/bin/sleep 0.1 (code=exited, status=0/SUCCESS)
            Main PID: 382 (nginx)
            Tasks: 3 (limit: 14167)
            Memory: 3.5M
            CPU: 103ms
            CGroup: /system.slice/nginx.service
            |-382 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
            |-383 nginx: worker process
            `-384 nginx: worker process

            Netstat:

            tcp 0 0 0.0.0.0:5355 0.0.0.0:* LISTEN 86/systemd-resolved
            tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 382/nginx: master p
            tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 86/systemd-resolved
            tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 340/master
            tcp6 0 0 :::5355 :::* LISTEN 86/systemd-resolved
            tcp6 0 0 :::80 :::* LISTEN 382/nginx: master p
            tcp6 0 0 :::22 :::* LISTEN 1/init
            tcp6 0 0 ::1:25 :::* LISTEN 340/master
            udp 0 0 127.0.0.53:53 0.0.0.0:* 86/systemd-resolved
            udp 0 0 0.0.0.0:5355 0.0.0.0:* 86/systemd-resolved
            udp6 0 0 :::5355 :::* 86/systemd-resolved

            Schönes Wochenende.

          • Jan sagt:

            Hi,

            das sieht alles gut aus.
            Wo genau geht es nun nicht weiter? Denn der Default-vHost sollte ja nun weg sein, damit der Port 80 nicht doppelt belegt wird.

            Gruß,
            Jan

  • Kemo sagt:

    Hallo nach langer Zeit,
    ich hatte endlich etwas Freizeit & habe den Server & Nginx komplett neu installiert. Dann hat es auch komischer weise mit dem test.txt wieder funktioniert.
    Auch die Zertifikate SSL Test usw. sehen gut aus (außer DNS CAA stand im test No?).

    Mein aktuelles Problem: Wenn ich domain.de oder sub.domain.de aufrufe bekomme ich eine 404 nginx Seite und auf der Matrix Fed. Tester Website:

    Non-200 response 502 from remote server

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

    Ich habe eine Dyndns auf Strato. Für Domain.de habe ich Cname: domain.de.

    SRV habe ich getestet mit “matrix tcp 10 5 443 sub.domain.de” hat leider nicht geklappt.

    Ich komme an dem Punkt leider auch nicht mehr weiter…

    Beste Grüße & vielen Dank für die Mühen.

    • Jan sagt:

      Hi,

      für DNS CAA brauchst du einen solchen DNS-Eintrag bei der Domain, siehe hier. Dieser ist aber nicht zwingend notwenig.

      Einen SRV-Eintrag für Matrix setze ich nicht, da hier die Weiterleitungen von nginx ausreichen. Das stellt also auch keinen Fehler dar.
      Nur dieses “Non-200 response 502 from remote server” sollte denke ich mal nicht so sein. HTTP 502 heißt “Bad Gateway” und deutet darauf hin, dass es im “Backend” (also im Matrix-Server selbst) kracht. Daher würde ich nun erst einmal einen Fehler in der Matrix-Konfiguration suchen. Bekommst du hier überhaupt eine Verbindung mit einem Client hin?

      Gruß,
      Jan

      • Kemo sagt:

        Eine Verbindung zum Client ist nicht möglich (die Url wird in der App nicht als Matrix Server erkannt). Kann es sein, dass zusätzlich eine Weiterleitung vom Matrix Container zum nginx Container eingerichtet werden muss? Für die Datenbank oder Datenverkehr? Ich werde mal Matrix Synapse nochmal neu aufsetzen & erneut Tests durchführen.

  • Kemo sagt:

    Folgende Entdeckung habe ich gemacht, ich weis nicht ob Das weiterhilft aber folgender Eintrag ist sehr oft in der Log Datei: …

    Is the server running on host “localhost” (127.0.0.1) and accepting TCP/IP connections on port 5432?

    2021-09-20 13:21:50,463 – synapse.app.homeserver – 357 – INFO – main – Setting up server
    2021-09-20 13:21:50,463 – synapse.server – 308 – INFO – main – Setting up.
    2021-09-20 13:21:50,482 – synapse.app._base – 161 – ERROR – main – Exception during startup
    Traceback (most recent call last):
    File “/opt/venvs/matrix-synapse/lib/python3.7/site-packages/synapse/app/homeserver.py”, line 360, in setup
    hs.setup()
    File “/opt/venvs/matrix-synapse/lib/python3.7/site-packages/synapse/server.py”, line 310, in setup
    self.datastores = Databases(self.DATASTORE_CLASS, self)
    File “/opt/venvs/matrix-synapse/lib/python3.7/site-packages/synapse/storage/databases/__init__.py”, line 48, in __init__
    with make_conn(database_config, engine, “startup”) as db_conn:
    File “/opt/venvs/matrix-synapse/lib/python3.7/site-packages/synapse/storage/database.py”, line 127, in make_conn
    native_db_conn = engine.module.connect(**db_params)
    File “/opt/venvs/matrix-synapse/lib/python3.7/site-packages/psycopg2/__init__.py”, line 122, in connect
    conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
    psycopg2.OperationalError: could not connect to server: Connection refused
    Is the server running on host “localhost” (::1) and accepting
    TCP/IP connections on port 5432?
    could not connect to server: Connection refused
    Is the server running on host “localhost” (127.0.0.1) and accepting
    TCP/IP connections on port 5432?

    VG.

    • Jan sagt:

      Hi,

      ja, das könnte ein guter Hinweis sein. Er kann keine Verbindung zur Datenbank (PostgreSQL auf Port 5432) herstellen, daher kann Matrix nicht gestartet werden. Der nächste Schritt wäre also mal die Datenbank-Konfiguration zu checken.

      Gruß,
      Jan

      • Kemo sagt:

        Hallo,
        Ich habe erneut alles runtergeschmissen, die Nginx mit in das selbe Container gepackt & alle Workarounds erneut durchgeführt.
        Es erschien dasselbe Problem Bild.
        ich habe dann als Test die Firewall deaktiviert & es funktionierte dann mit der Verbindung von Matrix & der Datenbank.
        Ich habe also die Firewall wieder aktiviert & den Port 5432 für die Datenbank freigeben, die 1. Sorge war ich los. Meine Frage wäre dazu, würde die Portfreigabe eine Sicherheitslücke darstellen?

        Folgende 2 Probleme habe ich jedoch auch noch…
        Wenn ich mich auf der App anmelden möchte & dabei mit dem WLAN verbunden bin (Heimnetz worauf auch der Server läuft) wird der Matrix Server nicht erkannt & es funktioniert nicht. Mit mobile Daten jedoch funktioniert alles problemlos.

        Als Info: Matrix Fed. Test zeigt “MatchingServerName Error” & die Seite matrix.meinedomain.de aufrufen zeigt mir die “404 Not Found” Seite von Nginx

        Was auch nicht funktioniert ist, sind die push Benachrichtigungen. (Getestet auf 2 Smartphones) mit dem Element Client 1.2.2 aus dem F-droid Store.

        Viele Grüße.

  • Gerd sagt:

    Hallo,

    wie schaffe ich es denn, dass die Verbindung auch über ipv6 klappt? Den DNS AAAA-Eintrag habe ich gemacht. Muss ich in nginx etwas einstellen?

  • Kemo sagt:

    Hi, ein Update… Die Verbindung durch das heim Netz hat komischer weiße plötzlich funktioniert. Dann wäre Das zumindest hoffentlich abgehackt. Hui. Grüße

    • Jan sagt:

      Hi,

      also funktioniert nun alles bei dir?
      Wegen der Port-Freigabe in der Firewall: Port 5432 ist PostgreSQL. Diesen Port solltest du nicht in der Firewall freigeben, wenn es dafür keine besonderen Gründe gibt. Matrix muss auch ohne diese Port-Freigabe auskommen.

      Gruß,
      Jan

      • Kemo sagt:

        Ja, es funktioniert soweit, obwohl es hier und da Fehler gibt, das liegt aber wohl an meinem Anbieter.. Vielen Dank für die Unterstützung. VG.

  • olaf sagt:

    Ich habe ein ganz seltsames Problem. Sobald ich smtp_host auskommentiere startet der Server nicht mehr.

    • Jan sagt:

      Hi Olaf,

      dieser Fehler ist mir noch nicht untergekommen. Kommen in den Matrix Logs irgendwelche Hinweise, warum er sich hier aufhängt?

      Gruß,
      Jan

      • olaf sagt:

        Hallo Jan,

        das war eigene Dusseligkeit. Ich habe scheinbar aus versehen eine Raute gelöscht. Damit war denn eine Erklärung offen.

        Ich nutze den Nginx Proxy Manager (NPM) Ich konnte alle Anforderungen von dem Federation Tester erfüllen, nur der erste Punkt MatchingServerName will nicht, die Domains müssten aber richtig sein, schon x mal überprüft

  • olaf sagt:

    Hallo,

    vielleicht kann mir jemand helfen. Ich habe Matrix auf meinem Server zuhause Installiert. Da habe ich keine Feste Domain sondern leiter von meiner Domain der Cname auf einen Dyndns Adresse. Aufgerufen wir über matrix.meinedomain.de. Da funktioniert auch. Nur der FederationTester nörgelt über einen falsche Domain. Was kann ich da tun?

    • Olaf sagt:

      Das scheint mit DDNS zu tun zu haben. Bei der Installation habe als als Servername domain.de eingeben da ich ja möchte das die User unter user:domain.de erreichbar sind. Der Sever sonst ist unter unter matrix.domain.de ereichbar. Habe ich hier einen Denkfehler?

    • olad sagt:

      Hallo,

      ich habe es geschafft. Danke für die Anleitung Jan, eine von vielen, Danke für Deine Arbeit

      • Jan sagt:

        Hi Olaf,

        woran lag es nun konkret? Wäre evtl. auch für andere recht interessant, die das gleiche Problem haben.

        Gruß,
        Jan

        • Olaf sagt:

          Hallo Jan,

          ich habe meinen Haupdomain als Servername eingetragen. Ziel war es den Username nach diiesem Schema zu bekommen user:donain.de

          Dazu musste aber auf der Hauptdomain ein:
          location /.well-known/matrix {
          proxy_pass https://matrix.meindedonain.e/.well-known/matrix;
          proxy_set_header X-Forwarded-For $remote_addr;
          }

          eingetragen werden. Und schon war der Tester Grün

          • Jan sagt:

            Hi Olaf,

            ok, dann lag das echt an Haupt- und Sub-Domain. Mit der well-known Direktive hast du es ja nun aber hinbekommen. Danke für die Rückmeldung, ist evtl. auch für andere interessant, die eine ähnliche Konfiguration fahren wollen.

            Gruß,
            Jan

  • Verone sagt:

    Guten Tag, seit kurzem funktioniert mein Turn Server nicht mehr.

    Folgendes steht in der Log Datei:

    Oct 22 08:14:23 MatrixSynapse turnserver: 0: #012CONFIG ERROR: Empty cli-password, and so telnet cli interface is disabled! Please set a non empty cli-password!
    Oct 22 08:14:23 MatrixSynapse turnserver: 0: WARNING: cannot find private key file: /etc/letsencrypt/sub.domain.de/rsa/key.pem (1)
    Oct 22 08:14:23 MatrixSynapse turnserver: 0: WARNING: cannot start TLS and DTLS listeners because private key file is not set properly

    Wie kann diese Störung beseitigt werden? Viele Grüße.

    • Jan sagt:

      Hi,

      ist das das “homeserver.log”? Das sind nämlich originale Logs von coturn. Diese sagen, dass coturn die Dateien für das TLS-Zertifikat nicht finden kann und coturn deshalb nicht gestartet werden kann (zumindest nicht auf dem TLS-Port). Daher kontrolliere doch noch einmal die coturn Logs und schau nach, was da mit den Zertifikaten nicht passt (oder ob diese überhaupt noch da sind).

      Gruß,
      Jan

  • Verone sagt:

    Hi Jan,
    ich habe die Zertifikate geprüft, alles ist vorhanden.

    Das komische ist, dass alles von jetzt auf gleich nicht mehr funktioniert.
    Auf dem Server wurde allerhöchstens automatisch ein apt Update & upgrade durchgeführt.

    Kann es eventuell an der Fritz box liegen? Der wurde jedoch auch nur mal neu gestartet…

    Grüße

    Oct 16 16:17:43 MatrixSynapse turnserver[704]: 0:
    CONFIG ERROR: Empty cli-password, and so telnet cli interface is disabled! Please set a non empty cli-password!
    Oct 16 16:17:43 MatrixSynapse turnserver[704]: 0: WARNING: cannot find certificate file: turn_server_cert.pem (1)
    Oct 16 16:17:43 MatrixSynapse turnserver[704]: 0: WARNING: cannot start TLS and DTLS listeners because certificate file is not set properly
    Oct 16 16:17:43 MatrixSynapse turnserver[704]: 0: WARNING: cannot find private key file: turn_server_pkey.pem (1)
    Oct 16 16:17:43 MatrixSynapse turnserver[704]: 0: WARNING: cannot start TLS and DTLS listeners because private key file is not set properly
    Oct 16 16:17:43 MatrixSynapse turnserver[704]: 0: NO EXPLICIT LISTENER ADDRESS(ES) ARE CONFIGURED
    Oct 16 16:17:43 MatrixSynapse turnserver[704]: 0: ===========Discovering listener addresses: =========
    Oct 16 16:17:43 MatrixSynapse turnserver[704]: 0: Listener address to use: 127.0.0.1
    Oct 16 16:17:43 MatrixSynapse turnserver[704]: 0: Listener address to use: 192.168.178.157
    Oct 16 16:17:43 MatrixSynapse turnserver[704]: 0: Listener address to use: ::1
    Oct 16 16:17:43 MatrixSynapse turnserver[704]: 0: =====================================================
    Oct 16 16:17:43 MatrixSynapse turnserver[704]: 0: Total: 1 ‘real’ addresses discovered

    • Jan sagt:

      Hi Verone,

      das sieht so aus, als ob der coturn die Zertifikats-Dateien nicht mehr finden kann und dementsprechend nicht mehr auf dem TLS-Port gestartet werden kann.
      Schau dir mal die Logs von coturn an, hier sollten ähnliche Meldungen zu finden sein. Dann nachsehen, ob coturn die angemeckerten Dateien noch lesen kann (bzw. ob diese überhaupt noch vorhanden sind).

      Gruß,
      Jan

  • Robert sagt:

    Hast Du einen Tipp, wie ich bei Deiner Konfiguration einen User deaktivieren kann?

    • Jan sagt:

      Hi Robert,

      nicht nur einen Tipp, sondern ein komplettes Skript, siehe hier.
      Bitte beachten: Der User wird wirklich nur deaktiviert, nicht gelöscht. Bisher ist es nicht möglich User endgültig zu löschen. Das ist wohl ein Design-Konzept bzgl. Matrix, damit keine Identitäten wiederverwendet werden können.

      Gruß,
      Jan

  • Ariel sagt:

    Hallo Jan,

    Ich möchte damit beginnen, dass das von Ihnen geschriebene Tutorial eines der besten ist, das ich im Internet gesehen habe, herzlichen Glückwunsch und danke, ich konnte es ohne Probleme konfigurieren.

    Ich wollte Ihnen folgende Frage stellen: In meinem jetzigen Job haben sie mich gebeten, Matrix zu installieren, aber die Nachrichten sind nicht Punkt-zu-Punkt verschlüsselt. Der Geschäftsinhaber gibt an, dass Klartextnachrichten in Einzelgesprächen und in Gruppen sichtbar sein sollten.

    Gibt es eine Möglichkeit, dies durch Deaktivieren einer Option in der Konfiguration zu tun, oder müssen die Codezeilen der Synapse unbedingt geändert werden?

    Danke im Voraus für die Antwort.

    Tut mir leid, wenn die Übersetzung falsch ist, meine Muttersprache ist Spanisch. (Ich habe die Übersetzung mit dem Google-Übersetzer gemacht)

    • Jan sagt:

      Hola Ariel,

      du kannst bei Erstellen eines Raums angeben, ob dieser verschlüsselt sein soll oder nicht (dies kann dann aber auch nicht mehr verändert werden).
      Wenn Räume viele Teilnehmer haben, kann dies aber zu einer schlechteren Performance führen.

      We could also switch to English if this is easier for you.

      Gruß,
      Jan

      • Ariel sagt:

        Hallo Jan, danke für die schnelle Antwort,

        Ich werde jetzt versuchen, die Verschlüsselung am Anfang eines Raums zu wählen.

        Wie auch immer, denken Sie, dass es konfiguriert werden kann, dass die Konfiguration standardmäßig nicht verschlüsselt ist?

        • Jan sagt:

          Hi,

          ich denke, dass es eine Variable “encryption_enabled_by_default_for_room_type” gibt, die man in der homeserver.yaml auf “off” setzen kann, damit die Verschlüsselung nicht mehr standardmäßig aktiviert wird.
          Allerdings würde ich hier nochmal genau abwägen, warum die Verschlüsselung standardmäßig deaktiviert werden sollte. Ist eigentlich ein sinnvolles Feature.

          Gruß,
          Jan

          • Ariel sagt:

            Hallo Jan,

            Beginnen Sie mit der Feststellung, dass ich versucht habe, einen Raum zu erstellen, und wenn Sie die Option “End-to-End-Verschlüsselung aktivieren” aktivieren oder deaktivieren können, sollte dies gemäß der Anfrage des Inhabers der Firma, in der ich arbeite, leider standardmäßig sein.
            Außerdem haben die “privaten Räume”, die beim Starten einer direkten Konversation mit einer Person generiert werden, nicht die Option “End-to-End-Verschlüsselung aktivieren”, sodass sie nicht deaktiviert werden kann, und versuchen Sie Ihren Vorschlag, den Wert von “encryption_enabled_by_default_for_room_type” zu ändern = off “, theoretisch ist die Standardverschlüsselung bereits deaktiviert.
            Nachdem ich die Änderung vorgenommen habe, werden alle Konversationen verschlüsselt, wenn ich den Element-Client verwende. Ich habe im Internet nach weiteren Informationen zu diesen Daten gesucht und festgestellt, dass der Element-Client anscheinend standardmäßig die Möglichkeit hat, eine verschlüsselte private Raumnachricht zu senden.
            Verwenden Sie also einen Client, der keine Punkt-zu-Punkt-Verschlüsselung (Quaternion) verwendet, und beim Starten eines privaten Raums (dh einer direkten Nachricht an eine Person) werden die Nachrichten in der Datenbank nicht mehr verschlüsselt.
            Nachdem ich ein paar Nachrichten mit dem Quaternion-Client gesendet und den Client auf Element geändert habe und weiterhin Nachrichten gesendet habe, werden die unverschlüsselten Nachrichten weiterhin in der Datenbank angezeigt.
            Daher kann der Client, obwohl die Option “encryption_enabled_by_default_for_room_type = off” konfiguriert ist, verschlüsselte Nachrichten senden und die oben genannte Option nicht einhalten.
            Daher ist es effektiv der Element-Client, der die Nachrichten verschlüsselt, wenn eine Konversation mit einer Person eingeleitet wird (privater Raum).

            Gemäß den Anweisungen des Geschäftsinhabers sollte der Standardclient Element sein. Glauben Sie, dass ich durch die Installation meines eigenen Element-Servers diese Option ändern kann, um die Standardnachrichten auf meinem eigenen Server an NOT ENCRYPTED zu senden? oder was hätten Sie sonst noch für einen Vorschlag?

            In Bezug auf den Kommentar zu Ihrer vorherigen Nachricht bin ich auch nicht mit der Deaktivierung der Verschlüsselung einverstanden, da dies die Sicherheit dieses großartigen Tools ist, aber es handelt sich um Anfragen, die der Eigentümer des Unternehmens hat.

            Danke im Voraus für die Antwort.
            Grüße

          • Jan sagt:

            Hi,

            ja, der Client Element aktiviert immer die Verschlüsselung, wenn 1:1 Chats mit einzelnen Personen begonnen werden. Das lässt sich meiner Meinung nach auch nicht deaktivieren. Der einzige Workaround wäre hier, nie mit einer Person einen Chat zu beginnen, sondern immer einen neuen Raum auf zu machen (hier die Verschlüsselung zu deaktivieren) und dann eine weitere Person (oder auch mehrere) einzuladen.

            Sind hier auch evtl. mehrere Matrix-Server beteiligt? Denn wenn Federation ins Spiel kommt, kann man die Verschlüsselung natürlich nur auf dem eigenen Server kontrollieren, nicht aber auf dem entfernten Server.

            Gruß,
            Jan

  • Ariel sagt:

    Hallo Jan,

    Ich sage Ihnen, dass dieser Matrix-Server mit keinem anderen Matrix-Server involviert ist (so wird es derzeit gedacht).

    Eine zusätzliche Abfrage:
    Je mehr gleichzeitige Benutzer wir auf dem Server haben, desto größer sollten die physischen Eigenschaften des Servers sein, um die Arbeitslast zu unterstützen. Hat der Matrix-Server jedoch eine begrenzte Anzahl von Benutzern für seinen korrekten Betrieb? oder kann es für unbegrenzte Benutzer reibungslos funktionieren?

    Danke für die Antwort, Gruß

    • Jan sagt:

      Hi,

      der Matrix Synapse Server hat erst einmal keine Begrenzung der Benutzerzahlen. Es kann jedoch aus Performance-Gründen sinnvoll sein, dass gewisse Aktivitäten in sog. Workers ausgelagert wird (siehe hier). Hier gibt es dazu auch noch ein paar Hintergrundinformationen.
      Ich habe aber leider noch keine praktischen Erfahrungen, ab welcher User-Anzahl dies sinnvoll/empfehlenswert ist.

      Gruß,
      Jan

1 2

Schreibe einen Kommentar

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