finallycoffee/matrix-docker-ansible-deploy
finallycoffee/matrix-docker-ansible-deploy
5
1
Fork 0
Code Issues Pull Requests Releases Wiki Activity
b77b967171
matrix-docker-ansible-deploy/CHANGELOG.md

499 lines
23 KiB
Markdown
Raw Normal View History

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 18:25:13 +00:00
# 2019-01-xx
## Running container processes as non-root
To improve security, this playbook no longer starts container processes as the `root` user.
Update changelog
2019-01-28 13:57:57 +00:00
Most containers were dropping privileges anyway, but we were trusting them with `root` privileges until they would do that.
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 18:25:13 +00:00
Not anymore -- container processes now start as a non-root user (usually `matrix`) from the get-go.
Update changelog
2019-01-28 13:57:57 +00:00
For additional security, various [capabilities are also dropped](https://github.com/projectatomic/atomic-site/issues/203) for all containers.
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 18:25:13 +00:00
## matrix-mailer is now based on Exim, not Postfix
While we would have preferred to stay with [Postfix](http://www.postfix.org/), we found out that it cannot run as a non-root user.
We've had to replace it with [Exim](https://www.exim.org/) (via the [devture/exim-relay](https://hub.docker.com/r/devture/exim-relay) container image).
The internal `matrix-mailer` service (running in a container) now listens on port `8025` (used to be `587` before).
The playbook will update your Synapse and mxisd email settings to match (`matrix-mailer:587` -> `matrix-mailer:8025`).
Using the [devture/exim-relay](https://hub.docker.com/r/devture/exim-relay) container image instead of [panubo/postfix](https://hub.docker.com/r/panubo/postfix/) also gives us a nice disk usage reduction (~200MB -> 8MB).
Update CHANGELOG
2019-01-17 12:37:29 +00:00
# 2019-01-17
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 16:05:48 +00:00
## (BC Break) Making the playbook's roles more independent of one another
The following change **affects people running a more non-standard setup** - external Postgres or using our roles in their own other playbook.
**Most users don't need to do anything**, besides becoming aware of the new glue variables file [`group_vars/matrix-servers`](group_vars/matrix-servers).
Because people like using the playbook's components independently (outside of this playbook) and because it's much better for maintainability, we've continued working on separating them.
Still, we'd like to offer a turnkey solution for running a fully-featured Matrix server, so this playbook remains important for wiring up the various components.
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 11:32:46 +00:00
With the new changes, **all roles are now only dependent on the minimal `matrix-base` role**. They are no longer dependent among themselves.
In addition, the following components can now be completely disabled (for those who want/need to):
- `matrix-coturn` by using `matrix_coturn_enabled: false`
- `matrix-mailer` by using `matrix_mailer_enabled: false`
- `matrix-postgres` by using `matrix_postgres_enabled: false`
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 16:05:48 +00:00
The following changes had to be done:
- glue variables had to be introduced to the playbook, so it can wire together the various components. Those glue vars are stored in the [`group_vars/matrix-servers`](group_vars/matrix-servers) file. When overriding variables for a given component (role), you need to be aware of both the role defaults (`role/ROLE/defaults/main.yml`) and the role's corresponding section in the [`group_vars/matrix-servers`](group_vars/matrix-servers) file.
- `matrix_postgres_use_external` has been superceeded by the more consistently named `matrix_postgres_enabled` variable and a few other `matrix_synapse_database_` variables. See the [Using an external PostgreSQL server (optional)](docs/configuring-playbook-external-postgres.md) documentation page for an up-to-date replacement.
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 11:32:46 +00:00
- Postgres tools (`matrix-postgres-cli` and `matrix-make-user-admin`) are no longer installed if you're not enabling the `matrix-postgres` role (`matrix_postgres_enabled: false`)
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 16:05:48 +00:00
- roles, being more independent now, are more minimal and do not do so much magic for you. People that are building their own playbook using our roles will definitely need to take a look at the [`group_vars/matrix-servers`](group_vars/matrix-servers) file and adapt their playbooks with the same (or similar) wiring logic.
Update CHANGELOG
2019-01-16 15:13:58 +00:00
# 2019-01-16
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 15:53:00 +00:00
## Splitting the playbook into multiple roles
For better maintainability, the playbook logic (which all used to reside in a single `matrix-server` role)
has been split out into a number of different roles: `matrix-synapse`, `matrix-postgres`, `matrix-riot-web`, `matrix-mxisd`, etc. (see the `roles/` directory).
To keep the filesystem more consistent with this separation, the **Postgres data had to be relocated**.
The default value of `matrix_postgres_data_path` was changed from `/matrix/postgres` to `/matrix/postgres/data`. The `/matrix/postgres` directory is what we consider a base path now (new variable `matrix_postgres_base_path`). **Your Postgres data files will automatically be relocated by the playbook** (`/matrix/postgres/*` -> `/matrix/postgres/data/`) when you run with `--tags=setup-all` (or `--tags=setup-postgres`). While this shouldn't cause data-loss, **it's better if you do a Postgres backup just in case**. You'd need to restart all services after this migration (`--tags=start`).
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 17:33:54 +00:00
# 2019-01-11
## (BC Break) mxisd configuration changes
To be more flexible and to support the upcoming [mxisd](https://github.com/kamax-io/mxisd) 1.3.0 (when it gets released),
we've had to redo how mxisd gets configured.
The following variables are no longer supported by this playbook:
- `matrix_mxisd_ldap_enabled`
- `matrix_mxisd_ldap_connection_host`
- `matrix_mxisd_ldap_connection_tls`
- `matrix_mxisd_ldap_connection_port`
- `matrix_mxisd_ldap_connection_baseDn`
- `matrix_mxisd_ldap_connection_baseDns`
- `matrix_mxisd_ldap_connection_bindDn`
- `matrix_mxisd_ldap_connection_bindDn`
- `matrix_mxisd_ldap_connection_bindPassword`
- `matrix_mxisd_ldap_filter`
- `matrix_mxisd_ldap_attribute_uid_type`
- `matrix_mxisd_ldap_attribute_uid_value`
- `matrix_mxisd_ldap_connection_bindPassword`
- `matrix_mxisd_ldap_attribute_name`
- `matrix_mxisd_ldap_attribute_threepid_email`
- `matrix_mxisd_ldap_attribute_threepid_msisdn`
- `matrix_mxisd_ldap_identity_filter`
- `matrix_mxisd_ldap_identity_medium`
- `matrix_mxisd_ldap_auth_filter`
- `matrix_mxisd_ldap_directory_filter`
- `matrix_mxisd_template_config`
You are encouraged to use the `matrix_mxisd_configuration_extension_yaml` variable to define your own mxisd configuration additions and overrides.
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 15:53:00 +00:00
Refer to the [default variables file](roles/matrix-mxisd/defaults/main.yml) for more information.
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 17:33:54 +00:00
This new way of configuring mxisd is beneficial because:
- it lets us support all mxisd configuration options, as the playbook simply forwards them to mxisd without needing to care or understand them
- it lets you upgrade to newer mxisd versions and make use of their features, without us having to add support for them explicitly
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 10:24:59 +00:00
# 2019-01-08
## (BC Break) Cronjob schedule no longer configurable
Due to the way we manage cronjobs now, you can no longer configure the schedule they're invoked at.
If you were previously using `matrix_ssl_lets_encrypt_renew_cron_time_definition` or `matrix_nginx_proxy_reload_cron_time_definition`
to set a custom schedule, you should note that these variables don't affect anything anymore.
If you miss this functionality, please [open an Issue](https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/new) and let us know about your use case!
Upgrade mxisd (1.2.1 -> 1.2.2)
2018-12-23 06:49:21 +00:00
# 2018-12-23
Update README
2018-12-23 09:03:42 +00:00
## (BC Break) More SSL certificate retrieval methods
Add support for 2 more SSL certificate retrieval methods Adds support for managing certificates manually and for having the playbook generate self-signed certificates for you. With this, Let's Encrypt usage is no longer required. Fixes Github issue #50.
2018-12-23 09:00:12 +00:00
The playbook now lets you decide between 3 different SSL certificate retrieval methods:
- (default) obtaining free SSL certificates from Let's Encrypt
- generating self-signed SSL certificates
- managing SSL certificates manually
Learn more in [Adjusting SSL certificate retrieval](docs/configuring-playbook-ssl-certificates.md).
For people who use Let's Encrypt (mostly everyone, since it's the default), you'll also have to rename a variable in your configuration:
- before: `host_specific_matrix_ssl_support_email`
- after: `host_specific_matrix_ssl_lets_encrypt_support_email`
Upgrade mxisd (1.2.1 -> 1.2.2)
2018-12-23 06:49:21 +00:00
## (BC Break) mxisd upgrade with multiple base DN support
mxisd has bee upgraded to [version 1.2.2](https://github.com/kamax-matrix/mxisd/releases/tag/v1.2.2), which supports [multiple base DNs](https://github.com/kamax-matrix/mxisd/blob/v1.2.2/docs/stores/ldap.md#base).
If you were configuring this playbook's `matrix_mxisd_ldap_connection_baseDn` variable until now (a string containing a single base DN), you'll need to change to configuring the `matrix_mxisd_ldap_connection_baseDns` variable (an array containing multiple base DNs).
Example change:
- before: `matrix_mxisd_ldap_connection_baseDn: OU=Users,DC=example,DC=org`
- after: `matrix_mxisd_ldap_connection_baseDns: ['OU=Users,DC=example,DC=org']`
Upgrade Synapse (0.33.9/Python 2 -> 0.33.4/Python 3)
2018-12-21 08:13:35 +00:00
# 2018-12-21
## Synapse 0.34.0 and Python 3
Synapse has been upgraded to 0.34.0 and now uses Python 3.
Based on feedback from others, running Synapse on Python 3 is supposed to decrease memory usage significantly (~2x).
Update changelog with some past information
2018-12-21 08:25:25 +00:00
# 2018-12-12
## Riot homepage customization
You can now customize some parts of the Riot homepage (or even completely replace it with your own custom page).
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 15:53:00 +00:00
See the `matrix_riot_web_homepage_` variables in `roles/matrix-riot-web/defaults/main.yml`.
Update changelog with some past information
2018-12-21 08:25:25 +00:00
# 2018-12-04
## mxisd extensibility
The [LDAP identity store for mxisd](https://github.com/kamax-matrix/mxisd/blob/master/docs/stores/ldap.md) can now be configured easily using playbook variables (see the `matrix_mxisd_ldap_` variables in `roles/matrix-server/defaults/main.yml`).
Add LDAP auth password provider documentation and changelog description
2018-11-28 09:21:03 +00:00
# 2018-11-28
update changelog
2018-11-28 10:05:35 +00:00
## More scripts
* matrix-remove-all allows to uninstall everything with a single command
* matrix-make-user-admin allows to upgrade a user's privileges
Add LDAP auth password provider documentation and changelog description
2018-11-28 09:21:03 +00:00
## LDAP auth support via matrix-synapse-ldap3
The playbook can now install and configure [LDAP auth support](https://github.com/matrix-org/matrix-synapse-ldap3) for you.
Additional details are available in [Setting up the LDAP authentication password provider module](docs/configuring-playbook-ldap-auth.md).
Update changelog
2018-11-23 09:21:30 +00:00
# 2018-11-23
## Support for controlling public registration and room auto-join
The playbook now lets you enable public registration for users (controlled via `matrix_synapse_enable_registration`).
By default, public registration is forbidden.
You can also make people automatically get auto-joined to rooms (controlled via `matrix_synapse_auto_join_rooms`).
## Support for changing the welcome user id (welcome bot)
By default, `@riot-bot:matrix.org` is used to welcome newly registered users.
This can be changed to something else (or disabled) via the new `matrix_riot_web_welcome_user_id` variable.
Allow Synapse log levels to be configured (#23)
2018-11-14 19:39:52 +00:00
# 2018-11-14
## Ability to set Synapse log levels
The playbook now allows you to set the log levels used by Synapse. The default logging levels remain the same.
You can now override following variables with any of the supported log levels listed here: https://docs.python.org/3/library/logging.html#logging-levels
```
matrix_synapse_log_level: "INFO"
matrix_synapse_storage_sql_log_level: "INFO"
matrix_synapse_root_log_level: "INFO"
```
Update changelog
2018-11-23 09:21:30 +00:00
Allow a few parts of Riot config.json to be configured (#24)
2018-11-03 01:14:03 +00:00
# 2018-11-03
## Customize parts of Riot's config
You can now customize some parts of Riot's `config.json`. These playbook variables, with these default values, have been added:
```
matrix_riot_web_disable_custom_urls: true
matrix_riot_web_disable_guests: true
matrix_riot_web_integrations_ui_url: "https://scalar.vector.im/"
matrix_riot_web_integrations_rest_url: "https://scalar.vector.im/api"
matrix_riot_web_integrations_widgets_urls: "https://scalar.vector.im/api"
matrix_riot_web_integrations_jitsi_widget_url: "https://scalar.vector.im/api/widgets/jitsi.html"
```
This now allows you use a custom integrations manager like [Dimesion](https://dimension.t2bot.io). For example, if you wish to use the Dimension instance hosted at dimension.t2bot.io, you can set the following in your vars.yml file:
```
matrix_riot_web_integrations_ui_url: "https://dimension.t2bot.io/riot"
matrix_riot_web_integrations_rest_url: "https://dimension.t2bot.io/api/v1/scalar"
matrix_riot_web_integrations_widgets_urls: "https://dimension.t2bot.io/widgets"
matrix_riot_web_integrations_jitsi_widget_url: "https://dimension.t2bot.io/widgets/jitsi"
```
Add new variable matrix_nginx_proxy_ssl_protocols
2018-11-02 23:20:05 +00:00
## SSL protocols used to serve Riot and Synapse
Fix typo
2018-11-03 08:15:54 +00:00
There's now a new `matrix_nginx_proxy_ssl_protocols` playbook variable, which controls the SSL protocols used to serve Riot and Synapse. Its default value is `TLSv1.1 TLSv1.2`. This playbook previously used `TLSv1 TLSv1.1 TLSv1.2` to serve Riot and Synapse.
Add new variable matrix_nginx_proxy_ssl_protocols
2018-11-02 23:20:05 +00:00
You may wish to reenable TLSv1 if you need to access Riot in older browsers.
Note: Currently the dockerized nginx doesn't support TLSv1.3. See https://github.com/nginxinc/docker-nginx/issues/190 for more details.
Allow a few parts of Riot config.json to be configured (#24)
2018-11-03 01:14:03 +00:00
Rename playbook variables so they are consistently prefixed Pretty much all variables live in their own `matrix_<whatever>` prefix now and are grouped closer together in the default variables file (`roles/matrix-server/defaults/main.yml`).
2018-11-01 06:46:47 +00:00
# 2018-11-01
Add support for Postgres 11
2018-11-01 07:48:20 +00:00
## Postgres 11 support
The playbook now installs [Postgres 11](https://www.postgresql.org/about/news/1894/) by default.
If you have have an existing setup, it's likely running on an older Postgres version (9.x or 10.x). You can easily upgrade by following the [Maintenance / upgrading PostgreSQL](docs/maintenance-upgrading-postgres.md) guide.
Rename playbook variables so they are consistently prefixed Pretty much all variables live in their own `matrix_<whatever>` prefix now and are grouped closer together in the default variables file (`roles/matrix-server/defaults/main.yml`).
2018-11-01 06:46:47 +00:00
## (BC Break) Renaming playbook variables
Due to the large amount of features added to this playbook lately, to keep things manageable we've had to reorganize its configuration variables a bit.
The following playbook variables were renamed:
- from `matrix_docker_image_mxisd` to `matrix_mxisd_docker_image`
- from `matrix_docker_image_mautrix_telegram` to `matrix_mautrix_telegram_docker_image`
- from `matrix_docker_image_mautrix_whatsapp` to `matrix_mautrix_whatsapp_docker_image`
- from `matrix_docker_image_mailer` to `matrix_mailer_docker_image`
- from `matrix_docker_image_coturn` to `matrix_coturn_docker_image`
- from `matrix_docker_image_goofys` to `matrix_s3_goofys_docker_image`
- from `matrix_docker_image_riot` to `matrix_riot_web_docker_image`
- from `matrix_docker_image_nginx` to `matrix_nginx_proxy_docker_image`
- from `matrix_docker_image_synapse` to `matrix_synapse_docker_image`
- from `matrix_docker_image_postgres_v9` to `matrix_postgres_docker_image_v9`
- from `matrix_docker_image_postgres_v10` to `matrix_postgres_docker_image_v10`
- from `matrix_docker_image_postgres_latest` to `matrix_postgres_docker_image_latest`
Add support for Postgres 11
2018-11-01 07:48:20 +00:00
Update documentation
2018-10-26 16:44:58 +00:00
# 2018-10-26
## Mautrix Whatsapp bridging support
The playbook now supports bridging with [Whatsapp](https://www.whatsapp.com/) by installing the [mautrix-whatsapp](https://github.com/tulir/mautrix-whatsapp) bridge. This playbook functionality is available thanks to [@izissise](https://github.com/izissise).
Additional details are available in [Setting up Mautrix Whatsapp bridging](docs/configuring-playbook-bridge-mautrix-whatsapp.md).
Add support for controlling Matrix federation
2018-10-25 15:02:04 +00:00
# 2018-10-25
## Support for controlling Matrix federation
Fix doc file name inconsistency (configuration -> configuring)
2018-11-01 16:20:49 +00:00
The playbook can now help you with [Controlling Matrix federation](docs/configuring-playbook-federation), should you wish to run a more private (isolated) server.
Add support for controlling Matrix federation
2018-10-25 15:02:04 +00:00
Use disable_guests=true for Riot
2018-10-24 10:59:06 +00:00
# 2018-10-24
## Disabling riot-web guests
From now on, Riot's configuration setting `disable_guests` would be set to `true`.
The homeserver was rejecting guests anyway, so this is just a cosmetic change affecting Riot's UI.
Add self-check command
2018-10-21 09:58:25 +00:00
# 2018-10-21
## Self-check maintenance command
The playbook can now [check if services are configured correctly](docs/maintenance-checking-services.md).
Make user presence-status tracking configurable
2018-10-05 07:32:43 +00:00
# 2018-10-05
## Presence tracking made configurable
The playbook can now enable/disable user presence-status tracking in Synapse, through the playbook's `matrix_synapse_use_presence` variable (having a default value of `true` - enabled).
If users participate in large rooms with many other servers, disabling presence will decrease server load significantly.
Make Synapse cache factor configurable
2018-09-27 07:03:31 +00:00
# 2018-09-27
## Synapse Cache Factor made configurable
The playbook now makes the Synapse cache factor configurable, through the playbook's `matrix_synapse_cache_factor` variable (having a default value of `0.5`).
Changing that value allows you to potentially decrease RAM usage or to increase performance by caching more stuff.
Some information on it is available here: https://github.com/matrix-org/synapse#help-synapse-eats-all-my-ram
Disable Docker container logging `--log-driver=none` is used for all Docker containers now. All these containers are started through systemd anyway and get logged in journald, so there's no need for Docker to be logging the same thing using the default `json-file` driver. Doing that was growing `/var/lib/docker/containers/..` infinitely until service/container restart. As a result of this, things like `docker logs matrix-synapse` won't work anymore. `journalctl -u matrix-synapse` is how one can see the logs.
2018-09-26 06:11:19 +00:00
# 2018-09-26
## Disabling Docker container logging
`--log-driver=none` is used for all Docker containers now.
All these containers are started through systemd anyway and get logged in journald, so there's no need for Docker to be logging the same thing using the default `json-file` driver. Doing that was growing `/var/lib/docker/containers/..` infinitely until service/container restart.
As a result of this, things like `docker logs matrix-synapse` won't work anymore. `journalctl -u matrix-synapse` is how one can see the logs.
Rename variable (matrix_nginx_riot_web_data_path -> matrix_riot_web_data_path)
2018-09-17 05:24:35 +00:00
# 2018-09-17
Add Service Discovery (/.well-known/matrix/client) support
2018-09-17 07:51:46 +00:00
## Service discovery support
The playbook now helps you set up [service discovery](https://matrix.org/docs/spec/client_server/r0.4.0.html#server-discovery) using a `/.well-known/matrix/client` file.
Additional details are available in [Configuring service discovery via .well-known](docs/configuring-well-known.md).
Rename variable (matrix_nginx_riot_web_data_path -> matrix_riot_web_data_path)
2018-09-17 05:24:35 +00:00
## (BC Break) Renaming playbook variables
The following playbook variables were renamed:
- from `matrix_nginx_riot_web_data_path` to `matrix_riot_web_data_path`
Rename variable (matrix_riot_web_default_identity_server_url -> matrix_identity_server_url)
2018-09-17 05:43:54 +00:00
- from `matrix_riot_web_default_identity_server_url` to `matrix_identity_server_url`
Rename variable (matrix_nginx_riot_web_data_path -> matrix_riot_web_data_path)
2018-09-17 05:24:35 +00:00
Add the ability to control statistics-reporting for Synapse Closes Github issue #3
2018-09-07 11:49:40 +00:00
# 2018-09-07
Update README
2018-09-07 20:35:04 +00:00
## Mautrix Telegram bridging support
The playbook now supports bridging with [Telegram](https://telegram.org/) by installing the [mautrix-telegram](https://github.com/tulir/mautrix-telegram) bridge. This playbook functionality is available thanks to [@izissise](https://github.com/izissise).
Additional details are available in [Setting up Mautrix Telegram bridging](docs/configuring-playbook-bridge-mautrix-telegram.md).
Add the ability to control event_cache_size for Synapse I've found the previous 10K default value to be way too low on a bunch of servers I'm running, so it's now up to 100K and made configurable.
2018-09-07 13:13:50 +00:00
## Events cache size increase and configurability for Matrix Synapse
The playbook now lets you configure Matrix Synapse's `event_cache_size` configuration via the `matrix_synapse_event_cache_size` playbook variable.
Previously, this value was hardcoded to `"10K"`. From now on, a more reasonable default of `"100K"` is used.
Add the ability to controll password-peppering for Synapse Closes Github issue #5
2018-09-07 12:01:38 +00:00
## Password-peppering support for Matrix Synapse
The playbook now supports enabling password-peppering for increased security in Matrix Synapse via the `matrix_synapse_password_config_pepper` playbook variable. Using a password pepper is disabled by default (just like it used to be before this playbook variable got introduced) and is not to be enabled/disabled after initial setup, as that would invalidate all existing passwords.
## Statistics-reporting support for Matrix Synapse
Add the ability to control statistics-reporting for Synapse Closes Github issue #3
2018-09-07 11:49:40 +00:00
There's now a new `matrix_synapse_report_stats` playbook variable, which controls the `report_stats` configuration option for Matrix Synapse. It defaults to `false`, so no change is required to retain your privacy.
If you'd like to start reporting statistics about your homeserver (things like number of users, number of messages sent, uptime, load, etc.) to matrix.org, you can turn on stats reporting.
Switch from acmetool to certbot for SSL certificate retrieval
2018-08-29 06:37:44 +00:00
# 2018-08-29
## Changing the way SSL certificates are retrieved
We've been using [acmetool](https://github.com/hlandau/acme) (with the [willwill/acme-docker](https://hub.docker.com/r/willwill/acme-docker/) Docker image) until now.
Fix wording
2018-08-29 06:41:24 +00:00
Due to the Docker image being deprecated, and things looking bleak for acmetool's support of the newer ACME v2 API endpoint, we've switched to using [certbot](https://certbot.eff.org/) (with the [certbot/certbot](https://hub.docker.com/r/certbot/certbot/) Docker image).
Switch from acmetool to certbot for SSL certificate retrieval
2018-08-29 06:37:44 +00:00
Fix wording
2018-08-29 06:41:24 +00:00
Simply re-running the playbook will retrieve new certificates (via certbot) for you.
Switch from acmetool to certbot for SSL certificate retrieval
2018-08-29 06:37:44 +00:00
To ensure you don't leave any old files behind, though, you'd better do this:
Fix systemctl command to avoid wildcard expansion
2018-08-29 06:42:59 +00:00
- `systemctl stop 'matrix*'`
Switch from acmetool to certbot for SSL certificate retrieval
2018-08-29 06:37:44 +00:00
- stop your custom webserver, if you're running one (only affects you if you've installed with `matrix_nginx_proxy_enabled: false`)
- `mv /matrix/ssl /matrix/ssl-acmetool-delete-later`
- re-run the playbook's [installation](docs/installing.md)
- possibly delete `/matrix/ssl-acmetool-delete-later`
Add support for matrix-corporal
2018-08-21 10:34:34 +00:00
# 2018-08-21
## Matrix Corporal support
The playbook can now install and configure [matrix-corporal](https://github.com/devture/matrix-corporal) for you.
Additional details are available in [Setting up Matrix Corporal](docs/configuring-playbook-matrix-corporal.md).
Add controls for influencing Matrix Synapse's rate-limiting
2018-08-20 18:24:54 +00:00
# 2018-08-20
## Matrix Synapse rate limit control variables
The following new variables can now be configured to control Matrix Synapse's rate-limiting (default values are shown below).
```yaml
matrix_synapse_rc_messages_per_second: 0.2
matrix_synapse_rc_message_burst_count: 10.0
```
## Shared Secret Auth support via matrix-synapse-shared-secret-auth
The playbook can now install and configure [matrix-synapse-shared-secret-auth](https://github.com/devture/matrix-synapse-shared-secret-auth) for you.
Fix broken link in changelog
2018-08-20 18:27:19 +00:00
Additional details are available in [Setting up the Shared Secret Auth password provider module](docs/configuring-playbook-shared-secret-auth.md).
Add controls for influencing Matrix Synapse's rate-limiting
2018-08-20 18:24:54 +00:00
Only run federation on 8448 and client on 80 This disables federation on the 80 port, as it's not necessary. We also disable the old Angular webclient. For the federation port (8448), we disable the client APIs as those are not necessary. Those can even cause trouble if one doesn't know about them and thinks that guarding the client APIs at the 80 port is enough.
2018-08-17 04:27:02 +00:00
# 2018-08-17
Add matrix-synapse-rest-auth support
2018-08-17 06:02:12 +00:00
## REST auth support via matrix-synapse-rest-auth
The playbook can now install and configure [matrix-synapse-rest-auth](https://github.com/kamax-io/matrix-synapse-rest-auth) for you.
Additional details are available in [Setting up the REST authentication password provider module](docs/configuring-playbook-rest-auth.md).
Improve compression support
2018-08-17 05:00:38 +00:00
## Compression improvements
Shifted Matrix Synapse compression from happening in the Matrix Synapse,
to happening in the nginx proxy that's in front of it.
Additionally, `riot-web` also gets compressed now (in the nginx proxy),
which drops the initial page load's size from 5.31MB to 1.86MB.
Only run federation on 8448 and client on 80 This disables federation on the 80 port, as it's not necessary. We also disable the old Angular webclient. For the federation port (8448), we disable the client APIs as those are not necessary. Those can even cause trouble if one doesn't know about them and thinks that guarding the client APIs at the 80 port is enough.
2018-08-17 04:27:02 +00:00
## Disabling some unnecessary Synapse services
The following services are not necessary, so they have been disabled:
- on the federation port (8448): the `client` service
Fix user registration regression Regression since a302a7d7489ec, which made the Matrix Client API only available on the http port (8008) and not over the federation port (8448).
2018-08-17 09:22:05 +00:00
- on the http port (8008, exposed over 443): the old Angular `webclient` and the `federation` service
Only run federation on 8448 and client on 80 This disables federation on the 80 port, as it's not necessary. We also disable the old Angular webclient. For the federation port (8448), we disable the client APIs as those are not necessary. Those can even cause trouble if one doesn't know about them and thinks that guarding the client APIs at the 80 port is enough.
2018-08-17 04:27:02 +00:00
Federation runs only on the federation port (8448) now.
Fix user registration regression Regression since a302a7d7489ec, which made the Matrix Client API only available on the http port (8008) and not over the federation port (8448).
2018-08-17 09:22:05 +00:00
The Client APIs run only on the http port (8008) now.
Only run federation on 8448 and client on 80 This disables federation on the 80 port, as it's not necessary. We also disable the old Angular webclient. For the federation port (8448), we disable the client APIs as those are not necessary. Those can even cause trouble if one doesn't know about them and thinks that guarding the client APIs at the 80 port is enough.
2018-08-17 04:27:02 +00:00
Add mxisd Identity Server support
2018-08-15 07:23:22 +00:00
# 2018-08-15
## mxisd Identity Server support
The playbook now sets up an [mxisd](https://github.com/kamax-io/mxisd) Identity Server for you by default.
Additional details are available in [Adjusting mxisd Identity Server configuration](docs/configuring-playbook-mxisd.md).
Add email-sending support
2018-08-14 11:11:41 +00:00
# 2018-08-14
## Email-sending support
The playbook now configures an email-sending service (postfix) by default.
Additional details are available in [Adjusting email-sending settings](docs/configuring-playbook-email.md).
With this, Matrix Synapse is able to send email notifications for missed messages, etc.
Put all containers in their own isolated Docker network (matrix) Moving away from using the default bridge network to using our own. This isolates our services from other Docker containers running on the default network on the same host. The benefits are that: - isolation is a little better - we no longer share a default bridge network with any other containers that might be running on the host - there are no longer hard dependencies - we do service discovery by DNS name, and not via explicit `--link` usage during container start, so containers can start out of order and fail without bringing down others with them (`matrix-nginx-proxy` can continue running, even if one of the other services dies) In the future, when other services get introduced, the increased resilience and simplicity will help as well.
2018-08-08 05:23:36 +00:00
# 2018-08-08
Rename a bunch of playbook variables for better consistency
2018-08-08 06:17:18 +00:00
## (BC Break) Renaming playbook variables
The following playbook variables were renamed:
- from `matrix_max_upload_size_mb` to `matrix_synapse_max_upload_size_mb`
- from `matrix_max_log_file_size_mb` to `matrix_synapse_max_log_file_size_mb`
- from `matrix_max_log_files_count` to `matrix_synapse_max_log_files_count`
- from `docker_matrix_image` to `matrix_docker_image_synapse`
- from `docker_nginx_image` to `matrix_docker_image_nginx`
- from `docker_riot_image` to `matrix_docker_image_riot`
- from `docker_goofys_image` to `matrix_docker_image_goofys`
- from `docker_coturn_image` to `matrix_docker_image_coturn`
If you're overriding any of them in your `vars.yml` file, you'd need to change to the new names.
Rename Ansible playbook tag (setup-main -> setup-all)
2018-08-08 06:03:37 +00:00
## Renaming Ansible playbook tag
The command for executing the whole playbook has changed.
The `setup-main` tag got renamed to `setup-all`.
Put all containers in their own isolated Docker network (matrix) Moving away from using the default bridge network to using our own. This isolates our services from other Docker containers running on the default network on the same host. The benefits are that: - isolation is a little better - we no longer share a default bridge network with any other containers that might be running on the host - there are no longer hard dependencies - we do service discovery by DNS name, and not via explicit `--link` usage during container start, so containers can start out of order and fail without bringing down others with them (`matrix-nginx-proxy` can continue running, even if one of the other services dies) In the future, when other services get introduced, the increased resilience and simplicity will help as well.
2018-08-08 05:23:36 +00:00
## Docker container linking
Add controls for influencing Matrix Synapse's rate-limiting
2018-08-20 18:24:54 +00:00
Changed the way the Docker containers are linked together. The ones that need to communicate with others operate in a `matrix` network now and not in the default bridge network.
Reference in New Issue Copy Permalink