mirrors/synapse
mirrors/synapse
1
0
Fork 0
mirror of https://github.com/element-hq/synapse.git synced 2025-03-13 11:18:43 +00:00
Code Activity

deploy: c141455049

Browse source
This commit is contained in:
anoadragon453 2021-07-15 11:48:16 +00:00
parent ca15a1d699
commit fc24a06cad
14 changed files with 44 additions and 48 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
develop/MSC1711_certificates_FAQ.html
View file

@ -295,7 +295,7 @@ and the key to Synapse via <code>tls_certificate_path</code> and <code>tls_priva
your domain, you can simply route all traffic through the reverse proxy by
updating the SRV record appropriately (or removing it, if the proxy listens on
8448).</p>
<p>See <a href="reverse_proxy.html">reverse_proxy.md</a> for information on setting up a
<p>See <a href="reverse_proxy.html">the reverse proxy documentation</a> for information on setting up a
reverse proxy.</p>
<h4 id="option-3-add-a-well-known-file-to-delegate-your-matrix-traffic"><a class="header" href="#option-3-add-a-well-known-file-to-delegate-your-matrix-traffic">Option 3: add a .well-known file to delegate your matrix traffic</a></h4>
<p>This will allow you to keep Synapse on a separate domain, without having to
@ -436,7 +436,7 @@ federation end points.</p>
<p>We no longer actively recommend against using a reverse proxy. Many admins will
find it easier to direct federation traffic to a reverse proxy and manage their
own TLS certificates, and this is a supported configuration.</p>
<p>See <a href="reverse_proxy.html">reverse_proxy.md</a> for information on setting up a
<p>See <a href="reverse_proxy.html">the reverse proxy documentation</a> for information on setting up a
reverse proxy.</p>
<h3 id="do-i-still-need-to-give-my-tls-certificates-to-synapse-if-i-am-using-a-reverse-proxy"><a class="header" href="#do-i-still-need-to-give-my-tls-certificates-to-synapse-if-i-am-using-a-reverse-proxy">Do I still need to give my TLS certificates to Synapse if I am using a reverse proxy?</a></h3>
<p>Practically speaking, this is no longer necessary.</p>

2
develop/admin_api/server_notices.html
View file

@ -212,7 +212,7 @@ ignored in the same way as with <code>PUT /_matrix/client/r0/rooms/{roomId}/send
}
</code></pre>
<p>Note that server notices must be enabled in <code>homeserver.yaml</code> before this API
can be used. See <a href="../server_notices.html">server_notices.md</a> for more information.</p>
can be used. See <a href="../server_notices.html">the server notices documentation</a> for more information.</p>
</main>

2
develop/consent_tracking.html
View file

@ -308,7 +308,7 @@ version of the policy. To do so:</p>
<p>ensure that the consent resource is configured, as in the previous section</p>
</li>
<li>
<p>ensure that server notices are configured, as in <a href="server_notices.html">server_notices.md</a>.</p>
<p>ensure that server notices are configured, as in <a href="server_notices.html">the server notice documentation</a>.</p>
</li>
<li>
<p>Add <code>server_notice_content</code> under <code>user_consent</code> in <code>homeserver.yaml</code>. For

2
develop/delegate.html
View file

@ -235,7 +235,7 @@ find it using delegation.</p>
<p>We no longer actively recommend against using a reverse proxy. Many admins will
find it easier to direct federation traffic to a reverse proxy and manage their
own TLS certificates, and this is a supported configuration.</p>
<p>See <a href="reverse_proxy.html">reverse_proxy.md</a> for information on setting up a
<p>See <a href="reverse_proxy.html">the reverse proxy documentation</a> for information on setting up a
reverse proxy.</p>
<h3 id="do-i-still-need-to-give-my-tls-certificates-to-synapse-if-i-am-using-a-reverse-proxy"><a class="header" href="#do-i-still-need-to-give-my-tls-certificates-to-synapse-if-i-am-using-a-reverse-proxy">Do I still need to give my TLS certificates to Synapse if I am using a reverse proxy?</a></h3>
<p>This is no longer necessary. If you are using a reverse proxy for all of your

8
develop/federate.html
View file

