Merge branch 'master' of https://github.com/spantaleev/matrix-docker-ansible-deploy

docs/README.md

@@ -12,6 +12,8 @@
 
 - [Registering users](registering-users.md)
 
+- [Updating users passwords](updating-users-passwords.md)
+
 - [Configuring service discovery via .well-known](configuring-well-known.md)
 
 - [Maintenance / checking if services work](maintenance-checking-services.md)

docs/configuring-dns.md

@@ -54,9 +54,9 @@ The SRV record should look like this:
 - Name: `_matrix._tcp` (use this text as-is)
 - Content: `10 0 8448 matrix.<your-domain>` (replace `<your-domain>` with your own)
 
-A [new file-based mechanism for Federation Server Discovery](configuring-well-known.md#introduction-to-federation-server-discovery) is superseding the `_matrix._tcp` SRV record. **During the transition phase, you'll need to set up both mechanisms**. We'll instruct you how to set up the file-based mechanism after the [installation phase](installing.md) for this playbook.
+A [new file-based mechanism for Federation Server Discovery](configuring-well-known.md#introduction-to-federation-server-discovery) is superseding the `_matrix._tcp` SRV record for our use case. **During the transition phase, you'll need to set up both mechanisms**. We'll instruct you how to set up the file-based mechanism after the [installation phase](installing.md) for this playbook.
 
-Doing delegation/redirection of Matrix services using a DNS SRV record (`_matrix._tcp`) is a **temporary measure** that is only necessary before Synapse v1.0 is released.
+Doing delegation/redirection of Matrix services using a DNS SRV record (`_matrix._tcp`) is a **temporary measure** for our use-case, that will only be necessary before Synapse v1.0 is released.
 
 As more and more people upgrade to the Synapse v0.99 transitional release and just before the final Synapse v1.0 gets released, at some point in the near future **you will need to remove the `_matrix._tcp` SRV record** and leave only the [new file-based mechanism for Federation Server Discovery](configuring-well-known.md#introduction-to-federation-server-discovery) in place.
 

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

@@ -0,0 +1,11 @@
+# Setting up Mautrix Facebook (optional)
+
+The playbook can install and configure [mautrix-facebook](https://github.com/tulir/mautrix-facebook) for you.
+
+See the project's [documentation](https://github.com/tulir/mautrix-facebook/wiki#usage) to learn what it does and why it might be useful to you.
+
+```yaml
+matrix_mautrix_facebook_enabled: true
+```
+
+You then need to start a chat with `@facebookbot:YOUR_DOMAIN` (where `YOUR_DOMAIN` is your base domain, not the `matrix.` domain).

docs/configuring-playbook-mxisd.md

@@ -24,6 +24,19 @@ If you'd like to change the default email templates used by mxisd, take a look a
 (in the `roles/matrix-mxisd/defaults/main.yml` file.
 
 
+## mxisd-controlled Registration
+
+To use the [Registration](https://github.com/kamax-matrix/mxisd/blob/master/docs/features/registration.md) feature of mxisd, you can make use of the following variables:
+
+- `matrix_synapse_enable_registration` - to enable user-initiated registration in Synapse
+
+- `matrix_synapse_registrations_require_3pid` - to control the types of 3pid (`'email'`, `'msisdn'`) required by the Synapse server for registering
+
+- variables prefixed with `matrix_nginx_proxy_proxy_matrix_3pid_registration_` (e.g. `matrix_nginx_proxy_proxy_matrix_3pid_registration_enabled`) - to configure the integrated nginx webserver to send registration requests to mxisd (instead of Synapse), so it can apply its additional functionality
+
+- `matrix_mxisd_configuration_extension_yaml` - to configure mxisd as required. See the [Registration feature's docs](https://github.com/kamax-matrix/mxisd/blob/master/docs/features/registration.md) for inspiration. Also see the [Additional features](#additional-features) section below to learn more about how to use `matrix_mxisd_configuration_extension_yaml`.
+
+
 ## Additional features
 
 What this playbook configures for your is some bare minimum Identity Server functionality, so that you won't need to rely on external 3rd party services.

docs/configuring-playbook-s3.md

@@ -3,9 +3,11 @@
 By default, this playbook configures your server to store Synapse's content repository (`media_store`) files on the local filesystem.
 If that's alright, you can skip this.
 
-If you'd like to store Synapse's content repository (`media_store`) files on Amazon S3,
+If you'd like to store Synapse's content repository (`media_store`) files on Amazon S3 (or other S3-compatible service),
 you can let this playbook configure [Goofys](https://github.com/kahing/goofys) for you.
 
+## Amazon S3
+
 You'll need an Amazon S3 bucket and some IAM user credentials (access key + secret key) with full write access to the bucket. Example security policy:
 
 ```json
@@ -37,3 +39,13 @@ matrix_s3_media_store_aws_access_key: "access-key-goes-here"
 matrix_s3_media_store_aws_secret_key: "secret-key-goes-here"
 matrix_s3_media_store_region: "eu-central-1"
 ```
+
+
+## Using other S3-compatible object stores
+
+You can use any S3-compatible object store by **additionally** configuring these variables:
+
+```yaml
+matrix_s3_media_store_custom_endpoint_enabled: true
+matrix_s3_media_store_custom_endpoint: "your-custom-endpoint"
+```

docs/configuring-playbook.md

@@ -77,6 +77,8 @@ When you're done with all the configuration you'd like to do, continue with [Ins
 
 - [Setting up Mautrix Whatsapp bridging](configuring-playbook-bridge-mautrix-whatsapp.md) (optional)
 
+- [Setting up Mautrix Facebook bridging](configuring-playbook-bridge-mautrix-facebook.md) (optional)
+
 - [Setting up Appservice IRC bridging](configuring-playbook-bridge-appservice-irc.md) (optional)
 
 - [Setting up Appservice Discord bridging](configuring-playbook-bridge-appservice-discord.md) (optional)

docs/configuring-well-known.md

@@ -13,15 +13,19 @@ There are 2 types of well-known service discovery that Matrix makes use of:
 
 All services created by this playbook are meant to be installed on their own server (such as `matrix.<your-domain>`).
 
-As [per the Server-Server specification](https://matrix.org/docs/spec/server_server/r0.1.0.html#server-discovery), to use a Matrix user identifier like `@<username>:<your-domain>` while hosting services on a subdomain like `matrix.<your-domain>`, we need to instruct the Matrix network of such a delegation/redirection by means of setting up a `/.well-known/matrix/server` file on the base domain (`<your-domain.com>).
+As [per the Server-Server specification](https://matrix.org/docs/spec/server_server/r0.1.0.html#server-discovery), to use a Matrix user identifier like `@<username>:<your-domain>` while hosting services on a subdomain like `matrix.<your-domain>`, the Matrix network needs to be instructed of such delegation/redirection.
 
-We have discussed this same thing already in the "`_matrix._tcp` SRV record setup (temporary requirement)" section of [Configuring DNS](configuring-dns.md).
+Server delegation can be configured using DNS SRV records or by setting up a `/.well-known/matrix/server` file on the base domain (`<your-domain.com>`).
 
-In short, you are required to set up both a `_matrix._tcp` DNS SRV record and the `/.well-known/matrix/server` file at the moment.
+We have discussed the DNS SRV record method already in the "`_matrix._tcp` SRV record setup (temporary requirement)" section of [Configuring DNS](configuring-dns.md).
 
-As the Synapse server progresses towards v1.0, only the `/.well-known/matrix/server` file will be used. At that future moment, you would need to remove the `_matrix._tcp` SRV record because Synapse v1.0+ will do the wrong thing if a SRV record exists. During the transitional phase (before Synapse 1.0), we do need to have both a SRV record and a `/.well-known/matrix/server` file, in order to federate correctly with v0.99 and older Synapse versions.
+Both methods have their place and will continue to do so. Usually, you would need to use just one of these delegation methods.
+For simplicity reasons, our setup advocates for the `/.well-known/matrix/server` method and guides you into using that.
+For backward compatibility with older Synapse servers (< v0.99), however, for now you are also required to set up a `_matrix._tcp` DNS SRV record (in addition to the `/.well-known/matrix/server` file on the base domain).
 
-To learn how to set it up, read the Installing section below.
+As the Synapse server progresses towards v1.0, only the `/.well-known/matrix/server` file will be used by us, unless you have a more special setup necessitating a DNS SRV record. At that future moment, you would need to remove the `_matrix._tcp` SRV record because Synapse v1.0+ will do the wrong thing if a SRV record exists.
+
+To learn how to set up `/.well-known/matrix/server`, read the Installing section below.
 
 
 ## Introduction to Client Server Discovery

docs/maintenance-checking-services.md

@@ -10,4 +10,4 @@ ansible-playbook -i inventory/hosts setup.yml --tags=self-check
 
 If it's all green, everything is probably running correctly.
 
-Besides this self-check, you can also check your server using the [Federation Tester](https://neo.lain.haus/fed-tester/).
+Besides this self-check, you can also check your server using the [Federation Tester](https://federationtester.matrix.org/).

docs/updating-users-passwords.md

@@ -0,0 +1,19 @@
+# Updating users passwords
+
+If you are using the matrix-postgres container(default), you can do it via this Ansible playbook (make sure to edit the `<your-username>` and `<your-password>` part below):
+
+	ansible-playbook -i inventory/hosts setup.yml --extra-vars='username=<your-username> password=<your-password>' --tags=update-user-password
+
+**Note**: `<your-username>` is just a plain username (like `john`), not your full `@<username>:<your-domain>` identifier.
+
+**You can then log in with that user** via the riot-web service that this playbook has created for you at a URL like this: `https://riot.<domain>/`.
+
+If you are NOT using the matrix-postgres container, you can generate the password hash by using the command-line after **SSH**-ing to your server (requires that [all services have been started](#starting-the-services)):
+
+	docker exec -it matrix-synapse /usr/local/bin/hash_password -c /data/homeserver.yaml
+
+and then connecting to the postgres server and executing:
+
+	UPDATE users SET password_hash = '<password-hash>' WHERE name = '@someone:server.com'
+
+where `<password-hash>` is the hash returned by the docker command above.