Merge branch 'master' into pr-jitsi-matrix-authentication
This commit is contained in:
Slavi Pantaleev
62
docs/configuring-playbook-bot-chatgpt.md
Normal file
62
docs/configuring-playbook-bot-chatgpt.md
Normal file
@ -0,0 +1,62 @@
|
||||
# Setting up ChatGPT (optional)
|
||||
|
||||
The playbook can install and configure [matrix-chatgpt-bot](https://github.com/matrixgpt/matrix-chatgpt-bot) for you.
|
||||
|
||||
Talk to [ChatGPT](https://openai.com/blog/chatgpt/) via your favourite Matrix client!
|
||||
|
||||
|
||||
## 1. Register the bot account
|
||||
|
||||
The playbook does not automatically create users for you. The bot requires an access token to be able to connect to your homeserver.
|
||||
|
||||
You **need to register the bot user manually** before setting up the bot.
|
||||
|
||||
Choose a strong password for the bot. You can generate a good password with a command like this: `pwgen -s 64 1`.
|
||||
|
||||
You can use the playbook to [register a new user](registering-users.md):
|
||||
|
||||
```
|
||||
ansible-playbook -i inventory/hosts setup.yml --extra-vars='username=bot.chatgpt password=PASSWORD_FOR_THE_BOT admin=no' --tags=register-user
|
||||
```
|
||||
|
||||
|
||||
## 2. Get an access token
|
||||
|
||||
Refer to the documentation on [how to obtain an access token](obtaining-access-tokens.md).
|
||||
|
||||
|
||||
## 3. Adjusting the playbook configuration
|
||||
|
||||
Add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file (adapt to your needs):
|
||||
|
||||
```yaml
|
||||
matrix_bot_chatgpt_enabled: true
|
||||
|
||||
# Obtain a new API key from https://platform.openai.com/account/api-keys
|
||||
matrix_bot_chatgpt_openai_api_key: ''
|
||||
|
||||
# This is the default username
|
||||
# matrix_bot_chatgpt_matrix_bot_username_localpart: 'bot.chatgpt'
|
||||
|
||||
# Matrix access token (from bot user above)
|
||||
# see: https://webapps.stackexchange.com/questions/131056/how-to-get-an-access-token-for-element-riot-matrix
|
||||
matrix_bot_chatgpt_matrix_access_token: ''
|
||||
```
|
||||
|
||||
You will need to get tokens for ChatGPT.
|
||||
|
||||
|
||||
## 4. Installing
|
||||
|
||||
After configuring the playbook, run the [installation](installing.md) command again:
|
||||
|
||||
```sh
|
||||
ansible-playbook -i inventory/hosts setup.yml --tags=install-all,start
|
||||
```
|
||||
|
||||
|
||||
## Usage
|
||||
|
||||
To use the bot, invite the `@bot.chatgpt:DOMAIN` to the room you specified in a config, after that start speaking to it, use the prefix if you configured one or mention the bot.
|
||||
|
||||
You can also refer to the upstream [documentation](https://github.com/matrixgpt/matrix-chatgpt-bot).
|
||||
114
docs/configuring-playbook-bot-draupnir.md
Normal file
114
docs/configuring-playbook-bot-draupnir.md
Normal file
@ -0,0 +1,114 @@
|
||||
# Setting up draupnir (optional)
|
||||
|
||||
The playbook can install and configure the [draupnir](https://github.com/Gnuxie/Draupnir) moderation bot for you.
|
||||
|
||||
See the project's [documentation](https://github.com/Gnuxie/Draupnir) to learn what it does and why it might be useful to you.
|
||||
|
||||
If your migrating from Mjolnir skip to step 5b.
|
||||
|
||||
## 1. Register the bot account
|
||||
|
||||
The playbook does not automatically create users for you. The bot requires an access token to be able to connect to your homeserver.
|
||||
|
||||
You **need to register the bot user manually** before setting up the bot.
|
||||
|
||||
Choose a strong password for the bot. You can generate a good password with a command like this: `pwgen -s 64 1`.
|
||||
|
||||
You can use the playbook to [register a new user](registering-users.md):
|
||||
|
||||
```
|
||||
ansible-playbook -i inventory/hosts setup.yml --extra-vars='username=bot.draupnir password=PASSWORD_FOR_THE_BOT admin=no' --tags=register-user
|
||||
```
|
||||
|
||||
If you would like draupnir to be able to deactivate users, move aliases, shutdown rooms, etc then it must be a server admin so you need to change `admin=no` to `admin=yes` in the command above.
|
||||
|
||||
|
||||
## 2. Get an access token
|
||||
|
||||
Refer to the documentation on [how to obtain an access token](obtaining-access-tokens.md).
|
||||
|
||||
|
||||
## 3. Make sure the account is free from rate limiting
|
||||
|
||||
You will need to prevent Synapse from rate limiting the bot's account. This is not an optional step. If you do not do this step draupnir will crash. This can be done using Synapse's [admin API](https://matrix-org.github.io/synapse/latest/admin_api/user_admin_api.html#override-ratelimiting-for-users). This can also be manually done by editing the Synapse database. Manually editing the Synapse database is rarely a good idea. Please ask for help if you are uncomfortable with these steps.
|
||||
|
||||
1. Copy the statement below into a text editor.
|
||||
|
||||
```
|
||||
INSERT INTO ratelimit_override VALUES ('@bot.draupnir:DOMAIN', 0, 0);
|
||||
```
|
||||
|
||||
1. Change the username (`@bot.draupnir:DOMAIN`) to the username you used when you registered the bot's account. You must change `DOMAIN` to your server's domain.
|
||||
|
||||
1. Get a database terminal by following these steps: [maintenance-postgres.md#getting-a-database-terminal](maintenance-postgres.md#getting-a-database-terminal)
|
||||
|
||||
1. Connect to Synapse's database by typing `\connect synapse` into the database terminal
|
||||
|
||||
1. Paste in the `INSERT INTO` command that you edited and press enter.
|
||||
|
||||
You can run `SELECT * FROM ratelimit_override;` to see if it worked. If the output looks like this:
|
||||
|
||||
```
|
||||
user_id | messages_per_second | burst_count
|
||||
-----------------------+---------------------+-------------
|
||||
@bot.draupnir:raim.ist | 0 | 0`
|
||||
```
|
||||
then you did it correctly.
|
||||
|
||||
|
||||
## 4. Create a management room
|
||||
|
||||
Using your own account, create a new invite only room that you will use to manage the bot. This is the room where you will see the status of the bot and where you will send commands to the bot, such as the command to ban a user from another room. Anyone in this room can control the bot so it is important that you only invite trusted users to this room. The room must be unencrypted since the playbook does not support installing Pantalaimon yet.
|
||||
|
||||
Once you have created the room you need to copy the room ID so you can tell the bot to use that room. In Element you can do this by going to the room's settings, clicking Advanced, and then coping the internal room ID. The room ID will look something like `!QvgVuKq0ha8glOLGMG:DOMAIN`.
|
||||
|
||||
Finally invite the `@bot.draupnir:DOMAIN` account you created earlier into the room.
|
||||
|
||||
|
||||
## 5a. Adjusting the playbook configuration
|
||||
|
||||
Add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file (adapt to your needs):
|
||||
|
||||
You must replace `ACCESS_TOKEN_FROM_STEP_2_GOES_HERE` and `ROOM_ID_FROM_STEP_4_GOES_HERE` with the your own values.
|
||||
|
||||
```yaml
|
||||
matrix_bot_draupnir_enabled: true
|
||||
|
||||
matrix_bot_draupnir_access_token: "ACCESS_TOKEN_FROM_STEP_2_GOES_HERE"
|
||||
|
||||
matrix_bot_draupnir_management_room: "ROOM_ID_FROM_STEP_4_GOES_HERE"
|
||||
```
|
||||
|
||||
## 5b. Migrating from Mjolnir (Only required if migrating.)
|
||||
|
||||
Replace your matrix_bot_mjolnir config with matrix_bot_draupnir config. Also disable mjolnir if you're doing migration.
|
||||
That is all you need to do due to that Draupnir can complete migration on its own.
|
||||
|
||||
## 6. Installing
|
||||
|
||||
After configuring the playbook, run the [installation](installing.md) command:
|
||||
|
||||
```
|
||||
ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
|
||||
```
|
||||
|
||||
|
||||
## Usage
|
||||
|
||||
You can refer to the upstream [documentation](https://github.com/Gnuxie/Draupnir) for additional ways to use and configure draupnir. Check out their [quickstart guide](https://github.com/matrix-org/draupnir/blob/main/docs/moderators.md#quick-usage) for some basic commands you can give to the bot.
|
||||
|
||||
You can configure additional options by adding the `matrix_bot_draupnir_configuration_extension_yaml` variable to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file.
|
||||
|
||||
For example to change draupnir's `recordIgnoredInvites` option to `true` you would add the following to your `vars.yml` file.
|
||||
|
||||
```yaml
|
||||
matrix_bot_draupnir_configuration_extension_yaml: |
|
||||
# Your custom YAML configuration goes here.
|
||||
# This configuration extends the default starting configuration (`matrix_bot_draupnir_configuration_yaml`).
|
||||
#
|
||||
# You can override individual variables from the default configuration, or introduce new ones.
|
||||
#
|
||||
# If you need something more special, you can take full control by
|
||||
# completely redefining `matrix_bot_draupnir_configuration_yaml`.
|
||||
recordIgnoredInvites: true
|
||||
```
|
||||
@ -1,6 +1,6 @@
|
||||
# Setting up Appservice Slack (optional)
|
||||
|
||||
**Note**: bridging to [Slack](https://slack.com) can also happen via the [mx-puppet-slack](configuring-playbook-bridge-mx-puppet-slack.md) bridge supported by the playbook.
|
||||
**Note**: bridging to [Slack](https://slack.com) can also happen via the [mx-puppet-slack](configuring-playbook-bridge-mx-puppet-slack.md) and [mautrix-slack](configuring-playbook-bridge-mautrix-slack.md) bridges supported by the playbook.
|
||||
|
||||
The playbook can install and configure [matrix-appservice-slack](https://github.com/matrix-org/matrix-appservice-slack) for you.
|
||||
|
||||
|
||||
77
docs/configuring-playbook-bridge-mautrix-slack.md
Normal file
77
docs/configuring-playbook-bridge-mautrix-slack.md
Normal file
@ -0,0 +1,77 @@
|
||||
# Setting up Mautrix Slack (optional)
|
||||
|
||||
**Note**: bridging to [Slack](https://slack.com/) can also happen via the [mx-puppet-slack](configuring-playbook-bridge-mx-puppet-slack.md) and [matrix-appservice-slack](configuring-playbook-bridge-appservice-slack.md) bridges supported by the playbook.
|
||||
- For using as a Bot we recommend the [Appservice Slack](configuring-playbook-bridge-appservice-slack.md), because it supports plumbing.
|
||||
- For personal use with a slack account we recommend the `mautrix-slack` bridge (the one being discussed here), because it is the most fully-featured and stable of the 3 Slack bridges supported by the playbook.
|
||||
|
||||
The playbook can install and configure [mautrix-slack](https://github.com/mautrix/slack) for you.
|
||||
|
||||
See the project's [documentation](https://docs.mau.fi/bridges/go/slack/index.html) to learn what it does and why it might be useful to you.
|
||||
|
||||
Note that as of Oct 2022, support for multiple Matrix users using the bot is incomplete. Different users do not yet share the bridged channels. Everyone gets their own copy.
|
||||
|
||||
See the [features and roadmap](https://github.com/mautrix/slack/blob/main/ROADMAP.md) for more information.
|
||||
|
||||
|
||||
## Prerequisites
|
||||
|
||||
For using this bridge, you would need to authenticate by **providing your username and password** (legacy) or by using a **token login**. See more information in the [docs](https://docs.mau.fi/bridges/go/slack/authentication.html).
|
||||
|
||||
Note that neither of these methods are officially supported by Slack. [matrix-appservice-slack](configuring-playbook-bridge-appservice-slack.md) uses a Slack bot account which is the only officially supported method for bridging a Slack channel.
|
||||
|
||||
|
||||
## Installing
|
||||
|
||||
To enable the bridge, add this to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_mautrix_slack_enabled: true
|
||||
```
|
||||
|
||||
You may optionally wish to add some [Additional configuration](#additional-configuration), or to [prepare for double-puppeting](#set-up-double-puppeting) before the initial installation.
|
||||
|
||||
After adjusting your `vars.yml` file, re-run the playbook and restart all services: `ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start`
|
||||
|
||||
To make use of the bridge, see [Usage](#usage) below.
|
||||
|
||||
|
||||
### Additional configuration
|
||||
|
||||
There are some additional options you may wish to configure with the bridge.
|
||||
|
||||
Take a look at:
|
||||
|
||||
- `roles/custom/matrix-bridge-mautrix-slack/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
|
||||
- `roles/custom/matrix-bridge-mautrix-slack/templates/config.yaml.j2` for the bridge's default configuration. You can override settings (even those that don't have dedicated playbook variables) using the `matrix_mautrix_slack_configuration_extension_yaml` variable
|
||||
|
||||
|
||||
### 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. Refer to the documentation on [how to do that](obtaining-access-tokens.md).
|
||||
|
||||
- send the access token to the bot. Example: `login-matrix MATRIX_ACCESS_TOKEN_HERE`
|
||||
|
||||
- make sure you don't log out the `Mautrix-Slack` device some time in the future, as that would break the Double Puppeting feature
|
||||
|
||||
|
||||
## Usage
|
||||
|
||||
1. Start a chat with `@slackbot:YOUR_DOMAIN` (where `YOUR_DOMAIN` is your base domain, not the `matrix.` domain).
|
||||
2. If you would like to login to Slack using a token, send the `login-token` command, otherwise, send the `login-password` command. Read [here](https://docs.mau.fi/bridges/go/slack/authentication.html) on how to retrieve your token and cookie token.
|
||||
3. The bot should respond with "Successfully logged into <email> for team <workspace>"
|
||||
4. Now that you're logged in, you can send a `help` command to the bot again, to see additional commands you have access to.
|
||||
5. Slack channels should automatically begin bridging if you authenticated using a token. Otherwise, you must wait to receive a message in the channel if you used password authentication.
|
||||
@ -11,6 +11,19 @@ matrix_mautrix_whatsapp_enabled: true
|
||||
```
|
||||
Whatsapp multidevice beta is required, now it is enough if Whatsapp is connected to the Internet every 2 weeks.
|
||||
|
||||
The relay bot functionality is off by default. If you would like to enable the relay bot, add the following to your `vars.yml` file:
|
||||
```yaml
|
||||
matrix_mautrix_whatsapp_bridge_relay_enabled: true
|
||||
```
|
||||
|
||||
By default, only admins are allowed to set themselves as relay users. To allow anyone on your homeserver to set themselves as relay users add this to your `vars.yml` file:
|
||||
```yaml
|
||||
matrix_mautrix_whatsapp_bridge_relay_admin_only: false
|
||||
```
|
||||
|
||||
If you want to activate the relay bot in a room, use `!whatsapp set-relay`.
|
||||
Use `!whatsapp unset-relay` to deactivate.
|
||||
|
||||
## 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.
|
||||
|
||||
@ -1,8 +1,7 @@
|
||||
# Setting up MX Puppet Slack (optional)
|
||||
|
||||
**Note**: bridging to [Slack](https://slack.com) can also happen via the
|
||||
[matrix-appservice-slack](configuring-playbook-bridge-appservice-slack.md)
|
||||
bridge supported by the playbook.
|
||||
[matrix-appservice-slack](configuring-playbook-bridge-appservice-slack.md) and [mautrix-slack](configuring-playbook-bridge-mautrix-slack.md) bridges supported by the playbook.
|
||||
|
||||
The playbook can install and configure [Beeper](https://www.beeper.com/)-maintained fork of
|
||||
[mx-puppet-slack](https://gitlab.com/beeper/mx-puppet-monorepo) for you.
|
||||
|
||||
@ -10,10 +10,10 @@ Remember to add `stats.<your-domain>` to DNS as described in [Configuring DNS](c
|
||||
matrix_prometheus_enabled: true
|
||||
|
||||
# You can remove this, if unnecessary.
|
||||
matrix_prometheus_node_exporter_enabled: true
|
||||
prometheus_node_exporter_enabled: true
|
||||
|
||||
# You can remove this, if unnecessary.
|
||||
matrix_prometheus_postgres_exporter_enabled: true
|
||||
prometheus_postgres_exporter_enabled: true
|
||||
|
||||
# You can remove this, if unnecessary.
|
||||
matrix_prometheus_nginxlog_exporter_enabled: true
|
||||
@ -40,8 +40,8 @@ The retention policy of Prometheus metrics is [15 days by default](https://prome
|
||||
Name | Description
|
||||
-----|----------
|
||||
`matrix_prometheus_enabled`|[Prometheus](https://prometheus.io) is a time series database. It holds all the data we're going to talk about.
|
||||
`matrix_prometheus_node_exporter_enabled`|[Node Exporter](https://prometheus.io/docs/guides/node-exporter/) is an addon of sorts to Prometheus that collects generic system information such as CPU, memory, filesystem, and even system temperatures
|
||||
`matrix_prometheus_postgres_exporter_enabled`|[Postgres Exporter](configuring-playbook-prometheus-postgres.md) is an addon of sorts to expose Postgres database metrics to Prometheus.
|
||||
`prometheus_node_exporter_enabled`|[Node Exporter](https://prometheus.io/docs/guides/node-exporter/) is an addon of sorts to Prometheus that collects generic system information such as CPU, memory, filesystem, and even system temperatures
|
||||
`prometheus_postgres_exporter_enabled`|[Postgres Exporter](configuring-playbook-prometheus-postgres.md) is an addon of sorts to expose Postgres database metrics to Prometheus.
|
||||
`matrix_prometheus_nginxlog_exporter_enabled`|[NGINX Log Exporter](configuring-playbook-prometheus-nginxlog.md) is an addon of sorts to expose NGINX logs to Prometheus.
|
||||
`matrix_grafana_enabled`|[Grafana](https://grafana.com/) is the visual component. It shows (on the `stats.<your-domain>` subdomain) the dashboards with the graphs that we're interested in
|
||||
`matrix_grafana_anonymous_access`|By default you need to log in to see graphs. If you want to publicly share your graphs (e.g. when asking for help in [`#synapse:matrix.org`](https://matrix.to/#/#synapse:matrix.org?via=matrix.org&via=privacytools.io&via=mozilla.org)) you'll want to enable this option.
|
||||
@ -52,7 +52,7 @@ Name | Description
|
||||
|
||||
Metrics and resulting graphs can contain a lot of information. This includes system specs but also usage patterns. This applies especially to small personal/family scale homeservers. Someone might be able to figure out when you wake up and go to sleep by looking at the graphs over time. Think about this before enabling anonymous access. And you should really not forget to change your Grafana password.
|
||||
|
||||
Most of our docker containers run with limited system access, but the `prometheus-node-exporter` has access to the host network stack and (readonly) root filesystem. This is required to report on them. If you don't like that, you can set `matrix_prometheus_node_exporter_enabled: false` (which is actually the default). You will still get Synapse metrics with this container disabled. Both of the dashboards will always be enabled, so you can still look at historical data after disabling either source.
|
||||
Most of our docker containers run with limited system access, but the `prometheus-node-exporter` has access to the host network stack and (readonly) root filesystem. This is required to report on them. If you don't like that, you can set `prometheus_node_exporter_enabled: false` (which is actually the default). You will still get Synapse metrics with this container disabled. Both of the dashboards will always be enabled, so you can still look at historical data after disabling either source.
|
||||
|
||||
|
||||
## Collecting metrics to an external Prometheus server
|
||||
@ -74,11 +74,11 @@ Name | Description
|
||||
`matrix_nginx_proxy_proxy_matrix_metrics_basic_auth_raw_content`|Set this to the Basic Authentication credentials (raw `htpasswd` file content) used to protect `/metrics/*`. This htpasswd-file needs to be generated with the `htpasswd` tool and can include multiple username/password pairs. If you only need one credential, use `matrix_nginx_proxy_proxy_matrix_metrics_basic_auth_username` and `matrix_nginx_proxy_proxy_matrix_metrics_basic_auth_password` instead.
|
||||
`matrix_synapse_metrics_enabled`|Set this to `true` to make Synapse expose metrics (locally, on the container network)
|
||||
`matrix_synapse_metrics_proxying_enabled`|Set this to `true` to expose Synapse's metrics on `https://matrix.DOMAIN/metrics/synapse/main-process` and `https://matrix.DOMAIN/metrics/synapse/worker/TYPE-ID` (only takes effect if `matrix_nginx_proxy_proxy_matrix_metrics_enabled: true`). Read [below](#collecting-synapse-worker-metrics-to-an-external-prometheus-server) if you're running a Synapse worker setup (`matrix_synapse_workers_enabled: true`).
|
||||
`matrix_prometheus_node_exporter_enabled`|Set this to `true` to enable the node (general system stats) exporter (locally, on the container network)
|
||||
`matrix_prometheus_node_exporter_metrics_proxying_enabled`|Set this to `true` to expose the node (general system stats) metrics on `https://matrix.DOMAIN/metrics/node-exporter` (only takes effect if `matrix_nginx_proxy_proxy_matrix_metrics_enabled: true`)
|
||||
`matrix_prometheus_postgres_exporter_enabled`|Set this to `true` to enable the [Postgres exporter](configuring-playbook-prometheus-postgres.md) (locally, on the container network)
|
||||
`prometheus_node_exporter_enabled`|Set this to `true` to enable the node (general system stats) exporter (locally, on the container network)
|
||||
`matrix_prometheus_services_proxy_connect_prometheus_node_exporter_metrics_proxying_enabled`|Set this to `true` to expose the node (general system stats) metrics on `https://matrix.DOMAIN/metrics/node-exporter` (only takes effect if `matrix_nginx_proxy_proxy_matrix_metrics_enabled: true`)
|
||||
`prometheus_postgres_exporter_enabled`|Set this to `true` to enable the [Postgres exporter](configuring-playbook-prometheus-postgres.md) (locally, on the container network)
|
||||
`matrix_prometheus_nginxlog_exporter_enabled`|Set this to `true` to enable the [NGINX Log exporter](configuring-playbook-prometheus-nginxlog.md) (locally, on the container network)
|
||||
`matrix_prometheus_postgres_exporter_metrics_proxying_enabled`|Set this to `true` to expose the [Postgres exporter](configuring-playbook-prometheus-postgres.md) metrics on `https://matrix.DOMAIN/metrics/postgres-exporter` (only takes effect if `matrix_nginx_proxy_proxy_matrix_metrics_enabled: true`)
|
||||
`matrix_prometheus_services_proxy_connect_prometheus_postgres_exporter_metrics_proxying_enabled`|Set this to `true` to expose the [Postgres exporter](configuring-playbook-prometheus-postgres.md) metrics on `https://matrix.DOMAIN/metrics/postgres-exporter` (only takes effect if `matrix_nginx_proxy_proxy_matrix_metrics_enabled: true`)
|
||||
`matrix_bridge_hookshot_metrics_enabled`|Set this to `true` to make [Hookshot](configuring-playbook-bridge-hookshot.md) expose metrics (locally, on the container network)
|
||||
`matrix_bridge_hookshot_metrics_proxying_enabled`|Set this to `true` to expose the [Hookshot](configuring-playbook-bridge-hookshot.md) metrics on `https://matrix.DOMAIN/metrics/hookshot` (only takes effect if `matrix_nginx_proxy_proxy_matrix_metrics_enabled: true`)
|
||||
`matrix_SERVICE_metrics_proxying_enabled`|Various other services/roles may provide similar `_metrics_enabled` and `_metrics_proxying_enabled` variables for exposing their metrics. Refer to each role for details. Only takes effect if `matrix_nginx_proxy_proxy_matrix_metrics_enabled: true`
|
||||
|
||||
@ -6,17 +6,17 @@ You can enable this with the following settings in your configuration file (`inv
|
||||
|
||||
|
||||
```yaml
|
||||
matrix_prometheus_postgres_exporter_enabled: true
|
||||
prometheus_postgres_exporter_enabled: true
|
||||
```
|
||||
|
||||
## What does it do?
|
||||
|
||||
Name | Description
|
||||
-----|----------
|
||||
`matrix_prometheus_postgres_exporter_enabled`|Enable the postgres prometheus exporter. This sets up the docker container, connects it to the database and adds a 'job' to the prometheus config which tells prometheus about this new exporter. The default is 'false'
|
||||
`matrix_prometheus_postgres_exporter_database_username`| The 'username' for the user that the exporter uses to connect to the database. The default is 'matrix_prometheus_postgres_exporter'
|
||||
`matrix_prometheus_postgres_exporter_database_password`| The 'password' for the user that the exporter uses to connect to the database. By default, this is auto-generated by the playbook
|
||||
`matrix_prometheus_postgres_exporter_metrics_proxying_enabled`|If set to `true`, exposes the Postgres exporter metrics on `https://matrix.DOMAIN/metrics/postgres-exporter` for usage with an [external Prometheus server](configuring-playbook-prometheus-grafana.md#collecting-metrics-to-an-external-prometheus-server) (only takes effect if `matrix_nginx_proxy_proxy_matrix_metrics_enabled: true`)
|
||||
`prometheus_postgres_exporter_enabled`|Enable the postgres prometheus exporter. This sets up the docker container, connects it to the database and adds a 'job' to the prometheus config which tells prometheus about this new exporter. The default is 'false'
|
||||
`prometheus_postgres_exporter_database_username`| The 'username' for the user that the exporter uses to connect to the database. The default is 'matrix_prometheus_postgres_exporter'
|
||||
`prometheus_postgres_exporter_database_password`| The 'password' for the user that the exporter uses to connect to the database. By default, this is auto-generated by the playbook
|
||||
`matrix_prometheus_services_proxy_connect_prometheus_postgres_exporter_metrics_proxying_enabled`|If set to `true`, exposes the Postgres exporter metrics on `https://matrix.DOMAIN/metrics/postgres-exporter` for usage with an [external Prometheus server](configuring-playbook-prometheus-grafana.md#collecting-metrics-to-an-external-prometheus-server) (only takes effect if `matrix_nginx_proxy_proxy_matrix_metrics_enabled: true`)
|
||||
|
||||
|
||||
## More information
|
||||
|
||||
@ -3,8 +3,6 @@
|
||||
If you'd like to store Synapse's content repository (`media_store`) files on Amazon S3 (or other S3-compatible service),
|
||||
you can use the [synapse-s3-storage-provider](https://github.com/matrix-org/synapse-s3-storage-provider) media provider module for Synapse.
|
||||
|
||||
**`synapse-s3-storage-provider` support is very new and still relatively untested. Using it may cause data loss.**
|
||||
|
||||
An alternative (which has worse performance) is to use [Goofys to mount the S3 store to the local filesystem](configuring-playbook-s3-goofys.md).
|
||||
|
||||
|
||||
@ -68,11 +66,11 @@ 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):
|
||||
|
||||
- `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
|
||||
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**).
|
||||
- `s3_media_upload check-deleted $MEDIA_PATH` - check whether files in the local cache still exist in the local media repository directory
|
||||
- `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
|
||||
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
|
||||
|
||||
The `s3_media_upload upload` command may take a lot of time to complete.
|
||||
|
||||
@ -93,13 +91,21 @@ To migrate your existing local data to S3, we recommend to:
|
||||
|
||||
#### Copying data to Amazon S3
|
||||
|
||||
Generally, you need to use the `aws s3` tool.
|
||||
To copy to AWS S3, start a container on the Matrix server like this:
|
||||
|
||||
This documentation section could use an improvement. Ideally, we'd come up with a guide like the one used in [Copying data to Backblaze B2](#copying-data-to-backblaze-b2) - running `aws s3` in a container, etc.
|
||||
```sh
|
||||
docker run -it --rm \
|
||||
-w /work \
|
||||
--env-file=/matrix/synapse/ext/s3-storage-provider/env \
|
||||
--mount type=bind,src=/matrix/synapse/storage/media-store,dst=/work,ro \
|
||||
--entrypoint=/bin/sh \
|
||||
docker.io/amazon/aws-cli:2.9.16 \
|
||||
-c 'aws s3 sync /work/. s3://$BUCKET/'
|
||||
```
|
||||
|
||||
#### Copying data to Backblaze B2
|
||||
|
||||
To copy to Backblaze B2, start a container like this:
|
||||
To copy to Backblaze B2, start a container on the Matrix server like this:
|
||||
|
||||
```sh
|
||||
docker run -it --rm \
|
||||
@ -109,7 +115,7 @@ docker run -it --rm \
|
||||
--env='B2_BUCKET_NAME=YOUR_BUCKET_NAME_GOES_HERE' \
|
||||
--mount type=bind,src=/matrix/synapse/storage/media-store,dst=/work,ro \
|
||||
--entrypoint=/bin/sh \
|
||||
tianon/backblaze-b2:3.6.0 \
|
||||
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'
|
||||
```
|
||||
|
||||
|
||||
@ -106,6 +106,8 @@ When you're done with all the configuration you'd like to do, continue with [Ins
|
||||
|
||||
- [Setting up Mautrix Telegram bridging](configuring-playbook-bridge-mautrix-telegram.md) (optional)
|
||||
|
||||
- [Setting up Mautrix Slack bridging](configuring-playbook-bridge-mautrix-slack.md) (optional)
|
||||
|
||||
- [Setting up Mautrix Whatsapp bridging](configuring-playbook-bridge-mautrix-whatsapp.md) (optional)
|
||||
|
||||
- [Setting up Mautrix Facebook bridging](configuring-playbook-bridge-mautrix-facebook.md) (optional)
|
||||
@ -161,6 +163,8 @@ When you're done with all the configuration you'd like to do, continue with [Ins
|
||||
|
||||
### Bots
|
||||
|
||||
- [Setting up matrix-bot-chatgpt](configuring-playbook-bot-chatgpt.md) - a bot through which you can talk to the [ChatGPT](https://openai.com/blog/chatgpt/) model(optional)
|
||||
|
||||
- [Setting up matrix-reminder-bot](configuring-playbook-bot-matrix-reminder-bot.md) - a bot to remind you about stuff (optional)
|
||||
|
||||
- [Setting up matrix-registration-bot](configuring-playbook-bot-matrix-registration-bot.md) - a bot to create and manage registration tokens to invite users (optional)
|
||||
@ -173,6 +177,8 @@ When you're done with all the configuration you'd like to do, continue with [Ins
|
||||
|
||||
- [Setting up Mjolnir](configuring-playbook-bot-mjolnir.md) - a moderation tool/bot (optional)
|
||||
|
||||
- [Setting up Draupnir](configuring-playbook-bot-draupnir.md) - a moderation tool/bot (optional), forked from Mjolnir and maintained by its former leader developer
|
||||
|
||||
- [Setting up Buscarron](configuring-playbook-bot-buscarron.md) - a bot you can use to send any form (HTTP POST, HTML) to a (encrypted) Matrix room (optional)
|
||||
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
If you've [configured your DNS](configuring-dns.md) and have [configured the playbook](configuring-playbook.md), you can start the installation procedure.
|
||||
|
||||
**Before installing** and each time you update the playbook in the future, you will need to update the Ansible roles in this playbook by running `make roles`. `make roles` is a shortcut (a `roles` target defined in [`Makefile`](Makefile) and executed by the [`make`](https://www.gnu.org/software/make/) utility) which ultimately runs [ansible-galaxy](https://docs.ansible.com/ansible/latest/cli/ansible-galaxy.html) to download Ansible roles. If you don't have `make`, you can also manually run the `roles` commands seen in the `Makefile`.
|
||||
**Before installing** and each time you update the playbook in the future, you will need to update the Ansible roles in this playbook by running `just roles`. `just roles` is a shortcut (a `roles` target defined in [`justfile`](../justfile) and executed by the [`just`](https://github.com/casey/just) utility) which ultimately runs [ansible-galaxy](https://docs.ansible.com/ansible/latest/cli/ansible-galaxy.html) to download Ansible roles. If you don't have `just`, you can also manually run the `roles` commands seen in the `justfile`.
|
||||
|
||||
|
||||
## Playbook tags introduction
|
||||
@ -57,7 +57,7 @@ Proceed to [Maintaining your setup in the future](#2-maintaining-your-setup-in-t
|
||||
If you will be importing data into your newly created Matrix server, install it, but **do not** start its services just yet.
|
||||
Starting its services or messing with its database now will affect your data import later on.
|
||||
|
||||
To do the installation **without** starting services, run only the `setup-all` tag:
|
||||
To do the installation **without** starting services, run only the `install-all` tag:
|
||||
|
||||
```sh
|
||||
ansible-playbook -i inventory/hosts setup.yml --tags=install-all
|
||||
@ -88,6 +88,8 @@ Feel free to **re-run the setup command any time** you think something is off wi
|
||||
|
||||
Note that if you remove components from `vars.yml`, or if we switch some component from being installed by default to not being installed by default anymore, you'd need to run the setup command with `--tags=setup-all` instead of `--tags=install-all`. See [Playbook tags introduction](#playbook-tags-introduction)
|
||||
|
||||
A way to invoke these `ansible-playbook` commands with less typing in the future is to use [just](https://github.com/casey/just) to run them: `just install-all` or `just setup-all`. See [our `justfile`](../justfile) for more information.
|
||||
|
||||
|
||||
## 3. Finalize the installation
|
||||
|
||||
|
||||
@ -10,8 +10,8 @@ To upgrade services:
|
||||
|
||||
- take a look at [the changelog](../CHANGELOG.md) to see if there have been any backward-incompatible changes that you need to take care of
|
||||
|
||||
- download the upstream Ansible roles used by the playbook by running `make roles`
|
||||
- download the upstream Ansible roles used by the playbook by running `just roles`
|
||||
|
||||
- re-run the [playbook setup](installing.md) and restart all serivces: `ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,ensure-matrix-users-created,start`
|
||||
- re-run the [playbook setup](installing.md) and restart all services: `just setup-all`
|
||||
|
||||
**Note**: major version upgrades to the internal PostgreSQL database are not done automatically. To upgrade it, refer to the [upgrading PostgreSQL guide](maintenance-postgres.md#upgrading-postgresql).
|
||||
|
||||
@ -22,7 +22,7 @@ If your distro runs within an [LXC container](https://linuxcontainers.org/), you
|
||||
|
||||
- [`git`](https://git-scm.com/) is the recommended way to download the playbook to your computer. `git` may also be required on the server if you will be [self-building](self-building.md) components.
|
||||
|
||||
- [`make`](https://www.gnu.org/software/make/) for running `make roles`, etc. (see [`Makefile`](../Makefile)), although you can also run these commands manually (without `make`)
|
||||
- [`just`](https://github.com/casey/just) for running `just roles`, etc. (see [`justfile`](../justfile)), although you can also run these commands manually
|
||||
|
||||
- An HTTPS-capable web server at the base domain name (`<your-domain>`) which is capable of serving static files. Unless you decide to [Serve the base domain from the Matrix server](configuring-playbook-base-domain-serving.md) or alternatively, to use DNS SRV records for [Server Delegation](howto-server-delegation.md).
|
||||
|
||||
|
||||
@ -16,13 +16,21 @@ Table of contents:
|
||||
|
||||
You can do it via this Ansible playbook (make sure to edit the `<your-username>` and `<your-password>` part below):
|
||||
|
||||
```sh
|
||||
just register-user <your-username> <your-password> <admin access: yes or no>
|
||||
|
||||
# Example: `just register-user john secret-password yes`
|
||||
```
|
||||
|
||||
**or** by invoking `ansible-playbook` manually:
|
||||
|
||||
```sh
|
||||
ansible-playbook -i inventory/hosts setup.yml --extra-vars='username=<your-username> password=<your-password> admin=<yes|no>' --tags=register-user
|
||||
```
|
||||
|
||||
**or** using the command-line after **SSH**-ing to your server (requires that [all services have been started](#starting-the-services)):
|
||||
|
||||
```
|
||||
```sh
|
||||
/matrix/synapse/bin/register-user <your-username> <your-password> <admin access: 0 or 1>
|
||||
```
|
||||
|
||||
|
||||
Reference in New Issue
Block a user