A bit late, but still better than nothing.

…s autostart

Some people requested that `--tags=start` not set up service autostart.

One can now do `--tags=start --extra-vars="matrix_services_autostart_enabled=false"`
to just start services ones and not set up autostarting.

This also disables presence if it's disabled for Synapse.

This may be a bit premature, because the bridge didn't work for me
the last time I tried it (RC3).

Some bugs have been fixed to make our config compatible with v1.0.0
though, so it may work for some people (especially those starting
fresh).

I'm not for shipping potentially broken things, but given that we were
using `docker.io/halfshot/matrix-appservice-discord:latest` and that
points to v1.0.0 already (with no other tag we can use), our setup was
already broken in any case.

Now, at least it has some chance of running.

Remove the recording button from the Jitsi UI if recording is disabled.

We've had a report of the `connection` value getting cut off,
supposedly because it contains something that breaks off the string.

Using `|to_json` takes care of it.

comments in config.js must begin with two slashes

fixes config.js

This keeps it in line with https://download.docker.com/linux/centos/docker-ce.repo

Whether or not Docker works well on CentOS 8 for our purposes
hasn't been verified yet.

Related to #300

ma1sd requires the openid endpoints for certain functionality.
Example: https://github.com/ma1uta/ma1sd/blob/90b2b5301c34168346fdc5e7eccc09d6958e999f/src/main/java/io/kamax/mxisd/auth/AccountManager.java#L67-L99

If federation is disabled, we still need to expose these openid APIs on the
federation port.

Previously, we were doing similar magic for Dimension.
As per its documentation, when running unfederated, one is to enable
the openid listener as well. As per their recommendation, people
are advised to do enable it on the Client-Server API port
and use the `federationUrl` variable to override where the federation
port is (making federation requests go to the Client-Server API).

Because ma1sd always uses the federation port (unless you do some
DNS overwriting magic using its configuration -- which we'd rather not
do), it's better if we just default to putting the `openid` listener
where it belongs - on the federation port.

With this commit, we retain the "automatically enable openid APIs" thing
we've been doing for Dimension, but move it to the federation port instead.
We also now do the same thing when ma1sd is enabled.

updated matrix-sms-bridge

Because the ARM images are not pushed yet, we hold back to v1.23.0
for now.

Continuation of aa86e0d, now that ARM images are out.

After recently updating my matrix-docker-ansible-deploy installation, matrix-appservice-discord would refuse to start, logging ECONNREFUSED to https://matrix.[mydomain]:443, which was resolving to 172.18.0.2 due to the `--hostname` in mailer grabbing that hostname.

Curious why the IRC bridge didn't have this issue, I looked into it, and it was connecting to `http://matrix-synapse:8008`.  Correcting this one to that URL resolved the issue.

Correct inabillity for appservice-discord to connect

The Docker 19.04 -> 20.10 upgrade contains the following change
in `/usr/lib/systemd/system/docker.service`:

```
-BindsTo=containerd.service
-After=network-online.target firewalld.service containerd.service
+After=network-online.target firewalld.service containerd.service multi-user.target
-Requires=docker.socket
+Requires=docker.socket containerd.service
Wants=network-online.target
```

The `multi-user.target` requirement in `After` seems to be in conflict
with our `WantedBy=multi-user.target` and `After=docker.service` /
`Requires=docker.service` definitions, causing the following error on
startup for all of our systemd services:

> Job matrix-synapse.service/start deleted to break ordering cycle starting with multi-user.target/start

A workaround which appears to work is to add `DefaultDependencies=no`
to all of our services.

If a service is enabled, a database for it is created in postgres with a uniqque password. The service can then use this database for data storage instead of relying on sqlite.

Starting with Docker 20.10, `--hostname` seems to have the side-effect
of making Docker's internal DNS server resolve said hostname to the IP
address of the container.

Because we were giving the mailer service a hostname of `matrix.DOMAIN`,
all requests destined for `matrix.DOMAIN` originating from other
services on the container network were resolving to `matrix-mailer`.
This is obviously wrong.

Initially reported here: #748

We normally try to not use the public hostname (and IP address) on the
container network and try to make services talk to one another locally,
but it sometimes could happen.

With this, we use a `matrix-mailer` hostname for the matrix-mailer
container. My testing shows that it doesn't cause any trouble with
email deliverability.

Upgrade synapse-admin (v0.5.0 -> 0.6.1)

v0.7.0 is broken right now, because it calls
`/_matrix/client/r0/admin/register`, which is now at
`/_synapse/admin/v1/register`.

This has been fixed here: zeratax/matrix-registration@6b26255

.. but it's not part of any release.

Switching to `master` (`docker.io/devture/zeratax-matrix-registration:latest`) until it gets resolved.

Reported upstream here: zeratax/matrix-registration#43

Now that a new release has been made, we no longer need to use
`latest` / `master`.

Related to 0a91097 and zeratax/matrix-registration#43

Fixes #746

