Commit Graph

474 Commits

Author SHA1 Message Date
18e31526a8 Rename some variables 2021-02-12 11:59:24 +02:00
989100b1c1 Grafana nginx proxy config 2021-02-10 22:54:14 +01:00
eb5aa93e8a Grafana
Also includes the dashboards for Synapse and for Node Exporter.

Again has only been tested on debian amd64 so far, but the grafana docker image is available for arm64 and arm32. Nice.
2021-02-10 22:54:14 +01:00
e525970b39 Prometheus Node Exporter
Basic system stats, to show stuff the synapse metrics
can't show such as resource usage by bridges, etc

Seems to work fine as well.

This too has only been tested on debian amd64 so far
2021-02-10 22:54:14 +01:00
13ef9e85cf Prometheus
Initial attempt. Seems to work fine.

Only tested on debian amd64 so far
2021-02-10 22:54:14 +01:00
064b2e533c Add variable for extra domains to get LE certs for
I felt that adding another variable was probably going to be the easiest way to do this. I may end up adding another variable to enable this feature, for consistency with some of the other things.
2021-02-06 20:02:39 +13:00
38bf1eda70 Etherpad Jitsi integration 2021-01-26 05:04:47 +01:00
4b451ff782 Etherpad role 2021-01-26 05:04:47 +01:00
d3ecc6f017 Fix bridges failing to upload media when Synapse workers are enabled 2021-01-25 13:55:08 +02:00
4d62a75f6f Get matrix-corporal to play nicely with a Synapse worker setup
We do this by creating one more layer of indirection.

First we reach some generic vhost handling matrix.DOMAIN.
A bunch of override rules are added there (capturing traffic to send to
ma1sd, etc). nginx-status and similar generic things also live there.

We then proxy to the homeserver on some other vhost (only Synapse being
available right now, but repointing this to Dendrite or other will be
possible in the future).
Then that homeserver-specific vhost does its thing to proxy to the
homeserver. It may or may not use workers, etc.

Without matrix-corporal, the flow is now:
1. matrix.DOMAIN (matrix-nginx-proxy/matrix-domain.conf)
2. matrix-nginx-proxy/matrix-synapse.conf
3. matrix-synapse

With matrix-corporal enabled, it becomes:
1. matrix.DOMAIN (matrix-nginx-proxy/matrix-domain.conf)
2. matrix-corporal
3. matrix-nginx-proxy/matrix-synapse.conf
4. matrix-synapse

(matrix-corporal gets injected at step 2).
2021-01-25 09:46:41 +02:00
63301b0ef1 Improvements around Synapse worker/metrics ports exposure
There was a `matrix_nginx_proxy_enabled|default(False)` check, but:
- it didn't seem to work reliably for some reason (hmm)
- referring to a `matrix_nginx_proxy_*` variable from within the
  `matrix-synapse` role is not ideal
- exposing always happened on `127.0.0.1`, which may not be good enough
  for some rarer setups (where the own webserver is external to the host)
2021-01-25 08:25:43 +02:00
5ca68210cd Do not handle /_matrix/federation on client-server port, nor /_matrix/client stuff on federation port
I guess it didn't hurt to do it until now, but it's not great serving
federation APIs on the client-server API port, etc.

