From 39861031eefd62b503e89b49093ceb4825939d6e Mon Sep 17 00:00:00 2001 From: squahtx Date: Tue, 20 Dec 2022 18:10:08 +0000 Subject: deploy: 774e20b57047b9f8700e62e7f4689717f4fa094c --- .../usage/configuration/config_documentation.html | 136 +++++++++++++-------- 1 file changed, 87 insertions(+), 49 deletions(-) (limited to 'latest/usage/configuration/config_documentation.html') diff --git a/latest/usage/configuration/config_documentation.html b/latest/usage/configuration/config_documentation.html index 65ea84fc77..ab15c6704b 100644 --- a/latest/usage/configuration/config_documentation.html +++ b/latest/usage/configuration/config_documentation.html @@ -842,7 +842,7 @@ the allowed_lifetime_min and allowed_lifetime_max conf which are older than the room's maximum retention period. Synapse will also filter events received over federation so that events that should have been purged are ignored and not stored again.

-

The message retention policies feature is disabled by default. Please be advised +

The message retention policies feature is disabled by default. Please be advised that enabling this feature carries some risk. There are known bugs with the implementation which can cause database corruption. Setting retention to delete older history is less risky than deleting newer history but in general caution is advised when enabling this @@ -2160,33 +2160,56 @@ Defaults to https://matrix.org/report-usage-stats/push

Config settings related to the client/server API

room_prejoin_state

-

Controls for the state that is shared with users who receive an invite -to a room. By default, the following state event types are shared with users who -receive invites to the room:

+

This setting controls the state that is shared with users upon receiving an +invite to a room, or in reply to a knock on a room. By default, the following +state events are shared with users:

To change the default behavior, use the following sub-options:

Example configuration:

room_prejoin_state:
-   disable_default_event_types: true
+   disable_default_event_types: false
    additional_event_types:
-     - org.example.custom.event.type
-     - m.room.join_rules
-
+ # Share all events of type `org.example.custom.event.typeA` + - org.example.custom.event.typeA + # Share only events of type `org.example.custom.event.typeB` whose + # state_key is "foo" + - ["org.example.custom.event.typeB", "foo"] + # Share only events of type `org.example.custom.event.typeC` whose + # state_key is "bar" or "baz" + - ["org.example.custom.event.typeC", "bar"] + - ["org.example.custom.event.typeC", "baz"] + +

Changed in Synapse 1.74: admins can filter the events in prejoin state based +on their state key.

track_puppeted_user_ips

We record the IP address of clients used to access the API for various @@ -2657,7 +2680,7 @@ which is set to the claims returned by the UserInfo Endpoint and/or in the ID Token.

  • -

    backchannel_logout_enabled: set to true to process OIDC Back-Channel Logout notifications. +

    backchannel_logout_enabled: set to true to process OIDC Back-Channel Logout notifications. Those notifications are expected to be received on /_synapse/client/oidc/backchannel_logout. Defaults to false.

    • @@ -3011,6 +3034,10 @@ ownership. Defaults to "[%(server_name)s] Validate your email"

    This setting defines options for push notifications.

    This option has a number of sub-options. They are as follows:

    Example configuration:

    push:
+  enabled: true
   include_content: false
   group_unread_count_by_room: false
    @@ -3305,7 +3333,7 @@ loads. Some workers are privileged and can accept requests from other workers.
  • The first part (in this section of the manual) defines which shardable tasks are delegated to privileged workers. This allows unprivileged workers to make -request a privileged worker to act on their behalf.
    • +requests to a privileged worker to act on their behalf.
  • The second part controls the behaviour of individual workers in isolation.
    • @@ -3314,13 +3342,14 @@ controls the behaviour of individual workers in isolation.

    worker_replication_secret

    A shared secret used by the replication APIs on the main process to authenticate HTTP requests from workers.

    -

    The default, this value is omitted (equivalently null), which means that +

    The default, this value is omitted (equivalently null), which means that traffic between the workers and the main process is not authenticated.

    Example configuration:

    worker_replication_secret: "secret_secret"

    start_pushers

    +

    Unnecessary to set if using pusher_instances with generic_workers.

    Controls sending of push notifications on the main process. Set to false if using a pusher worker. Defaults to true.

    Example configuration:

    @@ -3328,21 +3357,24 @@ if using a pusher worker. Defa

    pusher_instances

    -

    It is possible to run multiple pusher workers, -in which case the work is balanced across them. Use this setting to list the pushers by -worker_name. Ensure the main process and all pusher workers are -restarted after changing this option.

    -

    If no or only one pusher worker is configured, this setting is not necessary. -The main process will send out push notifications by default if you do not disable -it by setting start_pushers: false.

    -

    Example configuration:

    -
    start_pushers: false