@ -194,7 +194,7 @@ server (via port 8448). This is easy to set up and will work provided
you set the <code>server_name</code> to match your machine's public DNS hostname.</p>
<p>For this default configuration to work, you will need to listen for TLS
connections on port 8448. The preferred way to do that is by using a
reverse proxy: see <a href="reverse_proxy.html">reverse_proxy.md</a> for instructions
reverse proxy: see <a href="reverse_proxy.html">the reverse proxy documentation</a> for instructions
on how to correctly set one up.</p>
<p>In some cases you might not want to run Synapse on the machine that has
the <code>server_name</code> as its public DNS hostname, or you might want federation
@ -202,7 +202,7 @@ traffic to use a different port than 8448. For example, you might want to
have your user names look like <code>@user:example.com</code>, but you want to run
Synapse on <code>synapse.example.com</code> on port 443. This can be done using
delegation, which allows an admin to control where federation traffic should
be sent. See <a href="delegate.html">delegate.md</a> for instructions on how to set this up.</p>
be sent. See <a href="delegate.html">the delegation documentation</a> for instructions on how to set this up.</p>
<p>Once federation has been configured, you should be able to join a room over
federation. A good place to start is <code>#synapse:matrix.org</code> - a room for
Synapse admins.</p>
@ -218,8 +218,8 @@ servers in the room could not access yours. (Joining a room over federation is
a complicated dance which requires connections in both directions).</p>
<p>Another common problem is that people on other servers can't join rooms that
you invite them to. This can be caused by an incorrectly-configured reverse
proxy: see <a href="reverse_proxy.html">reverse_proxy.md</a> for instructions on how to correctly
configure a reverse proxy.</p>
proxy: see <a href="reverse_proxy.html">the reverse proxy documentation</a> for instructions on how
to correctly configure a reverse proxy.</p>
<h3 id="known-issues"><a class="header" href="#known-issues">Known issues</a></h3>
<p><strong>HTTP <code>308 Permanent Redirect</code> redirects are not followed</strong>: Due to missing features
in the HTTP library used by Synapse, 308 redirects are currently not followed by

44
develop/print.html
View file

