Eigener matrix Server on ease

In diesem Post werd ich beschreiben, wie leicht (oder was es braucht) es ist, einen matrix server aufzusetzen. Genauer gesagt einen Synapse-Server.

Was ist matrix überhaupt

Bei matrix handelt es sich nicht um ein bestimmtes Programm, sondern mehr um eine spezifikation, wie die Client-Server Kommunikation für Kommunikation im Internet generell, also Sprach und Videotelefonate oder auch Chaträume, funktionieren soll. Man kann es als eine Art großes Upgrade zu IRC sehen. IRC ist auch auch kein Programm, sondern nur das Protokoll. Und es gibt viele unterschiedliche Client- und Server-Programme
Aber gut, wer diesen Blog-Post per Suchmaschine gefunden hat, der wird schon wissen, was das ist, also werd ich auch nicht genauer ins Detail gehen.

Funktionsweise

So, also wie funktionert das? Im Grund genommen besteht die installation aus zwei Komponenten: Dem Synapse Server an sich und einem Webserver, mit dem man einen Proxy für die korrekte SSL zur Verfügung stellen muss.
Ich werde beim Installations-Part näher auf mein Setup im speziellen eingehen, was ich schon mal in einem (noch nicht fertigen) Blog-Post erklärt habe.

Installation

Gliedern kann man das ganze in drei Punkte:

  1. Installation und Vorwissen für Snynapse
  2. Einrichten der korrekten SSL-Verschlüsselung mit Let’s Encrypt (Webserver-Proxy)
  3. Final touch mit funktionierender Federation

1. Installation und Vorwissen für Synapse

Synapse ist die eigentliche Server Komponente. Bezogen werden kann es unter Debian ganz einfach über eine Paketquelle, die hinzu gefügt werden muss. Genauere Anweisungen dazu hier. Danach lässt sich Synapse wie jedes andere Paket updaten und verwalten.
Wichtig bei der Installation ist jedenfalls, dass man in den Dialog für den Server-Namen auch wirklich die Domain eingibt, unter der der matrix-server anschließend erreichbar sein soll. Also für mich war das matrix.asagi.moe und ich habe asagi.moe eingegeben. Warum das kein großes Problem war, dazu später mehr.
Gut, hat man das so weit am Laufen, geht es weiter mit dem bearbeiten der der config Datei. Dort ist angeben, dass auf IPv6 und IPv4 Adressen gehört werden soll. Ich hatte jedoch das Problem, dass Synapse einfach die IPv4 Adressen nicht gebunden hat und dann nur einfach die gleichen Ports auf IPv6 auszumachen, auch bei Deaktivierung von IPv6 an allen Interfaces. Lösen konnte ich das Problem dann damit, einfach die IPv6 Bindings aus der config-Datei zu löschen und voila, correct bindings accomplished.
Wenn verifiziert ist, dass Synapse auch auf den korrekten IP-Adressen und Ports hört, kann man weiter machen mit dem Webserver

2. Einrichten der korrekten SSL-Verschlüsselung mit Let’s Encrypt

Wer schonmal einen Webserver mit Zertifikaten von Let’s Encrypt ausgestattet hat, der wird bei diesem Part keine Probleme haben, allerdings sollte man das vorher schon mal ausprobiert haben und das Prinzip verstanden haben, bevor man gleich mit Proxying anfängt.
Synapse bindet zwei Ports, das sind einmal der Port 8008 für normale Verbindungen (um den es hier auch geht) und der federation Port 8448, um den es im nächsten Punkt genauer geht. Im Gegensatz zum Port 8448 ist der Port 8008 allerdings nichts standardmäßig SSL-verschlüsselt. Und das direkt mit Synapse umzusetzen ist etwas unkomfortabel, da man jedes mal die Zertifikate neu in die config Datei übertragen müsste, wenn man ein neues beziehen muss von Let’s Encrypt. Empfholen wird daher das einrichten eines Web-Proxys mit ngnix oder Apache. Ich habe hier zu Apache gegriffen, da das erstens mein eigentlicher Webserver ist und zweitens ich mich mit Proxying und generell der Konfiguration schon auskenne unter Apache.
Mein Virtual Host für diese Anwedung sieht also folgendermaßen aus:

