Remove all traces of matrix-nginx-proxy, add validation & uninstallation tasks
This commit is contained in:
Slavi Pantaleev
@ -10,9 +10,9 @@ Usually, there are 2 options:
|
||||
|
||||
- either get a separate server for the base domain, just for serving the files necessary for [Server Delegation via a well-known file](howto-server-delegation.md#server-delegation-via-a-well-known-file)
|
||||
|
||||
- or, arrange for the Matrix server to serve the base domain. This either involves you [using your own webserver](configuring-playbook-own-webserver.md) or making the integrated webserver (`matrix-nginx-proxy`) serve the base domain for you.
|
||||
- or, arrange for the Matrix server to serve the base domain. This either involves you [using your own webserver](configuring-playbook-own-webserver.md) or making the integrated webserver serve the base domain for you.
|
||||
|
||||
This documentation page tells you how to do the latter. With some easy changes, we make it possible to serve the base domain from the Matrix server via the integrated webserver (`matrix-nginx-proxy`).
|
||||
This documentation page tells you how to do the latter. With some easy changes, we make it possible to serve the base domain from the Matrix server via the integrated webserver.
|
||||
|
||||
Just **adjust your DNS records**, so that your base domain is pointed to the Matrix server's IP address (using a DNS `A` record) **and then use the following configuration**:
|
||||
|
||||
|
||||
@ -20,8 +20,6 @@ matrix_bot_buscarron_hostname: "{{ matrix_server_fqn_matrix }}"
|
||||
matrix_bot_buscarron_path_prefix: /buscarron
|
||||
```
|
||||
|
||||
**NOTE**: When using `matrix-nginx-proxy` instead of Traefik, you won't be able to override the path prefix. You can only override the domain, but that needs to happen using another variable: `matrix_server_fqn_buscarron` (e.g. `matrix_server_fqn_buscarron: "form.{{ matrix_domain }}"`).
|
||||
|
||||
|
||||
## Adjusting DNS records
|
||||
|
||||
|
||||
@ -39,8 +39,6 @@ matrix_bot_go_neb_hostname: "{{ matrix_server_fqn_matrix }}"
|
||||
matrix_bot_go_neb_path_prefix: /go-neb
|
||||
```
|
||||
|
||||
**NOTE**: When using `matrix-nginx-proxy` instead of Traefik, you won't be able to override the path prefix. You can only override the domain, but that needs to happen using another variable: `matrix_server_fqn_go_neb` (e.g. `matrix_server_fqn_go_neb: "mybot.{{ matrix_domain }}"`).
|
||||
|
||||
|
||||
## Adjusting DNS records
|
||||
|
||||
|
||||
@ -59,7 +59,7 @@ Unless indicated otherwise, the following endpoints are reachable on your `matri
|
||||
| widgets | `/hookshot/widgetapi/` | `matrix_hookshot_widgets_endpoint` | Widgets |
|
||||
| metrics | `/metrics/hookshot` | `matrix_hookshot_metrics_enabled` and exposure enabled via `matrix_hookshot_metrics_proxying_enabled` or `matrix_metrics_exposure_enabled`. Read more in the [Metrics section](#metrics) below. | Prometheus |
|
||||
|
||||
See also `matrix_hookshot_matrix_nginx_proxy_configuration` in [init.yml](/roles/custom/matrix-bridge-hookshot/tasks/inject_into_nginx_proxy.yml).
|
||||
Also see the various `matrix_hookshot_container_labels_*` variables in in [default/main.yml](/roles/custom/matrix-bridge-hookshot/default/main.yml), which expose URLs publicly.
|
||||
|
||||
The different listeners are also reachable *internally* in the docker-network via the container's name (configured by `matrix_hookshot_container_url`) and on different ports (e.g. `matrix_hookshot_appservice_port`). Read [main.yml](/roles/custom/matrix-bridge-hookshot/defaults/main.yml) in detail for more info.
|
||||
|
||||
|
||||
@ -41,12 +41,11 @@ With that, your server's users will only be able to talk among themselves, but n
|
||||
**Disabling federation does not necessarily disable the federation port** (`8448`). Services like [Dimension](configuring-playbook-dimension.md) and [ma1sd](configuring-playbook-ma1sd.md) normally rely on `openid` APIs exposed on that port. Even if you disable federation and only if necessary, we may still be exposing the federation port and serving the `openid` APIs there. To override this and completely disable Synapse's federation port use:
|
||||
|
||||
```yaml
|
||||
matrix_homeserver_federation_enabled: false
|
||||
|
||||
# This stops the federation port on the Synapse side (normally `matrix-synapse:8048` on the container network).
|
||||
matrix_synapse_federation_port_enabled: false
|
||||
|
||||
# This removes the `8448` virtual host from the matrix-nginx-proxy reverse-proxy server.
|
||||
matrix_nginx_proxy_proxy_matrix_federation_api_enabled: false
|
||||
|
||||
# This stops the federation port on the synapse-reverse-proxy-companion side (normally `matrix-synapse-reverse-proxy-companion:8048` on the container network).
|
||||
matrix_synapse_reverse_proxy_companion_federation_api_enabled: false
|
||||
```
|
||||
@ -55,6 +54,8 @@ matrix_synapse_reverse_proxy_companion_federation_api_enabled: false
|
||||
|
||||
Why? This change could be useful for people running small Synapse instances on small severs/VPSes to avoid being impacted by a simple DOS/DDOS when bandwidth, RAM, an CPU resources are limited and if your hosting provider does not provide a DOS/DDOS protection.
|
||||
|
||||
**NOTE**: this approach hasn't been tested with the new Traefik-only setup that the playbook started using in 2024-01. It may not work.
|
||||
|
||||
The following changes in the configuration file (`inventory/host_vars/matrix.<your-domain>/vars.yml`) will allow this and make it possible to proxy the federation through a CDN such as CloudFlare or any other:
|
||||
|
||||
```
|
||||
|
||||
@ -1,83 +1,3 @@
|
||||
# Configure Nginx (optional, advanced)
|
||||
|
||||
**Note**: the playbook is [in the process of moving to Traefik](../CHANGELOG.md#reverse-proxy-configuration-changes-and-initial-traefik-support). Traefik is already the default reverse-proxy for new installations and existing users are also strongly encouraged to switch to Traefik. As such, this **nginx documentation below may be incomplete or misleading**.
|
||||
|
||||
|
||||
## Using Nginx status
|
||||
|
||||
This will serve a statuspage to the hosting machine only. Useful for monitoring software like [longview](https://www.linode.com/docs/platform/longview/longview-app-for-nginx/)
|
||||
|
||||
```yaml
|
||||
matrix_nginx_proxy_proxy_matrix_nginx_status_enabled: true
|
||||
```
|
||||
|
||||
This will serve the status page under the following addresses:
|
||||
- `http://matrix.DOMAIN/nginx_status` (using HTTP)
|
||||
- `https://matrix.DOMAIN/nginx_status` (using HTTPS)
|
||||
|
||||
By default, if ```matrix_nginx_proxy_nginx_status_enabled``` is enabled, access to the status page would be allowed from the local IP address of the server. If you wish to allow access from other IP addresses, you can provide them as a list:
|
||||
|
||||
```yaml
|
||||
matrix_nginx_proxy_proxy_matrix_nginx_status_allowed_addresses:
|
||||
- 8.8.8.8
|
||||
- 1.1.1.1
|
||||
```
|
||||
|
||||
## Adjusting SSL in your server
|
||||
|
||||
You can adjust how the SSL is served by the nginx server using the `matrix_nginx_proxy_ssl_preset` variable. We support a few presets, based on the Mozilla Server Side TLS
|
||||
Recommended configurations. These presets influence the TLS Protocol, the SSL Cipher Suites and the `ssl_prefer_server_ciphers` variable of nginx.
|
||||
Possible values are:
|
||||
|
||||
- `"modern"` - For Modern clients that support TLS 1.3, with no need for backwards compatibility
|
||||
- `"intermediate"` (**default**) - Recommended configuration for a general-purpose server
|
||||
- `"old"` - Services accessed by very old clients or libraries, such as Internet Explorer 8 (Windows XP), Java 6, or OpenSSL 0.9.8
|
||||
|
||||
**Be really carefull when setting it to `"modern"`**. This could break comunication with other Matrix servers, limiting your federation posibilities.
|
||||
|
||||
Besides changing the preset (`matrix_nginx_proxy_ssl_preset`), you can also directly override these 3 variables:
|
||||
|
||||
- `matrix_nginx_proxy_ssl_protocols`: for specifying the supported TLS protocols.
|
||||
- `matrix_nginx_proxy_ssl_prefer_server_ciphers`: for specifying if the server or the client choice when negotiating the cipher. It can set to `on` or `off`.
|
||||
- `matrix_nginx_proxy_ssl_ciphers`: for specifying the SSL Cipher suites used by nginx.
|
||||
|
||||
For more information about these variables, check the `roles/custom/matrix-nginx-proxy/defaults/main.yml` file.
|
||||
|
||||
## Synapse + OpenID Connect for Single-Sign-On
|
||||
|
||||
If you want to use OpenID Connect as an SSO provider (as per the [Synapse OpenID docs](https://github.com/matrix-org/synapse/blob/develop/docs/openid.md)), you need to use the following configuration (in your `vars.yml` file) to instruct nginx to forward `/_synapse/oidc` to Synapse:
|
||||
|
||||
```yaml
|
||||
matrix_synapse_container_labels_public_client_synapse_oidc_api_enabled: true
|
||||
```
|
||||
|
||||
## Disable Nginx access logs
|
||||
|
||||
This will disable the access logging for nginx.
|
||||
|
||||
```yaml
|
||||
matrix_nginx_proxy_access_log_enabled: false
|
||||
```
|
||||
|
||||
## Additional configuration
|
||||
|
||||
This playbook also allows for additional configuration to be applied to the nginx server.
|
||||
|
||||
If you want this playbook to obtain and renew certificates for other domains, then you can set the `matrix_ssl_additional_domains_to_obtain_certificates_for` variable (as mentioned in the [Obtaining SSL certificates for additional domains](configuring-playbook-ssl-certificates.md#obtaining-ssl-certificates-for-additional-domains) documentation as well). Make sure that you have set the DNS configuration for the domains you want to include to point at your server.
|
||||
|
||||
```yaml
|
||||
matrix_ssl_additional_domains_to_obtain_certificates_for:
|
||||
- domain.one.example
|
||||
- domain.two.example
|
||||
```
|
||||
|
||||
You can include additional nginx configuration by setting the `matrix_nginx_proxy_proxy_http_additional_server_configuration_blocks` variable.
|
||||
|
||||
```yaml
|
||||
matrix_nginx_proxy_proxy_http_additional_server_configuration_blocks:
|
||||
- |
|
||||
# These lines will be included in the nginx configuration.
|
||||
# This is at the top level of the file, so you will need to define all of the `server { ... }` blocks.
|
||||
- |
|
||||
# For advanced use, have a look at the template files in `roles/custom/matrix-nginx-proxy/templates/nginx/conf.d`
|
||||
```
|
||||
Since 2024-01, this playbook no longer uses nginx as its reverse-proxy.
|
||||
|
||||
@ -6,9 +6,11 @@ If that's alright, you can skip this.
|
||||
|
||||
## Traefik
|
||||
|
||||
[Traefik](https://traefik.io/) is the default reverse-proxy for the playbook since [2023-02-26](../CHANGELOG.md/#2023-02-26).
|
||||
[Traefik](https://traefik.io/) is the default reverse-proxy for the playbook since [2023-02-26](../CHANGELOG.md/#2023-02-26) and serves **2 purposes**:
|
||||
|
||||
Besides serving public traffic, Traefik is also used for internal communication between addon services (briges, bots, etc.) and the homeserver.
|
||||
- serving public traffic and providing SSL-termination with certificates obtained from [Let's Encrypt](https://letsencrypt.org/). See [Adjusting SSL certificate retrieval](./configuring-playbook-ssl-certificates.md).
|
||||
|
||||
- assists internal communication between addon services (briges, bots, etc.) and the homeserver via an internal entrypoint (`matrix-internal-matrix-client-api`).
|
||||
|
||||
There are 2 ways to use Traefik with this playbook, as described below.
|
||||
|
||||
@ -24,7 +26,6 @@ devture_traefik_config_certificatesResolvers_acme_email: YOUR_EMAIL_ADDRESS
|
||||
|
||||
Traefik will manage SSL certificates for all services seamlessly.
|
||||
|
||||
**Note**: for a while longer, our old reverse-proxy (`matrix-nginx-proxy`) will still be installed in local-only mode. Do not be alarmed to see `matrix-nginx-proxy` running even when you've chosen Traefik as your reverse-proxy. In the near future, we'll be able to run without nginx, but we're not there yet.
|
||||
|
||||
### Traefik managed by you
|
||||
|
||||
@ -46,7 +47,7 @@ devture_traefik_certs_dumper_ssl_dir_path: "/path/to/your/traefiks/acme.json/dir
|
||||
|
||||
In this mode all roles will still have Traefik labels attached. You will, however, need to configure your Traefik instance and its entrypoints.
|
||||
|
||||
By default, the playbook configured services use a `web-secure` (443) and `matrix-federation` (8448) entrypoints, as well as a `default` certificate resolver.
|
||||
By default, the playbook configured a `default` certificate resolver and multiple entrypoints.
|
||||
|
||||
You need to configure 4 entrypoints for your Traefik server:
|
||||
|
||||
@ -186,57 +187,3 @@ Instead of [Fronting the integrated reverse-proxy webserver with another reverse
|
||||
This is more difficult, as you would need to handle the configuration for each service manually. Enabling additional services would come with extra manual work you need to do.
|
||||
|
||||
If your webserver is on the same machine, ensure your web server user (something like `http`, `apache`, `www-data`, `nginx`) is part of the `matrix` group. You should run something like this: `usermod -a -G matrix nginx`. This allows your webserver user to access files owned by the `matrix` group, so that it can serve static files from `/matrix/static-files`.
|
||||
|
||||
#### Using your own nginx reverse-proxy running on the same machine
|
||||
|
||||
**WARNING**: this type of setup is not maintained and will be removed in the near future. We recommend that you go for [Fronting the integrated reverse-proxy webserver with another reverse-proxy](#fronting-the-integrated-reverse-proxy-webserver-with-another-reverse-proxy) instead.
|
||||
|
||||
If you'll be using `nginx` running on the same machine (not in a container), you can make the playbook help you generate configuration for `nginx` with this configuration:
|
||||
|
||||
```yaml
|
||||
matrix_playbook_reverse_proxy_type: other-nginx-non-container
|
||||
|
||||
# If you want https configured in /matrix/nginx-proxy/conf.d/
|
||||
matrix_nginx_proxy_https_enabled: true
|
||||
|
||||
# If you will manage SSL certificates yourself, uncomment the line below
|
||||
# matrix_ssl_retrieval_method: none
|
||||
|
||||
# If you're using an old nginx version, consider using a custom protocol list
|
||||
# (removing `TLSv1.3` that is enabled by default) to suit your nginx version.
|
||||
# matrix_nginx_proxy_ssl_protocols: "TLSv1.2"
|
||||
```
|
||||
|
||||
You can most likely directly use the config files installed by this playbook at: `/matrix/nginx-proxy/conf.d`. Just include them in your own `nginx.conf` like this: `include /matrix/nginx-proxy/conf.d/*.conf;`
|
||||
|
||||
#### Using your own reverse-proxy running on the same machine or elsewhere
|
||||
|
||||
**WARNING**: this is difficult to set up, likely not very well supported and will be removed in the future. We recommend that you go for [Fronting the integrated reverse-proxy webserver with another reverse-proxy](#fronting-the-integrated-reverse-proxy-webserver-with-another-reverse-proxy) instead.
|
||||
|
||||
To reverse-proxy manually for each service, use configuration like this:
|
||||
|
||||
```yaml
|
||||
# If your reverse-proxy runs on the same machine:
|
||||
matrix_playbook_reverse_proxy_type: other-on-same-host
|
||||
|
||||
# Or, if it runs on another machine:
|
||||
# matrix_playbook_reverse_proxy_type: other-on-another-host
|
||||
|
||||
# Or, optionally customize the network interface prefix (note the trailing `:` character).
|
||||
# For other-on-same-host, the interface defaults to `127.0.0.1:`.
|
||||
# For other-on-another-host, the interface defaults to `0.0.0.0:`.
|
||||
# matrix_playbook_service_host_bind_interface_prefix: '192.168.30.4:'
|
||||
```
|
||||
|
||||
With this configuration, each service will be exposed on a custom port. Example:
|
||||
|
||||
- Synapse will be exposed on port `8008`
|
||||
- [Grafana](configuring-playbook-prometheus-grafana.md) will be exposed on port `3000`
|
||||
- [synapse-admin](configuring-playbook-synapse-admin.md) will be exposed on port `8766`
|
||||
|
||||
You can capture traffic for these services and forward it to their port.
|
||||
Some of these services are configured with certain default expecations with regard to hostname, path, etc., so it's not completely arbitrary where you can host them (unless you change the defaults).
|
||||
|
||||
For each new playbook service that you enable, you'll need special handling.
|
||||
|
||||
The [`examples/`](../examples/) directory contains examples for various servers: Caddy, Apache, HAproxy, Nginx, etc.
|
||||
|
||||
@ -20,8 +20,6 @@ matrix_rageshake_hostname: "{{ matrix_server_fqn_matrix }}"
|
||||
matrix_rageshake_path_prefix: /rageshake
|
||||
```
|
||||
|
||||
**NOTE**: When using `matrix-nginx-proxy` instead of Traefik, you won't be able to override the path prefix. You can only override the domain, but that needs to happen using another variable: `matrix_server_fqn_rageshake` (e.g. `matrix_server_fqn_rageshake: "some-domain.{{ matrix_domain }}"`).
|
||||
|
||||
|
||||
## Adjusting DNS records
|
||||
|
||||
|
||||
@ -10,8 +10,6 @@ Element X iOS is [available on TestFlight](https://testflight.apple.com/join/uZb
|
||||
|
||||
Element X Android is [available on the Github Releases page](https://github.com/element-hq/element-x-android/releases).
|
||||
|
||||
**NOTE**: The Sliding Sync proxy **only works with the Traefik reverse-proxy**. If you have an old server installation (from the time `matrix-nginx-proxy` was our default reverse-proxy - `matrix_playbook_reverse_proxy_type: playbook-managed-nginx`), you won't be able to use Sliding Sync.
|
||||
|
||||
**NOTE**: The sliding-sync proxy is **not required** when using the **Conduit homeserver**. Starting from version `0.6.0` Conduit has native support for some sliding sync features. If there are issues with the native implementation, you might have a better experience when enabling the sliding-sync proxy anyway.
|
||||
|
||||
## Decide on a domain and path
|
||||
|
||||
@ -26,8 +26,6 @@ matrix_sygnal_hostname: "{{ matrix_server_fqn_matrix }}"
|
||||
matrix_sygnal_path_prefix: /sygnal
|
||||
```
|
||||
|
||||
**NOTE**: When using `matrix-nginx-proxy` instead of Traefik, you won't be able to override the path prefix. You can only override the domain, but that needs to happen using another variable: `matrix_server_fqn_sygnal` (e.g. `matrix_server_fqn_sygnal: "push.{{ matrix_domain }}"`).
|
||||
|
||||
|
||||
## Adjusting DNS records
|
||||
|
||||
|
||||
@ -37,15 +37,3 @@ After installation, Synapse Admin will be accessible at: `https://matrix.DOMAIN/
|
||||
To use Synapse Admin, you need to have [registered at least one administrator account](registering-users.md) on your server.
|
||||
|
||||
The Homeserver URL to use on Synapse Admin's login page is: `https://matrix.DOMAIN`
|
||||
|
||||
### Sample configuration for running behind Caddy v2
|
||||
|
||||
Below is a sample configuration for using this playbook with a [Caddy](https://caddyserver.com/v2) 2.0 reverse proxy (non-default configuration where `matrix-nginx-proxy` is disabled - `matrix_nginx_proxy_enabled: false`).
|
||||
|
||||
```caddy
|
||||
# This is a basic configuration that will function the same as the default nginx proxy - exposing the synapse-admin panel to matrix.YOURSERVER.com/synapse-admin/
|
||||
handle_path /synapse-admin* {
|
||||
reverse_proxy localhost:8766 {
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
@ -73,7 +73,7 @@ matrix_synapse_oidc_providers:
|
||||
backchannel_logout_enabled: true # Optional
|
||||
```
|
||||
|
||||
**NOTE**: if you inject the OIDC configuration using `matrix_synapse_configuration_extension_yaml` (instead of `matrix_synapse_oidc_enabled: true` + `matrix_synapse_oidc_providers`), then the OIDC routes (`/_synapse/oidc`) will not be publicly exposed automatically. In such a case, you'd need to expose them manually by toggling: `matrix_synapse_container_labels_public_client_synapse_oidc_api_enabled: true`.
|
||||
**NOTE**: if you inject the OIDC configuration using `matrix_synapse_configuration_extension_yaml` (instead of `matrix_synapse_oidc_enabled: true` + `matrix_synapse_oidc_providers` as explained above), then the OIDC routes (`/_synapse/oidc`) will not be publicly exposed automatically. In such a case, you'd need to expose them manually by toggling: `matrix_synapse_container_labels_public_client_synapse_oidc_api_enabled: true`.
|
||||
|
||||
|
||||
## Customizing templates
|
||||
|
||||
@ -65,8 +65,6 @@ When you're done with all the configuration you'd like to do, continue with [Ins
|
||||
|
||||
- [Configure the Traefik reverse-proxy](configuring-playbook-traefik.md) (optional, advanced)
|
||||
|
||||
- (Deprecated) [Configure the Nginx reverse-proxy](configuring-playbook-nginx.md) (optional, advanced)
|
||||
|
||||
- [Using your own webserver, instead of this playbook's default reverse-proxy](configuring-playbook-own-webserver.md) (optional, advanced)
|
||||
|
||||
- [Adjusting TURN server configuration](configuring-playbook-turn.md) (optional, advanced)
|
||||
|
||||
@ -73,50 +73,22 @@ Based on your setup, you have different ways to go about it:
|
||||
- [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 matrix-nginx-proxy](#serving-the-federation-api-with-your-certificates-and-matrix-nginx-proxy)
|
||||
- [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 matrix-nginx-proxy
|
||||
|
||||
**If you are using matrix-nginx-proxy**, a reverse-proxy webserver used by default in this playbook, you only need to override the certificates used for the Matrix Federation API. You can do that using:
|
||||
|
||||
```yaml
|
||||
# Adjust paths below to point to your certificate.
|
||||
#
|
||||
# NOTE: these are in-container paths. `/matrix/ssl` on the host is mounted into the container
|
||||
# at the same path (`/matrix/ssl`) by default, so if that's the path you need, it would be seamless.
|
||||
matrix_nginx_proxy_proxy_matrix_federation_api_ssl_certificate: /matrix/ssl/config/live/<your-domain>/fullchain.pem
|
||||
matrix_nginx_proxy_proxy_matrix_federation_api_ssl_certificate_key: /matrix/ssl/config/live/<your-domain>/privkey.pem
|
||||
```
|
||||
|
||||
If your files are not in `/matrix/ssl` but in some other location, you would need to mount them into the container:
|
||||
|
||||
```yaml
|
||||
matrix_nginx_proxy_container_extra_arguments:
|
||||
- "--mount type=bind,src=/some/path/on/the/host,dst=/some/path/inside/the/container,ro"
|
||||
```
|
||||
|
||||
You then refer to them (for `matrix_nginx_proxy_proxy_matrix_federation_api_ssl_certificate` and `matrix_nginx_proxy_proxy_matrix_federation_api_ssl_certificate_key`) by using `/some/path/inside/the/container`.
|
||||
|
||||
Make sure to reload matrix-nginx-proxy once in a while (`systemctl reload matrix-nginx-proxy`), so that newer certificates can kick in.
|
||||
Reloading doesn't cause any downtime.
|
||||
|
||||
|
||||
### Serving the Federation API with your certificates and another webserver
|
||||
|
||||
**If you are NOT using matrix-nginx-proxy**, but rather some other webserver, you can set up reverse-proxying for the `tcp/8448` port by yourself.
|
||||
**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 `<your-domain>` (not for `matrix.<your-domain>`) when serving the `tcp/8448` port.
|
||||
|
||||
Proxying needs to happen to `127.0.0.1:8048` (unencrypted Synapse federation listener).
|
||||
|
||||
Make sure to reload/restart your webserver once in a while, so that newer certificates can kick in.
|
||||
|
||||
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**, if you are **NOT using matrix-nginx-proxy** and **would rather not use your own webserver for Federation traffic**, you can let Synapse handle Federation by itself.
|
||||
**Alternatively**, you can let Synapse handle Federation by itself.
|
||||
|
||||
To do that, make sure the certificate files are mounted into the Synapse container:
|
||||
|
||||
|
||||
@ -102,21 +102,6 @@ matrix_coturn_systemd_required_services_list: ['docker.service']
|
||||
# This changes the path of the loaded certificate, while maintaining the original functionality, we're now loading the wildcard certificate.
|
||||
matrix_coturn_container_additional_volumes: |
|
||||
{{
|
||||
(
|
||||
[
|
||||
{
|
||||
'src': (matrix_ssl_config_dir_path + '/live/*.' + matrix_domain + '/fullchain.pem'),
|
||||
'dst': '/fullchain.pem',
|
||||
'options': 'ro',
|
||||
},
|
||||
{
|
||||
'src': (matrix_ssl_config_dir_path + '/live/*.' + matrix_domain + '/privkey.pem'),
|
||||
'dst': '/privkey.pem',
|
||||
'options': 'ro',
|
||||
},
|
||||
] if matrix_playbook_reverse_proxy_type in ['playbook-managed-nginx', 'other-nginx-non-container'] and matrix_coturn_tls_enabled else []
|
||||
)
|
||||
+
|
||||
(
|
||||
[
|
||||
{
|
||||
@ -180,21 +165,6 @@ matrix_coturn_systemd_required_services_list: ['docker.service']
|
||||
# This changes the path of the loaded certificate, while maintaining the original functionality, we're now loading the wildcard certificate.
|
||||
matrix_coturn_container_additional_volumes: |
|
||||
{{
|
||||
(
|
||||
[
|
||||
{
|
||||
'src': (matrix_ssl_config_dir_path + '/live/*.' + matrix_domain + '/fullchain.pem'),
|
||||
'dst': '/fullchain.pem',
|
||||
'options': 'ro',
|
||||
},
|
||||
{
|
||||
'src': (matrix_ssl_config_dir_path + '/live/*.' + matrix_domain + '/privkey.pem'),
|
||||
'dst': '/privkey.pem',
|
||||
'options': 'ro',
|
||||
},
|
||||
] if matrix_playbook_reverse_proxy_type in ['playbook-managed-nginx', 'other-nginx-non-container'] and matrix_coturn_tls_enabled else []
|
||||
)
|
||||
+
|
||||
(
|
||||
[
|
||||
{
|
||||
|
||||
@ -4,15 +4,20 @@
|
||||
|
||||
You can check the status of your services by using `systemctl status`. Example:
|
||||
```
|
||||
sudo systemctl status matrix-nginx-proxy
|
||||
sudo systemctl status matrix-synapse
|
||||
|
||||
● matrix-nginx-proxy.service - Matrix nginx proxy server
|
||||
Loaded: loaded (/etc/systemd/system/matrix-nginx-proxy.service; enabled; vendor preset: enabled)
|
||||
Active: active (running) since Wed 2018-11-14 19:38:35 UTC; 49min ago
|
||||
● matrix-synapse.service - Synapse server
|
||||
Loaded: loaded (/etc/systemd/system/matrix-synapse.service; enabled; vendor preset: enabled)
|
||||
Active: active (running) since Sun 2024-01-14 09:13:06 UTC; 1h 31min ago
|
||||
```
|
||||
|
||||
You can see the logs by using journalctl. Example:
|
||||
```
|
||||
Docker containers that the playbook configures are supervised by [systemd](https://wiki.archlinux.org/title/Systemd) and their logs are configured to go to [systemd-journald](https://wiki.archlinux.org/title/Systemd/Journal).
|
||||
|
||||
To prevent double-logging, Docker logging is disabled by explicitly passing `--log-driver=none` to all containers. Due to this, you **cannot** view logs using `docker logs`.
|
||||
|
||||
To view systemd-journald logs using [journalctl](https://man.archlinux.org/man/journalctl.1), run a command like this:
|
||||
|
||||
```sh
|
||||
sudo journalctl -fu matrix-synapse
|
||||
```
|
||||
|
||||
|
||||
Reference in New Issue
Block a user