@ -493,7 +493,7 @@ caching model, smarter query optimiser</li>
<li>allowing the DB to be run on separate hardware</li>
</ul>
<p>For information on how to install and use PostgreSQL in Synapse, please see
<a href="setup/../postgres.html">docs/postgres.md</a></p>
<a href="setup/../postgres.html">Using Postgres</a></p>
<p>SQLite is only acceptable for testing purposes. SQLite should not be used in
a production server. Synapse will perform poorly when using
SQLite, especially when participating in large rooms.</p>
@ -504,7 +504,7 @@ but for any practical use, you will need Synapse's APIs to be served
over HTTPS.</p>
<p>The recommended way to do so is to set up a reverse proxy on port
<code>8448</code>. You can find documentation on doing so in
<a href="setup/../reverse_proxy.html">docs/reverse_proxy.md</a>.</p>
<a href="setup/../reverse_proxy.html">the reverse proxy documentation</a>.</p>
<p>Alternatively, you can configure Synapse to expose an HTTPS port. To do
so, you will need to edit <code>homeserver.yaml</code>, as follows:</p>
<ul>
@ -530,7 +530,7 @@ includes the full certificate chain including any intermediate certificates
</li>
</ul>
<p>For a more detailed guide to configuring your server for federation, see
<a href="setup/../federate.html">federate.md</a>.</p>
<a href="setup/../federate.html">Federation</a>.</p>
<h3 id="client-well-known-uri"><a class="header" href="#client-well-known-uri">Client Well-Known URI</a></h3>
<p>Setting up the client Well-Known URI is optional but if you set it up, it will
allow users to enter their full username (e.g. <code>@user:&lt;server_name&gt;</code>) into clients
@ -616,9 +616,7 @@ anyone with knowledge of it can register users, including admin accounts,
on your server even if <code>enable_registration</code> is <code>false</code>.</p>
<h3 id="setting-up-a-turn-server"><a class="header" href="#setting-up-a-turn-server">Setting up a TURN server</a></h3>
<p>For reliable VoIP calls to be routed via this homeserver, you MUST configure
a TURN server. See
<a href="setup/../turn-howto.html">docs/turn-howto.md</a>
for details.</p>
a TURN server. See <a href="setup/../turn-howto.html">TURN setup</a> for details.</p>
<h3 id="url-previews"><a class="header" href="#url-previews">URL previews</a></h3>
<p>Synapse includes support for previewing URLs, which is disabled by default. To
turn it on you must enable the <code>url_preview_enabled: True</code> config parameter
@ -856,7 +854,7 @@ port 8448. Where these are different, we refer to the 'client port' and the
'federation port'. See <a href="https://matrix.org/docs/spec/server_server/latest#resolving-server-names">the Matrix
specification</a>
for more details of the algorithm used for federation connections, and
<a href="delegate.html">delegate.md</a> for instructions on setting up delegation.</p>
<a href="delegate.html">Delegation</a> for instructions on setting up delegation.</p>
<p><strong>NOTE</strong>: Your reverse proxy must not <code>canonicalise</code> or <code>normalise</code>
the requested URI in any way (for example, by decoding <code>%xx</code> escapes).
Beware that Apache <em>will</em> canonicalise URIs unless you specify
@ -1379,7 +1377,7 @@ find it using delegation.</p>
<p>We no longer actively recommend against using a reverse proxy. Many admins will
find it easier to direct federation traffic to a reverse proxy and manage their
own TLS certificates, and this is a supported configuration.</p>
<p>See <a href="reverse_proxy.html">reverse_proxy.md</a> for information on setting up a
<p>See <a href="reverse_proxy.html">the reverse proxy documentation</a> for information on setting up a
reverse proxy.</p>
<h3 id="do-i-still-need-to-give-my-tls-certificates-to-synapse-if-i-am-using-a-reverse-proxy"><a class="header" href="#do-i-still-need-to-give-my-tls-certificates-to-synapse-if-i-am-using-a-reverse-proxy">Do I still need to give my TLS certificates to Synapse if I am using a reverse proxy?</a></h3>
<p>This is no longer necessary. If you are using a reverse proxy for all of your
@ -2635,7 +2633,7 @@ and the key to Synapse via <code>tls_certificate_path</code> and <code>tls_priva
your domain, you can simply route all traffic through the reverse proxy by
updating the SRV record appropriately (or removing it, if the proxy listens on
8448).</p>
<p>See <a href="reverse_proxy.html">reverse_proxy.md</a> for information on setting up a
<p>See <a href="reverse_proxy.html">the reverse proxy documentation</a> for information on setting up a
reverse proxy.</p>
<h4 id="option-3-add-a-well-known-file-to-delegate-your-matrix-traffic"><a class="header" href="#option-3-add-a-well-known-file-to-delegate-your-matrix-traffic">Option 3: add a .well-known file to delegate your matrix traffic</a></h4>
<p>This will allow you to keep Synapse on a separate domain, without having to
@ -2776,7 +2774,7 @@ federation end points.</p>
<p>We no longer actively recommend against using a reverse proxy. Many admins will
find it easier to direct federation traffic to a reverse proxy and manage their
own TLS certificates, and this is a supported configuration.</p>
<p>See <a href="reverse_proxy.html">reverse_proxy.md</a> for information on setting up a
<p>See <a href="reverse_proxy.html">the reverse proxy documentation</a> for information on setting up a
reverse proxy.</p>
<h3 id="do-i-still-need-to-give-my-tls-certificates-to-synapse-if-i-am-using-a-reverse-proxy-1"><a class="header" href="#do-i-still-need-to-give-my-tls-certificates-to-synapse-if-i-am-using-a-reverse-proxy-1">Do I still need to give my TLS certificates to Synapse if I am using a reverse proxy?</a></h3>
<p>Practically speaking, this is no longer necessary.</p>
@ -2810,7 +2808,7 @@ server (via port 8448). This is easy to set up and will work provided
you set the <code>server_name</code> to match your machine's public DNS hostname.</p>
<p>For this default configuration to work, you will need to listen for TLS
connections on port 8448. The preferred way to do that is by using a
reverse proxy: see <a href="reverse_proxy.html">reverse_proxy.md</a> for instructions
reverse proxy: see <a href="reverse_proxy.html">the reverse proxy documentation</a> for instructions
on how to correctly set one up.</p>
<p>In some cases you might not want to run Synapse on the machine that has
the <code>server_name</code> as its public DNS hostname, or you might want federation
@ -2818,7 +2816,7 @@ traffic to use a different port than 8448. For example, you might want to
have your user names look like <code>@user:example.com</code>, but you want to run
Synapse on <code>synapse.example.com</code> on port 443. This can be done using
delegation, which allows an admin to control where federation traffic should
be sent. See <a href="delegate.html">delegate.md</a> for instructions on how to set this up.</p>
be sent. See <a href="delegate.html">the delegation documentation</a> for instructions on how to set this up.</p>
<p>Once federation has been configured, you should be able to join a room over
federation. A good place to start is <code>#synapse:matrix.org</code> - a room for
Synapse admins.</p>
@ -2834,8 +2832,8 @@ servers in the room could not access yours. (Joining a room over federation is
a complicated dance which requires connections in both directions).</p>
<p>Another common problem is that people on other servers can't join rooms that
you invite them to. This can be caused by an incorrectly-configured reverse
proxy: see <a href="reverse_proxy.html">reverse_proxy.md</a> for instructions on how to correctly
configure a reverse proxy.</p>
proxy: see <a href="reverse_proxy.html">the reverse proxy documentation</a> for instructions on how
to correctly configure a reverse proxy.</p>
<h3 id="known-issues"><a class="header" href="#known-issues">Known issues</a></h3>
<p><strong>HTTP <code>308 Permanent Redirect</code> redirects are not followed</strong>: Due to missing features
in the HTTP library used by Synapse, 308 redirects are currently not followed by
@ -6872,8 +6870,8 @@ namespaces:
<div id="chapter_begin" style="break-before: page; page-break-before: always;"></div><h1 id="server-notices"><a class="header" href="#server-notices">Server Notices</a></h1>
<p>'Server Notices' are a new feature introduced in Synapse 0.30. They provide a
channel whereby server administrators can send messages to users on the server.</p>
<p>They are used as part of communication of the server polices(see
<a href="consent_tracking.html">consent_tracking.md</a>), however the intention is that
<p>They are used as part of communication of the server polices (see
<a href="consent_tracking.html">Consent Tracking</a>), however the intention is that
they may also find a use for features such as &quot;Message of the day&quot;.</p>
<p>This is a feature specific to Synapse, but it uses standard Matrix
communication mechanisms, so should work with any Matrix client.</p>
@ -7039,7 +7037,7 @@ version of the policy. To do so:</p>
<p>ensure that the consent resource is configured, as in the previous section</p>
</li>
<li>
<p>ensure that server notices are configured, as in <a href="server_notices.html">server_notices.md</a>.</p>
<p>ensure that server notices are configured, as in <a href="server_notices.html">the server notice documentation</a>.</p>
</li>
<li>
<p>Add <code>server_notice_content</code> under <code>user_consent</code> in <code>homeserver.yaml</code>. For
@ -7905,7 +7903,7 @@ https://hub.docker.com/r/matrixdotorg/synapse/.</p>
<p>To make effective use of the workers, you will need to configure an HTTP
reverse-proxy such as nginx or haproxy, which will direct incoming requests to
the correct worker, or to the main synapse instance. See
<a href="reverse_proxy.html">reverse_proxy.md</a> for information on setting up a reverse
<a href="reverse_proxy.html">the reverse proxy documentation</a> for information on setting up a reverse
proxy.</p>
<p>When using workers, each worker process has its own configuration file which
contains settings specific to that worker, such as the HTTP listener that it
@ -7980,8 +7978,8 @@ endpoints to the worker (<code>localhost:8083</code> in the above example).</p>
<code>synctl</code> or your distribution's preferred service manager such as <code>systemd</code>. We
recommend the use of <code>systemd</code> where available: for information on setting up
<code>systemd</code> to start synapse workers, see
<a href="systemd-with-workers">systemd-with-workers</a>. To use <code>synctl</code>, see
<a href="synctl_workers.html">synctl_workers.md</a>.</p>
<a href="systemd-with-workers">Systemd with Workers</a>. To use <code>synctl</code>, see
<a href="synctl_workers.html">Using synctl with Workers</a>.</p>
<h2 id="available-worker-applications"><a class="header" href="#available-worker-applications">Available worker applications</a></h2>
<h3 id="synapseappgeneric_worker"><a class="header" href="#synapseappgeneric_worker"><code>synapse.app.generic_worker</code></a></h3>
<p>This worker can handle API requests matching the following regular
@ -8313,7 +8311,7 @@ for the systemd unit files.</p>
<p>The folder <a href="https://github.com/matrix-org/synapse/tree/develop/docs/systemd-with-workers/workers/">workers</a>
contains an example configuration for the <code>federation_reader</code> worker.</p>
<h2 id="synapse-configuration-files"><a class="header" href="#synapse-configuration-files">Synapse configuration files</a></h2>
<p>See <a href="systemd-with-workers/../workers.html">workers.md</a> for information on how to set up the
<p>See <a href="systemd-with-workers/../workers.html">the worker documentation</a> for information on how to set up the
configuration files and reverse-proxy correctly.
Below is a sample <code>federation_reader</code> worker configuration file.</p>
<pre><code class="language-yaml">worker_app: synapse.app.federation_reader
@ -9633,7 +9631,7 @@ ignored in the same way as with <code>PUT /_matrix/client/r0/rooms/{roomId}/send
}
</code></pre>
<p>Note that server notices must be enabled in <code>homeserver.yaml</code> before this API
can be used. See <a href="admin_api/../server_notices.html">server_notices.md</a> for more information.</p>
can be used. See <a href="admin_api/../server_notices.html">the server notices documentation</a> for more information.</p>
<div id="chapter_begin" style="break-before: page; page-break-before: always;"></div><h1 id="deprecated-shutdown-room-api"><a class="header" href="#deprecated-shutdown-room-api">Deprecated: Shutdown room API</a></h1>
<p><strong>The old Shutdown room API is deprecated and will be removed in a future release.
See the new <a href="admin_api/rooms.html#delete-room-api">Delete Room API</a> for more details.</strong></p>
@ -12138,7 +12136,7 @@ needed to expose the append-only log to the readers should be fairly
minimal.</p>
<h2 id="architecture"><a class="header" href="#architecture">Architecture</a></h2>
<h3 id="the-replication-protocol"><a class="header" href="#the-replication-protocol">The Replication Protocol</a></h3>
<p>See <a href="tcp_replication.html">tcp_replication.md</a></p>
<p>See <a href="tcp_replication.html">the TCP replication documentation</a>.</p>
<h3 id="the-slaved-datastore"><a class="header" href="#the-slaved-datastore">The Slaved DataStore</a></h3>
<p>There are read-only version of the synapse storage layer in
<code>synapse/replication/slave/storage</code> that use the response of the