Listen 443
<VirtualHost *:443>
   DocumentRoot /var/www/matrix
   ServerName matrix.asagi.moe

   SSLEngine on

   ProxyPass "/" "http://localhost:8008/" retry=3
   ProxyPassReverse "/" "http://localhost:8008/" retry=3

   Include /etc/letsencrypt/options-ssl-apache.conf
   SSLCertificateFile /etc/letsencrypt/live/matrix.asagi.moe/fullchain.pem
   SSLCertificateKeyFile /etc/letsencrypt/live/matrix.asagi.moe/privkey.pem
</VirtualHost>

Jetzt nur noch den Virtual Host in Cloudflare eintragen, Zertifikate holem mit certbot und ausprobieren, ob unter https://matrix.asagi.moe irgendwas zu erreichen ist. And sure enough, it works. Die letzten drei Zeilen für die Zertifikate sind allerdings von certbot autogeneriert.
Wunderbar, was jetzt allerdings noch nicht funktioniert, ist das federating zwischen zwei oder mehr Servern, aber dazu mehr im nächsten Part

3. Final touch mit funktionierender Federation

Hier kommen wir wieder zu dem Fehler, den ich am Anfang gemacht hab und dem Port 8448.
Der Port 8448 heißt deswegen federation Port, weil auf ihn andere Server, eben keine Clients, verbinden. Er ist standartmäßig SSL verschlüsselt mit einem bei der Installatin automatisch generierten Zertifikat, also darum muss man sich nicht kümmern. Es wird auch empfohlen, diesen Port nicht extra mit einem Proxy zu versehen.
Was ich also gemacht hab in meiner Situation war, einfach diesen Port für die ganz Hauptdomain asagi.moe freizugeben. Also ab in das Menü der FritzBox und den Port frei geschalten.
Okay federation klappt nun, allerdings nur zum Teil, nämlich kann man von anderern Servern keine User auf dem Homeserver asagi.moe direkt kontaktieren, das geht nur umgekehrt, etwas unpraktisch, dachte ich mir.
Denn standartmäßig versuchen Clients, den Server Namen einfach als Domain aufzulösen und weil das auch die einfachste Version ist, habe ich mich dafür entschieden, das zu machen. Gebraucht hierfür wird ein SRV-DNS-Record für _matrix._tcp.asagi.moe, der auf asagi.moe:8448 zeigt. Dies sagt dem Client, dass der Service matrix auf der domain asagi.moe unter dem Port 8448 zu erreichen ist.
Und ja, das ist wirklich alles, was man braucht, wenn man mit Virtual Hosts und Cloudflare arbeitet, denn jetzt können mich auch Leute von anderen Servern finden.

Final thoughts

Einen Synapse Server aufzusetzen ist eine interessante Sache, wenn man anderen Messengern und Diesten nicht mehr so ganz traut und einfach mal etwas Service-Unabhängiges zu haben, das einfach funktioniert.
Matrix an sich finde ich eine wirklich sehr sehr gute Idee. Man sollte einen Standard haben für die Kommunikation im Internet und Nutzer von Telegram sollten Nutzer von WhatsApp einfach erreichen könnne. Warum ist so was nicht einfach möglich? Weil jeder seinen eigenen Standard benutzt, das soll sich mit matrix ändern. Und das untersütze ich sehr gern.
Wert also auch ein Hobbyadmin ist und in server Freizeit eigene Dienste auf seinem Server ausprobieren möchte, eine Kombination von Synapse und dem Client Riot ist eine super Alternative zu properitären Dingen, wie TeamSpeak oder Discord. Es ist etwas kniffelig zu installieren und setzt einige Dinge voraus, aber wenn einem kniffeln und neue Sachen lernen nichts ausmacht, ist das eine wirklich tolle Sache.
Zum Abschluss dieses Posts möchte ich noch anmerken, dass es unbedingt einfacher gemacht werden muss, so einen Webserver zu installieren. Ein großer Schritt in diese Richtung wäre das Zusammenarbeiten mit Let’s Encrypt, sodass Synapse sich selbst die Zertifikate für eine einfachere Einrichtung holen könnte. Und unbedingt eine Möglichkeit, das Verhalten von Synapse auch über eine Weboberfläche zu steuern, denn Anfänger lieben so was.
Jedem der dieser Post den Ansport gegeben hat, das mal auszuprobieren, wünsch ich viel Spaß und Erfolg und ich lass wieder von mir hören in einem weitern Post.