Eigener Matrix-Server im Kleinformat: continuwuity mit Föderation hinter Caddy

Matrix ist ein offenes Chat-Protokoll, ähnlich wie E-Mail: Jeder kann einen eigenen Server betreiben, und die Server tauschen Nachrichten untereinander aus. Wer einen eigenen Server hat, bekommt Adressen wie @name:sedv-lab.de und behält die Daten bei sich. Der bekannte Server Synapse braucht allerdings mehr Arbeitsspeicher, und für den Produktivbetrieb empfiehlt seine Doku PostgreSQL. continuwuity ist eine schlanke Alternative in Rust mit eingebauter Datenbank. Diese Anleitung richtet continuwuity hinter Caddy ein, legt die Adressen auf die Hauptdomain, prüft die Föderation mit dem offiziellen Testwerkzeug und zeigt eine Falle im Caddyfile, die alle Anfragen mit 404 beantwortet.

Dies ist Teil 14 der Reihe „Server im Netz“. Als Beispiel dient ein netcup-VPS mit Ubuntu und Docker, auf dem Caddy die Domain sedv-lab.de mit HTTPS ausliefert. Die Website aus Teil 5 liegt dort hinter Anubis aus Teil 6.

Voraussetzungen

• Der VPS aus Teil 4 mit Caddy im Host-Netz und Docker
• Ein Name für den Server, im Beispiel matrix.sedv-lab.de, und die Möglichkeit, unter der Hauptdomain zwei Pfade weiterzuleiten
• Ein Matrix-Client wie Element für den Alltag

Servername und Delegation

Matrix trennt zwei Namen. Der Servername steht in jeder Adresse, hier sedv-lab.de. Der Server selbst darf unter einem anderen Namen laufen, hier matrix.sedv-lab.de. Wer wo erreichbar ist, verraten zwei kleine JSON-Dateien unter https://sedv-lab.de/.well-known/matrix/: server für andere Server und client für Apps. continuwuity liefert beide selbst aus, Caddy muss nur diese Pfade an continuwuity weiterreichen. Der Servername lässt sich später nicht mehr ändern, ohne die Datenbank neu anzulegen. Wählen Sie ihn also bewusst.

Schritt 1: continuwuity einrichten

Die Konfiguration als etc/continuwuity.toml:

[global]
server_name = "sedv-lab.de"
database_path = "/var/lib/continuwuity"
address = ["127.0.0.1"]
port = 8008
allow_registration = true
registration_token_file = "/etc/continuwuity/reg-token"
allow_federation = true
trusted_servers = ["matrix.org"]
new_user_displayname_suffix = ""

[global.well_known]
client = "https://matrix.sedv-lab.de"
server = "matrix.sedv-lab.de:443"

allow_registration zusammen mit einem Token heißt: Registrieren kann sich nur, wer das Token kennt. Das Token liegt in einer eigenen Datei, erzeugt etwa mit openssl rand -hex 16 und mit chmod 600. new_user_displayname_suffix setzen wir leer, denn laut Beispielkonfiguration hängt continuwuity neuen Benutzern sonst ein Flaggen-Symbol an den Anzeigenamen.

Die compose.yaml:

services:
  continuwuity:
    image: forgejo.ellis.link/continuwuation/continuwuity:v26.9.1
    container_name: continuwuity
    restart: unless-stopped
    network_mode: host
    environment:
      CONTINUWUITY_CONFIG: "/etc/continuwuity/continuwuity.toml"
    volumes:
      - ./etc:/etc/continuwuity:ro
      - ./data:/var/lib/continuwuity

docker compose up -d
docker logs continuwuity 2>&1 | tail -15

Beim ersten Start begrüßt continuwuity mit einem Hinweis: Den ersten Benutzer legen Sie mit einem einmaligen Token an, das im Log steht. Erst danach gilt das Token aus der Datei, vorher lehnte continuwuity es im Test mit Invalid registration token ab. Eine Zeile ERROR zur Adresse 127.0.0.1 in Docker erscheint ebenfalls beim Start. Sie warnt davor, dass der Server im Container nur auf Loopback lauscht, mit network_mode: host ist das gewollt.

Verifizieren: Im Log steht Welcome to Continuwuity 26.9.1 mit dem Einmal-Token, ss -tlnp | grep 8008 zeigt den Port nur auf 127.0.0.1.

Schritt 2: Caddy, und die Falle mit respond

Für matrix.sedv-lab.de sollen nur die Matrix-Pfade an continuwuity gehen, alles andere eine 404 bekommen. Der erste Versuch sah so aus und lieferte für jede Anfrage 404:

matrix.sedv-lab.de {
	reverse_proxy /_matrix/* 127.0.0.1:8008
	respond 404
}

Caddy bearbeitet Direktiven nicht in der Reihenfolge, in der sie im Caddyfile stehen, sondern in einer festen Reihenfolge, und darin kommt respond vor reverse_proxy. Die 404 griff also zuerst. Mit handle-Blöcken ist die Reihenfolge eindeutig:

matrix.sedv-lab.de {
	import sicher
	@matrix path /_matrix/* /_continuwuity/*
	handle @matrix {
		reverse_proxy 127.0.0.1:8008
	}
	handle {
		respond 404
	}
}

Im Block der Hauptdomain kommen die Pfade für die Delegation dazu. Caddy sortiert die Weiterleitung mit Pfad-Matcher vor die allgemeine Weiterleitung an Anubis:

sedv-lab.de {
	...
	@matrix path /.well-known/matrix/*
	reverse_proxy @matrix 127.0.0.1:8008
	...
}

Anubis lässt /.well-known/ ohnehin durch, mit diesem Eintrag erreichen die Anfragen Anubis aber gar nicht erst.

curl -s https://sedv-lab.de/.well-known/matrix/server
curl -s https://matrix.sedv-lab.de/_matrix/federation/v1/version

Verifizieren: Die erste Antwort lautet {"m.server":"matrix.sedv-lab.de:443"}, die zweite {"server":{"name":"continuwuity","version":"26.9.1 (046074b)"}}.

Schritt 3: Föderation prüfen

Matrix stellt mit dem Federation Tester ein Werkzeug bereit, das einen Server von außen so prüft, wie es andere Server tun. Sie geben dort den Servernamen ein, nicht den Namen des Hosts:

Beide Verbindungen meldeten „Success“, die Delegation über .well-known wurde erkannt. Dieselbe Prüfung gibt es als JSON unter https://federationtester.matrix.org/api/report?server_name=sedv-lab.de, dort steht dann "FederationOK": true.

Verifizieren: curl -s "https://federationtester.matrix.org/api/report?server_name=sedv-lab.de" | grep -o '"FederationOK":[a-z]*' liefert "FederationOK":true.

Schritt 4: Erster Benutzer und Abfragen über Server hinweg

Den ersten Benutzer haben wir über die Client-API registriert, mit dem Einmal-Token aus dem Log. Ein Client wie Element erledigt dasselbe über ein Formular. Die Antwort enthielt "user_id":"@lab:sedv-lab.de". Das Log meldete dazu @lab:sedv-lab.de has been invited to the admin room as the first user: Der erste Benutzer wird in den Admin-Raum eingeladen, über den sich der Server mit Befehlen verwalten lässt.

Eine Registrierung ohne Token beantwortet der Server mit Status 401 und dem Hinweis, dass der Schritt m.login.registration_token verlangt wird. Mit dem Token aus der Datei gelang danach ein zweiter Benutzer, ein falsches Token endete mit Invalid registration token. Mit dem Konto haben wir dann Abfragen gestellt, die der eigene Server bei matrix.org weiterleiten muss, und umgekehrt von matrix.org aus das eigene Profil abgefragt:

Das Profil eines Benutzers auf matrix.org kam beim ersten Mal nach 1,36 Sekunden, beim zweiten Mal nach 0,07 Sekunden aus dem Zwischenspeicher. Raumadressen und das Raumverzeichnis von matrix.org ließen sich ebenfalls abfragen. Von matrix.org aus war das Profil @lab:sedv-lab.de ohne Anmeldung abrufbar. Der Server brauchte dabei 32,1 MiB Arbeitsspeicher, die Datenbank belegte 61 MB.

Große öffentliche Räume wie #matrix:matrix.org haben über tausend beteiligte Server. Ein Beitritt lädt den Raumzustand mit allen Mitgliedern nach. Rechnen Sie dann mit deutlich mehr Speicher und Rechenzeit als in diesem Test.

Verifizieren: curl -s https://matrix.org/_matrix/client/v3/profile/%40NAME%3Asedv-lab.de liefert den Anzeigenamen Ihres Benutzers.

Typische Fehler

Meldung oder Beobachtung	Ursache und Lösung
Jede Anfrage an den Matrix-Host liefert 404	respond läuft vor reverse_proxy. Mit handle-Blöcken arbeiten, Schritt 2.
Federation Tester: Non-200 response 404 from remote server	Die Föderations-Pfade erreichen continuwuity nicht. Caddy-Block prüfen.
Invalid registration token	Beim ersten Benutzer gilt nur das Einmal-Token aus dem Log, danach das Token aus der Datei.
Apps finden den Server nicht	/.well-known/matrix/client fehlt oder wird von einer anderen Regel beantwortet. Mit curl prüfen.

Häufige Fragen

Warum nicht Synapse?

Synapse ist der Referenzserver mit dem größten Funktionsumfang, braucht aber mehr Speicher, und für den Produktivbetrieb empfiehlt die Doku PostgreSQL. Für einen kleinen Server mit wenigen Benutzern reicht continuwuity mit seiner eingebauten Datenbank.

Sind die Nachrichten verschlüsselt?

Element und andere verbreitete Clients verschlüsseln private Chats standardmäßig Ende zu Ende. Der Server speichert dann nur verschlüsselte Inhalte, Metadaten wie Teilnehmer und Zeitpunkte sieht er aber.

Kann ich Benutzer anderer Server einladen?

Ja, das ist der Sinn der Föderation. Benutzer von matrix.org oder anderen Servern können Räume auf Ihrem Server betreten und umgekehrt.

Fazit

continuwuity ist in wenigen Minuten eingerichtet und braucht kaum Ressourcen. Die Delegation über .well-known gibt den Benutzern Adressen auf der Hauptdomain, während der Server unter einem eigenen Namen läuft. Die einzige Hürde im Test war das Caddyfile: Wer Weiterleitung und 404 nebeneinander schreibt, bekommt nur 404. Mit handle und einem Token für die Registrierung steht ein eigener Matrix-Server, der mit dem Rest der Matrix-Welt spricht.

Weiterführende Anleitungen und Quellen

• Teil 4: Caddy als Eingangstür
• Teil 3: Domain fürs Lab verdrahten
• Teil 6: Anubis vor der Website
• Docker und Docker Compose auf Linux installieren
• Docker Compose absichern
• continuwuity
• continuwuity: Beispielkonfiguration v26.9.1
• Matrix Federation Tester
• Matrix-Spezifikation: Server-Erkennung
• Caddy: Reihenfolge der Direktiven