mirror/matrix-docker-ansible-deploy
1
0
Fork 0
mirror of https://github.com/spantaleev/matrix-docker-ansible-deploy.git synced 2024-12-27 11:28:31 +01:00
Code Issues Packages Projects Releases Wiki Activity

Update docs/howto-server-delegation.md: related to removal of matrix-nginx-proxy

Browse Source 
The current ToC was added by 065b70203d, but the links were initially added by ef903fe544 as a navigation to sections under them. This commit replaces the ToC with such navigation.

Also, one of the sections was removed by f4f3d57520, and since matrix-nginx-proxy was removed, it seems to me that letting Synapse handle Federation by itself would be simpler than the other method which requires setting another webserver. Therefore this commit switches the alternative method from using another webserver to using Synapse.

Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This commit is contained in:
Suguru Hirahara 2024-11-16 14:32:19 +09:00
parent f19cbe6dd4
commit c97dbc9ec6
No known key found for this signature in database
GPG Key ID: E4F9743DAB4B7B75
1 changed files with 8 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
docs/howto-server-delegation.md
View File

@ -67,27 +67,9 @@ Regardless of which method for obtaining certificates you've used, once you've m
Based on your setup, you have different ways to go about it:
- [Server Delegation](#server-delegation)
- [Server Delegation via a well-known file](#server-delegation-via-a-well-known-file)
- [Downsides of well-known-based Server Delegation](#downsides-of-well-known-based-server-delegation)
- [Server Delegation via a DNS SRV record (advanced)](#server-delegation-via-a-dns-srv-record-advanced)
- [Obtaining certificates](#obtaining-certificates)
- [Serving the Federation API with your certificates](#serving-the-federation-api-with-your-certificates)
- [Serving the Federation API with your certificates and another webserver](#serving-the-federation-api-with-your-certificates-and-another-webserver)
- [Serving the Federation API with your certificates and Synapse handling Federation](#serving-the-federation-api-with-your-certificates-and-synapse-handling-federation)
#### Serving the Federation API with your certificates and Synapse handling Federation
### Serving the Federation API with your certificates and another webserver
**If you are using some other webserver**, you can set up reverse-proxying for the `tcp/8448` port by yourself. Make sure to use the proper certificates for `example.com` (not for `matrix.example.com`) when serving the `tcp/8448` port.
As recommended in our [Fronting the integrated reverse-proxy webserver with another reverse-proxy](./configuring-playbook-own-webserver.md#fronting-the-integrated-reverse-proxy-webserver-with-another-reverse-proxy) documentation section, we recommend you to expose the Matrix Federation entrypoint from traffic at a local port (e.g. `127.0.0.1:8449`), so your reverese-proxy should send traffic there.
### Serving the Federation API with your certificates and Synapse handling Federation
**Alternatively**, you can let Synapse handle Federation by itself.
You can let Synapse handle Federation by itself.
To do that, make sure the certificate files are mounted into the Synapse container:
@ -105,3 +87,9 @@ matrix_synapse_tls_private_key_path: /some/path/inside/the/container/private.key
```
Make sure to reload Synapse once in a while (`systemctl reload matrix-synapse`), so that newer certificates can kick in. Reloading doesn't cause any downtime.
#### Serving the Federation API with your certificates and another webserver
**Alternatively**, if you are using another webserver, you can set up reverse-proxying for the `tcp/8448` port by yourself. Make sure to use the proper certificates for `example.com` (not for `matrix.example.com`) when serving the `tcp/8448` port.
As recommended in our [Fronting the integrated reverse-proxy webserver with another reverse-proxy](./configuring-playbook-own-webserver.md#fronting-the-integrated-reverse-proxy-webserver-with-another-reverse-proxy) documentation section, we recommend you to expose the Matrix Federation entrypoint from traffic at a local port (e.g. `127.0.0.1:8449`), so your reverese-proxy should send traffic there.