Matrix Synapse installieren: Unterschied zwischen den Versionen

Aus Hostsharing Wiki
Zur Navigation springen Zur Suche springen
Keine Bearbeitungszusammenfassung
 
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt)
Zeile 28: Zeile 28:


<syntaxhighlight lang="shell">
<syntaxhighlight lang="shell">
mkdir -p ~/synapse
mkdir -p ~/synapse
cd ~/synapse
cd ~/synapse
pipenv install --python 3.9.18
pipenv install --python 3.9.18
</syntaxhighlight>
</syntaxhighlight>


Zeile 36: Zeile 36:


<syntaxhighlight lang="shell">
<syntaxhighlight lang="shell">
cd ~/synapse
cd ~/synapse
pipenv shell
pipenv shell
pipenv install matrix-synapse[postgres]
pipenv install matrix-synapse[postgres]
</syntaxhighlight>
</syntaxhighlight>


Zeile 44: Zeile 44:


<syntaxhighlight lang="shell">
<syntaxhighlight lang="shell">
cd ~/synapse
cd ~/synapse
pipenv run python -m synapse.app.homeserver --server-name beispiel.de --config-path homeserver.yaml --generate-config --report-stats=no
pipenv run python -m synapse.app.homeserver --server-name beispiel.de --config-path homeserver.yaml --generate-config --report-stats=no
</syntaxhighlight>
</syntaxhighlight>


Zeile 55: Zeile 55:


<syntaxhighlight lang=yaml line>
<syntaxhighlight lang=yaml line>
    - port: 32801
- port: 32801
      tls: false
    tls: false
      bind_addresses: ['::1', '127.0.0.1']
    bind_addresses: ['::1', '127.0.0.1']
      type: http
    type: http
      x_forwarded: true
    x_forwarded: true
</syntaxhighlight>
</syntaxhighlight>


Postgres-Datenbank:
Postgres-Datenbank:
<syntaxhighlight lang=yaml line>
<syntaxhighlight lang=yaml line>
    database:
database:
      # The database engine name
    # The database engine name
      name: "psycopg2"
    name: "psycopg2"
      # Arguments to pass to the engine
    # Arguments to pass to the engine
      args:
    args:
        host: "localhost"
    host: "localhost"
        database: "xyz00_matrixdb"
    database: "xyz00_matrixdb"
        user: "xyz00_matrixuser"
    user: "xyz00_matrixuser"
        password: "meinPasswort"
    password: "meinPasswort"
        cp_min: 5
    cp_min: 5
        cp_max: 10
    cp_max: 10
</syntaxhighlight>
</syntaxhighlight>


Zeile 83: Zeile 83:
Lege dazu die folgende Datei an: ''~/.config/systemd/user/synapse.service'' mit dem Inhalt:
Lege dazu die folgende Datei an: ''~/.config/systemd/user/synapse.service'' mit dem Inhalt:
<syntaxhighlight lang="ini" line>
<syntaxhighlight lang="ini" line>
[Unit]
[Unit]
Description=Synapse
Description=Synapse
 
[Service]
[Service]
Type=simple
Type=simple
WorkingDirectory=%h/synapse
WorkingDirectory=%h/synapse
Environment=LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2
Environment=LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2
ExecStart=pipenv run python -m synapse.app.homeserver --config-path=%h/synapse/homeserver.yaml
ExecStart=pipenv run python -m synapse.app.homeserver --config-path=%h/synapse/homeserver.yaml
 
