Commit graph

95 commits

Author SHA1 Message Date
Slavi Pantaleev 0ca21d80d7 Add Synapse Maintenance docs and synapse-janitor integration 2019-07-08 09:38:36 +03:00
Slavi Pantaleev 631a14bf0c Rename run control variables for consistency 2019-07-08 09:38:36 +03:00
Slavi Pantaleev ef5e4ad061 Make Synapse not log to text files
Somewhat related to #213 (Github Pull Request).

We've been moving in the opposite direction for quite a long time.
All services should just leave logging to systemd's journald.
2019-07-04 17:46:31 +03:00
Slavi Pantaleev 420b46ad2e
Update CHANGELOG.md 2019-06-27 09:34:08 +03:00
Slavi Pantaleev bccfd13c7f Fix changelog entry typo 2019-06-26 10:48:19 +03:00
Slavi Pantaleev 8529efcd1c Make Discord bridge configuration playbook-managed
Well, `config.yaml` has been playbook-managed for a long time.
It's now extended to match the default sample config of the Discord
bridge.

With this patch, we also make `registration.yaml` playbook-managed,
which leads us to consistency with all other bridges.

Along with that, we introduce `./config` and `./data` separation,
like we do for the other bridges.
2019-06-26 10:35:00 +03:00
Thomas Kuehne 39b6e3ed26 Added a changelog for the new WhatsApp config style
- changelog entry for commit 4797469383
2019-06-24 00:22:02 +02:00
Slavi Pantaleev e585f314b8
Merge pull request #204 from spantaleev/irc-bridge-refactoring
Make IRC bridge configuration entirely managed by the playbook
2019-06-20 17:00:16 +03:00
Slavi Pantaleev 764feb4d7b
Bump changelog entry date 2019-06-20 17:00:05 +03:00
Slavi Pantaleev c98eacdd70 Add BC Break label to old changelog entry 2019-06-20 16:59:16 +03:00
Slavi Pantaleev 174a6fcd1b Make IRC bridge configuration entirely managed by the playbook 2019-06-19 12:29:44 +03:00
Slavi Pantaleev 9b97a42ffb Add a note about DNS SRV records not being obsolete 2019-06-15 16:14:14 +03:00
Slavi Pantaleev 2a2e7a7f6c Minor changelog clarification 2019-06-15 09:53:01 +03:00
Slavi Pantaleev 4e8543ce21 Make Telegram bridge configuration playbook-managed 2019-06-15 09:43:43 +03:00
Slavi Pantaleev 2e16257e50 Do not ask for _matrix._tcp SRV records anymore
With most people on Synapse v0.99+ and Synapse v1.0 now available,
we should no longer try to be backward compatible with Synapse 0.34,
because this just complicates the instructions for no good reason.
2019-06-12 14:51:10 +03:00
Slavi Pantaleev 67c13d0a77 Update changelog 2019-06-07 15:11:25 +03:00
Slavi Pantaleev 330648a3e0 Make Facebook bridge configuration playbook-managed
Related to #193, but for the Facebook bridge.
(other bridges can be changed to do the same later).

This patch makes the bridge configuration entirely managed by the
Ansible playbook. The bridge's `config.yaml` and `registration.yaml`
configuration files are regenerated every time the playbook runs.

This allows us to apply updates to those files and to avoid
people having to manage the configuration files manually on the server.

-------------------------------------------------------------

A deficiency of the current approach to dumping YAML configuration in
`config.yaml` is that we strip all comments from it.
Later on, when the bridge actually starts, it will load and redump
(this time with comments), which will make the `config.yaml` file
change.

Subsequent playbook runs will report "changed" for the
"Ensure mautrix-facebook config.yaml installed" task, which is a little
strange.

We might wish to improve this in the future, if possible.

Still, it's better to have a (usually) somewhat meaningless "changed"
task than to what we had -- never rebuilding the configuration.
2019-06-07 14:05:53 +03:00
Slavi Pantaleev ab59cc50bd Add support for more flexible container port exposing
Fixes #171 (Github Issue).
2019-05-25 07:41:08 +09:00
Slavi Pantaleev 7a08c9b7cc Update changelog 2019-05-23 08:52:12 +09:00
Slavi Pantaleev affb99003c Improve Synapse variable naming consistency 2019-05-21 12:09:38 +09:00
Slavi Pantaleev a21b410c51 Update README and changelog 2019-05-21 11:04:58 +09:00
Slavi Pantaleev 9d14e2dcb1 Fix broken link in changelog 2019-05-09 10:31:22 +03:00
Slavi Pantaleev c669ea1b79 Update changelog 2019-05-09 10:30:08 +03:00
Slavi Pantaleev 0b034ac34b Update changelog 2019-04-03 11:28:51 +03:00
Slavi Pantaleev 59e37105e8 Add TLS support to Coturn 2019-03-19 10:24:39 +02:00
Slavi Pantaleev c545d3eb85 Add support for serving base domain via matrix-nginx-proxy 2019-03-12 23:01:16 +02:00
Slavi Pantaleev e645b0e372 Rename matrix_nginx_proxy_data_path to matrix_nginx_proxy_base_path
`matrix_nginx_proxy_data_path` has always served as a base path,
so we're renaming it to reflect that.