2
develop/replication.html
View file

@ -205,7 +205,7 @@ needed to expose the append-only log to the readers should be fairly
minimal.</p>
<h2 id="architecture"><a class="header" href="#architecture">Architecture</a></h2>
<h3 id="the-replication-protocol"><a class="header" href="#the-replication-protocol">The Replication Protocol</a></h3>
<p>See <a href="tcp_replication.html">tcp_replication.md</a></p>
<p>See <a href="tcp_replication.html">the TCP replication documentation</a>.</p>
<h3 id="the-slaved-datastore"><a class="header" href="#the-slaved-datastore">The Slaved DataStore</a></h3>
<p>There are read-only version of the synapse storage layer in
<code>synapse/replication/slave/storage</code> that use the response of the

2
develop/reverse_proxy.html
View file

@ -202,7 +202,7 @@ port 8448. Where these are different, we refer to the 'client port' and the
'federation port'. See <a href="https://matrix.org/docs/spec/server_server/latest#resolving-server-names">the Matrix
specification</a>
for more details of the algorithm used for federation connections, and
<a href="delegate.html">delegate.md</a> for instructions on setting up delegation.</p>
<a href="delegate.html">Delegation</a> for instructions on setting up delegation.</p>
<p><strong>NOTE</strong>: Your reverse proxy must not <code>canonicalise</code> or <code>normalise</code>
the requested URI in any way (for example, by decoding <code>%xx</code> escapes).
Beware that Apache <em>will</em> canonicalise URIs unless you specify