[Install]
[Install]
WantedBy=default.target
WantedBy=default.target
</syntaxhighlight>
</syntaxhighlight>
Durch Aufruf der folgenden Kommandos wird der Dienst aktiviert und gestartet:
Durch Aufruf der folgenden Kommandos wird der Dienst aktiviert und gestartet:
<syntaxhighlight lang="shell" lines>
<syntaxhighlight lang="shell" lines>
systemctl --user daemon-reload
systemctl --user daemon-reload
systemctl --user enable synapse.service
systemctl --user enable synapse.service
systemctl --user start synapse.service
systemctl --user start synapse.service
</syntaxhighlight>
</syntaxhighlight>
== Einrichten des Apache VHost ==
== Einrichten des Apache VHost ==
Zeile 106: Zeile 107:
folgende Konfiguration einfügen:
folgende Konfiguration einfügen:
<syntaxhighlight lang=apache line>
<syntaxhighlight lang=apache line>
DirectoryIndex disabled
DirectoryIndex disabled
RewriteEngine On
RewriteEngine On
RewriteBase /
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* http://localhost:32801%{REQUEST_URI} [NE,proxy]
RewriteRule .* http://localhost:32801%{REQUEST_URI} [NE,proxy]
RequestHeader set X-Forwarded-Proto "https"
RequestHeader set X-Forwarded-Proto "https"
</syntaxhighlight>
</syntaxhighlight>
== Well-Known unter beispiel.de ==
== Well-Known unter beispiel.de ==
Zeile 120: Zeile 121:
https://beispiel.de/.well-known/matrix/server
https://beispiel.de/.well-known/matrix/server
<syntaxhighlight lang=json line>
<syntaxhighlight lang=json line>
{
{
  "m.server": "matrix.beispiel.de:443"
    "m.server": "matrix.beispiel.de:443"
}
}
</syntaxhighlight>
</syntaxhighlight>
https://beispiel.de/.well-known/matrix/client
https://beispiel.de/.well-known/matrix/client
<syntaxhighlight lang=json line>
<syntaxhighlight lang=json line>
{
{
  "m.homeserver": {
    "m.homeserver": {
    "base_url": "https://matrix.beispiel.de"
        "base_url": "https://matrix.beispiel.de"
  },
    },
  "m.identity_server": {
    "m.identity_server": {
    "base_url": "https://vector.im"
        "base_url": "https://vector.im"
  }
    }
}
}
</syntaxhighlight>
</syntaxhighlight>
Für die muss noch der CORS-Header Access-Control-Allow-Origin "*" gesetzt werden, damit die Datei aus beliebigem Riot-Web im Browser abrufbar ist. Dazu in den Ordner .well-known/matrix/ folgende .htaccess anlegen:
Für die muss noch der CORS-Header Access-Control-Allow-Origin "*" gesetzt werden, damit die Datei aus beliebigem Riot-Web im Browser abrufbar ist. Dazu in den Ordner .well-known/matrix/ folgende .htaccess anlegen:
<syntaxhighlight lang=apache line>
<syntaxhighlight lang=apache line>
Zeile 141: Zeile 144:
</IfModule>
</IfModule>
</syntaxhighlight>
</syntaxhighlight>
Die Dokumentation dazu findet man unter https://matrix.org/docs/spec/server_server/r0.1.2#get-well-known-matrix-server und https://matrix.org/docs/spec/client_server/r0.5.0#get-well-known-matrix-client
Die Dokumentation dazu findet man unter https://matrix.org/docs/spec/server_server/r0.1.2#get-well-known-matrix-server und https://matrix.org/docs/spec/client_server/r0.5.0#get-well-known-matrix-client


Zeile 147: Zeile 151:
mit pipenv:
mit pipenv:
<syntaxhighlight lang=shell>
<syntaxhighlight lang=shell>
systemctl --user stop synapse.service
systemctl --user stop synapse.service
cd ~/synapse
cd ~/synapse
source .venv/bin/activate || pipenv shell
source .venv/bin/activate || pipenv shell
pipenv install update
pipenv install update
systemctl --user start synapse.service
systemctl --user start synapse.service
</syntaxhighlight>
</syntaxhighlight>
oder falls Synapse mit pip verwaltet wird:
oder falls Synapse mit pip verwaltet wird:
<syntaxhighlight lang=shell>
<syntaxhighlight lang=shell>
systemctl --user stop synapse.service
systemctl --user stop synapse.service
cd ~/synapse
cd ~/synapse
source venv/bin/activate
source venv/bin/activate
pip freeze > requirements.txt
pip freeze > requirements.txt
sed -i "s/==.*//g" requirements.txt
sed -i "s/==.*//g" requirements.txt
pip install -r requirements.txt --upgrade
pip install -r requirements.txt --upgrade
systemctl --user start synapse.service
systemctl --user start synapse.service
</syntaxhighlight>
</syntaxhighlight>
Falls Monit verwendet wird statt systemctl:
Falls Monit verwendet wird statt systemctl:


monit stop synapse
<syntaxhighlight lang=shell>
... updaten ...
monit stop synapse
monit start synapse
#... updaten ...
monit start synapse
</syntaxhighlight>


Wenn die Föderation für den Synapse Server aktiviert ist, kann mit dem [https://federationtester.matrix.org/ Matrix Federation Tester] die eigene Instanz auf die laufende Version geprüft werden. Als Server nicht matrix.example.org eingeben, sondern den öffentlichen Namen, wo auch die Benutzernamen drauf laufen, z.B. example.org
Wenn die Föderation für den Synapse Server aktiviert ist, kann mit dem [https://federationtester.matrix.org/ Matrix Federation Tester] die eigene Instanz auf die laufende Version geprüft werden. Als Server nicht matrix.example.org eingeben, sondern den öffentlichen Namen, wo auch die Benutzernamen drauf laufen, z.B. example.org
Zeile 190: Zeile 198:


<syntaxhighlight lang=shell>
<syntaxhighlight lang=shell>
$ xmlsec1  --version
$ xmlsec1  --version
xmlsec1 1.2.23 (openssl)
xmlsec1 1.2.23 (openssl)
</syntaxhighlight>
</syntaxhighlight>
Das Python-Paket pysaml2 installieren
Das Python-Paket pysaml2 installieren
<syntaxhighlight lang=shell>
<syntaxhighlight lang=shell>
cd ~/synapse
cd ~/synapse
pipenv shell
pipenv shell
pipenv install pysaml2
pipenv install pysaml2
</syntaxhighlight>
</syntaxhighlight>
In der homeserver.yaml die SAML-Direktiven einkommentieren, hier mit dem Beispiel eines SAML IdP unter https://login.beispiel.de/simplesaml/saml2/idp/metadata.php:
In der homeserver.yaml die SAML-Direktiven einkommentieren, hier mit dem Beispiel eines SAML IdP unter https://login.beispiel.de/simplesaml/saml2/idp/metadata.php:
<syntaxhighlight lang=yaml line>
<syntaxhighlight lang=yaml line>
# Once SAML support is enabled, a metadata file will be exposed at
# Once SAML support is enabled, a metadata file will be exposed at
# https://<server>:<port>/_matrix/saml2/metadata.xml, which you may be able to  
# https://<server>:<port>/_matrix/saml2/metadata.xml, which you may be able to  
# use to configure your SAML IdP with. Alternatively, you can manually configure
# use to configure your SAML IdP with. Alternatively, you can manually configure
# the IdP to use an ACS location of
# the IdP to use an ACS location of
# https://<server>:<port>/_matrix/saml2/authn_response.
# https://<server>:<port>/_matrix/saml2/authn_response.
#
#
saml2_config:
saml2_config:
  sp_config:
    sp_config:
    # point this to the IdP's metadata. You can use either a local file or
        # point this to the IdP's metadata. You can use either a local file or
    # (preferably) a URL.
        # (preferably) a URL.
    metadata:
        metadata:
      #local: ["saml2/idp.xml"]
        #local: ["saml2/idp.xml"]
      remote:
        remote:
        - url: https://login.beispiel.de/simplesaml/saml2/idp/metadata.php
            - url: https://login.beispiel.de/simplesaml/saml2/idp/metadata.php
</syntaxhighlight>
</syntaxhighlight>
Wichtig ist außerdem, dass die public_baseurl in der homeserver.yaml gesetzt ist, damit Synapse weiß, wie es erreichbar ist und dies in seine SP-Metadaten einbauen kann:
Wichtig ist außerdem, dass die public_baseurl in der homeserver.yaml gesetzt ist, damit Synapse weiß, wie es erreichbar ist und dies in seine SP-Metadaten einbauen kann:
Zeile 234: Zeile 246:
In der homeserver.yaml die Worker-Konfiguration aktivieren:
In der homeserver.yaml die Worker-Konfiguration aktivieren:
<syntaxhighlight lang=yaml line>
<syntaxhighlight lang=yaml line>
## Worker ##
## Worker ##
worker_app: synapse.app.homeserver
worker_app: synapse.app.homeserver
daemonize: true
daemonize: true
</syntaxhighlight>
</syntaxhighlight>
und dazugehörige Listener (Abschnitt listener:) aktivieren:
und dazugehörige Listener (Abschnitt listener:) aktivieren:
<syntaxhighlight lang=yaml line>
<syntaxhighlight lang=yaml line>
# The TCP replication port
# The TCP replication port
- port: 32892
- port: 32892
  bind_address: '127.0.0.1'
  bind_address: '127.0.0.1'
  type: replication
  type: replication
# The HTTP replication port
# The HTTP replication port
- port: 32893
- port: 32893
  bind_address: '127.0.0.1'
  bind_address: '127.0.0.1'
  type: http
  type: http
  resources:
  resources:
    - names: [replication]
  - names: [replication]
</syntaxhighlight>
</syntaxhighlight>
Funktionen, die Worker machen sollen, in der homeserver.yaml deaktivieren:
Funktionen, die Worker machen sollen, in der homeserver.yaml deaktivieren:
<syntaxhighlight lang=yaml line>
<syntaxhighlight lang=yaml line>
# disable federation sending here, use worker for it
# disable federation sending here, use worker for it
send_federation: False
send_federation: False
</syntaxhighlight>
</syntaxhighlight>
Dann Verzeichnis synapse/workers anlegen, darin federation_sender.yaml:
Dann Verzeichnis synapse/workers anlegen, darin federation_sender.yaml:
<syntaxhighlight lang=yaml line>
<syntaxhighlight lang=yaml line>
worker_app: synapse.app.federation_sender
worker_app: synapse.app.federation_sender
 
# The replication listener on the synapse to talk to.
# The replication listener on the synapse to talk to.
worker_replication_host: 127.0.0.1
worker_replication_host: 127.0.0.1
worker_replication_port: 32892
worker_replication_port: 32892
worker_replication_http_port: 32893
worker_replication_http_port: 32893
 
worker_daemonize: True
worker_daemonize: True
worker_pid_file: /home/pacs/xyz00/users/matrix/synapse/federation_sender.pid
worker_pid_file: /home/pacs/xyz00/users/matrix/synapse/federation_sender.pid
worker_log_config: /home/pacs/xyz00/users/matrix/synapse/federation_sender.log.config
worker_log_config: /home/pacs/xyz00/users/matrix/synapse/federation_sender.log.config
</syntaxhighlight>
</syntaxhighlight>
.monitrc um worker erweitern:
.monitrc um worker erweitern:
<syntaxhighlight lang=shell line>
<syntaxhighlight lang=shell line>
check process federation_sender with pidfile /home/pacs/xyz00/users/matrix/synapse/federation_sender.pid
check process federation_sender with pidfile /home/pacs/xyz00/users/matrix/synapse/federation_sender.pid
     start program "/bin/bash -c 'export VIRTUAL_ENV=$HOME/synapse/env && export PATH=$VIRTUAL_ENV/bin:$PATH && cd $HOME/synapse && synctl -w workers/federation_sender.yaml start'"
     start program "/bin/bash -c 'export VIRTUAL_ENV=$HOME/synapse/env && export PATH=$VIRTUAL_ENV/bin:$PATH && cd $HOME/synapse && synctl -w workers/federation_sender.yaml start'"
     stop program "/bin/bash -c '/bin/kill $( cat $HOME/synapse/federation_sender.pid )'"
     stop program "/bin/bash -c '/bin/kill $( cat $HOME/synapse/federation_sender.pid )'"
Zeile 277: Zeile 291:
Monit neu laden und synapse und federation_sender neustarten:
Monit neu laden und synapse und federation_sender neustarten:


monit reload
<syntaxhighlight lang=shell>
monit restart all
monit reload
monit restart all
</syntaxhighlight>


Nach Updates ebenfalls immer Hauptprozess und alle Worker neustarten
Nach Updates ebenfalls immer Hauptprozess und alle Worker neustarten


monit restart all
<syntaxhighlight lang=shell>
monit restart all
</syntaxhighlight>


== Sliding Sync Proxy ==
== Sliding Sync Proxy ==
Zum Zeitpunkt dieser Anleitung werden aktiv neue Element Anwendungen (Element X) und ein neues Syncverfahren entwickelt um Matrix performater und weniger ressourcenhungrig zu machen. Unterstützung hierfür findet sich noch(!) nicht nativ in Synapse, sondern wird mit einem dedizierten kleinen Proxy umgesetzt. Bei stärkerer Matrix Nutzung können die neuen Anwendungen besonders mobil schon eine große Entlastung sein – es sind allerdings noch nicht alle Matrix-Funktionen fertig eingebaut.
Zum Zeitpunkt dieser Anleitung werden aktiv neue Element Anwendungen (Element X) und ein neues Syncverfahren entwickelt um Matrix performanter und weniger ressourcenhungrig zu machen. Bei stärkerer Matrix Nutzung können die neuen Anwendungen besonders mobil schon eine große Entlastung sein.
 
=== Installation ===
Best practice ist auch hier wieder ein eigener User, sowie eigene Domain.
 
''Wir brauchen:''<br>
* eine PostgreSQL Datenbank
* einen freien internen http Port
* eine aktuelle sliding-sync Binary – [https://github.com/matrix-org/sliding-sync/releases diese kann hier bezogen werden]
 
''Verzeichnisstruktur''<br>
Es wird die folgende Struktur vorgeschlagen:
  mkdir -p .config/systemd/user config bin scripts
 
''Binary laden:''<br>
Mit den folgenden Befehlen kann die aktuelle Release erkannt, und von dieser das Binary heruntergeladen werden:
<pre bash>
export release=`curl -L https://api.github.com/repos/matrix-org/sliding-sync/releases/latest -s | jq -r '.tag_name'`
wget --show-progress -q -O $HOME/bin/syncv3 https://github.com/matrix-org/sliding-sync/releases/download/$release/syncv3_linux_amd64
</pre>
Nun sollte sich die Datei als <code>./bin/syncv3</code> wiederfinden.
 
=== Konfiguration ===
Wir legen eine Environment-Datei an. In diesem Beispiel: <code>config/config.env</code>. Dies sind die wichtigsten Einstellungen – bitte vor ausprobieren anpassen:
<pre environment>
SYNCV3_SECRET=$(cat $HOME/.secret)
SYNCV3_SERVER=https://matrix.meinedomain.de
SYNCV3_DB="user=xyz00_syncv3 dbname=xyz00_syncv3 sslmode=disable host=localhost password=sicherespasswort"
SYNCV3_BINDADDR=0.0.0.0:32804
SYNCV3_LOG_LEVEL=warn
# Prometheus
# SYNCV3_PROM=0.0.0.0:8882
</pre>
 
Jetzt fehlt noch das Secret, das wir oben aus einer Datei lesen lassen wollen. Das Secret darf nicht gelöscht werden. Andernfalls muss die Datenbank zurückgesetzt werden.
<pre bash>
echo -n "$(openssl rand -hex 32)" > $HOME/.secret
</pre>


=== .htaccess anpassen ===
<strong>Ende 2024 wurden grundlegende Funktionen direkt in Synapse implementiert. Der Proxy wird nicht länger weiterentwickelt und sollte deinstalliert werden (nicht vergessen die .well-known zurück zu ändern).</strong> Auch der 3rdparty Server [[Conduit]] bringt nativ Support für Sliding Sync.</strong>
Ähnlich wie für Synapse oben, scheint das Folgende direkt zu funktionieren:
<syntaxhighlight lang="apache">
DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* http://localhost:32804%{REQUEST_URI} [NE,proxy]
RequestHeader set X-Forwarded-Proto "https"
</syntaxhighlight>
 
=== Starten ===
In der Datei <code>~/.config/systemd/user/syncv3.service</code> schreiben wir den folgenden Inhalt:
 
<syntaxhighlight lang="ini" lines>
[Unit]
Description=Matrix SyncV3 Proxy
After=postgresql.service
 
[Service]
Type=simple
WorkingDirectory=%h
EnvironmentFile=%h/config/config.env
ExecStart=%h/bin/syncv3
 
[Install]
WantedBy=default.target
</syntaxhighlight>
 
Sicherheitshalber jetzt noch einmal <code>export XDG_RUNTIME_DIR=/run/user/$UID</code> damit wir systemd auch steuern können und dann: <code>systemctl enable --user --now syncv3</code>. Logs können beispielsweise mittels <code>journalctl --user -xefu syncv3</code> betrachtet werden.
 
=== Auffindbar machen ===
Moderne Anwendungen wie Element X erwarten automatisch zu erkennen, ob syncv3 Support vorhanden ist. Hierfür müssen wir die well-known für die Hauptdomain des Matrixservers ergänzen. Also den <code>server_name</code> des Synapse servers.
 
Konkret muss <code>/.well-known/matrix/client</code> auf das Folgende erweitert werden:
<syntaxhighlight lang="json" line start="4">
"org.matrix.msc3575.proxy": {
    "url": "https://syncv3.meinedomain.de"
}
</syntaxhighlight>


== Links ==
== Links ==

Aktuelle Version vom 18. November 2024, 18:28 Uhr

Der Matrix Server Synapse, der sogenannte 'Homeserver', ist aktuell die einzige vollständige serverseitige Implementierung des Matrix-Protokolls.


Work in Progress

Leider funktioniert die Server-zu-Server-Kommunikation von Synapse hinter dem Apache-Proxy mit den genannten Rewrite-Rules nicht. Bitten Sie dazu den Service, Ihren Apache VHost individuell für den Matrix Server anzupassen.


Synapse wird bei Hostsharing als eigener Daemon betrieben. Der Betrieb ist im Shared Hosting anmelde- und kostenpflichtig. Daher empfehlen wir für den Betrieb einen Managed Server.

Diese Anleitung beschreibt, wie man den Matrix-Homeserver Synapse auf der Managed Hosting Plattform von Hostsharing installieren kann. Dabei sind die User-IDs nach dem Schema @user:beispiel.de aufgebaut, der Homeserver an sich ist unter matrix.beispiel.de erreichbar.

Vorbereitungen

Mit Hilfe von HSAdmin werden angelegt:

  1. Ein User als Service-User mit /bin/bash als Shell, zum Beispiel Beispiel: xyz00-matrix
  2. Eine Domain mit xyz00-matrix als Domain-Administrator, zum Beispiel matrix.beispiel.de
  3. Einen Postgresql-User xyz00_matrixuser mit Passwort meinPasswort
  4. Eine Postgresql-Datenbank xyz00_matrixdb mit Datenbank-Owner xyz00_matrixuser

Verwendeter IP-Port für den Server-Dienst:

  1. Synapse: localhost:32801

Installation von Synapse

Installationsanleitung basierend auf https://matrix-org.github.io/synapse/latest/setup/installation.html#installing-as-a-python-module-from-pypi

Auf Debian Buster muss ein neueres Python, z.B. Python 3.9 installiert werden, siehe Eigenes Python mit pyenv installieren.

Als User xyz00-matrix" ein Python3 virtualenv mit Python 3.9 erstellen

mkdir -p ~/synapse
cd ~/synapse
pipenv install --python 3.9.18

Synapse und Postgres-Dependencies installieren

cd ~/synapse
pipenv shell
pipenv install matrix-synapse[postgres]

Initiale Konfiguration mit richtigem server-name "beispiel.de" generieren, außerdem im laufenden Betrieb keine Statistiken an Matrix.org senden

cd ~/synapse
pipenv run python -m synapse.app.homeserver --server-name beispiel.de --config-path homeserver.yaml --generate-config --report-stats=no

Konfiguration von Synapse

In die initial generierte Konfiguration muss noch die Port- und Datenbank-Konfiguration eingetragen werden:

Port: Innerhalb der listener-section den Port 8008 auf 32801 (wie initial definiert) ändern, alles andere beibehalten:

- port: 32801
    tls: false
    bind_addresses: ['::1', '127.0.0.1']
    type: http
    x_forwarded: true

Postgres-Datenbank:

database:
    # The database engine name
    name: "psycopg2"
    # Arguments to pass to the engine
    args:
    host: "localhost"
    database: "xyz00_matrixdb"
    user: "xyz00_matrixuser"
    password: "meinPasswort"
    cp_min: 5
    cp_max: 10

Starten der Dienste

Der Synapse-Dienst wird hier als Service-Unit im SystemD des Users eingetragen.

Lege dazu die folgende Datei an: ~/.config/systemd/user/synapse.service mit dem Inhalt:

[Unit]
Description=Synapse

[Service]
Type=simple
WorkingDirectory=%h/synapse
Environment=LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2
ExecStart=pipenv run python -m synapse.app.homeserver --config-path=%h/synapse/homeserver.yaml

[Install]
WantedBy=default.target

Durch Aufruf der folgenden Kommandos wird der Dienst aktiviert und gestartet:

systemctl --user daemon-reload
systemctl --user enable synapse.service
systemctl --user start synapse.service

Einrichten des Apache VHost

Die ~/doms/matrix.beispiel.de/.htaccess mit dem Editor der Wahl öffnen und folgende Konfiguration einfügen:

DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* http://localhost:32801%{REQUEST_URI} [NE,proxy]
RequestHeader set X-Forwarded-Proto "https"

Well-Known unter beispiel.de

Damit die User-Accounts das Format @user:beispiel.de haben, der Server aber unter matrix.beispiel.de erreichbar ist, müssen noch folgende zwei Dateien unter der Domain beispiel.de abgelegt werden:

https://beispiel.de/.well-known/matrix/server

{
    "m.server": "matrix.beispiel.de:443"
}

https://beispiel.de/.well-known/matrix/client

{
    "m.homeserver": {
        "base_url": "https://matrix.beispiel.de"
    },
    "m.identity_server": {
        "base_url": "https://vector.im"
    }
}

Für die muss noch der CORS-Header Access-Control-Allow-Origin "*" gesetzt werden, damit die Datei aus beliebigem Riot-Web im Browser abrufbar ist. Dazu in den Ordner .well-known/matrix/ folgende .htaccess anlegen:

<IfModule mod_headers.c>
  Header set Access-Control-Allow-Origin "*"
</IfModule>

Die Dokumentation dazu findet man unter https://matrix.org/docs/spec/server_server/r0.1.2#get-well-known-matrix-server und https://matrix.org/docs/spec/client_server/r0.5.0#get-well-known-matrix-client

Update von Synapse

mit pipenv:

systemctl --user stop synapse.service
cd ~/synapse
source .venv/bin/activate || pipenv shell
pipenv install update
systemctl --user start synapse.service

oder falls Synapse mit pip verwaltet wird:

systemctl --user stop synapse.service
cd ~/synapse
source venv/bin/activate
pip freeze > requirements.txt
sed -i "s/==.*//g" requirements.txt
pip install -r requirements.txt --upgrade
systemctl --user start synapse.service

Falls Monit verwendet wird statt systemctl:

monit stop synapse
#... updaten ...
monit start synapse

Wenn die Föderation für den Synapse Server aktiviert ist, kann mit dem Matrix Federation Tester die eigene Instanz auf die laufende Version geprüft werden. Als Server nicht matrix.example.org eingeben, sondern den öffentlichen Namen, wo auch die Benutzernamen drauf laufen, z.B. example.org

Ansonsten ist die laufende Version auch über die URL https://matrix.example.org/_synapse/admin/v1/server_version zu erfahren.

Element-Web

Element-Web ist aus Server-Seite eine rein statische html+javascript-Kombination, daher:

  • Account und Domain anlegen (separat von der Synapse-Domain)
  • aktuelles element-web release .tgz herunterladen
  • Symlink von htdocs-ssl auf entpacktes element-web-Verzeichnis
  • config.sample.json in config.json kopieren und Matrix-Homeserver-Einträge anpassen
  • Piwik aus config.json entfernen

SAML mit Synapse

Synapse unterstützt mit Version 1.1.0 SAML. Dazu wie folgt vorgehen:

Das Paket xmlsec1 muss installiert sein:

$ xmlsec1  --version
xmlsec1 1.2.23 (openssl)

Das Python-Paket pysaml2 installieren

cd ~/synapse
pipenv shell
pipenv install pysaml2

In der homeserver.yaml die SAML-Direktiven einkommentieren, hier mit dem Beispiel eines SAML IdP unter https://login.beispiel.de/simplesaml/saml2/idp/metadata.php:

# Once SAML support is enabled, a metadata file will be exposed at
# https://<server>:<port>/_matrix/saml2/metadata.xml, which you may be able to 
# use to configure your SAML IdP with. Alternatively, you can manually configure
# the IdP to use an ACS location of
# https://<server>:<port>/_matrix/saml2/authn_response.
#
saml2_config:
    sp_config:
        # point this to the IdP's metadata. You can use either a local file or
        # (preferably) a URL.
        metadata:
        #local: ["saml2/idp.xml"]
        remote:
            - url: https://login.beispiel.de/simplesaml/saml2/idp/metadata.php

Wichtig ist außerdem, dass die public_baseurl in der homeserver.yaml gesetzt ist, damit Synapse weiß, wie es erreichbar ist und dies in seine SP-Metadaten einbauen kann:

public_baseurl: https://matrix.beispiel.de/

Die Service-Provider-Konfiguration als XML bekommt man von Synapse dann wie schon in der homeserver.yaml als Kommentar beschrieben, unter https://matrix.beispiel.de/_matrix/saml2/metadata.xml

Diese dann in den SAML-IdP-importieren und dann sollte der Single-Sign-On via SAML funktionieren.

Federation Sender Worker für Synapse

Zur Parallelisierung bietet Synapse das Konzept "Worker" an, die spezifische Aufgaben übernehmen, damit der Hauptprozess diese nicht durchführen muss.

Details dazu: https://github.com/matrix-org/synapse/blob/master/docs/workers.md

Ein einfach einzurichtender Worker, der auch viel Last abfedert, ist der Federation Sender Worker, da das Verschicken des Federation-Traffics 10-50% der Serverlast ausmacht.

In der homeserver.yaml die Worker-Konfiguration aktivieren:

## Worker ##
worker_app: synapse.app.homeserver
daemonize: true

und dazugehörige Listener (Abschnitt listener:) aktivieren:

# The TCP replication port
- port: 32892
  bind_address: '127.0.0.1'
  type: replication
# The HTTP replication port
- port: 32893
  bind_address: '127.0.0.1'
  type: http
  resources:
   - names: [replication]

Funktionen, die Worker machen sollen, in der homeserver.yaml deaktivieren:

# disable federation sending here, use worker for it
send_federation: False

Dann Verzeichnis synapse/workers anlegen, darin federation_sender.yaml:

worker_app: synapse.app.federation_sender

# The replication listener on the synapse to talk to.
worker_replication_host: 127.0.0.1
worker_replication_port: 32892
worker_replication_http_port: 32893

worker_daemonize: True
worker_pid_file: /home/pacs/xyz00/users/matrix/synapse/federation_sender.pid
worker_log_config: /home/pacs/xyz00/users/matrix/synapse/federation_sender.log.config

.monitrc um worker erweitern:

check process federation_sender with pidfile /home/pacs/xyz00/users/matrix/synapse/federation_sender.pid
    start program "/bin/bash -c 'export VIRTUAL_ENV=$HOME/synapse/env && export PATH=$VIRTUAL_ENV/bin:$PATH && cd $HOME/synapse && synctl -w workers/federation_sender.yaml start'"
    stop program "/bin/bash -c '/bin/kill $( cat $HOME/synapse/federation_sender.pid )'"

Monit neu laden und synapse und federation_sender neustarten:

monit reload
monit restart all

Nach Updates ebenfalls immer Hauptprozess und alle Worker neustarten

monit restart all

Sliding Sync Proxy

Zum Zeitpunkt dieser Anleitung werden aktiv neue Element Anwendungen (Element X) und ein neues Syncverfahren entwickelt um Matrix performanter und weniger ressourcenhungrig zu machen. Bei stärkerer Matrix Nutzung können die neuen Anwendungen besonders mobil schon eine große Entlastung sein.

Ende 2024 wurden grundlegende Funktionen direkt in Synapse implementiert. Der Proxy wird nicht länger weiterentwickelt und sollte deinstalliert werden (nicht vergessen die .well-known zurück zu ändern). Auch der 3rdparty Server Conduit bringt nativ Support für Sliding Sync.

Links