Along with this, we're also introducing a new "data path" variable
(`matrix_nginx_proxy_data_path`), which is really a data path this time.
It's used for storing additional, non-configuration, files related to
matrix-nginx-proxy.
2019-03-12 23:01:16 +02:00
Slavi Pantaleev 6745ee4ab6 Add changelog entry for Dimension support
Related to #107 and #111 (Github Pull Requests)
2019-03-10 19:03:04 +02:00
Slavi Pantaleev ae7e17e64a Add information about mxisd email template customization
Related to #108 (Github Pull Request).
2019-03-08 12:06:50 +02:00
Slavi Pantaleev 08aa676338 Update changelog
Related to #105 (Github Pull Request).
2019-03-05 09:23:12 +02:00
Slavi Pantaleev a43bcd81fe Rename some variables 2019-02-28 11:51:09 +02:00
Slavi Pantaleev 28a5027138 Update changelog a bit 2019-02-16 11:50:06 +02:00
Slavi Pantaleev 350b25690d Add Riot v1.0 (v1.0.1) support 2019-02-16 11:48:17 +02:00
Slavi Pantaleev 1dd4f85e61 Update changelog 2019-02-14 19:05:14 +02:00
Slavi Pantaleev 70b2f07fec Add PostgreSQL backup information 2019-02-09 14:36:47 +02:00
Slavi Pantaleev fd4bd204e1 Improve changelog entry 2019-02-06 14:02:10 +02:00
Slavi Pantaleev 33726cdb08 Fix anchor 2019-02-06 13:02:17 +02:00
Slavi Pantaleev 241a4f9ef9 Add changelog entry for Synapse v0.99 2019-02-06 12:57:33 +02:00
Slavi Pantaleev cd332d9b4e Add TLS v1.3 support to matrix-nginx-proxy
This was mentioned in #27 (Github Pull Request),
but it's just now that the nginx Docker image actually supports
TLS v1.3 and we can enable it.
2019-02-01 11:49:22 +02:00
Slavi Pantaleev 345d53b693 Update changelog 2019-01-31 20:52:20 +02:00
Slavi Pantaleev 0be7b25c64 Make (most) containers run with a read-only filesystem 2019-01-29 18:52:02 +02:00
Slavi Pantaleev 9c09978ecd Update changelog 2019-01-28 15:57:57 +02:00
Slavi Pantaleev 299a8c4c7c Make (most) containers start as non-root
This makes all containers (except mautrix-telegram and
mautrix-whatsapp), start as a non-root user.

We do this, because we don't trust some of the images.
In any case, we'd rather not trust ALL images and avoid giving
`root` access at all. We can't be sure they would drop privileges
or what they might do before they do it.

Because Postfix doesn't support running as non-root,
it had to be replaced by an Exim mail server.