2
develop/searchindex.js
View file

File diff suppressed because one or more lines are too long

2
develop/searchindex.json
View file

File diff suppressed because one or more lines are too long

4
develop/server_notices.html
View file

@ -185,8 +185,8 @@
<h1 id="server-notices"><a class="header" href="#server-notices">Server Notices</a></h1>
<p>'Server Notices' are a new feature introduced in Synapse 0.30. They provide a
channel whereby server administrators can send messages to users on the server.</p>
<p>They are used as part of communication of the server polices(see
<a href="consent_tracking.html">consent_tracking.md</a>), however the intention is that
<p>They are used as part of communication of the server polices (see
<a href="consent_tracking.html">Consent Tracking</a>), however the intention is that
they may also find a use for features such as &quot;Message of the day&quot;.</p>
<p>This is a feature specific to Synapse, but it uses standard Matrix
communication mechanisms, so should work with any Matrix client.</p>

10
develop/setup/installation.html
View file

@ -492,7 +492,7 @@ caching model, smarter query optimiser</li>
<li>allowing the DB to be run on separate hardware</li>
</ul>
<p>For information on how to install and use PostgreSQL in Synapse, please see
<a href="../postgres.html">docs/postgres.md</a></p>
<a href="../postgres.html">Using Postgres</a></p>
<p>SQLite is only acceptable for testing purposes. SQLite should not be used in
a production server. Synapse will perform poorly when using
SQLite, especially when participating in large rooms.</p>
@ -503,7 +503,7 @@ but for any practical use, you will need Synapse's APIs to be served
over HTTPS.</p>
<p>The recommended way to do so is to set up a reverse proxy on port
<code>8448</code>. You can find documentation on doing so in
<a href="../reverse_proxy.html">docs/reverse_proxy.md</a>.</p>
<a href="../reverse_proxy.html">the reverse proxy documentation</a>.</p>
<p>Alternatively, you can configure Synapse to expose an HTTPS port. To do
so, you will need to edit <code>homeserver.yaml</code>, as follows:</p>
<ul>
@ -529,7 +529,7 @@ includes the full certificate chain including any intermediate certificates
</li>
</ul>
<p>For a more detailed guide to configuring your server for federation, see
<a href="../federate.html">federate.md</a>.</p>
<a href="../federate.html">Federation</a>.</p>
<h3 id="client-well-known-uri"><a class="header" href="#client-well-known-uri">Client Well-Known URI</a></h3>
<p>Setting up the client Well-Known URI is optional but if you set it up, it will
allow users to enter their full username (e.g. <code>@user:&lt;server_name&gt;</code>) into clients
@ -615,9 +615,7 @@ anyone with knowledge of it can register users, including admin accounts,
on your server even if <code>enable_registration</code> is <code>false</code>.</p>
<h3 id="setting-up-a-turn-server"><a class="header" href="#setting-up-a-turn-server">Setting up a TURN server</a></h3>
<p>For reliable VoIP calls to be routed via this homeserver, you MUST configure
a TURN server. See
<a href="../turn-howto.html">docs/turn-howto.md</a>
for details.</p>
a TURN server. See <a href="../turn-howto.html">TURN setup</a> for details.</p>
<h3 id="url-previews"><a class="header" href="#url-previews">URL previews</a></h3>
<p>Synapse includes support for previewing URLs, which is disabled by default. To
turn it on you must enable the <code>url_preview_enabled: True</code> config parameter

