modified example for jitsi ldap authentication to show all available variables.

Change anonymized to more proper term as server vice this is not anonymized. Server name is the first parameter that is collected. And if server happens to be for individual use these statistics would be at personal level without any anonymising.

We recently had a report of the Postgres backup container's log file
growing the size of /var/lib/docker until it ran out of disk space.

Trying to prevent similar problems in the future.

Related to #620 (Github Pull Request).

Potentially the CURLing could be a better approach, since then you don't leave spare sessions hanging.

Add an example to open all domains for registration in relation to black- and whitelists.

Fixes #562 (Github Issue)

Fixes #595 (Github Issue)

Adding a comment with regard to DNS propagation

Fixes #586 (Github Issue)

Related to #583 (Github Issue).

If a Postgres dump contains ALTER TABLE ... OWNER_TO <username>
statements which set the owner to a username different from
'synapse' the post Postgres import task will fail complaining
about lack of role.

Changing the matrix_postgres_connection_username group var has no
effect. However, the ALTER TABLE statements (and accompanying comments)
can be rewritten to change the username to 'synapse', which permits the
import task to succeed.

From a sample of 1, having the owner set in this was causes no
discernable side effects on the homeserver.

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).

Fixes #573 (Github Issue).

Related to #557 (Github Pull Request).

Related to #540 (Github Pull Request).

Related to #551 and #555 (Github Pull Requests).

Signed-off-by: Tulir Asokan <tulir@maunium.net>

`matrix_container_images_self_build` was not really doing anything
anymore. It previously was influencing `matrix_*_self_build` variables,
but it's no longer the case since some time ago.

Individual `matrix_*_self_build` variables are still available.
People that would like to toggle self-building for a specific component
ought to use those.

These variables are also controlled automatically (via
`group_vars/matrix_servers`) depending on `matrix_architecture`.

In other words, self-building is being done automatically for
all components when they don't have a prebuilt image for the specified
architecture. Some components only support `amd64`, while others also
have images for other architectures.