The matrix-nginx-proxy nginx container image is patched up
(by replacing its main configuration) so that it can work as non-root.
It seems like there's no other good image that we can use and that is up-to-date
(https://hub.docker.com/r/nginxinc/nginx-unprivileged is outdated).

Likewise for riot-web (https://hub.docker.com/r/bubuntux/riot-web/),
we patch it up ourselves when starting (replacing the main nginx
configuration).
Ideally, it would be fixed upstream so we can simplify.
2019-01-27 20:25:13 +02:00
Slavi Pantaleev 2fdafaa85b Update CHANGELOG 2019-01-17 14:37:29 +02:00
Slavi Pantaleev f4f06ae068 Make matrix-nginx-proxy role independent of others
The matrix-nginx-proxy role can now be used independently.
This makes it consistent with all other roles, with
the `matrix-base` role remaining as their only dependency.

Separating matrix-nginx-proxy was relatively straightforward, with
the exception of the Mautrix Telegram reverse-proxying configuration.
Mautrix Telegram, being an extension/bridge, does not feel important enough
to justify its own special handling in matrix-nginx-proxy.

Thus, we've introduced the concept of "additional configuration blocks"
(`matrix_nginx_proxy_proxy_matrix_additional_server_configuration_blocks`),
where any module can register its own custom nginx server blocks.

For such dynamic registration to work, the order of role execution
becomes important. To make it possible for each module participating
in dynamic registration to verify that the order of execution is
correct, we've also introduced a `matrix_nginx_proxy_role_executed`
variable.

It should be noted that this doesn't make the matrix-synapse role
dependent on matrix-nginx-proxy. It's optional runtime detection
and registration, and it only happens in the matrix-synapse role
when `matrix_mautrix_telegram_enabled: true`.
2019-01-17 13:32:46 +02:00
Slavi Pantaleev c10182e5a6 Make roles more independent of one another
With this change, the following roles are now only dependent
on the minimal `matrix-base` role:
- `matrix-corporal`
- `matrix-coturn`
- `matrix-mailer`
- `matrix-mxisd`
- `matrix-postgres`
- `matrix-riot-web`
- `matrix-synapse`

The `matrix-nginx-proxy` role still does too much and remains
dependent on the others.

Wiring up the various (now-independent) roles happens
via a glue variables file (`group_vars/matrix-servers`).
It's triggered for all hosts in the `matrix-servers` group.

According to Ansible's rules of priority, we have the following
chain of inclusion/overriding now:
- role defaults (mostly empty or good for independent usage)
- playbook glue variables (`group_vars/matrix-servers`)
- inventory host variables (`inventory/host_vars/matrix.<your-domain>`)

All roles default to enabling their main component
(e.g. `matrix_mxisd_enabled: true`, `matrix_riot_web_enabled: true`).
Reasoning: if a role is included in a playbook (especially separately,
in another playbook), it should "work" by default.

Our playbook disables some of those if they are not generally useful
(e.g. `matrix_corporal_enabled: false`).
2019-01-16 18:05:48 +02:00
Slavi Pantaleev 515f04e936 Update CHANGELOG 2019-01-16 17:13:58 +02:00
Slavi Pantaleev 51312b8250 Split playbook into multiple roles
As suggested in #63 (Github issue), splitting the
playbook's logic into multiple roles will be beneficial for
maintainability.

This patch realizes this split. Still, some components
affect others, so the roles are not really independent of one
another. For example:
- disabling mxisd (`matrix_mxisd_enabled: false`), causes Synapse
and riot-web to reconfigure themselves with other (public)
Identity servers.

- enabling matrix-corporal (`matrix_corporal_enabled: true`) affects
how reverse-proxying (by `matrix-nginx-proxy`) is done, in order to
put matrix-corporal's gateway server in front of Synapse

We may be able to move away from such dependencies in the future,
at the expense of a more complicated manual configuration, but
it's probably not worth sacrificing the convenience we have now.

As part of this work, the way we do "start components" has been
redone now to use a loop, as suggested in #65 (Github issue).
This should make restarting faster and more reliable.
2019-01-12 18:01:10 +02:00
Slavi Pantaleev 9a9b7383e9 Completely redo how mxisd configuration gets generated
This change is provoked by a few different things:

- #54 (Github Pull Request), which rightfully says that we need a
way to support ALL mxisd configuration options easily

- the upcoming mxisd 1.3.0 release, which drops support for
property-style configuration (dot-notation), forcing us to
redo the way we generate the configuration file

With this, mxisd is much more easily configurable now
and much more easily maintaneable by us in the future
(no need to introduce additional playbook variables and logic).
2019-01-11 19:33:54 +02:00
Slavi Pantaleev b222d26c86 Switch to managing cronjobs with the Ansible cron module
As suggested in #65 (Github issue), this patch switches
cronjob management from using templates to using Ansible's `cron` module.

It also moves the management of the nginx-reload cronjob to `setup_ssl_lets_encrypt.yml`,
which is a more fitting place for it (given that this cronjob is only required when
Let's Encrypt is used).

Pros:
- using a module is more Ansible-ish than templating our own files in
special directories

- more reliable: will fail early (during playbook execution) if `/usr/bin/crontab`
is not available, which is more of a guarantee that cron is working fine
(idea: we should probably install some cron package using the playbook)

Cons:
- invocation schedule is no longer configurable, unless we define individual
variables for everything or do something smart (splitting on ' ', etc.).
Likely not necessary, however.

- requires us to deprecate and clean-up after the old way of managing cronjobs,
because it's not compatible (using the same file as before means appending
additional jobs to it)
2019-01-08 12:52:03 +02:00