This page (revision-28) was last changed on 04-Apr-2022 23:13 by Tester

This page was created on 07-Aug-2019 19:32 by Johannes Brakensiek

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note
28 04-Apr-2022 23:13 10 KB Tester to previous
27 27-Feb-2021 16:26 10 KB Christoph S. to previous | to last
26 14-Nov-2020 17:58 10 KB Christoph S. to previous | to last
25 21-Sep-2020 23:01 10 KB Christoph S. to previous | to last
24 21-Sep-2020 21:28 10 KB Christoph S. to previous | to last
23 21-Sep-2020 21:27 10 KB Christoph S. to previous | to last
22 21-Sep-2020 21:15 9 KB Christoph S. to previous | to last
21 21-Sep-2020 21:12 9 KB Christoph S. to previous | to last

Page References

Incoming links Outgoing links
AdminMatrix
AdminMatrix

Version management

Difference between version and

At line 2 removed 300 lines
Bei Matrix sind die User-IDs nach dem Schema "@user:beispiel.de" aufgebaut, der Homeserver an sich ist unter "matrix.beispiel.de" erreichbar. Diese Werte "beispiel.de" und "matrix.beispiel.de" durch die eigenen Werte in den Anleitungen weiter unten ersetzen.
!!Synapse
!Matrix Synapse bei Hostsharing installieren
[https://wiki.hostsharing.net/index.php?title=Matrix_Synapse_installieren]
!Matrix Synapse mit Docker und Ansible installieren
[https://github.com/spantaleev/matrix-docker-ansible-deploy]
!Matrix Synapse auf Ubuntu Server 20.04 manuell installieren
Kurz gefasst enthält die Anleitung folgende Punkte
* Debian-Pakete von matrix.org
* Postgres
* .well-known unter beispiel.de, Matrix-Server gehostet als matrix.beispiel.de
* Apache als Reverse Proxy
__1. Ubuntu-Pakete von Matrix-Machern__
Quelle: [https://github.com/matrix-org/synapse/blob/master/INSTALL.md#debianubuntu]
Bei der Installation wird der "server name" abgefragt, hier "beispiel.de" angeben, der Teil der Account-Namen wird.
{{{
sudo apt install -y lsb-release wget apt-transport-https
sudo wget -O /usr/share/keyrings/matrix-org-archive-keyring.gpg https://packages.matrix.org/debian/matrix-org-archive-keyring.gpg
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
sudo apt update
sudo apt install matrix-synapse-py3
}}}
__2. Postgres 12 aus Ubuntu-Paketen installieren__
{{{
sudo apt install postgresql
}}}
__3. Postgres in Synapse konfigurieren__
Quelle: [https://github.com/matrix-org/synapse/blob/master/docs/postgres.md]
Postgres Nutzer anlegen
{{{
sudo su - postgres
createuser --pwprompt synapse_user
}}}
Datenbank initial mit psql anlegen, wichtig wg. Zeichensatz:
{{{
psql
CREATE DATABASE synapse
ENCODING 'UTF8'
LC_COLLATE='C'
LC_CTYPE='C'
template=template0
OWNER synapse_user;
}}}
In der homeserver.yaml mit vorher vergebenem Passwort konfigurieren:
{{{
database:
name: psycopg2
args:
user: synapse_user
password: <pass>
database: synapse
host: localhost
cp_min: 5
cp_max: 10
}}}
Synapse neu starten um Konfiguration zu übernehmen
{{{
sudo systemctl restart matrix-synapse
}}}
__4. Reverse-Proxy für Synapse konfigurieren__
Quelle: [https://github.com/matrix-org/synapse/blob/master/docs/reverse_proxy.md]
Apache-VHost für matrix.beispiel.de unter /etc/apache2/sites-available/matrix.beispiel.de.conf anlegen
Die Zertifikatsconfig ist nur angedeutet, hier via präferierter Methode SSL-Zertifikate (LetsEncrypt) angeben.
{{{
<VirtualHost *:443>
SSLEngine on
ServerName matrix.beispiel.de;
AllowEncodedSlashes NoDecode
ProxyPass /_matrix http://127.0.0.1:8008/_matrix nocanon
ProxyPassReverse /_matrix http://127.0.0.1:8008/_matrix
SSLCertificateFile ...
SSLCertificateKeyFile ...
</VirtualHost>
}}}
Sowohl "AllowEncodedSlashes NoDecode" als auch "nocanon" sind zwingend notwendig.
Dann den VHost aktivieren:
{{{
sudo a2enmod proxy_http
sudo a2ensite matrix.beispiel.de.conf
sudo systemctl reload apache2
}}}
Der Server sollte dann schon unter https://matrix.beispiel.de/_matrix/static/ erreichbar sein
__5. Synapse-Föderations-Konfiguration__
Quelle: [https://github.com/matrix-org/synapse/blob/master/docs/federate.md]
Unter beispiel.de im Verzeichnis .well-known/matrix folgende Dateien "server" und "client" anlegen:
.well-known/matrix/server:
{{{
{
"m.server": "matrix.beispiel.de:443"
}
}}}
.well-known/matrix/client:
{{{
{
  "m.homeserver": {
    "base_url": "https://matrix.beispiel.de"
  }
}
}}}
Außerdem via .htaccess noch folgende Header setzen, damit die Dateien in Riot-Web ankommen:
{{{
Header set Access-Control-Allow-Origin "*"
Header set Content-Type "application/json"
}}}
Jetzt kann das Setup mit dem Federation Tester geprüft werden, dort beispiel.de eingeben:
[https://federationtester.matrix.org]
!!Element Webclient
Element Web ist eine statische html/js-Anwendung, daher keine Anforderungen außer einem Webserver (apache, nginx, ...):
* Aktuelles Release von [https://github.com/vector-im/element-web/releases] herunterladen und im Webspace (zB /var/www/element) auspacken
* vhost für /var/www/element anlegen
* config.sample.json in config.json kopieren und anpassen: [https://github.com/vector-im/element-web/blob/develop/docs/config.md]
!!Identity-Server
Wird nicht benötigt und soll mittelfristig komplett aus dem Matrix-Universum verschwinden. Daher richten wir den nicht ein.
!!Integration-Server Dimension
* Aktueller NodeJS und NPM
* Offizielle Anleitung: [https://github.com/turt2live/matrix-dimension/blob/master/docs/installing.md]
* User "dimension" auf eigenem Homeserver anlegen, access token via riot oder aus der access_tokens Tabelle aus der Synapse-Datenbank holen.
!!Push-Server für iOS und Android
* Anleitung: [https://github.com/matrix-org/sygnal/blob/master/README.rst]
!!Worker-Setup
Da Synapse als Python-Programm wegen des Python Global Interpreter Locks (GIL) auf eine CPU beschränkt ist, empfiehlt es sich, für größere Installationen ein Worker-Setup einzurichten. Dies ist grundsätzlich unter [https://github.com/matrix-org/synapse/blob/develop/docs/workers.md] beschrieben. Als ersten Schritt empfiehlt es sich, die Federation-Teile auszulagern. Dazu ist der federation_sender-Worker und ein generic_worker für die Federation-Requests (/_matrix/federation/*) notwendig.
Zur Kommunikation zwischen Hauptprozess und Worker-Prozessen wird Redis mit pub/sub channels verwendet.
Die Architektur sieht dann wie folgt aus:
[workers.png]
Main<->Worker-Kommunikation im Hauptprozess ermöglichen:
{{{
listeners:
- port: 32993
bind_address: '127.0.0.1'
type: http
resources:
- names: [replication]
# redis pub/sub main -> worker
redis:
enabled: true
port: 32992
## Worker ##
worker_app: synapse.app.homeserver
daemonize: true
# disable federation sending here, use worker for it
send_federation: false
}}}
generic_worker für die Federation-Requests, der auf Port 32902 lauscht:
{{{
worker_app: synapse.app.generic_worker
worker_name: federation_reader
worker_replication_host: 127.0.0.1
worker_replication_http_port: 32993
worker_listeners:
- type: http
port: 32902
bind_address: '127.0.0.1'
resources:
- names:
- client
- federation
- type: metrics
port: 32981
bind_address: '127.0.0.1'
}}}
Die notwendigen Einstellungen im Apache-Reverse-Proxy dazu sind:
{{{
# Federation Reader
ProxyPass "/_matrix/federation/v1/send/" "http://127.0.0.1:32902/_matrix/federation/v1/send/" nocanon
ProxyPass "/_matrix/federation/v1/event/" "http://127.0.0.1:32902/_matrix/federation/v1/event/" nocanon
ProxyPass "/_matrix/federation/v1/state/" "http://127.0.0.1:32902/_matrix/federation/v1/state/" nocanon
ProxyPass "/_matrix/federation/v1/state_ids/" "http://127.0.0.1:32902/_matrix/federation/v1/state_ids/" nocanon
ProxyPass "/_matrix/federation/v1/backfill/" "http://127.0.0.1:32902/_matrix/federation/v1/backfill/" nocanon
ProxyPass "/_matrix/federation/v1/get_missing_events/" "http://127.0.0.1:32902/_matrix/federation/v1/get_missing_events/" nocanon
ProxyPass "/_matrix/federation/v1/publicRooms" "http://127.0.0.1:32902/_matrix/federation/v1/publicRooms" nocanon
ProxyPass "/_matrix/federation/v1/query/" "http://127.0.0.1:32902/_matrix/federation/v1/query/" nocanon
ProxyPass "/_matrix/federation/v1/make_join/" "http://127.0.0.1:32902/_matrix/federation/v1/make_join/" nocanon
ProxyPass "/_matrix/federation/v1/make_leave/" "http://127.0.0.1:32902/_matrix/federation/v1/make_leave/" nocanon
ProxyPass "/_matrix/federation/v1/send_join/" "http://127.0.0.1:32902/_matrix/federation/v1/send_join/" nocanon
ProxyPass "/_matrix/federation/v2/send_join/" "http://127.0.0.1:32902/_matrix/federation/v2/send_join/" nocanon
ProxyPass "/_matrix/federation/v1/send_leave/" "http://127.0.0.1:32902/_matrix/federation/v1/send_leave/" nocanon
ProxyPass "/_matrix/federation/v2/send_leave/" "http://127.0.0.1:32902/_matrix/federation/v2/send_leave/" nocanon
ProxyPass "/_matrix/federation/v1/invite/" "http://127.0.0.1:32902/_matrix/federation/v1/invite/" nocanon
ProxyPass "/_matrix/federation/v2/invite/" "http://127.0.0.1:32902/_matrix/federation/v2/invite/" nocanon
ProxyPass "/_matrix/federation/v1/query_auth/" "http://127.0.0.1:32902/_matrix/federation/v1/query_auth/" nocanon
ProxyPass "/_matrix/federation/v1/event_auth/" "http://127.0.0.1:32902/_matrix/federation/v1/event_auth/" nocanon
ProxyPass "/_matrix/federation/v1/exchange_third_party_invite/" "http://127.0.0.1:32902/_matrix/federation/v1/exchange_third_party_invite/" nocanon
ProxyPass "/_matrix/federation/v1/user/devices/" "http://127.0.0.1:32902/_matrix/federation/v1/user/devices/" nocanon
ProxyPass "/_matrix/federation/v1/get_groups_publicised" "http://127.0.0.1:32902/_matrix/federation/v1/get_groups_publicised" nocanon
ProxyPass "/_matrix/key/v2/query" "http://127.0.0.1:32902/_matrix/key/v2/query" nocanon
}}}
Der federation_sender schickt nur Requests raus, daher benötigt nur seine eigene Worker-Konfiguration:
{{{
worker_app: synapse.app.federation_sender
# The replication listener on the synapse to talk to.
worker_replication_host: 127.0.0.1
worker_replication_http_port: 32993
worker_listeners:
- type: metrics
port: 32980
bind_address: '127.0.0.1'
}}}
Die Worker entweder per init-System der Wahl starten, für systemd sind Konfigurationen hier verfügbar: [https://github.com/matrix-org/synapse/tree/develop/docs/systemd-with-workers]
!!Monitoring
Einen Überblick über größere Installationen und Details, wofür CPU-Zeit verbraucht wird, ist mit dem Prometheus/Grafana-basierten Monitoring möglich:
[https://github.com/matrix-org/synapse/tree/develop/contrib/grafana]
Dabei sind für den Hauptprozess und die einzelnen Worker die CPU-Auslastung interessant, um herauszufinden, ob der Hauptprozess oder einer der Worker am CPU-Limit ist:
[metrics-cpu.png]
Im Normalzustand sollte die Event Send Time im 100ms-Bereich sein:
[metrics-send-time.png]
Falls die CPU-Auslastung hoch ist, kann man mit den Block-Metriken herausfinden, welcher Teil von Synapse die CPU verbrät:
[metrics-block-usage.png]
Um die Cache-Größe der Synapse-internen Caches einzuschätzen, die Cache-Eviction-Rate beachten. Wenn hier viel evicted wird, dann allgemein den Cache-Faktor hochsetzen:
[metrics-cache-eviction.png]
Dabei benötigt ein Cache-Faktor von 4 maximal ungefähr 3GB RAM. Werte zwischen 2 (max 1,5GB RAM) und 10 (max 7,5GB RAM) haben sich bei synod.im bewährt.
This page (revision-28) was last changed on 04-Apr-2022 23:13 by TesterTop