diff --git a/develop/admin_api/account_validity.html b/develop/admin_api/account_validity.html index b7a27e0094..8ebf393d08 100644 --- a/develop/admin_api/account_validity.html +++ b/develop/admin_api/account_validity.html @@ -151,7 +151,7 @@ use it, you must enable the account validity feature (under account_validity) in Synapse's configuration.

To use it, you will need to authenticate by providing an access_token -for a server admin: see Admin API.

+for a server admin: see Admin API.

Renew account

This API extends the validity of an account by as much time as configured in the period parameter from the account_validity configuration.

diff --git a/develop/admin_api/event_reports.html b/develop/admin_api/event_reports.html index 62f3d2e113..a8493ecd9d 100644 --- a/develop/admin_api/event_reports.html +++ b/develop/admin_api/event_reports.html @@ -149,7 +149,7 @@

Show reported events

This API returns information about reported events.

To use it, you will need to authenticate by providing an access_token -for a server admin: see Admin API.

+for a server admin: see Admin API.

The api is:

GET /_synapse/admin/v1/event_reports?from=0&limit=10
 
diff --git a/develop/admin_api/media_admin_api.html b/develop/admin_api/media_admin_api.html index d1005372de..8c8aa1830d 100644 --- a/develop/admin_api/media_admin_api.html +++ b/develop/admin_api/media_admin_api.html @@ -151,7 +151,7 @@

Details about the format of the media_id and storage of the media in the file system are documented under media repository.

To use it, you will need to authenticate by providing an access_token -for a server admin: see Admin API.

+for a server admin: see Admin API.

List all media in a room

This API gets a list of known media in a room. However, it only shows media from unencrypted events or rooms.

diff --git a/develop/admin_api/purge_history_api.html b/develop/admin_api/purge_history_api.html index bec236320b..9a61ccad38 100644 --- a/develop/admin_api/purge_history_api.html +++ b/develop/admin_api/purge_history_api.html @@ -155,7 +155,7 @@ paginate further back in the room from the point being purged from.

Note that Synapse requires at least one message in each room, so it will never delete the last message in a room.

To use it, you will need to authenticate by providing an access_token -for a server admin: see Admin API.

+for a server admin: see Admin API.

The API is:

POST /_synapse/admin/v1/purge_history/<room_id>[/<event_id>]
 
diff --git a/develop/admin_api/room_membership.html b/develop/admin_api/room_membership.html index ac593aca69..718d2ce478 100644 --- a/develop/admin_api/room_membership.html +++ b/develop/admin_api/room_membership.html @@ -152,7 +152,7 @@ to a room with a given room_id_or_alias. You can only modify the me local users. The server administrator must be in the room and have permission to invite users.

To use it, you will need to authenticate by providing an access_token -for a server admin: see Admin API.

+for a server admin: see Admin API.

Parameters

The following parameters are available:

@@ -288,7 +288,7 @@ Room objects contain the following fields:
  • room_id - string - The ID of the room.
  • stream_ordering - integer - The stream ordering of the most recent -successfully-sent PDU +successfully-sent PDU to this destination in this room.
diff --git a/develop/usage/administration/admin_api/index.html b/develop/usage/administration/admin_api/index.html index 0d5587271d..62901ed644 100644 --- a/develop/usage/administration/admin_api/index.html +++ b/develop/usage/administration/admin_api/index.html @@ -151,7 +151,7 @@

Many of the API calls in the admin api will require an access_token for a server admin. (Note that a server admin is distinct from a room admin.)

An existing user can be marked as a server admin by updating the database directly.

-

Check your database settings in the configuration file, connect to the correct database using either psql [database name] (if using PostgreSQL) or sqlite3 path/to/your/database.db (if using SQLite) and elevate the user @foo:bar.com to administrator.

+

Check your database settings in the configuration file, connect to the correct database using either psql [database name] (if using PostgreSQL) or sqlite3 path/to/your/database.db (if using SQLite) and elevate the user @foo:bar.com to administrator.

UPDATE users SET admin = 1 WHERE name = '@foo:bar.com';
 

A new server admin user can also be created using the register_new_matrix_user @@ -168,10 +168,10 @@ providing the token as either a query parameter or a request header. To add it a

curl --header "Authorization: Bearer <access_token>" <the_rest_of_your_API_request>
 

For example, suppose we want to -query the account of the user +query the account of the user @foo:bar.com. We need an admin access token (e.g. syt_AjfVef2_L33JNpafeif_0feKJfeaf0CQpoZk), and we need to know which port -Synapse's client listener is listening +Synapse's client listener is listening on (e.g. 8008). Then we can use the following command to request the account information from the Admin API.

curl --header "Authorization: Bearer syt_AjfVef2_L33JNpafeif_0feKJfeaf0CQpoZk" -X GET http://127.0.0.1:8008/_synapse/admin/v2/users/@foo:bar.com
diff --git a/develop/usage/administration/admin_api/registration_tokens.html b/develop/usage/administration/admin_api/registration_tokens.html
index 30877efb34..c3415214de 100644
--- a/develop/usage/administration/admin_api/registration_tokens.html
+++ b/develop/usage/administration/admin_api/registration_tokens.html
@@ -153,7 +153,7 @@ registration requests, as proposed in
 and stabilised in version 1.2 of the Matrix specification.
 To use it, you will need to enable the registration_requires_token config
 option, and authenticate by providing an access_token for a server admin:
-see Admin API.

+see Admin API.

Registration token objects

Most endpoints make use of JSON objects that contain details about tokens. These objects have the following fields:

diff --git a/develop/usage/administration/admin_faq.html b/develop/usage/administration/admin_faq.html index f9825d21d1..4fb69892cd 100644 --- a/develop/usage/administration/admin_faq.html +++ b/develop/usage/administration/admin_faq.html @@ -148,7 +148,7 @@

Admin FAQ

How do I become a server admin?

-

If your server already has an admin account you should use the User Admin API to promote other accounts to become admins.

+

If your server already has an admin account you should use the User Admin API to promote other accounts to become admins.

If you don't have any admin accounts yet you won't be able to use the admin API, so you'll have to edit the database manually. Manually editing the database is generally not recommended so once you have an admin account: use the admin APIs to make further changes.

UPDATE users SET admin = 1 WHERE name = '@foo:bar.com';
 
@@ -216,7 +216,7 @@ error (typically along the lines of "Invalid signature"). They might s something like the following in their logs:

2019-09-11 19:32:04,271 - synapse.federation.transport.server - 288 - WARNING - GET-11752 - authenticate_request failed: 401: Invalid signature for server <server> with key ed25519:a_EqML: Unable to verify signature for <server>
 
-

This is normally caused by a misconfiguration in your reverse-proxy. See the reverse proxy docs and double-check that your settings are correct.

+

This is normally caused by a misconfiguration in your reverse-proxy. See the reverse proxy docs and double-check that your settings are correct.

Help!! Synapse is slow and eats all my RAM/CPU!

First, ensure you are running the latest version of Synapse, using Python 3 with a PostgreSQL database.

diff --git a/develop/usage/administration/monitoring/reporting_homeserver_usage_statistics.html b/develop/usage/administration/monitoring/reporting_homeserver_usage_statistics.html index 9321a512ba..f04402eab6 100644 --- a/develop/usage/administration/monitoring/reporting_homeserver_usage_statistics.html +++ b/develop/usage/administration/monitoring/reporting_homeserver_usage_statistics.html @@ -218,7 +218,7 @@ option. By default, statistics are sent to Matrix.org.

consider using one of the following known implementations:

diff --git a/develop/usage/administration/request_log.html b/develop/usage/administration/request_log.html index e5b7100be4..38eceea543 100644 --- a/develop/usage/administration/request_log.html +++ b/develop/usage/administration/request_log.html @@ -147,7 +147,7 @@

Request log format

-

HTTP request logs are written by synapse (see site.py for details).

+

HTTP request logs are written by synapse (see synapse/http/site.py for details).

See the following for how to decode the dense data available from the default logging configuration.

2020-10-01 12:00:00,000 - synapse.access.http.8008 - 311 - INFO - PUT-1000- 192.168.0.1 - 8008 - {another-matrix-server.com} Processed request: 0.100sec/-0.000sec (0.000sec, 0.000sec) (0.001sec/0.090sec/3) 11B !200 "PUT /_matrix/federation/v1/send/1600000000000 HTTP/1.1" "Synapse/1.20.1" [0 dbevts]
 -AAAAAAAAAAAAAAAAAAAAA-   -BBBBBBBBBBBBBBBBBBBBBB-   -C-   -DD-   -EEEEEE-  -FFFFFFFFF-   -GG-    -HHHHHHHHHHHHHHHHHHHHHHH-                     -IIIIII- -JJJJJJJ-  -KKKKKK-, -LLLLLL-  -MMMMMMM- -NNNNNN- O  -P- -QQ-  -RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR-   -SSSSSSSSSSSS-   -TTTTTT-
diff --git a/develop/usage/configuration/config_documentation.html b/develop/usage/configuration/config_documentation.html
index 933801dc7b..560496dc39 100644
--- a/develop/usage/configuration/config_documentation.html
+++ b/develop/usage/configuration/config_documentation.html
@@ -1276,7 +1276,7 @@ connection pool. For a reference to valid arguments, see:

@@ -3545,7 +3545,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:

diff --git a/develop/workers.html b/develop/workers.html index 53a9574015..1a291d18ae 100644 --- a/develop/workers.html +++ b/develop/workers.html @@ -283,7 +283,7 @@ endpoints to the worker (localhost:8083 in the above example).

synctl or your distribution's preferred service manager such as systemd. We recommend the use of systemd where available: for information on setting up systemd to start synapse workers, see -Systemd with Workers. To use synctl, see +Systemd with Workers. To use synctl, see Using synctl with Workers.

Available worker applications

synapse.app.generic_worker

@@ -504,7 +504,7 @@ An event_creator listens for requests from clients to create new ev so. It will then pass those events over HTTP replication to any configured event persisters (or the main process if none are configured).

Note that event_creators and event_persisters are implemented using the same -synapse.app.generic_worker.

+synapse.app.generic_worker.

An example stream_writers configuration with multiple writers:

stream_writers: