Merge branch 'spantaleev:master' into default_room_version_9

Author: altsalt

CHANGELOG.md

@@ -1,3 +1,32 @@
+# 2021-12-14
+
+## (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.

README.md

@@ -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/)

collections/requirements.yml

@@ -0,0 +1,4 @@
+---
+collections:
+  - name: community.general
+  - name: community.docker  

docs/alternative-architectures.md

@@ -21,6 +21,6 @@ matrix_architecture: "arm32"
 
 ## Implementation details
 
-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.

docs/ansible.md

@@ -51,7 +51,7 @@ docker run -it --rm \
 -v `pwd`:/work \
 -v $HOME/.ssh/id_rsa:/root/.ssh/id_rsa:ro \
 --entrypoint=/bin/sh \
-docker.io/devture/ansible:2.9.14-r0
+docker.io/devture/ansible:2.10.7-r0
 ```
 
 The above command tries to mount an SSH key (`$HOME/.ssh/id_rsa`) into the container (at `/root/.ssh/id_rsa`).

docs/configuring-playbook-bridge-mautrix-googlechat.md

@@ -0,0 +1,58 @@
+# Setting up Mautrix Google Chat (optional)
+
+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:
+
+```
+curl \
+--data '{"identifier": {"type": "m.id.user", "user": "YOUR_MATRIX_USERNAME" }, "password": "YOUR_MATRIX_PASSWORD", "type": "m.login.password", "device_id": "Mautrix-googlechat", "initial_device_display_name": "Mautrix-googlechat"}' \
+https://matrix.DOMAIN/_matrix/client/r0/login
+```
+
+- 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.
+

docs/configuring-playbook-bridge-mautrix-hangouts.md

@@ -1,3 +1,5 @@
+# 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.

docs/configuring-playbook-bridge-mautrix-whatsapp.md

@@ -8,8 +8,25 @@ Use the following playbook configuration:
 
 ```yaml
 matrix_mautrix_whatsapp_enabled: true
-```
+``` 
+Whatsapp multidevice beta is required, now it is enough if Whatsapp is connected to the Internet every 2 weeks.
+
+## Enable backfilling history
+This requires a server with MSC2716 support, which is currently an experimental feature in synapse.
+Note that as of Synapse 1.46, there are still some bugs with the implementation, especially if using event persistence workers.
+Use the following playbook configuration:
 
+```yaml
+matrix_synapse_configuration_extension_yaml: |
+  experimental_features:
+    msc2716_enabled: true
+```
+```yaml
+matrix_mautrix_whatsapp_configuration_extension_yaml:
+  bridge:
+    history_sync:
+      backfill: true
+```
 
 ## Set up Double Puppeting
 

docs/configuring-playbook-jitsi.md

@@ -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:
-
-```bash
-docker exec matrix-jitsi-prosody prosodyctl --config /config/prosody.cfg.lua register <USERNAME> meet.jitsi <PASSWORD>
-```
-
-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).
-
 
 ## Usage
 

docs/configuring-playbook-matrix-corporal.md

@@ -37,6 +37,7 @@ matrix_synapse_ext_password_provider_rest_auth_endpoint: "http://matrix-corporal
 
 matrix_corporal_enabled: true
 
+# 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:
+
+```yaml
+matrix_corporal_policy_provider_config: |
+  {
+    "Type": "static_file",
+    "Path": "/etc/matrix-corporal/policy.json"
+  }
+
+# Modify the policy below as you see fit
+matrix_aux_file_definitions:
+  - dest: "{{ matrix_corporal_config_dir_path }}/policy.json"
+    content: |
+      {
+        "schemaVersion": 1,
+        "identificationStamp": "stamp-1",
+        "flags": {
+          "allowCustomUserDisplayNames": false,
+          "allowCustomUserAvatars": false,
+          "forbidRoomCreation": false,
+          "forbidEncryptedRoomCreation": true,
+          "forbidUnencryptedRoomCreation": false,
+          "allowCustomPassthroughUserPasswords": true,
+          "allowUnauthenticatedPasswordResets": false,
+          "allow3pidLogin": false
+        },
+        "managedCommunityIds": [],
+        "managedRoomIds": [],
+        "users": []
+      }
+```
+
+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`).
+
 
 ## Matrix Corporal files