Matrix Synapse installieren: Unterschied zwischen den Versionen

Aus Hostsharing Wiki
Zur Navigation springen Zur Suche springen
 
(42 dazwischenliegende Versionen von 7 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
Diese Anleitung beschreibt, wie man den Matrix-Homeserver Synapse auf der Managed Hosting Plattform von Hostsharing installieren kann.  
Der Matrix Server ''Synapse'', der sogenannte 'Homeserver', ist aktuell die einzige vollständige serverseitige Implementierung des Matrix-Protokolls.
 
 
{{Textkasten|gelb|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 ==
== Vorbereitungen ==


Mit Hilfe von HSAdmin wird angelegt:
Mit Hilfe von HSAdmin werden angelegt:
# Ein User als Service-User mit ''/bin/bash'' als Shell, zum Beispiel Beispiel: ''xyz00-matrix''
# Ein User als Service-User mit ''/bin/bash'' als Shell, zum Beispiel Beispiel: ''xyz00-matrix''
# Eine Domain mit ''xyz00-matrix'' als Domain-Administrator, zum Beispiel ''matrix.beispiel.de''
# Eine Domain mit ''xyz00-matrix'' als Domain-Administrator, zum Beispiel ''matrix.beispiel.de''
Zeile 9: Zeile 16:
# Eine Postgresql-Datenbank ''xyz00_matrixdb'' mit Datenbank-Owner ''xyz00_matrixuser''
# Eine Postgresql-Datenbank ''xyz00_matrixdb'' mit Datenbank-Owner ''xyz00_matrixuser''


Verwendete IP-Ports der Server-Dienste:
Verwendeter IP-Port für den Server-Dienst:
# Monit: localhost:32800
# Synapse: localhost:32801
# Synapse: localhost:32801


== Installation von Synapse ==
== Installation von Synapse ==


Installationsanleitung basierend auf https://github.com/matrix-org/synapse/blob/master/INSTALL.md#installing-from-source
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 [https://wiki.hostsharing.net/index.php?title=Eigenes_Python_installieren#Installation_mit_pyenv Eigenes Python mit pyenv installieren].


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


  mkdir -p ~/synapse
  mkdir -p ~/synapse
  virtualenv -p python3 ~/synapse/env
  cd ~/synapse
source ~/synapse/env/bin/activate
  pipenv install --python 3.9.18
pip install --upgrade pip
  pip install --upgrade setuptools


Synapse an sich installieren
Synapse und Postgres-Dependencies installieren


  pip install matrix-synapse
  cd ~/synapse
 
pipenv shell
Jinja2 und Postgres-Python-Bindings installieren
  pipenv install matrix-synapse[postgres]
 
  pip install jinja2 psycopg2


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


  cd ~/synapse
  cd ~/synapse
  python -m synapse.app.homeserver --server-name matrix.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


== Konfiguration von Synapse
== Konfiguration von Synapse ==


In die initial generierte Konfiguration muss noch die Port- und Datenbank-Konfiguration eingetragen werden:
In die initial generierte Konfiguration muss noch die Port- und Datenbank-Konfiguration eingetragen werden:
Zeile 66: Zeile 70:
== Starten der Dienste  ==
== Starten der Dienste  ==


Zum Start aller notwendigen Dienste wird in dieser Anleitung ''monit'' benutzt. Hier ein Beispiel für eine Datei ''.monitrc'' (überlange Zeilen werden hier im Wiki umgebrochen)
Der ''Synapse''-Dienst wird hier als Service-Unit im SystemD des Users eingetragen.


Das monitpassword auf jeden Fall durch ein sicheres Passwort ersetzen:
Lege dazu die folgende Datei an: ''~/.config/systemd/user/synapse.service'' mit dem Inhalt:


  set daemon 60
  [Unit]
    with start delay 120
Description=Synapse
  set logfile /home/pacs/xyz00/users/matrix/monit/var/monit.log
  set idfile /home/pacs/xyz00/users/matrix/monit/var/monit.id
[Service]
  set statefile /home/pacs/xyz00/users/matrix/monit/var/monit.state
  Type=simple
  set mailserver localhost
  WorkingDirectory=%h/synapse
set mail-format { from: monit@matrix.beispiel.de }
  Environment=LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2
set alert matrix@matrix.beispiel.de
  ExecStart=pipenv run python -m synapse.app.homeserver --config-path=%h/synapse/homeserver.yaml
set httpd port 32800 address xyz00.hostsharing.net
    allow matrix:monitpassword
[Install]
check process synapse with pidfile /home/pacs/xyz00/users/matrix/synapse/homeserver.pid
WantedBy=default.target
    start program "/bin/bash -c 'export VIRTUAL_ENV=$HOME/synapse/env && export PATH=$VIRTUAL_ENV/bin:$PATH && cd $HOME/synapse && synctl start'"
    stop program "/bin/bash -c '/bin/kill $( cat $HOME/synapse/homeserver.pid )'"
 
== Cronjobs ==
 
''Cron'' wird für eine Aufgabe genutzt:
* Start von monit nach einem Server Reboot


Einrichten der crontab mit ''cronttab -e''
Durch Aufruf der folgenden Kommandos wird der Dienst aktiviert und gestartet:


  HOME=/home/pacs/xyz00/users/matrix
  systemctl --user daemon-reload
  MAILTO=matrix@matrix.beispiel.de
  systemctl --user enable synapse.service
   
  systemctl --user start synapse.service
@reboot /usr/bin/monit -c $HOME/.monitrc


== Einrichten des Apache VHost ==
== Einrichten des Apache VHost ==
Zeile 108: Zeile 104:
  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"
== 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 ==
== Update von Synapse ==


  source ~/synapse/env/bin/activate
mit pipenv:
  pip install -U matrix-synapse
 
  monit restart synapse
  systemctl --user stop synapse.service
cd ~/synapse
pipenv shell
pipenv install matrix-synapse[postgres]
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
  pip install -r requirements.txt --upgrade
systemctl --user start synapse.service
 
Mit dem [https://federationtester.matrix.org/ Matrix Federation Tester] kann 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
 
== Element-Web ==
 
Element-Web ist aus Server-Seite eine rein statische html+javascript-Kombination, daher:
 
* Account und Domain anlegen (separat von der Synapse-Domain)
* [https://github.com/element-hq/element-web/releases/latest 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
 
== Links ==


== TODO ==
* https://matrix.org/docs/projects/server/synapse
* https://github.com/matrix-org/synapse
* https://github.com/matrix-org/synapse/blob/master/INSTALL.md
* https://matrix.org/docs/spec/
* https://www.hostsharing.net/loesungen/matrix/
* https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/synapse
* https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/element


* riot-web?
[[Kategorie:Installationsanleitungen]]
* SimpleSAML mit Wordpress-Userdb
[[Kategorie:Ansible Playbook]]
* Synapse mit pysaml gegen SimpleSAML

Aktuelle Version vom 2. März 2024, 05:17 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
pipenv shell
pipenv install matrix-synapse[postgres]
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
pip install -r requirements.txt --upgrade
systemctl --user start synapse.service

Mit dem Matrix Federation Tester kann 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

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

Links