## (Security) Users of the Signal bridge may wish to upgrade it to work around log4j vulnerability
Recently, a security vulnerability affecting the Java logging package `log4j` [has been discovered](https://www.huntress.com/blog/rapid-response-critical-rce-vulnerability-is-affecting-java). Software that uses this Java package is potentially vulnerable.
One such piece of software that is part of the playbook is the [mautrix-signal bridge](./docs/configuring-playbook-bridge-mautrix-signal.md), which [has been patched already](https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1452). If you're running this bridge, you may wish to [upgrade](./docs/maintenance-upgrading-services.md).
# 2021-11-11
## Dropped support for Postgres v9.6
Postgres v9.6 reached its end of life today, so the playbook will refuse to run for you if you're still on that version.
Synapse still supports v9.6 (for now), but we're retiring support for it early, to avoid having to maintain support for so many Postgres versions. Users that are still on Postgres v9.6 can easily [upgrade Postgres](docs/maintenance-postgres.md#upgrading-postgresql) via the playbook.
# 2021-10-23
## Hangouts bridge no longer updated, superseded by a Googlechat bridge
The mautrix-hangouts bridge is no longer receiving updates upstream and is likely to stop working in the future.
We still retain support for this bridge in the playbook, but you're encouraged to switch away from it.
There's a new [mautrix-googlechat](https://github.com/mautrix/googlechat) bridge that you can [install using the playbook](docs/configuring-playbook-bridge-mautrix-googlechat.md).
Your **Hangouts bridge data will not be migrated**, however. You need to start fresh with the new bridge.
# 2021-08-23
## LinkedIn bridging support via beeper-linkedin
@ -233,6 +262,8 @@ The fact that we've renamed Synapse's database from `homeserver` to `synapse` (i
## (Breaking Change) The mautrix-facebook bridge now requires a Postgres database
**Update from 2021-11-15**: SQLite support has been re-added to the mautrix-facebook bridge in [v0.3.2](https://github.com/mautrix/facebook/releases/tag/v0.3.2). You can ignore this changelog entry.
A new version of the [mautrix-facebook](https://github.com/tulir/mautrix-facebook) bridge has been released. It's a full rewrite of its backend and the bridge now requires Postgres. New versions of the bridge can no longer run on SQLite.
**TLDR**: if you're NOT using an [external Postgres server](docs/configuring-playbook-external-postgres.md) and have NOT forcefully kept the bridge on SQLite during [The big move to all-on-Postgres (potentially dangerous)](#the-big-move-to-all-on-postgres-potentially-dangerous), you will be automatically upgraded without manual intervention. All you need to do is send a `login` message to the Facebook bridge bot again.
@ -53,6 +53,8 @@ Using this playbook, you can get the following services configured on your serve
- (optional) the [mautrix-hangouts](https://github.com/mautrix/hangouts) bridge for bridging your Matrix server to [Google Hangouts](https://en.wikipedia.org/wiki/Google_Hangouts)
- (optional) the [mautrix-googlechat](https://github.com/mautrix/googlechat) bridge for bridging your Matrix server to [Google Chat](https://en.wikipedia.org/wiki/Google_Chat)
- (optional) the [mautrix-instagram](https://github.com/mautrix/instagram) bridge for bridging your Matrix server to [Instagram](https://instagram.com/)
- (optional) the [mautrix-signal](https://github.com/mautrix/signal) bridge for bridging your Matrix server to [Signal](https://www.signal.org/)
For `amd64`, prebuilt container images (see the [container images we use](container-images.md)) are used everywhere, because all images are available for this architecture.
For `amd64`, prebuilt container images (see the [container images we use](container-images.md)) are used for all components (except [Hydrogen](configuring-playbook-client-hydrogen.md), which goes through self-building).
For other architectures, components which have a prebuilt image make use of it. If the component is not available for the specific architecture, [self-building](self-building.md) will be used. Not all components support self-building though, so your mileage may vary.
The playbook can install and configure [mautrix-googlechat](https://github.com/mautrix/googlechat) for you.
See the project's [documentation](https://docs.mau.fi/bridges/python/googlechat/index.html) to learn what it does and why it might be useful to you.
To enable the [Google Chat](https://chat.google.com/) bridge just use the following playbook configuration:
```yaml
matrix_mautrix_googlechat_enabled: true
```
## Set up Double Puppeting
If you'd like to use [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do), you have 2 ways of going about it.
### Method 1: automatically, by enabling Shared Secret Auth
The bridge will automatically perform Double Puppeting if you enable [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) for this playbook.
This is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
### Method 2: manually, by asking each user to provide a working access token
**Note**: This method for enabling Double Puppeting can be configured only after you've already set up bridging (see [Usage](#usage)).
When using this method, **each user** that wishes to enable Double Puppeting needs to follow the following steps:
- retrieve a Matrix access token for yourself. You can use the following command:
- send the access token to the bot. Example: `login-matrix MATRIX_ACCESS_TOKEN_HERE`
- make sure you don't log out the `Mautrix-googlechat` device some time in the future, as that would break the Double Puppeting feature
## Usage
Once the bot is enabled you need to start a chat with `googlechat bridge bot` with handle `@googlechatbot:YOUR_DOMAIN` (where `YOUR_DOMAIN` is your base domain, not the `matrix.` domain).
Send `login` to the bridge bot to receive a link to the portal from which you can enable the bridging. Open the link sent by the bot and follow the instructions.
Automatic login may not work. If it does not, reload the page and select the "Manual login" checkbox before starting. Manual login involves logging into your Google account normally and then manually getting the OAuth token from browser cookies with developer tools.
Once logged in, recent chats should show up as new conversations automatically. Other chats will get portals as you receive messages.
You can learn more about authentication from the bridge's [official documentation on Authentication](https://docs.mau.fi/bridges/python/googlechat/authentication.html).
After successfully enabling bridging, you may wish to [set up Double Puppeting](#set-up-double-puppeting), if you haven't already done so.
# The [Mautrix Hangouts Bridge](https://mau.dev/mautrix/hangouts) is no longer maintained. It has changed to a [Google Chat Bridge](https://github.com/mautrix/googlechat). Setup instructions for the Google Chat Bridge can be [found here](configuring-playbook-bridge-mautrix-googlechat.md).
# Setting up Mautrix Hangouts (optional)
The playbook can install and configure [mautrix-hangouts](https://github.com/mautrix/hangouts) for you.
@ -41,13 +41,23 @@ If you're fine with such an open Jitsi instance, please skip to [Apply changes](
If you would like to control who is allowed to open meetings on your new Jitsi instance, then please follow this step to enable Jitsi's authentication and guests mode. With authentication enabled, all meeting rooms have to be opened by a registered user, after which guests are free to join. If a registered host is not yet present, guests are put on hold in individual waiting rooms.
Add these two lines to your `inventory/host_vars/matrix.DOMAIN/vars.yml` configuration:
Add these lines to your `inventory/host_vars/matrix.DOMAIN/vars.yml` configuration:
```yaml
matrix_jitsi_enable_auth: true
matrix_jitsi_enable_guests: true
matrix_jitsi_prosody_auth_internal_accounts:
- username: "jitsi-moderator"
password: "secret-password"
- username: "another-user"
password: "another-password"
```
**Caution:** Accounts added here and subsquently removed will not be automatically removed from the Prosody server until user account cleaning is integrated into the playbook.
**If you get an error** like this: "Error: Account creation/modification not supported.", it's likely that you had previously installed Jitsi without auth/guest support. In such a case, you should look into [Rebuilding your Jitsi installation](#rebuilding-your-jitsi-installation).
### (Optional) LDAP authentication
The default authentication mode of Jitsi is `internal`, however LDAP is also supported. An example LDAP configuration could be:
@ -122,19 +132,6 @@ You may want to **limit the maximum video resolution**, to save up resources on
Then re-run the playbook: `ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start`
## Required if configuring Jitsi with internal authentication: register new users
Until this gets integrated into the playbook, we need to register new users / meeting hosts for Jitsi manually.
Please SSH into your matrix host machine and execute the following command targeting the `matrix-jitsi-prosody` container:
Run this command for each user you would like to create, replacing `<USERNAME>` and `<PASSWORD>` accordingly. After you've finished, please exit the host.
**If you get an error** like this: "Error: Account creation/modification not supported.", it's likely that you had previously installed Jitsi without auth/guest support. In such a case, you should look into [Rebuilding your Jitsi installation](#rebuilding-your-jitsi-installation).
# See below for an example of how to use a locally-stored static policy
matrix_corporal_policy_provider_config: |
{
"Type": "http",
@ -74,10 +75,48 @@ Matrix Corporal operates with a specific Matrix user on your server.
By default, it's `matrix-corporal` (controllable by the `matrix_corporal_reconciliation_user_id_local_part` setting, see above).
No matter what Matrix user id you configure to run it with, make sure that:
- the Matrix Corporal user is created by [registering it](registering-users.md). Use a password you remember, as you'll need to log in from time to time to create or join rooms
- the Matrix Corporal user is created by [registering it](registering-users.md)**with administrator privileges**. Use a password you remember, as you'll need to log in from time to time to create or join rooms
- the Matrix Corporal user is joined and has Admin/Moderator-level access to any rooms you want it to manage
### Using a locally-stored static policy
If you'd like to use a [static policy file](https://github.com/devture/matrix-corporal/blob/master/docs/policy-providers.md#static-file-pull-style-policy-provider), you can use a configuration like this:
To learn more about what the policy configuration, see the matrix-corporal documentation on [policy](https://github.com/devture/matrix-corporal/blob/master/docs/policy.md).
Each time you update the policy in your `vars.yml` file, you'd need to re-run the playbook and restart matrix-corporal (`--tags=setup-all,start` or `--tags=setup-aux-files,setup-corporal,start`).
@ -71,7 +71,7 @@ After following the [Preparation](#preparation) guide above, you can take a loo
### Using another external webserver
Feel free to look at the [examples/apache](../examples/apache) directory, or the [template files in the matrix-nginx-proxy role](../roles/matrix-nginx-proxy/templates/conf.d/).
Feel free to look at the [examples/apache](../examples/apache) directory, or the [template files in the matrix-nginx-proxy role](../roles/matrix-nginx-proxy/templates/nginx/conf.d/).
## Method 2: Fronting the integrated nginx reverse-proxy webserver with another reverse-proxy
@ -111,6 +111,9 @@ matrix_coturn_enabled: false
# Trust the reverse proxy to send the correct `X-Forwarded-Proto` header as it is handling the SSL connection.
matrix_nginx_proxy_trust_forwarded_proto: true
# Trust and use the other reverse proxy's `X-Forwarded-For` header.
`matrix_synapse_metrics_enabled`|Set this to `true` to make Synapse expose metrics (locally, on the container network)
`matrix_nginx_proxy_proxy_synapse_metrics`|Set this to `true` to make matrix-nginx-proxy expose the Synapse metrics at `https://matrix.DOMAIN/_synapse/metrics`
`matrix_nginx_proxy_proxy_synapse_metrics_basic_auth_enabled`|Set this to `true` to password-protect (using HTTP Basic Auth) `https://matrix.DOMAIN/_synapse/metrics` (the username is always `prometheus`, the password is defined in `matrix_nginx_proxy_proxy_synapse_metrics_basic_auth_key`)
`matrix_nginx_proxy_proxy_synapse_metrics_basic_auth_key`|Set this to a password to use for HTTP Basic Auth for protecting `https://matrix.DOMAIN/_synapse/metrics` (the username is always `prometheus` - it's not configurable)
`matrix_nginx_proxy_proxy_synapse_metrics_basic_auth_key`|Set this to a password to use for HTTP Basic Auth for protecting `https://matrix.DOMAIN/_synapse/metrics` (the username is always `prometheus` - it's not configurable). Do not write the password in plain text. See `man 1 htpasswd` or use `htpasswd -c mypass.htpasswd prometheus` to generate the expected hash for nginx.
`matrix_server_fqn_grafana`|Use this variable to override the domain at which the Grafana web user-interface is at (defaults to `stats.DOMAIN`)
### Collecting worker metrics to an external Prometheus server
If you are using workers (`matrix_synapse_workers_enabled`) and have enabled `matrix_nginx_proxy_proxy_synapse_metrics` as described above, the playbook will also automatically proxy the all worker threads's metrics to `https://matrix.DOMAIN/_synapse-worker-TYPE-ID/metrics`, where `TYPE` corresponds to the type and `ID` to the instanceId of a worker as exemplified in `matrix_synapse_workers_enabled_list`.
The playbook also generates an exemplary prometheus.yml config file (`matrix_base_data_path/external_prometheus.yml.template`) with all the correct paths which you can copy to your Prometheus server and adapt to your needs, especially edit the specified `password_file` path and contents and path to your `synapse-v2.rules`.
### Collecting system and Postgres metrics to an external Prometheus server (advanced)
When you normally enable the Prometheus and Grafana via the playbook, it will also show general system (via node-exporter) and Postgres (via postgres-exporter) stats. If you are instead collecting your metrics to an external Prometheus server, you can follow this advanced configuration example to also export these stats.
@ -48,6 +48,8 @@ These services are not part of our default installation, but can be enabled by [
- [mautrix/hangouts](https://mau.dev/mautrix/hangouts/container_registry) - the [mautrix-hangouts](https://github.com/mautrix/hangouts) bridge to [Google Hangouts](https://en.wikipedia.org/wiki/Google_Hangouts) (optional)
- [mautrix/googlechat](https://mau.dev/mautrix/googlechat/container_registry) - the [mautrix-googlechat](https://github.com/mautrix/googlechat) bridge to [Google Chat](https://en.wikipedia.org/wiki/Google_Chat) (optional)
- [mautrix/instagram](https://mau.dev/mautrix/instagram/container_registry) - the [mautrix-instagram](https://github.com/mautrix/instagram) bridge to [Instagram](https://instagram.com/) (optional)
- [mautrix/signal](https://mau.dev/mautrix/signal/container_registry) - the [mautrix-signal](https://github.com/mautrix/signal) bridge to [Signal](https://www.signal.org/) (optional)
@ -13,6 +13,7 @@ If your database name differs, be sure to change `matrix_synapse_database_databa
The playbook supports importing Postgres dump files in **text** (e.g. `pg_dump > dump.sql`) or **gzipped** formats (e.g. `pg_dump | gzip -c > dump.sql.gz`).
Importing multiple databases (as dumped by `pg_dumpall`) is also supported.
But the migration might be a good moment, to "reset" a not properly working bridge. Be aware, that it might affect all users (new link to bridge, new roomes, ...)
Before doing the actual import, **you need to upload your Postgres dump file to the server** (any path is okay).
A table ownership issue can occur if you are importing from a Synapse installation which was both:
- migrated from SQLite to Postgres, and
@ -48,7 +50,7 @@ where `synapse_user` is the database username from the previous Synapse installa
This can be verified by examining the dump for ALTER TABLE statements which set OWNER TO that username:
```Shell
$ grep "ALTER TABLE" homeserver.sql"
$ grep "ALTER TABLE" homeserver.sql
ALTER TABLE public.access_tokens OWNER TO synapse_user;
ALTER TABLE public.account_data OWNER TO synapse_user;
ALTER TABLE public.account_data_max_stream_id OWNER TO synapse_user;
@ -60,10 +62,10 @@ ALTER TABLE public.application_services_state OWNER TO synapse_user;
It can be worked around by changing the username to `synapse`, for example by using `sed`:
```Shell
$ sed -i "s/synapse_user/synapse/g" homeserver.sql
$ sed -i "s/OWNER TO synapse_user;/OWNER TO synapse;/g" homeserver.sql
```
This uses sed to perform an 'in-place' (`-i`) replacement globally (`/g`), searching for `synapseuser` and replacing with `synapse` (`s/synapse_user/synapse`). If your database username was different, change `synapse_user` to that username instead.
This uses sed to perform an 'in-place' (`-i`) replacement globally (`/g`), searching for `synapse_user` and replacing with `synapse` (`s/synapse_user/synapse`). If your database username was different, change `synapse_user` to that username instead. Expand search/replace statement as shown in example above, in case of old user name like `matrix` - replacing `matrix` only would... well - you can imagine.
Note that if the previous import failed with an error it may have made changes which are incompatible with re-running the import task right away; if you do so it may fail with an error such as:
@ -71,6 +73,8 @@ Note that if the previous import failed with an error it may have made changes w
ERROR: relation \"access_tokens\" already exists
```
### Repeat import
In this case you can use the command suggested in the import task to clear the database before retrying the import:
```Shell
@ -79,4 +83,20 @@ In this case you can use the command suggested in the import task to clear the d
# systemctl start matrix-postgres
```
Now on your local machine run `ansible-playbook -i inventory/hosts setup.yml --tags=setup-postgres` to prepare the database roles etc.
If not, you probably get this error. `synapse` is the correct table owner, but the role is missing in database.
```
"ERROR: role synapse does not exist"
```
Once the database is clear and the ownership of the tables has been fixed in the SQL file, the import task should succeed.
Check, if `--dbname` is set to `synapse` (not `matrix`) and replace paths (or even better, copy this line from your terminal)
If you've [configured your DNS](configuring-dns.md) and have [configured the playbook](configuring-playbook.md), you can start the installation procedure.
**Note**: if you don't use SSH keys for authentication, but rather a regular password, you may need to add `--ask-pass` to the above (and all other) Ansible commands.
**Note**: if you **do** use SSH keys for authentication, **and** use a non-root user to *become* root (sudo), you may need to add `-K` (`--ask-become-pass`) to the above (and all other) Ansible commands.
The above command **doesn't start any services just yet** (another step does this later - below). Feel free to **re-run this setup command any time** you think something is off with the server configuration.
The above command **doesn't start any services just yet** (another step does this later - below).
**Notes**:
- if you **don't** use SSH keys for authentication, but rather a regular password, you may need to add `--ask-pass` to the above (and all other) Ansible commands.
- if you **do** use SSH keys for authentication, **and** use a non-root user to *become* root (sudo), you may need to add `-K` (`--ask-become-pass`) to the above (and all other) Ansible commands.
Feel free to **re-run this setup command any time** you think something is off with the server configuration.
## 2. Things you might want to do after installing
## Things you might want to do after installing
After installing, but before starting the services, you may want to do additional things like:
**Before starting the services**, you may want to do additional things like:
- [Importing an existing SQLite database (from another Synapse installation)](importing-synapse-sqlite.md) (optional)
@ -28,20 +28,22 @@ After installing, but before starting the services, you may want to do additiona
- [Importing `media_store` data files from an existing Synapse installation](importing-synapse-media-store.md) (optional)
## Starting the services
## 3. Starting the services
When you're ready to start the Matrix services (and set them up to auto-start in the future):
When you're ready to start the Matrix services (and set them up to auto-start in the future), run this command:
Now that services are running, you need to **finalize the installation process** (required for federation to work!) by [Configuring Service Discovery via .well-known](configuring-well-known.md)
## 4. Finalize the installation
Now that services are running, you need to **finalize the installation process** (required for federation to work!) by [Configuring Service Discovery via .well-known](configuring-well-known.md).
## Things to do next
## 5. Things to do next
If you have started services and **finalized the installation process** (required for federation to work!) by [Configuring Service Discovery via .well-known](configuring-well-known.md), you can:
After you have started the services and **finalized the installation process** (required for federation to work!) by [Configuring Service Discovery via .well-known](configuring-well-known.md), you can:
- [check if services work](maintenance-checking-services.md)
- or [create your first Matrix user account](registering-users.md)
matrix_identity_server_url: "{{ ('https://' + matrix_server_fqn_matrix) if matrix_ma1sd_enabled else None }}"
# If Synapse workers are enabled and matrix-nginx-proxy is disabled, certain APIs may not work over 'http://matrix-synapse:8008'.
# If Synapse workers are enabled and matrix-nginx-proxy is disabled, certain APIs may not work over 'http://matrix-synapse:{{ matrix_synapse_container_client_api_port }}'.
# This is because we explicitly disable them for the main Synapse process.
matrix_homeserver_container_url: "{{ 'http://matrix-nginx-proxy:12080' if matrix_nginx_proxy_enabled else 'http://matrix-synapse:8008' }}"
matrix_homeserver_container_url: "{{ 'http://matrix-nginx-proxy:12080' if matrix_nginx_proxy_enabled else 'http://matrix-synapse:'+ matrix_synapse_container_client_api_port|string }}"
}] if (matrix_mautrix_hangouts_enabled and matrix_mautrix_hangouts_database_engine == 'postgres' and matrix_mautrix_hangouts_database_hostname == 'matrix-postgres') else [])
}] if (matrix_mautrix_googlechat_enabled and matrix_mautrix_googlechat_database_engine == 'postgres' and matrix_mautrix_googlechat_database_hostname == 'matrix-postgres') else [])
@ -1660,18 +1723,18 @@ matrix_synapse_container_image_self_build: "{{ matrix_architecture not in ['arm6
# When ma1sd is enabled, we can use it to validate email addresses and phone numbers.
# Synapse can validate email addresses by itself as well, but it's probably not what we want by default when we have an identity server.
matrix_synapse_account_threepid_delegates_email: "{{ 'http://matrix-ma1sd:8090' if matrix_ma1sd_enabled else '' }}"
matrix_synapse_account_threepid_delegates_msisdn: "{{ 'http://matrix-ma1sd:8090' if matrix_ma1sd_enabled else '' }}"
matrix_synapse_account_threepid_delegates_email: "{{ 'http://matrix-ma1sd:' + matrix_ma1sd_container_port|string if matrix_ma1sd_enabled else '' }}"
matrix_synapse_account_threepid_delegates_msisdn: "{{ 'http://matrix-ma1sd:' + matrix_ma1sd_container_port|string if matrix_ma1sd_enabled else '' }}"
# Normally, matrix-nginx-proxy is enabled and nginx can reach Synapse over the container network.
# If matrix-nginx-proxy is not enabled, or you otherwise have a need for it,
# you can expose Synapse's ports to the host.
#
# For exposing the Matrix Client API's port (plain HTTP) to the local host.
matrix_synapse_container_client_api_host_bind_port: "{{ '' if matrix_nginx_proxy_enabled else '127.0.0.1:8008' }}"
matrix_synapse_container_client_api_host_bind_port: "{{ '' if matrix_nginx_proxy_enabled else '127.0.0.1:' + matrix_synapse_container_client_api_port|string }}"
#
# For exposing the Matrix Federation API's plain port (plain HTTP) to the local host.
matrix_synapse_container_federation_api_plain_host_bind_port: "{{ '' if matrix_nginx_proxy_enabled else '127.0.0.1:8048' }}"
matrix_synapse_container_federation_api_plain_host_bind_port: "{{ '' if matrix_nginx_proxy_enabled else '127.0.0.1:' + matrix_synapse_container_federation_api_plain_port|string }}"
#
# For exposing the Matrix Federation API's TLS port (HTTPS) to the internet on all network interfaces.
matrix_synapse_container_federation_api_tls_host_bind_port: "{{ matrix_federation_public_port if (matrix_synapse_federation_enabled and matrix_synapse_tls_federation_listener_enabled) else '' }}"
@ -1685,7 +1748,7 @@ matrix_synapse_container_manhole_api_host_bind_port: "{{ '127.0.0.1:9000' if mat
# For exposing the Synapse worker (and metrics) ports to the local host.
matrix_synapse_workers_container_host_bind_address: "{{ '127.0.0.1' if (matrix_synapse_workers_enabled and not matrix_nginx_proxy_enabled) else '' }}"
"question_description": "The OAuth2 'CLIENT ID' which can be found in the 'OAuth2' tab of your new discord application: https://discord.com/developers/applications",
"required": true,
"min": 0,
"max": 128,
"default": "{{ matrix_appservice_discord_client_id | trim }}",
"question_description": "The Bot 'TOKEN' which can be found in the 'Bot' tab of your new discord application: https://discord.com/developers/applications",
"required": true,
"min": 0,
"max": 256,
"default": "{{ matrix_appservice_discord_bot_token | trim }}",
"question_description": "The username you would like to be automatically joined and promoted to administrator (PL100) in bridged rooms. Exclude the '@' and server name postfix. So to create @stevo:example.org just enter 'stevo'.",
"required": false,
"min": 0,
"max": 1024,
"default": "",
"choices": "",
"new_question": true,
"variable": "awx_appservice_discord_admin_user",
"type": "text"
},
{
"question_name": "Auto-Admin Rooms",
"question_description": "A list of rooms you want the user to be automatically joined and promoted to administrator (PL100) in. These should be the internal IDs (for example '!axfBUsKhfAjSMBdjKX:example.org') separated by newlines.",
when:(awx_purge_mode.find("No local users [recommended]") != -1) or (awx_purge_mode.find("Number of users [slower]") != -1) or (awx_purge_mode.find("Number of events [slower]") != -1)
when:(awx_purge_mode.find("No local users [recommended]") != -1) or (awx_purge_mode.find("Number of users [slower]") != -1) or (awx_purge_mode.find("Number of events [slower]") != -1)
when:(awx_purge_mode.find("No local users [recommended]") != -1) or (awx_purge_mode.find("Number of users [slower]") != -1) or (awx_purge_mode.find("Number of events [slower]") != -1)
@ -84,7 +84,7 @@
when:(awx_purge_mode.find("No local users [recommended]") != -1) or (awx_purge_mode.find("Number of users [slower]") != -1) or (awx_purge_mode.find("Number of events [slower]") != -1)
when:(awx_purge_mode.find("No local users [recommended]") != -1) or (awx_purge_mode.find("Number of users [slower]") != -1) or (awx_purge_mode.find("Number of events [slower]") != -1)
matrix_ntpd_package:"{{ 'systemd-timesyncd' if (ansible_distribution == 'CentOS' and ansible_distribution_major_version > '7') or (ansible_distribution == 'Ubuntu' and ansible_distribution_major_version > '18') else 'ntp' }}"
matrix_ntpd_service:"{{ 'systemd-timesyncd' if (ansible_distribution == 'CentOS' and ansible_distribution_major_version > '7') or (ansible_distribution == 'Ubuntu' and ansible_distribution_major_version > '18') or ansible_distribution == 'Archlinux' else ('ntpd' if ansible_os_family == 'RedHat' else 'ntp') }}"
matrix_ntpd_package:"{{ 'systemd-timesyncd' if (ansible_distribution == 'CentOS' and ansible_distribution_major_version > '7') or (ansible_distribution == 'Ubuntu' and ansible_distribution_major_version > '18') else ( 'systemd' if ansible_os_family == 'Suse' else 'ntp' ) }}"
matrix_ntpd_service:"{{ 'systemd-timesyncd' if (ansible_distribution == 'CentOS' and ansible_distribution_major_version > '7') or (ansible_distribution == 'Ubuntu' and ansible_distribution_major_version > '18') or ansible_distribution == 'Archlinux' or ansible_os_family == 'Suse' else ('ntpd' if ansible_os_family == 'RedHat' else 'ntp') }}"
matrix_well_known_matrix_client_configuration_extension:"{{ matrix_well_known_matrix_client_configuration_extension_json|from_json if matrix_well_known_matrix_client_configuration_extension_json|from_json is mapping else {} }}"
# Holds the final `/.well-known/matrix/client` configuration (a combination of the default and its extension).
# You most likely don't need to touch this variable. Instead, see `matrix_well_known_matrix_client_configuration_default` and `matrix_well_known_matrix_client_configuration_extension_json`.
matrix_well_known_matrix_server_configuration_extension:"{{ matrix_well_known_matrix_server_configuration_extension_json|from_json if matrix_well_known_matrix_server_configuration_extension_json|from_json is mapping else {} }}"
# Holds the final `/.well-known/matrix/server` configuration (a combination of the default and its extension).
# You most likely don't need to touch this variable. Instead, see `matrix_well_known_matrix_server_configuration_default` and `matrix_well_known_matrix_server_configuration_extension_json`.
- name:Fail if on SQLite, unless on the last version supporting SQLite
fail:
msg:>-
You're trying to use the mautrix-facebook bridge with an SQLite database.
Going forward, this bridge only supports Postgres.
To learn more about this, see our changelog:https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/master/CHANGELOG.md#breaking-change-the-mautrix-facebook-bridge-now-requires-a-postgres-database
- name:Inject warning if on an old SQLite-supporting version
set_fact:
matrix_playbook_runtime_results:|
{{
matrix_playbook_runtime_results|default([])
+
[
"NOTE: Your mautrix-facebook bridge setup is still on SQLite. Your bridge is not getting any updates and will likely stop working at some point. To learn more about this, see our changelog: https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/master/CHANGELOG.md#breaking-change-the-mautrix-facebook-bridge-now-requires-a-postgres-database"
"NOTE: Your mautrix-facebook bridge is still on SQLite and on the last version that supported it, before support was dropped. Support has been subsequently re-added in v0.3.2, so we advise you to upgrade (by removing your `matrix_mautrix_facebook_docker_image` definition from vars.yml)"
when:"matrix_mautrix_facebook_database_engine == 'sqlite' and matrix_mautrix_facebook_docker_image.endswith(':da1b4ec596e334325a1589e70829dea46e73064b')"
matrix_mautrix_googlechat_configuration_extension:"{{ matrix_mautrix_googlechat_configuration_extension_yaml|from_yaml if matrix_mautrix_googlechat_configuration_extension_yaml|from_yaml is mapping else {} }}"
# Holds the final configuration (a combination of the default and its extension).
# You most likely don't need to touch this variable. Instead, see `matrix_mautrix_googlechat_configuration_yaml`.
# See https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/1070
# and https://github.com/spantaleev/matrix-docker-ansible-deploy/commit/1ab507349c752042d26def3e95884f6df8886b74#commitcomment-51108407
- name:Fail if trying to self-build on Ansible < 2.8
fail:
msg:"To self-build the Element image, you should use Ansible 2.8 or higher. See docs/ansible.md"
when:"ansible_version.major == 2 and ansible_version.minor < 8 and matrix_mautrix_googlechat_container_image_self_build and matrix_mautrix_googlechat_enabled"
Wm Salt Hale
3 years ago
committed by
GitHub