Adding jitsi as well

Moving it above the "uninstalling" set of tasks is better.
Extracting it out to another file at the same time, for readability,
especially given that it will probably have to become more complex in
the future (potentially installing `jq`, etc.)

We'll most likely use one that matches the database name, but
it's better to have it configurable.

Quotes are necessary around dictionary field names.

There was a missing `}` as well.

To avoid needing to have `jq` installed on the machine, we could:
- try to run jq in a Docker container using some small image providing
that
- better yet, avoid `jq` altogether

> Invalid data passed to 'loop', it requires a list, got this instead: matrix_postgres_additional_databases. Hint: If you passed a list/dict of just one element, try adding wantlist=True to your lookup invocation or use q/query instead of lookup.

Well, or working around it, as I've done in this commit (which seems
more sane than `wantlist=True` stuff).

The tasks in `create_additional_databases.yml` will likely
ensure `matrix-postgres.service` is started, etc.

If no additional databases are defined, we'd rather not execute that
file and all these tasks that it may do in the future.

While these modules are really nice and helpful, we can't use them
for at least 2 reasons:

- for us, Postgres runs in a container on a private Docker network
(`--network=matrix`) without usually being exposed to the host.
These modules execute on the host so they won't be able to reach it.

- these modules require `psycopg2`, so we need to install it before
using it. This might or might not be its own can of worms.

Being more explicit sounds better.

People can toggle between them now. The playbook also defaults
to using SQLite if an external Postgres server is used.

Ideally, we'd be able to create databases/users in external Postgres
servers as well, but our initialization logic (and `docker run` command,
etc.) hardcode too many things right now.

…users/databases

Using the result of `password_hash` works for creating them,
but authentication seems to be failing with some tools like pgloader.

It's possible that we're not escaping things properly somewhere.
Ideally, it'd be nice to solve that. But the easier (and still
relatively safe/good) solution is to just turn that password hash
into a UUID that's safe for passing around without worrying about
escaping.

Since we'll likely have generic SQLite database importing
via [pgloader](https://pgloader.io/) for migrating bridge
databases from SQLite to Postgres, we'd rather avoid
calling the "import Synapse SQLite database" command
as just `--tags=import-sqlite-db`.

Similarly, for the media store, we'd like to mention that it's
related to Synapse as well.

We'd like to be more explicit, so as to be less confusing,
especially in light of other homeserver implementations
coming in the future.

This can be used by various bridges, etc., to import an SQLite
(or some other supported) database into Postgres.

…tgres_*`)

`matrix_SERVICE_database_engine` remains as it is - the only one with a
`_database_` infix. Postgres-related ones move to `_postgres_`.

…nnection string around

Instead of passing the connection string, we can now pass a name of a
variable, which contains a connection string.

Both are supported for having extra flexibility.

I don't use this bridge, so this is completely untested.

Should have been done during 2a99e84, but I've missed it.

Because of this, 9bf8ce8 was also incomplete and would have caused
an error.

…x_telegram_postgres_hostname)

Related to 9bf8ce8.

…es_pasword`

The only one that remains is `matrix_synapse_database_password`, but
that's something old and should be dealt with separately in the future
(unless it remains as it is).

I don't use this bridge, so this is completely untested.

Regression since 2d99ade and 9bf8ce8, respectively.

When SQLite is to be used, these bridges expect an `sqlite://`
connection string, and not a plain file name (path), like Appservice
Discord and mautrix-whatsapp do.

I don't use this bridge, so this is completely untested.

I was thinking that it makes sense to be more specific,
and using `_postgres_` also separated these variables
from the `_database_` variables that ended up in bridge configuration.

However, @jdreichmann makes a good point
(#740 (comment))
that we don't need to be so specific and can allow for other engines (like MySQL) to use these variables.

…and migration notice

…tabase_*`

Looks like there are some that I missed in 087dbe4

This has been tested and appears to work.

…in role and migration notice

…cebook

…ngouts

…legram

…atsapp

…-discord

Auto-migration and everything seems to work. It's just that
matrix-registration cannot load the Python modules required
for talking to a Postgres database.

Tracked here: zeratax/matrix-registration#44

Until this gets fixed, we'll continue default to 'sqlite'.

We were referencing them from `group_vars/matrix_servers` since
recently, but there were no such variables and they weren't being put to
use.

…ension

We were running into conflicts, because having initialized
the roles (users) and databases, trying to import leads to
errors (role XXX already exists, etc.).

We were previously ignoring the Synapse database (`homeserver`)
when upgrading/importing, because that one gets created by default
whenever the container starts.

For our additional databases, it's a similar situation now.
It's not created by default as soon as Postgres starts with an empty
database, but rather we create it as part of running the playbook.

So we either need to skip those role/database creation statements
while upgrading/importing, or to avoid creating the additional database
and rely on the import for that. I've gone for the former, because
it's already similar to what we were doing and it's simpler
(it lets `setup_postgres.yml` be the same in all scenarios).