matrix-corporal doesn't work yet (still something to be solved in the
future), but its firewalling operations will also be sabotaged
by Client-Server APIs being served on the federation port (it's a way to get around its firewalling).
2021-01-24 22:22:57 +02:00
183adec3d8 Merge remote-tracking branch 'origin/master' into synapse-workers 2021-01-23 15:04:11 +01:00
f10e3fef0d Merge branch 'master' into irc 2021-01-22 20:30:24 +00:00
e502ee33da Selfbuild appservice-irc bridge 2021-01-22 21:28:53 +01:00
f9c1d62435 Fix Postgres database (-alpine) failing to start on ARM32 2021-01-22 13:52:55 +02:00
95346f3117 Reorganize Postgres access (breaking change)
In short, this makes Synapse a 2nd class citizen,
preparing for a future where it's just one-of-many homeserver software
options.

We also no longer have a default Postgres superuser password,
which improves security.

The changelog explains more as to why this was done
and how to proceed from here.
2021-01-22 13:26:12 +02:00
024a23ed17 Upgrade mautrix-facebook to the new Postgres-only version
I had intentionally held it back in 39ea3496a4
until:
- it received more testing (there were a few bugs during the
migration, but now it seems OK)
- this migration guide was written
2021-01-20 10:12:51 +02:00
28d86e3aaa Initial work on support for matrix-corporal v2 2021-01-16 23:47:14 +02:00
a66a604e53 Selfbuild appservice-slack bridge 2021-01-14 01:29:11 +01:00
48b6487d41 Use ready-made image for mautrix-telegram on arm64
Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/793
2021-01-13 22:40:47 +02:00
105354a052 Remove useless comment 2021-01-13 17:56:10 +02:00
fd540d8592 Enable Telegram self-building 2021-01-13 16:51:45 +01:00
cd8100544b Merge remote-tracking branch 'origin/master' into synapse-workers
Sync with upstream
2021-01-08 20:58:50 +01:00
a2f6adbeaf Fix appservice-slack default db: nedb 2021-01-06 22:00:49 +01:00
6b1e25d843 Do not create matrix_bridge_sms Postgres database
That bridge only supports its own file-based database,
so preparing a Postgres database for it is pointless.
2021-01-03 10:21:59 +02:00
df8d9cfd34 Remove some TODOs
The answer to these is: it's good to have them in both places.
The role defines the obvious things it depends on (not knowing
what setup it will find itself into), and then
`group_vars/matrix_servers` "extends" it based on everything else it
knows (the homeserver being Synapse, whether or not the internal
Postgres server is being used, etc.)
2021-01-03 07:46:55 +02:00
ffb837d4bc made the bridge use the default postgres db 2021-01-02 00:39:11 +01:00
a06c58c753 Merge branch 'master' into signal 2021-01-01 21:05:00 +01:00
befffa926b Fix concatenation of additional databases
Otherwise the postgres upgrade fails with the following error:

Unexpected templating type error occurred on ({{
  [matrix_postgres_connection_username]
  +
  matrix_postgres_additional_databases|map(attribute='username')
}}
): can only concatenate list (not "generator") to list
2020-12-23 19:24:45 +01:00
ea804f2f9f Do not use underscore in salts passed to sha512
Some Ansible installations choke on it, it seems.
Similar to 9f00970c90
2020-12-23 12:59:48 +02:00
9f00970c90 Do not use salts longer than 16 characters
We've hit this problem before as well. Certain Ansible installations
choke on it.
2020-12-23 12:31:52 +02:00
f19b29846d Merge pull request #740 from jdreichmann/postgres-per-default
postgres: create databases for all services
2020-12-23 11:00:41 +02:00
ad1425eee4 Add pgloader self-building support (for ARM) 2020-12-23 09:08:54 +02:00
715bdf2c64 Add support for automatic (nedb -> Postgres) migration to mx-appservice-irc 2020-12-22 19:32:43 +02:00
815a80c290 Fix alignment issues 2020-12-22 17:16:56 +02:00
15f4cc924d Rename variables (_database_db_name -> _database_name) 2020-12-22 17:10:02 +02:00
69cc2145d2 Add support for automatic (Postgres -> SQLite) migration to mx-puppet-steam 2020-12-22 16:51:59 +02:00
ed159cc742 Move matrix_architecture to matrix-base
We were only defining this in `group_vars/matrix_servers`, which is
inconsistent with how we normally do things.
2020-12-17 11:33:18 +02:00
a197968b7f Make matrix-registration use Postgres by default
Now that 0.7.2 is out, the Docker image supports Postgres
and we can do the (SQLite -> Postgres) migration.

I've also found out that we needed to fix up the `tokens.ex_date` column
data type a bit to prevent matrix-registration from raising exceptions
when comparing `datetime.now()` with `ex_date` coming from the database.

Example:

> File "/usr/local/lib/python3.8/site-packages/matrix_registration/tokens.py", line 58, in valid
> expired = self.ex_date < datetime.now()
> TypeError: can't compare offset-naive and offset-aware datetimes
2020-12-15 23:19:56 +02:00
dd797ba6a7 Fix Postgres database importing/upgrading conflicts
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).
2020-12-14 22:28:20 +02:00
2a502db239 Add (SQLite + Postgres) support and automatic migration to matrix-dimension 2020-12-14 21:01:47 +02:00
8d74593878 Prepare matrix-registation for (SQLite + Postgres) support
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: https://github.com/ZerataX/matrix-registration/issues/44

Until this gets fixed, we'll continue default to 'sqlite'.
2020-12-14 18:58:37 +02:00
3ab7dd1abe Potentially add matrix-postgres.service as required for bridges, etc. 2020-12-14 17:22:31 +02:00
af3ea67bba Add (SQLite + Postgres) support and automatic migration to matrix-ma1sd 2020-12-14 17:16:25 +02:00
e3a0c9adda Add (Postgres + SQLite) support to matrix-reminder-bot
This has been tested and appears to work.
2020-12-14 15:02:11 +02:00
b9a04a7f95 Rename some remaining matrix_*_postgres_* vars back to matrix_*_database_*
Looks like there are some that I missed in 087dbe4ddc
2020-12-14 14:42:18 +02:00
087dbe4ddc Rename matrix_*_postgres_* back to matrix_*_database_*
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
(https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/740#discussion_r542281102)
that we don't need to be so specific and can allow for other engines (like MySQL) to use these variables.
2020-12-14 13:02:47 +02:00
2848322461 Remove some remaining _database_password usage in favor of _postgres_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).
2020-12-14 12:19:35 +02:00
6a2dd8088c Fix typo (matrix_telegram_facebook_postgres_hostname -> matrix_mautrix_telegram_postgres_hostname)
Related to 9bf8ce878e.
2020-12-14 12:13:10 +02:00