We've had people who get the impression that well-known = bad,
DNS SRV = good, and who try to use DNS SRV for server delegation.
While it's true that DNS SRV can be superior for high-availability
scenarios, it's much harder to set up and comes with its own potential
downsides.
Using the well-known method is more straightforward and is enough
for almost all of us. Throwing people into the deep for no good
reason is not nice. Hopefully wording is better after this patch.
One could also remove the two variables from the docs completely,
because they are set by the playbook automatically.
Error: javax.net.ssl.SSLPeerUnverifiedException: Certificate for
<matrix.<your-domain>> doesn't match any of the subject alternative
names: [<your-domain>]
Fixes#577 (Github Issue).
This doesn't replace all usage of `-v`, but it's a start.
People sometimes troubleshoot by deleting files (especially bridge
config files). Restarting Synapse with a missing registration.yaml file
for a given bridge, causes the `-v
/something/registration.yaml:/something/registration.yaml:ro` option
to force-create `/something/registration.yaml` as a directory.
When a path that's provided to the `-v` option is missing, Docker
auto-creates that path as a directory.
This causes more breakage and confusion later on.
We'd rather fail, instead of magically creating directories.
Using `--mount`, instead of `-v` is the solution to this.
From Docker's documentation:
> When you use --mount with type=bind, the host-path must refer to an existing path on the host.
> The path will not be created for you and the service will fail with an error if the path does not exist.
`matrix_synapse_no_tls` is now implicit, so we've gotten rid of it.
The `homeserver.yaml.j2` template has been synchronized with the
configuration generated by Synapse v0.99.1 (some new options
are present, etc.)
We had something like that on the Server Delegation how-to page,
but it's better if we have it on the SSL certificates page.
Relocated there and improved linking.
Fixes#94 (Github Issue)