-pusher_instances:
+
    It is possible to scale the processes that handle sending push notifications to sygnal
+and email by running a generic_worker and adding it's worker_name to
+a pusher_instances map. Doing so will remove handling of this function from the main
+process. Multiple workers can be added to this map, in which case the work is balanced
+across them. Ensure the main process and all pusher workers are restarted after changing
+this option.
    
+
    Example configuration for a single worker:
    
+
    pusher_instances:
+  - pusher_worker1
+
    
+
    And for multiple workers:
    
+
    pusher_instances:
   - pusher_worker1
   - pusher_worker2
 
    
 
    
 
    send_federation
    
+
    Unnecessary to set if using federation_sender_instances with generic_workers.
    
 
    Controls sending of outbound federation transactions on the main process.
 Set to false if using a federation sender worker.
 Defaults to true.
    
@@ -3351,25 +3383,31 @@ Defaults to true.

    federation_sender_instances

    -

    It is possible to run multiple -federation sender worker, in which -case the work is balanced across them. Use this setting to list the senders.

    -

    This configuration setting must be shared between all federation sender workers, and if -changed all federation sender workers must be stopped at the same time and then -started, to ensure that all instances are running with the same config (otherwise +

    It is possible to scale the processes that handle sending outbound federation requests +by running a generic_worker and adding it's worker_name to +a federation_sender_instances map. Doing so will remove handling of this function from +the main process. Multiple workers can be added to this map, in which case the work is +balanced across them.

    +

    This configuration setting must be shared between all workers handling federation +sending, and if changed all federation sender workers must be stopped at the same time +and then started, to ensure that all instances are running with the same config (otherwise events may be dropped).

    -

    Example configuration:

    -
    send_federation: false
-federation_sender_instances:
+
    Example configuration for a single worker:
    
+
    federation_sender_instances:
+  - federation_sender1
+
    
+
    And for multiple workers:
    
+
    federation_sender_instances:
   - federation_sender1
+  - federation_sender2
 
    
 
    
 
    instance_map
    
 
    When using workers this should be a map from worker_name to the
 HTTP replication listener of the worker, if configured.
-Each worker declared under stream_writers needs 
+Each worker declared under stream_writers needs
 a HTTP replication listener, and that listener should be included in the instance_map.
-(The main process also needs an HTTP replication listener, but it should not be 
+(The main process also needs an HTTP replication listener, but it should not be
 listed in the instance_map.)
    
 
    Example configuration:
    
 
    instance_map:
@@ -3470,8 +3508,8 @@ See worker_replication_secret<
 
    
 
    
 
    worker_listeners
    
-
    A worker can handle HTTP requests. To do so, a worker_listeners option 
-must be declared, in the same way as the listeners option 
+
    A worker can handle HTTP requests. To do so, a worker_listeners option
+must be declared, in the same way as the listeners option
 in the shared config.
    
 
    Workers declared in stream_writers will need to include a
 replication listener here, in order to accept internal HTTP requests from
@@ -3486,7 +3524,7 @@ other workers.
    
 
    
 
    worker_daemonize
    
 
    Specifies whether the worker should be started as a daemon process.
-If Synapse is being managed by systemd, this option 
+If Synapse is being managed by systemd, this option
 must be omitted or set to false.
    
 
    Defaults to false.
    
 
    Example configuration:
    
@@ -3494,10 +3532,10 @@ must be omitted or set to false.

    worker_pid_file

    -

    When running a worker as a daemon, we need a place to store the +

    When running a worker as a daemon, we need a place to store the PID of the worker. This option defines the location of that "pid file".

    -

    This option is required if worker_daemonize is true and ignored +

    This option is required if worker_daemonize is true and ignored otherwise. It has no default.

    See also the pid_file option option for the main Synapse process.

    Example configuration:

    -- cgit 1.5.1