We have a flow like this:
1. matrix.DOMAIN vhost (matrix-domain.conf)
2. matrix-synapse vhost (matrix-synapse.conf); or matrix-corporal container, if enabled
3. (optional) matrix-synapse vhost (matrix-synapse.conf), if matrix-corporal enabled
4. matrix-synapse container
We are setting `X-Forwarded-For` correctly in step #1, but were
overwriting it in step #2 with something inaccurate.
Not doing anything in step #2 is better than doing the wrong thing.
It's probably best if we append another reverse-proxy address there
though, although what we're doing now (with this patch) seems to yield
the correct result (when matrix-corporal is not enabled).
When matrix-corporal is enabled, we still seem to do the wrong thing for
some reason. It's something to be fixed later on.
During first setup postgres takes its time to get up and running, resulting in "postgres in startup" exceptions from synapse if you run without additional services that come in between. Hence suggesting increasing the time a bit to avoid having an error which heals itself and thus is hard to spot for newcomers.
People who were disabling matrix-nginx-proxy (in favor of their own
nginx webserver) and also overriding `matrix_federation_public_port`,
found that the generated nginx configuration still hardcoded `8448`,
which forced their nginx server to use that, regardless of the fact
that `matrix_federation_public_port` was pointing elsewhere.
We now allow for the in-container federation port to be configurable,
and also automatically wire things properly.
This reverts commit fd3d48bb6d.
Normally this environment variable gets referred to from `settings.json.docker`,
but we have our own full configuration, which hardcodes `"trustProxy": true`,
thus making this useless.
This has been pointed out here:
fd3d48bb6d (commitcomment-47403097)
don't spawn an extra container
run pg_dumpall within matrix-postgres instead, ensures correct version
store under /matrix so a backup of the folder will contain a DB dump
use absolute paths just in case something in the ENV is messed up
We're talking about a webserver running on the same machine, which
imports the configuration files generated by the `matrix-nginx-proxy`
in the `/matrix/nginx-proxy/conf.d` directory.
Users who run an nginx webserver on some other machine will need to do
something different.