Commit Graph

217 Commits

Author SHA1 Message Date
Slavi Pantaleev
d94d0e2ca5
Merge pull request #456 from eMPee584/synapse-workers
Synapse workers
2021-02-19 11:40:36 +02:00
Slavi Pantaleev
217b4a8808 Release Synapse v1.27.0 to ARM32 via self-building
Related to: https://matrix.org/blog/2021/02/18/synapse-1-27-0-released#dropping-armv7-docker-images
2021-02-19 09:10:16 +02:00
Béla Becker
005f4d57f9 Remove mention of sqlite3 support for Etherpad
The official Etherpad Docker image has no support for sqlite3 databases.
2021-02-18 17:39:36 +01:00
Slavi Pantaleev
daae74b074 Merge branch 'master' into synapse-workers 2021-02-16 17:31:40 +02:00
Marc Leuser
1434c371bd safer port binding of etherpad docker container
don't bind to any host port if nginx_proxy is used
only bind to localhost if it's not used
2021-02-15 10:46:23 +01:00
Slavi Pantaleev
5cfeae806b Merge branch 'master' into synapse-workers 2021-02-14 13:00:57 +02:00
Slavi Pantaleev
894679750e
Merge pull request #862 from s-thom/nginx-additional
Add additional domains for Let's Encrypt certificates to be obtained
2021-02-14 11:05:25 +02:00
Slavi Pantaleev
2b47258c6c Do not auto-expose metrics on matrix.DOMAIN/_synapse/metrics
.. and other documentation improvements.
2021-02-12 13:47:53 +02:00
Slavi Pantaleev
c8ab200cb1 Break dependency between matrix-prometheus and (matrix-prometheus-node-exporter, matrix-synapse) 2021-02-12 11:59:24 +02:00
Slavi Pantaleev
18e31526a8 Rename some variables 2021-02-12 11:59:24 +02:00
Peetz0r
989100b1c1 Grafana nginx proxy config 2021-02-10 22:54:14 +01:00
Peetz0r
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
Peetz0r
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
Peetz0r
13ef9e85cf Prometheus
Initial attempt. Seems to work fine.

Only tested on debian amd64 so far
2021-02-10 22:54:14 +01:00
Stuart Thomson
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
Béla Becker
38bf1eda70 Etherpad Jitsi integration 2021-01-26 05:04:47 +01:00
Béla Becker
4b451ff782 Etherpad role 2021-01-26 05:04:47 +01:00
Slavi Pantaleev
d3ecc6f017 Fix bridges failing to upload media when Synapse workers are enabled 2021-01-25 13:55:08 +02:00
Slavi Pantaleev
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
Slavi Pantaleev
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
Slavi Pantaleev
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
Marcel Partap
183adec3d8 Merge remote-tracking branch 'origin/master' into synapse-workers 2021-01-23 15:04:11 +01:00
Panagiotis Georgiadis
f10e3fef0d
Merge branch 'master' into irc 2021-01-22 20:30:24 +00:00
Panagiotis Georgiadis
e502ee33da
Selfbuild appservice-irc bridge 2021-01-22 21:28:53 +01:00
Slavi Pantaleev
f9c1d62435 Fix Postgres database (-alpine) failing to start on ARM32 2021-01-22 13:52:55 +02:00
Slavi Pantaleev
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
Slavi Pantaleev
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
Slavi Pantaleev
28d86e3aaa Initial work on support for matrix-corporal v2 2021-01-16 23:47:14 +02:00
Panagiotis Georgiadis
a66a604e53
Selfbuild appservice-slack bridge 2021-01-14 01:29:11 +01:00
Slavi Pantaleev
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
Slavi Pantaleev
105354a052
Remove useless comment 2021-01-13 17:56:10 +02:00
Panagiotis Georgiadis
fd540d8592
Enable Telegram self-building 2021-01-13 16:51:45 +01:00
Marcel Partap
cd8100544b Merge remote-tracking branch 'origin/master' into synapse-workers
Sync with upstream
2021-01-08 20:58:50 +01:00
teutat3s
a2f6adbeaf
Fix appservice-slack default db: nedb 2021-01-06 22:00:49 +01:00
Slavi Pantaleev
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
Slavi Pantaleev
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
Sabine Laszakovits
ffb837d4bc made the bridge use the default postgres db 2021-01-02 00:39:11 +01:00
Sabine Laszakovits
a06c58c753 Merge branch 'master' into signal 2021-01-01 21:05:00 +01:00
David Gnedt
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
Slavi Pantaleev
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
Slavi Pantaleev
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
Slavi Pantaleev
f19b29846d
Merge pull request #740 from jdreichmann/postgres-per-default
postgres: create databases for all services
2020-12-23 11:00:41 +02:00
Slavi Pantaleev
ad1425eee4 Add pgloader self-building support (for ARM) 2020-12-23 09:08:54 +02:00
Slavi Pantaleev
715bdf2c64 Add support for automatic (nedb -> Postgres) migration to mx-appservice-irc 2020-12-22 19:32:43 +02:00
Slavi Pantaleev
815a80c290 Fix alignment issues 2020-12-22 17:16:56 +02:00
Slavi Pantaleev
15f4cc924d Rename variables (_database_db_name -> _database_name) 2020-12-22 17:10:02 +02:00
Slavi Pantaleev
69cc2145d2 Add support for automatic (Postgres -> SQLite) migration to mx-puppet-steam 2020-12-22 16:51:59 +02:00
Slavi Pantaleev
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
Slavi Pantaleev
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
Slavi Pantaleev
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