2
develop/systemd-with-workers/index.html
View file

@ -193,7 +193,7 @@ for the systemd unit files.</p>
<p>The folder <a href="https://github.com/matrix-org/synapse/tree/develop/docs/systemd-with-workers/workers/">workers</a>
contains an example configuration for the <code>federation_reader</code> worker.</p>
<h2 id="synapse-configuration-files"><a class="header" href="#synapse-configuration-files">Synapse configuration files</a></h2>
<p>See <a href="../workers.html">workers.md</a> for information on how to set up the
<p>See <a href="../workers.html">the worker documentation</a> for information on how to set up the
configuration files and reverse-proxy correctly.
Below is a sample <code>federation_reader</code> worker configuration file.</p>
<pre><code class="language-yaml">worker_app: synapse.app.federation_reader

6
develop/workers.html
View file

@ -237,7 +237,7 @@ https://hub.docker.com/r/matrixdotorg/synapse/.</p>
<p>To make effective use of the workers, you will need to configure an HTTP
reverse-proxy such as nginx or haproxy, which will direct incoming requests to
the correct worker, or to the main synapse instance. See
<a href="reverse_proxy.html">reverse_proxy.md</a> for information on setting up a reverse
<a href="reverse_proxy.html">the reverse proxy documentation</a> for information on setting up a reverse
proxy.</p>
<p>When using workers, each worker process has its own configuration file which
contains settings specific to that worker, such as the HTTP listener that it
@ -312,8 +312,8 @@ endpoints to the worker (<code>localhost:8083</code> in the above example).</p>
<code>synctl</code> or your distribution's preferred service manager such as <code>systemd</code>. We
recommend the use of <code>systemd</code> where available: for information on setting up
<code>systemd</code> to start synapse workers, see
<a href="systemd-with-workers">systemd-with-workers</a>. To use <code>synctl</code>, see
<a href="synctl_workers.html">synctl_workers.md</a>.</p>
<a href="systemd-with-workers">Systemd with Workers</a>. To use <code>synctl</code>, see
<a href="synctl_workers.html">Using synctl with Workers</a>.</p>
<h2 id="available-worker-applications"><a class="header" href="#available-worker-applications">Available worker applications</a></h2>
<h3 id="synapseappgeneric_worker"><a class="header" href="#synapseappgeneric_worker"><code>synapse.app.generic_worker</code></a></h3>
<p>This worker can handle API requests matching the following regular