From c97dbc9ec6062b844d0b4aee0d9c77d3d9d884f5 Mon Sep 17 00:00:00 2001 From: Suguru Hirahara Date: Sat, 16 Nov 2024 14:32:19 +0900 Subject: [PATCH] Update docs/howto-server-delegation.md: related to removal of matrix-nginx-proxy The current ToC was added by 065b70203ded30412d3d03ff5ad3e885f55ab78b, but the links were initially added by ef903fe544398e04f4f247e7146457fae2a7d8ae as a navigation to sections under them. This commit replaces the ToC with such navigation. Also, one of the sections was removed by f4f3d575207c6207b53d1e61d9b877f30971b6ee, 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 --- docs/howto-server-delegation.md | 28 ++++++++-------------------- 1 file changed, 8 insertions(+), 20 deletions(-) diff --git a/docs/howto-server-delegation.md b/docs/howto-server-delegation.md index 35ed957f2..a4056f397 100644 --- a/docs/howto-server-delegation.md +++ b/docs/howto-server-delegation.md @@ -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.