1
0
mirror of https://github.com/spantaleev/matrix-docker-ansible-deploy.git synced 2024-12-12 08:43:55 +02:00

Merge pull request #3679 from luixxiul/fix

Fix indentations of list items
This commit is contained in:
Slavi Pantaleev 2024-10-25 12:15:43 +03:00 committed by GitHub
commit 65db73e808
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
7 changed files with 117 additions and 110 deletions

View File

@ -1684,8 +1684,8 @@ See our [Setting up the ntfy push notifications server](docs/configuring-playboo
**If you are using the [Hookshot bridge](docs/configuring-playbook-bridge-hookshot.md)**, you may find that:
1. **Metrics may not be enabled by default anymore**:
- If Prometheus is enabled (`prometheus_enabled: true`), then Hookshot metrics will be enabled automatically (`matrix_hookshot_metrics_enabled: true`). These metrics will be collected from the local (in-container) Prometheus over the container network.
- **If Prometheus is not enabled** (you are either not using Prometheus or are using an external one), **Hookshot metrics will not be enabled by default anymore**. Feel free to enable them by setting `matrix_hookshot_metrics_enabled: true`. Also, see below.
- If Prometheus is enabled (`prometheus_enabled: true`), then Hookshot metrics will be enabled automatically (`matrix_hookshot_metrics_enabled: true`). These metrics will be collected from the local (in-container) Prometheus over the container network.
- **If Prometheus is not enabled** (you are either not using Prometheus or are using an external one), **Hookshot metrics will not be enabled by default anymore**. Feel free to enable them by setting `matrix_hookshot_metrics_enabled: true`. Also, see below.
2. When metrics are meant to be **consumed by an external Prometheus server**, `matrix_hookshot_metrics_proxying_enabled` needs to be set to `true`, so that metrics would be exposed (proxied) "publicly" on `https://matrix.example.com/metrics/hookshot`. To make use of this, you'll also need to enable the new `https://matrix.example.com/metrics/*` endpoints mentioned above, using `matrix_nginx_proxy_proxy_matrix_metrics_enabled`. Learn more in our [Collecting metrics to an external Prometheus server](docs/configuring-playbook-prometheus-grafana.md#collecting-metrics-to-an-external-prometheus-server) documentation.
3. **We've changed the URL we're exposing Hookshot metrics at** for external Prometheus servers. Until now, you were advised to consume Hookshot metrics from `https://stats.example.com/hookshot/metrics` (working in conjunction with `matrix_nginx_proxy_proxy_synapse_metrics`). From now on, **this no longer works**. As described above, you need to start consuming metrics from `https://matrix.example.com/metrics/hookshot`.
@ -2136,9 +2136,9 @@ To migrate to the new setup, expect a few minutes of downtime, while you follow
2. Generate a strong password to be used for your superuser Postgres user (called `matrix`). You can use `pwgen -s 64 1` to generate it, or some other tool. The **maximum length** for a Postgres password is 100 bytes (characters). Don't go crazy!
3. Update your playbook's `inventory/host_vars/matrix.example.com/vars.yml` file, adding a line like this:
```yaml
matrix_postgres_connection_password: 'YOUR_POSTGRES_PASSWORD_HERE'
```
```yaml
matrix_postgres_connection_password: 'YOUR_POSTGRES_PASSWORD_HERE'
```
.. where `YOUR_POSTGRES_PASSWORD_HERE` is to be replaced with the password you generated during step #2.
@ -2148,31 +2148,31 @@ matrix_postgres_connection_password: 'YOUR_POSTGRES_PASSWORD_HERE'
7. Open a Postgres shell: `/usr/local/bin/matrix-postgres-cli`
8. Execute the following query, while making sure to **change the password inside** (**don't forget the ending `;`**):
```sql
CREATE ROLE matrix LOGIN SUPERUSER PASSWORD 'YOUR_POSTGRES_PASSWORD_HERE';
```
```sql
CREATE ROLE matrix LOGIN SUPERUSER PASSWORD 'YOUR_POSTGRES_PASSWORD_HERE';
```
.. where `YOUR_POSTGRES_PASSWORD_HERE` is to be replaced with the password you generated during step #2.
9. Execute the following queries as you see them (no modifications necessary, so you can just **paste them all at once**):
```sql
CREATE DATABASE matrix OWNER matrix;
```sql
CREATE DATABASE matrix OWNER matrix;
ALTER DATABASE postgres OWNER TO matrix;
ALTER DATABASE template0 OWNER TO matrix;
ALTER DATABASE template1 OWNER TO matrix;
ALTER DATABASE postgres OWNER TO matrix;
ALTER DATABASE template0 OWNER TO matrix;
ALTER DATABASE template1 OWNER TO matrix;
\c matrix;
\c matrix;
ALTER DATABASE homeserver RENAME TO synapse;
ALTER DATABASE homeserver RENAME TO synapse;
ALTER ROLE synapse NOSUPERUSER NOCREATEDB NOCREATEROLE;
ALTER ROLE synapse NOSUPERUSER NOCREATEDB NOCREATEROLE;
\quit
```
\quit
```
You may need to press *Enter* after pasting the lines above.
You may need to press *Enter* after pasting the lines above.
10. Re-run the playbook normally: `ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start`

View File

@ -15,23 +15,23 @@ By default, if you're using the integrated Postgres database server (as opposed
1. Create a new SSH key:
```bash
ssh-keygen -t ed25519 -N '' -f matrix-borg-backup -C matrix
```
```bash
ssh-keygen -t ed25519 -N '' -f matrix-borg-backup -C matrix
```
This can be done on any machine and you don't need to place the key in the `.ssh` folder. It will be added to the Ansible config later.
This can be done on any machine and you don't need to place the key in the `.ssh` folder. It will be added to the Ansible config later.
2. Add the **public** part of this SSH key (the `matrix-borg-backup.pub` file) to your BorgBackup provider/server:
If you plan to use a hosted solution, follow their instructions. If you have your own server, copy the key over:
If you plan to use a hosted solution, follow their instructions. If you have your own server, copy the key over:
```bash
# example to append the new PUBKEY contents, where:
# PUBKEY is path to the public key,
# USER is a ssh user on a provider / server
# HOST is a ssh host of a provider / server
cat PUBKEY | ssh USER@HOST 'dd of=.ssh/authorized_keys oflag=append conv=notrunc'
```
```bash
# example to append the new PUBKEY contents, where:
# PUBKEY is path to the public key,
# USER is a ssh user on a provider / server
# HOST is a ssh host of a provider / server
cat PUBKEY | ssh USER@HOST 'dd of=.ssh/authorized_keys oflag=append conv=notrunc'
```
## Adjusting the playbook configuration

View File

@ -18,17 +18,20 @@ Instructions loosely based on [this](https://github.com/Half-Shot/matrix-appserv
3. Create a bot from the Bot tab and retrieve the Bot token.
4. Enable the bridge with the following configuration in your `vars.yml` file:
```yaml
matrix_appservice_discord_enabled: true
matrix_appservice_discord_client_id: "YOUR DISCORD APP CLIENT ID"
matrix_appservice_discord_bot_token: "YOUR DISCORD APP BOT TOKEN"
```
```yaml
matrix_appservice_discord_enabled: true
matrix_appservice_discord_client_id: "YOUR DISCORD APP CLIENT ID"
matrix_appservice_discord_bot_token: "YOUR DISCORD APP BOT TOKEN"
```
5. As of Synapse 1.90.0, you will need to add the following to `matrix_synapse_configuration_extension_yaml` to enable the [backwards compatibility](https://matrix-org.github.io/synapse/latest/upgrade#upgrading-to-v1900) that this bridge needs:
```yaml
matrix_synapse_configuration_extension_yaml: |
use_appservice_legacy_authorization: true
```
**Note**: This deprecated method is considered insecure.
```yaml
matrix_synapse_configuration_extension_yaml: |
use_appservice_legacy_authorization: true
```
**Note**: This deprecated method is considered insecure.
6. If you've already installed Matrix services using the playbook before, you'll need to re-run it (`--tags=setup-all,start`). If not, proceed with [configuring other playbook services](configuring-playbook.md) and then with [Installing](installing.md). Get back to this guide once ready.

View File

@ -12,25 +12,27 @@ loosely based on [this](https://github.com/turt2live/matrix-appservice-webhooks/
1. All you basically need is to adjust your `inventory/host_vars/matrix.example.com/vars.yml`:
```yaml
matrix_appservice_webhooks_enabled: true
matrix_appservice_webhooks_api_secret: '<your_secret>'
```
```yaml
matrix_appservice_webhooks_enabled: true
matrix_appservice_webhooks_api_secret: '<your_secret>'
```
2. In case you want to change the verbosity of logging via `journalctl -fu matrix-appservice-webhooks.service` you can adjust this in `inventory/host_vars/matrix.example.com/vars.yml` as well.
**Note**: default value is: `info` and availabe log levels are : `info`, `verbose`
**Note**: default value is: `info` and availabe log levels are : `info`, `verbose`
```yaml
matrix_appservice_webhooks_log_level: '<log_level>'
```
```yaml
matrix_appservice_webhooks_log_level: '<log_level>'
```
3. As of Synapse 1.90.0, you will need to add the following to `matrix_synapse_configuration_extension_yaml` to enable the [backwards compatibility](https://matrix-org.github.io/synapse/latest/upgrade#upgrading-to-v1900) that this bridge needs:
```yaml
matrix_synapse_configuration_extension_yaml: |
use_appservice_legacy_authorization: true
```
**Note**: This deprecated method is considered insecure.
```yaml
matrix_synapse_configuration_extension_yaml: |
use_appservice_legacy_authorization: true
```
**Note**: This deprecated method is considered insecure.
4. If you've already installed Matrix services using the playbook before, you'll need to re-run it (`--tags=setup-all,start`). If not, proceed with [configuring other playbook services](configuring-playbook.md) and then with [Installing](installing.md). Get back to this guide once ready.
@ -43,29 +45,31 @@ matrix_synapse_configuration_extension_yaml: |
- or simply add the bridge bot to a private channel (personal channels imply you being an administrator)
7. Send a message to the bridge bot in order to receive a private message including the webhook link.
```
!webhook
```
```
!webhook
```
8. The JSON body for posting messages will have to look like this:
```json
{
```json
{
"text": "Hello world!",
"format": "plain",
"displayName": "My Cool Webhook",
"avatar_url": "http://i.imgur.com/IDOBtEJ.png"
}
```
You can test this via curl like so:
```sh
curl --header "Content-Type: application/json" \
--data '{
"text": "Hello world!",
"format": "plain",
"displayName": "My Cool Webhook",
"avatar_url": "http://i.imgur.com/IDOBtEJ.png"
}
```
You can test this via curl like so:
```
curl --header "Content-Type: application/json" \
--data '{
"text": "Hello world!",
"format": "plain",
"displayName": "My Cool Webhook",
"avatar_url": "http://i.imgur.com/IDOBtEJ.png"
}' \
<the link you've gotten in 5.>
```
}' \
<the link you've gotten in 5.>
```

View File

@ -298,13 +298,13 @@ The installation + migration steps are like this:
2. Perform the initial [installation](#installing). At this point:
- Matrix Authentication Service will be installed. Its database will be empty, so it cannot validate existing access tokens or authentication users yet.
- Matrix Authentication Service will be installed. Its database will be empty, so it cannot validate existing access tokens or authentication users yet.
- The homeserver will still continue to use its local database for validating existing access tokens.
- The homeserver will still continue to use its local database for validating existing access tokens.
- Various [compatibility layer URLs](https://element-hq.github.io/matrix-authentication-service/setup/homeserver.html#set-up-the-compatibility-layer) are not yet installed. New login sessions will still be forwarded to the homeserver, which is capable of completing them.
- Various [compatibility layer URLs](https://element-hq.github.io/matrix-authentication-service/setup/homeserver.html#set-up-the-compatibility-layer) are not yet installed. New login sessions will still be forwarded to the homeserver, which is capable of completing them.
- The `matrix-user-creator` role would be suppressed, so that it doesn't automatically attempt to create users (for bots, etc.) in the MAS database. These user accounts likely already exist in Synapse's user database and could be migrated over (via syn2mas, as per the steps below), so creating them in the MAS database would have been unnecessary and potentially problematic (conflicts during the syn2mas migration).
- The `matrix-user-creator` role would be suppressed, so that it doesn't automatically attempt to create users (for bots, etc.) in the MAS database. These user accounts likely already exist in Synapse's user database and could be migrated over (via syn2mas, as per the steps below), so creating them in the MAS database would have been unnecessary and potentially problematic (conflicts during the syn2mas migration).
3. Consider taking a full [backup of your Postgres database](./maintenance-postgres.md#backing-up-postgresql). This is done just in case. The **syn2mas migration tool does not delete any data**, so it should be possible to revert to your previous setup by merely disabling MAS and re-running the playbook (no need to restore a Postgres backup). However, do note that as users start logging in (creating new login sessions) via the new MAS setup, disabling MAS and reverting back to the Synapse user database will cause these new sessions to break.
@ -318,9 +318,9 @@ The installation + migration steps are like this:
5. Perform the [installation](#installing) again. At this point:
- The homeserver will start delegating authentication to MAS.
- The homeserver will start delegating authentication to MAS.
- The compatibility layer URLs will be installed. New login sessions will be completed by MAS.
- The compatibility layer URLs will be installed. New login sessions will be completed by MAS.
6. [Verify that Matrix Authentication Service is installed correctly](#verify-that-matrix-authentication-service-is-installed-correctly)

View File

@ -52,21 +52,21 @@ It's a good idea to [make a complete server backup](faq.md#how-do-i-backup-the-d
3. In addition to the base configuration you see above, add this to your `vars.yml` file:
```yaml
matrix_s3_media_store_path: /matrix/s3-media-store
```
```yaml
matrix_s3_media_store_path: /matrix/s3-media-store
```
This enables S3 support, but mounts the S3 storage bucket to `/matrix/s3-media-store` without hooking it to your homeserver yet. Your homeserver will still continue using your local filesystem for its media store.
This enables S3 support, but mounts the S3 storage bucket to `/matrix/s3-media-store` without hooking it to your homeserver yet. Your homeserver will still continue using your local filesystem for its media store.
4. Run the playbook to apply the changes: `ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start`
5. Do an **initial sync of your files** by running this **on the server** (it may take a very long time):
```sh
sudo -u matrix -- rsync --size-only --ignore-existing -avr /matrix/synapse/storage/media-store/. /matrix/s3-media-store/.
```
```sh
sudo -u matrix -- rsync --size-only --ignore-existing -avr /matrix/synapse/storage/media-store/. /matrix/s3-media-store/.
```
You may need to install `rsync` manually.
You may need to install `rsync` manually.
6. Stop all Matrix services (`ansible-playbook -i inventory/hosts setup.yml --tags=stop`)
@ -78,9 +78,9 @@ You may need to install `rsync` manually.
10. Get the old media store out of the way by running this command on the server:
```sh
mv /matrix/synapse/storage/media-store /matrix/synapse/storage/media-store-local-backup
```
```sh
mv /matrix/synapse/storage/media-store /matrix/synapse/storage/media-store-local-backup
```
11. Remove the `matrix_s3_media_store_path` configuration from your `vars.yml` file (undoing step #3 above)
@ -97,34 +97,34 @@ It's a good idea to [make a complete server backup](faq.md#how-do-i-backup-the-d
1. While all Matrix services are running, run the following command on the server:
(you need to adjust the 3 `--env` line below with your own data)
(you need to adjust the 3 `--env` line below with your own data)
```sh
docker run -it --rm -w /work \
--env='B2_KEY_ID=YOUR_KEY_GOES_HERE' \
--env='B2_KEY_SECRET=YOUR_SECRET_GOES_HERE' \
--env='B2_BUCKET_NAME=YOUR_BUCKET_NAME_GOES_HERE' \
--mount type=bind,src=/matrix/synapse/storage/media-store,dst=/work,ro \
--entrypoint=/bin/sh \
docker.io/tianon/backblaze-b2:3.6.0 \
-c 'b2 authorize-account $B2_KEY_ID $B2_KEY_SECRET && b2 sync /work b2://$B2_BUCKET_NAME --skipNewer'
```
```sh
docker run -it --rm -w /work \
--env='B2_KEY_ID=YOUR_KEY_GOES_HERE' \
--env='B2_KEY_SECRET=YOUR_SECRET_GOES_HERE' \
--env='B2_BUCKET_NAME=YOUR_BUCKET_NAME_GOES_HERE' \
--mount type=bind,src=/matrix/synapse/storage/media-store,dst=/work,ro \
--entrypoint=/bin/sh \
docker.io/tianon/backblaze-b2:3.6.0 \
-c 'b2 authorize-account $B2_KEY_ID $B2_KEY_SECRET && b2 sync /work b2://$B2_BUCKET_NAME --skipNewer'
```
This is some initial file sync, which may take a very long time.
This is some initial file sync, which may take a very long time.
2. Stop all Matrix services (`ansible-playbook -i inventory/hosts setup.yml --tags=stop`)
3. Run the command from step #1 again.
Doing this will sync any new files that may have been created locally in the meantime.
Doing this will sync any new files that may have been created locally in the meantime.
Now that Matrix services aren't running, we're sure to get Backblaze B2 and your local media store fully in sync.
Now that Matrix services aren't running, we're sure to get Backblaze B2 and your local media store fully in sync.
4. Get the old media store out of the way by running this command on the server:
```sh
mv /matrix/synapse/storage/media-store /matrix/synapse/storage/media-store-local-backup
```
```sh
mv /matrix/synapse/storage/media-store /matrix/synapse/storage/media-store-local-backup
```
5. Put the [Backblaze B2 settings seen above](#backblaze-b2) in your `vars.yml` file

View File

@ -76,8 +76,8 @@ This launches a Synapse container, which has access to the local media store, Po
Then use the following commands (`$` values come from environment variables - they're **not placeholders** that you need to substitute):
1. `s3_media_upload update-db $UPDATE_DB_DURATION` - create a local SQLite database (`cache.db`) with a list of media repository files (from the `synapse` Postgres database) eligible for operating on
- `$UPDATE_DB_DURATION` is influenced by the `matrix_synapse_ext_synapse_s3_storage_provider_update_db_day_count` variable (defaults to `0`)
- `$UPDATE_DB_DURATION` defaults to `0d` (0 days), which means **include files which haven't been accessed for more than 0 days** (that is, **all files will be included**).
- `$UPDATE_DB_DURATION` is influenced by the `matrix_synapse_ext_synapse_s3_storage_provider_update_db_day_count` variable (defaults to `0`)
- `$UPDATE_DB_DURATION` defaults to `0d` (0 days), which means **include files which haven't been accessed for more than 0 days** (that is, **all files will be included**).
2. `s3_media_upload check-deleted $MEDIA_PATH` - check whether files in the local cache still exist in the local media repository directory
3. `s3_media_upload upload $MEDIA_PATH $BUCKET --delete --storage-class $STORAGE_CLASS --endpoint-url $ENDPOINT` - uploads locally-stored files to S3 and deletes them from the local media repository directory