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: 126

  • Brucie sagt:

    Danke für den Artikel! Schönes Projekt, gerade während dem Lockdown – und bei den sich ändernden WA Bedingungen für den ein oder anderen eine schöne Alternative.

  • Tom sagt:

    Hallo Jan,

    Danke für diesen tollen Artikel.

    Ich nutze aktuell XMPP über einen „fremden“ Server um mit der Familie zu kommunizieren. Eigener Matrix-Server waere evtl. eine Alternative.

    Dies ist (aus meiner Erfahrung) nur der erste Schritt.
    Vielleicht kannst du in einem zweiten Artikel noch was zur Administration (Update, Userverwaltung) und Backup & Restore sagen.
    Evtl. auch was zu tun ist falls z.B. ein Unternehmen nicht an der Föderation teilnehmen will.

    Gruss
    Tom

    • Jan sagt:

      Hi Tom,

      zum Thema Matrix kommt denke ich noch mehr, ich arbeite da schon an Folgeartikeln.

      Gruß,
      Jan

      • Marc sagt:

        Hey Jan, richtig gut, was du machst, ich hab schon mehrere deiner Anleitungen benutzt. Reicht hierfür ein apt update && apt upgrade matrix-synapse-py3 aus?

        • Jan sagt:

          Hi Marc,

          ja, Updates werden hier automatisch über apt update && apt upgrade ausgeführt. Bisher hatte ich damit keinerlei Probleme. Nur die Web-Anwendung Element muss noch manuell upgedated werden, wenn diese auch auf dem System installiert ist.

          Gruß,
          Jan

          • Marc sagt:

            Super! Startet ein Update auch matrix-synapse neu, bzw. muss man etwas manuell machen? Ich würde das gerne mit unattended upgrades machen.

            Deinen Update Prozess für Element hab ich übrigens in ein Skript gepackt:
            localversion=$(cat /var/www/element/version)
            latestversion=$(curl –silent „https://api.github.com/repos/vector-im/element-web/releases/latest“ | jq -r .tag_name | sed ’s/^v//‘)
            if [ „$localversion“ = „$latestversion“ ]; then
            echo „No update for Element available.“
            else
            downloadlink=$(curl –silent „https://api.github.com/repos/vector-im/element-web/releases/latest“ | jq -r .assets[0].browser_download_url)
            mv /etc/nginx/conf.d/element.meinedomain.de.conf /etc/nginx/conf.d/element.meinedomain.de.conf_disabled
            service nginx reload
            mv /var/www/element /var/www/element_old
            wget $downloadlink
            tar -xf element-v$latestversion.tar.gz
            mv element-v$latestversion /var/www/element
            cp /var/www/element_old/config.json /var/www/element/config.json
            chown -R www-data:www-data /var/www/element
            mv /etc/nginx/conf.d/element.meinedomain.de.conf_disabled /etc/nginx/conf.d/element.meinedomain.de.conf
            service nginx reload
            rm element-v$latestversion.tar.gz
            rm -r /var/www/element_old
            fi

            So oder so ähnlich könnte man das in einen systemd service oder cronjob packen.

          • Jan sagt:

            Hi Marc,

            genau, weil das ja nur ein paar wenige Schritte sind, die auch immer gleich sind, kann man das gut automatisieren. Ich würde hier aber vermutlich kein „jq“ nutzen, da dies standardmäßig ja nicht installiert ist.

            Gruß,
            Jan

          • Marc sagt:

            Eine Frag hätt ich noch. Ich hab gesehen, dass du auf deinem Server eine Weiterleitung von matrix.domain.de auf domain.de eingebaut hast. Wenn ich in nginx rewrite oder redirect benutze verträgt sich das mit matrix-synapse gar nicht. Wie hast du das gemacht, dass man den nginx 404 nicht sieht, bzw. die Weiterleitung?

          • Jan sagt:

            Hi Marc,

            wo genau ist diese Weiterleitung denn gelistet? Ich finde sie gerade nicht.

            Gruß,
            Jan

          • Marc sagt:

            Achso, naja wenn ich im Browser matrix.decatec.de eingebe werd ich auf deine Hauptseite weitergeleitet. Wenn ich das bei mir ansteuere komme ich auf einen nginx error 404. Ich will den da weghaben. Deshalb dachte ich mir, du hast da vielleicht eine Weiterleitung bei dir eingebaut, wenn ich das bei mir probiere funktioniert der Matrix Server dann nicht mehr. Hast du eine Lösung dafür?

          • Jan sagt:

            Hi Marc,

            ach, das meinst du. Ja, ich habe da eine Weiterleitung auf meinen Blog eingerichtet. Ich wollte da auch keinen 404 Fehler haben. Da die Kommunikation mit dem Server aber nicht über die Domains selbst, sondern über _matrix, .well-known, usw. abläuft, ist dies auch kein Problem.
            Einige Matrix-Betreiber liefern über die Matrix-Domain dann einfach den Web-Client Element aus. Dies wird aber aus Gründen der Sicherheit nicht empfohlen.

            Gruß,
            Jan

  • Bernd sagt:

    Hallo Jan,

    ein super cooler Artikel und ein spannendes Projekt! Danke!
    ich hätte noch eine Frage, welche groben System-Voraussetzungen würdest du in einem VM Betrieb mit ca. 15 – 20 Nutzern empfehlen?
    (LXC / VM – auf einem Proxmox)

    Danke

    Gruß Bernd

    • Jan sagt:

      Hi Bernd,

      also als Systemvoraussetzung wird nur 1 GB RAM genannt (siehe hier). Ich würde hier aber minimal 4 GB RAM und 4 CPU Cores empfehlen, da sollte man auf der sicheren Seite sein.

      Gruß,
      Jan

      • Bernd sagt:

        Hallo Jan, danke für deine schnelle Antwort.

        Der Server schnurrt wie ein Kätzchen und braucht wirklich kaum Ressourcen
        mit ca. 15 Usern braucht dieser als LXC Ubuntu Container gerade mal 250 MB Ram und die CPU Auslastung ist im Schnitt bei gerade mal 3 % :D

        was ich aber aktuell nicht zum Laufen bekomme ist das federated Sharing und das telefonieren.

        müssen hierzu extra Ports nach draußen gelegt werden, oder müsste das nach deiner Anleitung direkt funktionieren?

        Ich betreibe den Matrix Server hinter einer OpnSense mit HA Proxy, port 80 und 332 habe ich nach draußen gelegt, bzw. sieht mein vHost so aus, da den SSL Teil die OpnSense übernimmt:

        server {
        listen 80 default_server;
        listen [::]:80 default_server;
        server_name matrix.ABCD.de 10.0.20.225;

        location / {
        proxy_pass http://localhost:8008;
        proxy_set_header X-Forwarded-For $remote_addr;
        }

        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;
        client_max_body_size 50M;
        }

        location /.well-known/matrix/server {
        return 200 ‚{„m.server“: „matrix.ABCD.de:443“}‘;
        add_header Content-Type application/json;
        }

        location /.well-known/matrix/client {
        return 200 ‚{„m.homeserver“: {„base_url“: „https://matrix.matrix.ABCD.de“}}‘;
        add_header Content-Type application/json;
        add_header „Access-Control-Allow-Origin“ *;
        }
        }

        Vielen Dank

        Gruß Bernd

        • Bernd sagt:

          Hallo, ein kleines Update, das telefonieren geht jetzt – ich habe einfach den TURN Server noch mal aufgesetzt.

          aber leider schlägt der Federation Test fehl:

          hier bekomme ich folgende Meldung:

          Connection Errors
          Non-200 response 503 from remote server
          No SRV Records

          und das ist der JSON Bericht:

          {
          „WellKnownResult“: {
          „m.server“: „matrix.ABCD.de:443“,
          „CacheExpiresAt“: 0
          },
          „DNSResult“: {
          „SRVCName“: „“,
          „SRVRecords“: null,
          „SRVError“: null,
          „Hosts“: {
          „matrix.ABCD.de“: {
          „CName“: „ABCD.de.“,
          „Addrs“: [
          „XX.XX:XX.XX“
          ],
          „Error“: null
          }
          },
          „Addrs“: [
          „XX.XX.XX.XX:443“
          ]
          },
          „ConnectionReports“: {},
          „ConnectionErrors“: {
          „XX.XX:XX.XX:443“: {
          „Message“: „Non-200 response 503 from remote server“
          }
          },
          „Version“: {
          „error“: „contents=[60 104 116 109 108 62 60 98 111 100 121 62 60 104 49 62 53 48 51 32 83 101 114 118 105 99 101 32 85 110 97 118 97 105 108 97 98 108 101 60 47 104 49 62 10 78 111 32 115 101 114 118 101 114 32 105 115 32 97 118 97 105 108 97 98 108 101 32 116 111 32 104 97 110 100 108 101 32 116 104 105 115 32 114 101 113 117 101 115 116 46 10 60 47 98 111 100 121 62 60 47 104 116 109 108 62 10] msg=Failed to GET JSON (hostname \“matrix.ABCD.de:443\“ path \“/_matrix/federation/v1/version\“): \u003chtml\u003e\u003cbody\u003e\u003ch1\u003e503 Service Unavailable\u003c/h1\u003e\nNo server is available to handle this request.\n\u003c/body\u003e\u003c/html\u003e\n code=503 wrapped=“
          },
          „FederationOK“: false
          }

          Danke

          Gruß Bernd

          • Jan sagt:

            Hi Bernd,

            wie gesagt, da wird am Proxy irgend etwas vermutlich nicht weitergeleitet. Wenn du einen HAProxy hast, dann kannst du dir übrigens den nginx vor Matrix Synapse sparen denke ich. Das macht das Setup dann weitaus wenig komplex, da hier ja nicht zwei Proxies durchlaufen werden.
            Link zur Konfiguration von HAProxy, siehe meine vorherige Antwort.

            Gruß,
            Jan

        • Jan sagt:

          Hi Bernd,

          da wird denke ich ein Request nicht ordentlich an dein Matrix-Backend weitergeleitet. Schau mal hier, da wird eine Proxy-Konfig für HAProxy genannt.
          Oftmals wird auch der Port 8448 als „Federation-Port“ eingerichtet. Ich habe mich in diesem Artikel allerdings dagegen entschieden, weil alles nur über Port 443 gehen soll.
          Mit coturn für die Telefonie wird das sicherlich ähnlich sein. Dazu gibt es hier eine Möglichkeit, wie man die (STUN-)Funktion am besten testen kann.

          Gruß,
          Jan

  • Horst Vogel sagt:

    Hallo Jan,
    für den Revers Proxy muss man ab der Version 1.29 folgendes beachten

    https://github.com/matrix-org/synapse/releases/tag/v1.29.0

    Note that synapse now expects an X-Forwarded-Proto header when used with a reverse proxy. Please see UPGRADE.rst for more details on this change.

  • stefan sagt:

    Hallo zusammen,

    besten Dank für die Anleitung.
    Bitte die nano /etc/matrix-synapse/homeserver.yml in yaml ändern.
    Danke

  • Thomas sagt:

    Hallo Jan,

    Ich habe bei 1blu einen vServer gemietet und streng nach der Anleitung installiert (denke ich jedenfalls) und hab’s auch schon mehrfach kontrolliert.
    Der Server selbst läuft, ich kann auch Nachrichten verschicken. Aber ich kann keine Videocalls oder VoiceCalls machen.
    Es klingelt beim Gegenüber, ich sehe, dass er andere annimmt und nach einpaar Sekunden kommt dann „…. hat den Anruf beendet. (Medienverbindung konnte nicht hergestellt werden)“
    Beim Federation-Tester kommt auch nur eine Success-Meldung. Ich weiss aber nicht warum. Es sollten doch zwei sein.
    Hast Du vielleicht ne Idee? Ich verzweifle langsam….

    • Jan sagt:

      Hi Thomas,

      beim Federation Tester gibt es nur zwei Success-Meldungen, wenn der Server sowohl per IPv4, als auch per IPv6 erreichbar ist. Wenn dieser z.B. nur über IPv4 erreichbar ist, dann wird es bei einer Meldung bleiben. Hier vermute ich also erst einmal kein Problem.
      Welchen STUN/TURN-Server hast du denn konfiguriert? Hier vermute ich eher die Probleme.
      Was sagen die Logs am Server?

      Gruß,
      Jan

      • Thomas sagt:

        Ich habe COTURN installiert.
        Aber der Tipp hat schon geholfen, danke. War ein Tippfehler.
        fullchaim.pem anstatt fullchain.pem

        Vielen Dank für die klasse Anleitung.

  • David sagt:

    Erstmal vielen Dank für diese ausführliche Anleitung!

    Leider hat sich bei mir ein Fehler eingeschlichen und ich finde ihn nicht …

    – Der Server Läuft mit Letsencrypt Zertifikat.
    – via http://www.ssllabs.com/ssltest/ bekomme ich ein A+ ausgestellt
    – via https://federationtester.matrix.org/ bekomme ich einmal SUCCESSE statt zweimal … nehme an das liegt daran das ich keine IP6 habe …

    Versuche ich mich via Element an zu melden deht sich ewicht das ‚Rädchen‘ vor „Synchronisiere…“ aber es passiert nichts. Nach einigen Minuten steht oben im Tab des Browser „Element [Offline]“.

    Schaue ich in die ‚matrix-synapse/homeserver.log‘ finde ich nach dem Loggin versuch dort die folgenden Zeilen:

    2021-04-03 16:43:23,636 – synapse.rest.client.v1.login – 212 – INFO – POST-43 – Got login request with identifier: {‚type‘: ‚m.id.user‘, ‚user‘: ‚@david:matrix.staron-it.de‘}, medium: None, address: None, user: None
    2021-04-03 16:43:24,254 – synapse.handlers.auth – 809 – INFO – POST-43 – Logging in user @david:matrix.staron-it.de on device KUEBHXKMYF
    2021-04-03 16:43:24,258 – synapse.access.http.8008 – 308 – INFO – POST-43 – – 8008 – {None} Processed request: 0.622sec/-0.000sec (0.610sec, 0.000sec) (0.001sec/0.007sec/5) 495B 200 „POST /_matrix/client/r0/login HTTP/1.0“ „“ [0 dbevts]

    Ich habe leider keinen Ansatz wo ich nach dem Fehler suchen soll.
    Für ein Tipp wäre ich sehr dankbar!!!

    Gruß David

    • Jan sagt:

      Hi David,

      beim Federation Test bekommst du nur eine Sucess-Meldung, wenn du nur IPv4 oder IPv6 hast. Das ist soweit korrekt.
      Beim Log kann ich allerdings keinen Fehler erkennen. Das sieht für mich nach einem erfolgreichen Login aus.
      Mit welchem Element-Client hast du das denn probiert? Mit dem „offiziellen“ Web-Client https://app.element.io/#/welcome oder mit was anderem (eigener Web-Client, App, etc.)?

      Ein erstmaliger Sync kann meiner Erfahrung nach schon mal ein paar Minuten dauern.

      Gruß,
      Jan

  • Peter sagt:

    Hallo und besten Dank für die Anleitung,
    wie kann ich den einen Benutzer wieder löschen.

    Hier kann man ja nur einen Benutzer anlegen aber nicht löschen.
    register_new_matrix_user -c /etc/matrix-synapse/homeserver.yaml http://localhost:8008

  • Werner sagt:

    Moin Jan,

    erstmal: super Anleitung wie immer.

    Ich habe ein Problem mit coturn und zwar vermute ich, dass der User, der den coturn Service startet den key nicht lesen kann der auf 600 mit dem Besitzer letsencrypt eingestellt sind.

    Die Fehlermeldung aus dem syslog ist(domain auf meinedomain.de geändert)

    Apr 19 00:23:34 v2202104127894150926 turnserver: 0: WARNING: cannot find private key file: /etc/letsencrypt/meinedomain.de/rsa/key.pem (1)
    Apr 19 00:23:34 v2202104127894150926 turnserver: 0: WARNING: cannot start TLS and DTLS listeners because private key file is not set properly

    Wie hast du das gelöst?

    • Jan sagt:

      Hi Werner,

      mach mal ein „chmod 644“ auf die pem-Datei. Danach sollte coturn nicht mehr meckern.

      Gruß,
      Jan

      • Werner sagt:

        Hallo Jan,

        ja das würde das Problem bestimmt lösen, aber ist das auch im Sinne des Erfinders? Dann könnten alle Benutzer den private key lesen, obwohl es nur der coturn user können muss?

        Viele Grüße
        Werner

  • Werner sagt:

    Hi Jan,

    ist das dann im SInne des Erfinders? Müsste nicht nur der coturn darauf Zugriff haben?

    Viele Grüße
    Hendrik

    • Jan sagt:

      Hi Hendrik,

      ich sehe da momentan keine einfache Lösung (außer eben das chmod). Vielleicht kann man per ACL dem User turnserver hier noch Berechtigungen erteilen.
      Wenn man acme.sh mit Root-Rechten aufruft, könnte man auch im Reload-Command ein Skript angeben, welches Dateien umkopiert/Berechtigungen setzt. Aber acme.sh sollte ja nicht als Root-User aufgerufen werden.

      Gruß,
      Jan

  • Steffen sagt:

    Hallo Jan,

    danke für deine Anleitungen. Ich schaue auch bei dir immer gern vorbei und probiere aus, was mich interessiert.

    Ein kleiner Hinweis von mir zum Thema location /.well-known/matrix/…

    Bei mir funktioniert es nur, wenn ich statt

    location /.well-known/matrix/…

    location ^~ /.well-known/matrix/…

    nehme. Ansonsten bekomme ich einen Fehler 403 beim Direktaufruf, bzw. einen Fehler im Federation Tester, weil er die Response nicht bekommt. Da sich sonst noch niemand dazu geäußert hat, gehe ich davon aus, dass es an meiner Konfiguration liegt. Aber vielleicht nutz ja jemand eine ähnliche Konfiguration und steht vor dem selben Problem. Dann hilft dieser Tipp.

    Das Ganze kann ganz einfach im Browser über https://matrix.meinedomain.de/.well-known/matrix/server getestet werden. Wenn dort nicht der Text nach return 200 zu sehen ist, kann auch der Federation Tester nichts lesen und es kommt zum Fehler.

    Die .well-known Files können nicht nur für die Umgehung der Nutzung von Port 8448 genutzt werden, sondern darüber sind auch noch weitere Voreinstellungen möglich. Wer das optisch sauber anlegen will mit Zeilenumbrüchen und Einrückungen, sollte die Dateien server und client vielleicht tatsächlich mit den Ordnern .well-known und matrix anlegen, analog zu .well-known von letsencrypt.
    Das virtuelle Erzeugen über „return 200“ im vhost funktioniert aber genauso gut. Ich hab die Optionen kommagetrennt komplett als Fließtext angelegt. Wie gesagt, dass ist nur für die Optik wichtig. Die Funktionalität ist davon nicht betroffen.

    Grüße

    Steffen

    • Jan sagt:

      Hi Steffen,

      warum das bei dir nur mit „^~“ im vHost funktioniert kann ich dir ehrlich gesagt nicht sagen. Aber da hast du ja schon die Lösung gefunden.
      Ansonsten danke für deine Hinweise, evtl. auch für andere interessant.

      Gruß,
      Jan

  • Samuel sagt:

    Hi,

    Ich bin etwas verwirrt wegen den unterschiedlichen Domains.
    Wenn ich matrix.xyz.de und für element.xyz.de benutze nehme ich dann für den coturn eine andere wie turn.xyz.de?

    Ich hänge beim Verständnis noch. Da nginx ja ein host erstellt wird um die Zertifikate einzubinden und erreichbar zu sein. Das brauch ich bei dem coturn dann nicht oder ist das der realm?

    Danke für deine Hilfe:)

    LG
    Sam

    • Jan sagt:

      Hi Sam,

      nginx behandelt HTTP(S)-Verbindungen. coturn läuft hier nicht über HTTP(s), sondern direkt über TCP/UDP (also quasi eine Schicht „weiter unten“).
      Daher brauchst du für den coturn auch keinen nginx vHost. Auf welcher Domain der coturn dann läuft, ist auch egal. Das kann die gleiche Domain sein, aber auch eine beliebige andere.

      Gruß,
      Jan

  • Daniel sagt:

    Hallo Jan,
    erstmal vielen herzlichen Dank für dieses tolle Tutorial! Wirklich richtig gut und informativ gemacht!

    Ich hänge jetzt jedoch an dem Problem, dass bei mir beim Versenden der Email (Smtp) der Fehler 500 auftaucht. Das Protokoll gibt aus, dass es sich dabei um einen TLS-Fehler handelt.
    Ich hatte das Problem auch schon mal gelöst – allerdings weiß ich nach dem Rebuit nicht mehr wie… irgendwo hatte ich noch „TLS 1.0“ oder so ähnlich eingefügt.

    Hättest du da einen Tipp für mich?
    Liebe Grüße
    Daniel

    • Jan sagt:

      Hi Daniel,

      soweit ich weiß, kann man bei Matrix selbst gar keine TLS-Version für SMTP einstellen.
      Ich habe dazu das hier gefunden: Hier liegt es allerdings an den verwendeten Modulen für den SMTP-Versand. Diese wurden mittlerweile upgedated und das Problem sollte sich damit erledigt haben.
      Auch wenn du die Stelle wiederfinden solltest, in der du die TLSv1.0 Option eingefügt hast: TLSv1.0 (und 1.1) sollten aus Sicherheitsgründen eh nicht mehr verwendet werden. Hier sollte man also mal besser beim Mail-Betreiber nachhaken, damit dieser mindestens TLSv1.2 unterstützt.

      Gruß,
      Jan

      • Daniel sagt:

        Hallo Jan,
        vielen Dank für den schnellen Support. Ich habe mich entschieden den Martix-Server neu aufzusetzen und er rennt jetzt wieder wie gewohnt. ;-)
        Danke dir und liebe Grüße
        Daniel

  • pf sagt:

    Hallo Jan,
    habe auch mal ein Server aufgesetzt und es funktioniert soweit auch alles.
    Meine Frage nun: Was bedeutet beim Test(https://federationtester.matrix.org) „No SRV Records“? Meine Subdomain habe ich per CNAME angelegt. Habe ich mit Einschränkungen zu rechen?

    Danke und Grüße
    pf

    • Jan sagt:

      Hi,

      der SRV-Record kann genutzt werden, um den Matrix-Endpunkt bekannt zu geben. Dies finde ich allerdings zu umständlich, so dass ich hier die alternative Methode mittels Well-Known-URL genutzt habe, also location /.well-known/matrix/server { ... }
      Hier gibt es dann beim Federation Tester bisher auch keine Probleme.

      Gruß,
      Jan

  • Simon sagt:

    Moin Jan,

    Danke für deine Anleitung.
    Bei ich habe noch zwei Fragen dazu:

    1. Wenn ich den Federation Tester verwende löst er meine matrix Domain als IP auf und versucht diese mit Port 8448 zu erreichen welche nicht freigegeben ist.
    Get „https://XXX.XXX.XXX.XXX:8448/_matrix/key/v2/server“: context deadline exceeded (Client.Timeout exceeded while awaiting headers)
    Wenn ich die URL mit der richtigen Domain im Browser aufrufe klappt es.
    Hast du eine Idee woran das liegt?

    2. Ich habe ebenfalls das Problem, dass der Turn Server nicht richtig läuft. Ich bekomme nach dem Anruf direkt die Meldung, dass der Medienserver nicht erreichbar ist. Hängen diese Fehler vielleicht zusammen?

    Grüße,
    Simon

    • Jan sagt:

      Hi Simon,

      das erste Problem liegt vermutlich an der nginx-Konfiguration. Im Artikel habe ich ja einen Weg gewählt, dass dies nicht über den „Federation-Port“ (8448), sondern nur über den normalen HTTPS-Port (443) geht. Hier sind dann die well-known location-Blöcke ausschlaggebend.

      Was den coturn angeht: Hier kann es an vielen Stellen haken. Hier würde ich zunächst mal auf dieser Seite testen, ob der coturn von außen richtig erreichbar ist. Hier muss dann für die STUN-URI „stun:meinedomain.de:5349“ beim „Gather candidates“ mindestens ein „srflx“-Paket mitkommen. Wenn dies nicht der Fall ist und der coturn Server-seitig aber korrekt eingerichtet ist, dann blockt hier vermutlich noch eine Firewall o.ä.

      Gruß,
      Jan

      • Simon sagt:

        Moin Jan,
        Vielen Dank für die schnelle Antwort.
        Das ist es ja eben. Die nginx Konfiguration ist gesetzt. Die locations funktionieren für mich auch problemlos, wenn ich diese im Browser aufrufe.
        Nur der Federation Tester probiert es trotzdem via port 8448

        Der Turnserver läuft soweit. Er ist auch erfolgreich für einen Jitsiserver im Einsatz. Es ist tatsächlich die Lokale Firewall auf dem Server die blockt.
        Wir haben den Turn ausschließlich via tcp Port 443 laufen. Komischerweise blockt uns die Firewall bei eingeschaltetem Zustand trotz dementsprechender Freigaben. Bei deaktivierter Firewall funktioniert alles einwandfrei.

        LG Simon

        • Jan sagt:

          Hi Simon,

          leider kann ich das Verhalten des Federation Testers nicht nachvollziehen. Eigentlich sollte er „merken“, dass auf Port 8448 nichts läuft und daher die well-known-URLs durchprobieren. Das sollte er dann finden und diese dann auch nutzen.
          Hast du in der homeserver.yaml irgend etwas konfiguriert, was Port 8448 nutzt?

          Wenn die Firewall den coturn blockt, dann muss man meist recht lange suchen. Ich kenne leider nicht viele Firewalls, habe aber die Vermutung, dass einige (z.B. Sophos) hier eine Art Deep Package Inspection vornehmen. Die Clients liefern durch STUN ja ihre externe Internet-IP. Hier könnte es sein, dass die Firewall dies als schützenswerte Information auswertet und daher entsprechende Pakete blockiert. Ist aber nur so eine Vermutung.

          Gruß,
          Jan

          • Simon sagt:

            Moin Jan,

            Nein gar nichts. Es horcht auch auf dem ganzen Server nichts auf Port 8448

            Setsam an der Sache ist, auch wenn ich den Coturn auf dem gleichen Server wie das Matrix installiere blockt die lokale Firewall mich auch.
            Netzwerk analysen welche Ports zwischen den Server geöffnet und geschlossen werden haben leider auch noch keine Erkenntnis gebracht.
            Mit Jitsi funktioniert der Coturn einwandfrei auch via tcp port 443.

            Ich dank dir schonmal für deine Hilfe.

            Gruß,
            Simon

          • Jan sagt:

            Hi Simon,

            schau im Federation Tester mal den rohen Output als JSON an. Steht hier irgend etwas bei „WellKnownResult“? Oder wird hier auch irgendwo der Port 8448 aufgeführt.

            Zu Coturn „auf dem gleichen Server“: Die Kommunikation zwischen coturn und der Server-Anwendung (Matrix/Jitsi) ist fast schon nebensächlich. Hier geht es v.a. um die Kommunikation zwischen den Clients – genauer gesagt, dass sich diese über NAT Grenzen hinweg „finden“ können.
            Eine detailliertere Anleitung bzgl. Matrix/coturn ist hier zu finden. Vielleicht nochmal querlesen.

            Gruß,
            Jan

          • Simon sagt:

            Moin Jan,

            Ich hatte ein Chain Issue im Zertifikat. Dies ist nun behoben. Die Ausgabe des Testers ist jetzt:
            Got 0 connection report. This usually means at least one error happened.

            In der JSON wird mir unter WellKnown Result
            m.server: „meine.domain.de:443“
            CacheExpiresAT: 0
            angezeigt.

          • Jan sagt:

            Hi Simon,

            dieses „Got 0 connection report“ kommt eigentlich nur dann, wenn er gar keine Matrix Instanz „erkennen“ kann. Sicher, dass da nicht noch was andere mit kaputt gegangen ist?

            Gruß,
            Jan

  • blaubaer sagt:

    danke für die anleitung.

    erste mal einen cloud server in der hand gehabt und einen server aufgesetzt. hat alles geklappt.

    war eine gute lernerfahrung – vorallem weil du oft beschrieben hast was eigentlich passiert. danke!

  • Marc sagt:

    Hey, ich hab ein bisschen Nachforschung betrieben und bin auf folgende Artikel hier gestoßen:
    https://www.hackea.org/notas/matrix.html
    https://gist.github.com/maxidorius/5736fd09c9194b7a6dc03b6b8d7220d0
    Hast du das auch verfolgt? Hat sich daran mittlerweile was geändert?
    Hab dazu im selben Artikel nur das hier gefunden: https://www.matrix.org/blog/2019/09/27/privacy-improvements-in-synapse-1-4-and-riot-1-4
    Sehr vertrauenswürdig scheint matrix damit nicht zu sein. Sehr seltsam was da abgeht.

    • Jan sagt:

      Hi,

      ich habe die Artikel mal überflogen und vieles von den „Findings“ ist hier schon recht alt. Eine neuere Liste scheint das hier zu sein. Hier wird aber fast ausschließlich auf die DSGVO verwiesen. Das ganze hat dann wohl noch weitere Kreise gezogen (z.B. hier).
      Irgendwie ist das ganze wohl fast schon wie ein Kleinkrieg ausgeartet. Mittlerweile scheinen sich die Wogen aber wieder geglättet zu haben.

      Gruß,
      Jan

  • Andreas sagt:

    Moin! acme.sh verwendet seit v3.0.0 ZeroSSL als default CA. Da „darf“ man dann zunächst einen Account anlegen. Wenn man weiterhin letsencrypt als CA verwenden möchte, muss die Option „–server letsencrypt“ im acme.sh Befehl angefügt werden.

    • Jan sagt:

      Hi,

      danke, guter Hinweis! Ab 01.08.21 wird acme.sh tatsächlich ZeroSSL als Standard verwenden, siehe hier.
      Hier werde ich in den Artikeln wohl mal einen Hinweis dazu einbauen.

      Edit: So, nun für alle Artikel, die mit acme.sh arbeiten, einen Hinweis bzgl. ZeroSSL und Let’s Encrypt hinzugefügt.

      Gruß,
      Jan

  • Lars sagt:

    Hi,

    erstmal danke für die sehr ausführliche Anleitung! Ich habe allerdings ein Problem beim Federation Test: Wenn ich meine Domain matrix.domain.de eingebe, erhalte ich einen MatchingServerName-Error.

    „It is possible that the MatchingServerName error below is caused by you entering the wrong URL in the federation tester, not because there is an actual issue with your federation. You should enter the server name into the Federation Tester, not the location where your server is. The server name is the public facing name of your server that appears at the end of usernames and room aliases.“

    Ich wüsste allerdings nicht, welche Einstellung ich vergessen haben sollte… Meine Hauptdomain (domain.de) läuft auf einen anderen Server. Ist das ggf. ein Problem an der Stelle?

    • Jan sagt:

      Hi Lars,

      sieht so aus, als ob das mit der Domain-Konfiguration etwas nicht passt. Ich habe die Domains auch bei einem anderen Anbieter als den Server selbst. Aber wenn du A- und AAAA-Record auf den „richtigen“ Server zeigen lässt, sollte dieses Problem eigentlich behoben sein.

      Gruß,
      Jan

  • Thorsten sagt:

    Hallo Jan,

    vielen Dank für das tolle Tutorial und ganz besonders für das regelmäßige zeitnahe aktualisieren!

    meine Anwendung des Tutorials gerät erstmals bei folgendem Befehl als user letsencrypt aus der Spur:
    acme.sh –set-default-ca –server letsencrypt (not found)

    acme.sh wurde dabei nämlich nicht im Verzeichnis /home/letsencrypt angelegt sondern in einem Unterverzeichnis .acme.sh

    deshalb sieht mein Befehl so aus:
    .acme.sh/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“

    er bringt diese Meldungen und am Ende eine Fehlermeldung:
    [Mo 28. Jun 18:59:38 CEST 2021] Your cert is in /home/letsencrypt/.acme.sh/matrix.MEINEDOMAIN.de/matrix.MEINEDOMAIN.de.cer
    [Mo 28. Jun 18:59:38 CEST 2021] Your cert key is in /home/letsencrypt/.acme.sh/matrix.MEINEDOMAIN.de/matrix.MEINEDOMAIN.de.key
    [Mo 28. Jun 18:59:38 CEST 2021] The intermediate CA cert is in /home/letsencrypt/.acme.sh/matrix.MEINEDOMAIN.de/ca.cer
    [Mo 28. Jun 18:59:38 CEST 2021] And the full chain certs is there: /home/letsencrypt/.acme.sh/matrix.MEINEDOMAIN.de/fullchain.cer
    [Mo 28. Jun 18:59:39 CEST 2021] Installing cert to:/etc/letsencrypt/matrix.MEINEDOMAIN.de/rsa/cert.pem
    .acme.sh/acme.sh: Zeile 5483: /etc/letsencrypt/matrix.MEINEDOMAIN.de/rsa/cert.pem: Datei oder Verzeichnis nicht gefunden

    ebenso bei den ECDSA-Zertifikaten:

    .acme.sh/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“

    [Mo 28. Jun 19:02:00 CEST 2021] Your cert is in /home/letsencrypt/.acme.sh/matrix.MEINEDOMAIN.de_ecc/matrix.MEINEDOMAIN.de.cer
    [Mo 28. Jun 19:02:00 CEST 2021] Your cert key is in /home/letsencrypt/.acme.sh/matrix.MEINEDOMAIN.de_ecc/matrix.MEINEDOMAIN.de.key
    [Mo 28. Jun 19:02:00 CEST 2021] The intermediate CA cert is in /home/letsencrypt/.acme.sh/matrix.MEINEDOMAIN.de_ecc/ca.cer
    [Mo 28. Jun 19:02:00 CEST 2021] And the full chain certs is there: /home/letsencrypt/.acme.sh/matrix.MEINEDOMAIN.de_ecc/fullchain.cer
    [Mo 28. Jun 19:02:00 CEST 2021] Installing cert to:/etc/letsencrypt/matrix.MEINEDOMAIN.de/ecc/cert.pem
    .acme.sh/acme.sh: Zeile 5483: /etc/letsencrypt/matrix.MEINEDOMAIN.de/ecc/cert.pem: Datei oder Verzeichnis nicht gefunden

    Der nächste Neustart von nginx nach den folgenden edits schlägt dann natürlich fehl.

    irgendeine Idee, was schief lief?

    Herzlichen Dank und viele Grüße
    Thorsten

  • Thorsten sagt:

    Hallo Lars,
    ich nochmal.
    ich habe die acme.sh (Version 3.0.0 aus meiner Installation) mit einer 2.9.0 von https://fossies.org/linux/acme.sh/acme.sh überschrieben, die befehle mit –force nochmal abgesetzt und nun läuft es. Ist die 3.0.0 buggy oder hab ich was falsch gemacht?
    Viele Grüße!
    Thorsten

    • Jan sagt:

      Hi Thorsten,

      bevor du „acme.sh“ direkt als Befehl nutzen kannst, bitte einmal mit dem letsencrypt-User ab- und wieder anmelden. acme.sh --set-default-ca --server letsencrypt sollte danach funktionieren.
      Die Version 3.0.0 ist eigentlich nicht buggy, hast du vor dem Generieren der Zertifikate auch die Verzeichnisse „…/rsa“ und „…/ecc“ angelegt und mit den entsprechenden Rechten ausgestattet? Denn wenn diese Verzeichnisse nicht da sind, dann schlägt das Kommando fehlt.

      Gruß,
      Jan

      • Thorsten sagt:

        Hallo Jan,

        ich hab in meinem Installationsprotokoll noch mal nachgelesen:

        Als erstes hatte ich die beiden „mkdir“ Befehle tatsächlich glatt überlesen und nicht ausgeführt.
        Danach hatte ich das Skript gegoogelt und ausgetauscht. Und DANN hab ich fatalerweise nochmal per journalctl in das Fehlerprotokoll geschaut, die fehlenden Verzeichnisse bemerkt und angelegt. Danach lief die 2.9.0 fehlerfrei durch und ich dachte, es läge am Script. Die 3.0.0 läuft jetzt natürlich ebenfalls fehlerfrei. Typischer „war schon spät“ Fehler.
        Danke für’s nachschauen und kommentieren!

        Thorsten

  • Jörg sagt:

    Hallo Jan,
    schon mal mit dem Entfernen älterer Messages beschäftigt, falls ja, gibt es Empfehlungen?
    Gerade beim Räumen kommt schnell mal Einiges zusammen.

    Gruß,
    Jörg

    • Jan sagt:

      Hi Jörg,

      schau mal hier vorbei: Da habe ich schon ein paar Skripte erstellt, mit den ich per Cron hin und wieder Aufräumarbeiten durchführen kann. Bezieht sich momentan nur auf Medien, diese nehmen ja aber den meisten Platz in Anspruch.

      Gruß,
      Jan

  • Thorsten sagt:

    Hallo Jan, nachdem mit matrix nun alles läuft auf unserem Server, wollte ich coturn von unserem Signaling Server lokal auf den matrix Server holen. Ein simples „apt-get update && apt-get upgrade -V
    apt-get install coturn“ bringt:
    Paketlisten werden gelesen… Fertig
    Abhängigkeitsbaum wird aufgebaut.
    Statusinformationen werden eingelesen…. Fertig
    E: Paket coturn kann nicht gefunden werden.
    Hast Du eine Idee, was da schief liegt?

    lsb_release -a
    No LSB modules are available.
    Distributor ID: Ubuntu
    Description: Ubuntu 20.04.2 LTS
    Release: 20.04
    Codename: focal

    cat /etc/apt/sources.list
    # deb ftp://ftp.stratoserver.net/pub/linux/ubuntu bionic main restricted universe
    # deb-src ftp://ftp.stratoserver.net/pub/linux/ubuntu bionic main restricted universe
    # deb ftp://ftp.stratoserver.net/pub/linux/ubuntu bionic-updates main restricted universe
    # deb-src ftp://ftp.stratoserver.net/pub/linux/ubuntu bionic-updates main restricted universe
    # deb ftp://ftp.stratoserver.net/pub/linux/ubuntu bionic-security main restricted universe
    # deb-src ftp://ftp.stratoserver.net/pub/linux/ubuntu bionic-security main restricted universe

    deb http://archive.ubuntu.com/ubuntu focal main restricted # auto generated by ubuntu-release-upgrader
    deb http://archive.ubuntu.com/ubuntu focal-updates main restricted # auto generated by ubuntu-release-upgrader
    deb http://security.ubuntu.com/ubuntu focal-security main restricted # auto generated by ubuntu-release-upgrader

    Viele Grüße
    Thorsten

    • Jan sagt:

      Hi Thorsten,

      ich denke, du brauchst noch die „universe“-Pakete: sudo add-apt-repository universe
      Damit sollte der dann das Paket coturn auch finden können.

      Gruß,
      Jan

  • SionSavior sagt:

    Herzlichen Dank für die tolle Anleitung allerdings würde ich dich bitten ein bisschen mehr über die Administration zu erzählen vor allem was die AdminApi betrifft.
    Es gibt zwar viele Wiki Seiten dazu aber es ist nicht 100% schlüssig wie das nun zu verwenden ist. Ich meine 1. 2. 3. Beispiele wären da vielleicht ganz gut. Es muss ja nicht so etwas Umfangreiches sein wie deine tollen exemplarische Tutorials

    Ich fände das echt toll.
    Mit freundlichen Grüßen
    SS

    • Jan sagt:

      Hi,

      also einen Artikel habe ich dazu noch nicht geplant, aber wenn hier größeres Interesse besteht, dann kann ich das ja mal einplanen.
      Für den Anfang gibt es allerdings hier ein Repository, in dem ein paar Skripte enthalten sind, die die API von Synapse nutzen. Ist vielleicht ein guter Startpunkt.

      Gruß,
      Jan

  • Julian sagt:

    Hi Jan,
    das sieht ja super aus. Ich weiß schon was mein nächstes „kleines“ Projekt wird. Vielen Dank für deine Arbeit.
    Meinst du ich bekomme das auf einem RasPi4 zum laufen?.
    Ich habe auf einem RasPi4 noch einen Mumble Server laufen.
    Wird nur zum abentlichen Zocken al la „TeamSpeak“ genutzt.
    Meinst du ich kann versuchen den Matrix Server da mit drauf zu machen?
    Kannst du in der Hinsicht was sagen? Erfahrungen?

    Gruß
    Julian

    • Jan sagt:

      Hi Julian,

      also auf einem Raspi4 habe ich es noch nie probiert. Wenn die Matrix-Instanz nicht viele User haben sollte, könnte das aber klappen.
      Sag auf jeden Fall mal Bescheid, wenn du dein Projekt mal umgesetzt hast. Interessiert mich, ob das auf dem Raspi von der Performance her gut läuft.

      Gruß,
      Jan

1 2

Schreibe einen Kommentar

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