mirror of
https://github.com/spantaleev/matrix-docker-ansible-deploy.git
synced 2025-01-15 20:53:12 +01:00
Edit lines for vars.yml
(#3933)
* Simplify paths to vars.yml if referred multiple times Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org> * Fix the filename: vars.yaml → vars.yml Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org> --------- Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org> Co-authored-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This commit is contained in:
parent
04cb2f8fa5
commit
61ace3a063
@ -67,7 +67,7 @@ By default, this playbook installs matrix-alertmanager-receiver on the `matrix.`
|
||||
|
||||
By tweaking the `matrix_alertmanager_receiver_hostname` and `matrix_alertmanager_receiver_path_prefix` variables, you can easily make the service available at a **different hostname and/or path** than the default one.
|
||||
|
||||
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
Example additional configuration for your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Change the default hostname and path prefix
|
||||
|
@ -52,7 +52,7 @@ matrix_appservice_draupnir_for_all_master_control_room_alias: "MANAGEMENT_ROOM_A
|
||||
|
||||
You can configure additional options by adding the `matrix_appservice_draupnir_for_all_extension_yaml` variable.
|
||||
|
||||
For example, to change Draupnir's `protectAllJoinedRooms` option to `true`, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
For example, to change Draupnir's `protectAllJoinedRooms` option to `true`, add the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_appservice_draupnir_for_all_extension_yaml: |
|
||||
|
@ -78,7 +78,7 @@ To specify who is considered a bot [👮♂️ Administrator](https://github.
|
||||
|
||||
If `matrix_admin` is already configured in your `vars.yml` configuration, you can skip this section.
|
||||
|
||||
**If necessary**, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
**If necessary**, add the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Uncomment to add one or more admins to this bridge:
|
||||
@ -107,7 +107,7 @@ Configuring `matrix_bot_baibot_config_initial_global_config_user_patterns` is op
|
||||
|
||||
**Note**: Once initially configured, the allowed users list **cannot be managed via Ansible anymore**. It can only be managed subsequently via bot commands.
|
||||
|
||||
**If necessary**, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
**If necessary**, add the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Uncomment and adjust the bot users if necessary:
|
||||
|
@ -35,7 +35,7 @@ By default, this playbook installs Buscarron on the `buscarron.` subdomain (`bus
|
||||
|
||||
By tweaking the `matrix_bot_buscarron_hostname` and `matrix_bot_buscarron_path_prefix` variables, you can easily make the service available at a **different hostname and/or path** than the default one.
|
||||
|
||||
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
Example additional configuration for your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Switch to the domain used for Matrix services (`matrix.example.com`),
|
||||
|
@ -66,7 +66,7 @@ Finally invite the `@bot.draupnir:example.com` account you created earlier into
|
||||
|
||||
## Adjusting the playbook configuration
|
||||
|
||||
To enable the bot, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file. Make sure to replace `MANAGEMENT_ROOM_ID_HERE`.
|
||||
To enable the bot, add the following configuration to your `vars.yml` file. Make sure to replace `MANAGEMENT_ROOM_ID_HERE`.
|
||||
|
||||
```yaml
|
||||
# Enable Draupnir
|
||||
@ -85,7 +85,7 @@ To support E2EE, Draupnir needs to [use Pantalaimon](configuring-playbook-pantal
|
||||
|
||||
When using Pantalaimon, Draupnir will log in to its bot account itself through Pantalaimon, so configure its username and password.
|
||||
|
||||
Add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file (adapt to your needs):
|
||||
Add the following configuration to your `vars.yml` file (adapt to your needs):
|
||||
|
||||
```yaml
|
||||
# Enable Pantalaimon. See docs/configuring-playbook-pantalaimon.md
|
||||
@ -115,7 +115,7 @@ matrix_bot_draupnir_raw_homeserver_url: "{{ matrix_addons_homeserver_client_api_
|
||||
|
||||
When NOT using Pantalaimon, Draupnir does not log in by itself and you must give it an access token for its bot account.
|
||||
|
||||
Add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file. Make sure to replace `ACCESS_TOKEN_HERE` with the one created [above](#obtain-an-access-token).
|
||||
Add the following configuration to your `vars.yml` file. Make sure to replace `ACCESS_TOKEN_HERE` with the one created [above](#obtain-an-access-token).
|
||||
|
||||
```yaml
|
||||
matrix_bot_draupnir_access_token: "ACCESS_TOKEN_HERE"
|
||||
@ -137,7 +137,7 @@ The other method polls an Synapse Admin API endpoint, hence it is available only
|
||||
|
||||
You can configure additional options by adding the `matrix_bot_draupnir_configuration_extension_yaml` variable.
|
||||
|
||||
For example, to change Draupnir's `pollReports` option to `true`, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
For example, to change Draupnir's `pollReports` option to `true`, add the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_bot_draupnir_configuration_extension_yaml: |
|
||||
|
@ -200,7 +200,7 @@ By default, this playbook installs Go-NEB on the `goneb.` subdomain (`goneb.exam
|
||||
|
||||
By tweaking the `matrix_bot_go_neb_hostname` and `matrix_bot_go_neb_path_prefix` variables, you can easily make the service available at a **different hostname and/or path** than the default one.
|
||||
|
||||
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
Example additional configuration for your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Switch to the domain used for Matrix services (`matrix.example.com`),
|
||||
|
@ -29,7 +29,7 @@ By default, this playbook installs Honoroit on the `matrix.` subdomain, at the `
|
||||
|
||||
By tweaking the `matrix_bot_honoroit_hostname` and `matrix_bot_honoroit_path_prefix` variables, you can easily make the service available at a **different hostname and/or path** than the default one.
|
||||
|
||||
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
Example additional configuration for your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Change the default hostname and path prefix
|
||||
|
@ -31,7 +31,7 @@ By default, this playbook installs maubot on the `matrix.` subdomain, at the `/_
|
||||
|
||||
By tweaking the `matrix_bot_maubot_hostname` and `matrix_bot_maubot_path_prefix` variables, you can easily make the service available at a **different hostname and/or path** than the default one.
|
||||
|
||||
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
Example additional configuration for your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Change the default hostname and path prefix
|
||||
@ -53,7 +53,7 @@ Certain [maubot plugins](https://plugins.mau.bot/) require additional dependenci
|
||||
|
||||
You can customize the default maubot container image and install your own dependencies.
|
||||
|
||||
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
Example additional configuration for your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_bot_maubot_container_image_customizations_enabled: true
|
||||
|
@ -62,7 +62,7 @@ Finally invite the `@bot.mjolnir:example.com` account you created earlier into t
|
||||
|
||||
## Adjusting the playbook configuration
|
||||
|
||||
To enable the bot, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file. Make sure to replace `MANAGEMENT_ROOM_ID_HERE`.
|
||||
To enable the bot, add the following configuration to your `vars.yml` file. Make sure to replace `MANAGEMENT_ROOM_ID_HERE`.
|
||||
|
||||
```yaml
|
||||
# Enable Mjolnir
|
||||
@ -81,7 +81,7 @@ To support E2EE, Mjolnir needs to [use Pantalaimon](configuring-playbook-pantala
|
||||
|
||||
When using Pantalaimon, Mjolnir will log in to its bot account itself through Pantalaimon, so configure its username and password.
|
||||
|
||||
Add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file (adapt to your needs):
|
||||
Add the following configuration to your `vars.yml` file (adapt to your needs):
|
||||
|
||||
```yaml
|
||||
# Enable Pantalaimon. See docs/configuring-playbook-pantalaimon.md
|
||||
@ -111,7 +111,7 @@ matrix_bot_mjolnir_raw_homeserver_url: "{{ matrix_addons_homeserver_client_api_u
|
||||
|
||||
When NOT using Pantalaimon, Mjolnir does not log in by itself and you must give it an access token for its bot account.
|
||||
|
||||
Add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file. Make sure to replace `ACCESS_TOKEN_HERE` with the one created [above](#obtain-an-access-token).
|
||||
Add the following configuration to your `vars.yml` file. Make sure to replace `ACCESS_TOKEN_HERE` with the one created [above](#obtain-an-access-token).
|
||||
|
||||
```yaml
|
||||
matrix_bot_mjolnir_access_token: "ACCESS_TOKEN_HERE"
|
||||
@ -119,7 +119,7 @@ matrix_bot_mjolnir_access_token: "ACCESS_TOKEN_HERE"
|
||||
|
||||
### Adding Mjolnir synapse antispam module (optional)
|
||||
|
||||
To enable Mjolnir synapse antispam module, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file (adapt to your needs):
|
||||
To enable Mjolnir synapse antispam module, add the following configuration to your `vars.yml` file (adapt to your needs):
|
||||
|
||||
```yaml
|
||||
matrix_synapse_ext_spam_checker_mjolnir_antispam_enabled: true
|
||||
@ -133,7 +133,7 @@ matrix_synapse_ext_spam_checker_mjolnir_antispam_config_ban_lists: []
|
||||
|
||||
You can configure additional options by adding the `matrix_bot_mjolnir_configuration_extension_yaml` variable to your `inventory/host_vars/matrix.example.com/vars.yml` file.
|
||||
|
||||
For example, to change Mjolnir's `recordIgnoredInvites` option to `true`, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
For example, to change Mjolnir's `recordIgnoredInvites` option to `true`, add the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_bot_mjolnir_configuration_extension_yaml: |
|
||||
|
@ -47,7 +47,7 @@ ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,ensure-matrix-use
|
||||
|
||||
## Self-Service Bridging (Manual)
|
||||
|
||||
Self-service bridging allows you to bridge specific and existing Matrix rooms to specific Discord rooms. To enable it, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
Self-service bridging allows you to bridge specific and existing Matrix rooms to specific Discord rooms. To enable it, add the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_appservice_discord_bridge_enableSelfServiceBridging: true
|
||||
@ -73,7 +73,7 @@ Through portal bridging, Matrix rooms will automatically be created by the bot a
|
||||
|
||||
All Matrix rooms created this way are **listed publicly** by default, and you will not have admin permissions to change this. To get more control, [make yourself a room Administrator](#getting-administrator-access-in-a-portal-bridged-room). You can then unlist the room from the directory and change the join rules.
|
||||
|
||||
To disable portal bridging, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
To disable portal bridging, add the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_appservice_discord_bridge_disablePortalBridging: true
|
||||
|
@ -31,7 +31,7 @@ This makes it easy to install it, because it **doesn't require additional DNS re
|
||||
|
||||
By tweaking the `matrix_heisenbridge_hostname` and `matrix_heisenbridge_path_prefix` variables, you can easily make the service available at a **different hostname and/or path** than the default one.
|
||||
|
||||
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
Example additional configuration for your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Change the default hostname and path prefix
|
||||
|
@ -105,7 +105,7 @@ The GitHub bridge requires you to install a private key file. This can be done i
|
||||
- somehow copy the file to the path `{{ matrix_hookshot_base_path }}/{{ matrix_hookshot_github_private_key_file }}` (default: `/matrix/hookshot/private-key.pem`) on the server manually.
|
||||
- use the [`aux` role](https://github.com/mother-of-all-self-hosting/ansible-role-aux) to copy the file from an arbitrary path on your ansible client to the correct path on the server.
|
||||
|
||||
To use the `aux` role, make sure the `matrix_hookshot_github_private_key` variable is empty. Then add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
To use the `aux` role, make sure the `matrix_hookshot_github_private_key` variable is empty. Then add the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
aux_file_definitions:
|
||||
|
@ -23,7 +23,7 @@ There are some additional things you may wish to configure about the bridge befo
|
||||
|
||||
By default any user on your homeserver will be able to use the mautrix bridges. To limit who can use them you would need to configure their permissions settings.
|
||||
|
||||
Different levels of permission can be granted to users. For example, to **configure a user as an administrator for all bridges**, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
Different levels of permission can be granted to users. For example, to **configure a user as an administrator for all bridges**, add the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_admin: "@alice:{{ matrix_domain }}"
|
||||
@ -46,7 +46,7 @@ You could also redefine the default permissions settings completely, rather than
|
||||
|
||||
### Enable encryption (optional)
|
||||
|
||||
[Encryption (End-to-Bridge Encryption, E2BE) support](https://docs.mau.fi/bridges/general/end-to-bridge-encryption.html) is off by default. If you would like to enable encryption, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
[Encryption (End-to-Bridge Encryption, E2BE) support](https://docs.mau.fi/bridges/general/end-to-bridge-encryption.html) is off by default. If you would like to enable encryption, add the following configuration to your `vars.yml` file:
|
||||
|
||||
**for all bridges with encryption support**:
|
||||
|
||||
@ -66,7 +66,7 @@ matrix_mautrix_SERVICENAME_bridge_encryption_default: true
|
||||
|
||||
[Relay mode](https://docs.mau.fi/bridges/general/relay-mode.html) is off by default. Check [the table on the official documentation](https://docs.mau.fi/bridges/general/relay-mode.html#support-table) for bridges which support relay mode.
|
||||
|
||||
If you would like to enable it, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
If you would like to enable it, add the following configuration to your `vars.yml` file:
|
||||
|
||||
**for all bridges with relay mode support**:
|
||||
|
||||
@ -103,7 +103,7 @@ Use `!prefix set-pl 100` to be able for the bot to modify room settings and invi
|
||||
|
||||
#### Allow anyone on the homeserver to become a relay user (optional)
|
||||
|
||||
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 the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
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 the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_mautrix_SERVICENAME_bridge_relay_admin_only: false
|
||||
@ -111,7 +111,7 @@ matrix_mautrix_SERVICENAME_bridge_relay_admin_only: false
|
||||
|
||||
### Set the bot's username (optional)
|
||||
|
||||
To set the bot's username, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
To set the bot's username, add the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_mautrix_SERVICENAME_appservice_bot_username: "BOTNAME"
|
||||
@ -119,7 +119,7 @@ matrix_mautrix_SERVICENAME_appservice_bot_username: "BOTNAME"
|
||||
|
||||
### Configure the logging level (optional)
|
||||
|
||||
To specify the logging level, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
To specify the logging level, add the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_mautrix_SERVICENAME_logging_level: warn
|
||||
@ -177,7 +177,7 @@ To set up [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppetin
|
||||
|
||||
Appservice Double Puppet is a homeserver appservice through which bridges (and potentially other services) can impersonate any user on the homeserver.
|
||||
|
||||
To enable the Appservice Double Puppet service, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
To enable the Appservice Double Puppet service, add the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_appservice_double_puppet_enabled: true
|
||||
|
@ -38,7 +38,7 @@ matrix_mautrix_telegram_api_hash: YOUR_TELEGRAM_API_HASH
|
||||
|
||||
### Enable relay-bot (optional)
|
||||
|
||||
If you want to use the relay-bot feature ([relay bot documentation](https://docs.mau.fi/bridges/python/telegram/relay-bot.html)), which allows anonymous user to chat with telegram users, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
If you want to use the relay-bot feature ([relay bot documentation](https://docs.mau.fi/bridges/python/telegram/relay-bot.html)), which allows anonymous user to chat with telegram users, add the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_mautrix_telegram_bot_token: YOUR_TELEGRAM_BOT_TOKEN
|
||||
@ -56,7 +56,7 @@ More details about permissions in this example: https://github.com/mautrix/teleg
|
||||
|
||||
### Use the bridge for direct chats only (optional)
|
||||
|
||||
If you want to exclude all groups from syncing and use the Telegram-Bridge only for direct chats, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
If you want to exclude all groups from syncing and use the Telegram-Bridge only for direct chats, add the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_mautrix_telegram_filter_mode: whitelist
|
||||
|
@ -34,7 +34,7 @@ By default, this playbook installs wsproxy on the `wsproxy.` subdomain (`wsproxy
|
||||
|
||||
By tweaking the `matrix_mautrix_wsproxy_hostname` variable, you can easily make the service available at a **different hostname** than the default one.
|
||||
|
||||
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
Example additional configuration for your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Change the default hostname
|
||||
|
@ -44,7 +44,7 @@ By default, this playbook installs Cactus Comments' client on the `matrix.` subd
|
||||
|
||||
By tweaking the `matrix_cactus_comments_client_hostname` and `matrix_cactus_comments_client_path_prefix` variables, you can easily make the service available at a **different hostname and/or path** than the default one.
|
||||
|
||||
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
Example additional configuration for your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Change the default hostname and path prefix to host the client assets at a different location
|
||||
|
@ -24,7 +24,7 @@ By tweaking the `matrix_client_cinny_hostname` variable, you can easily make the
|
||||
|
||||
While a `matrix_client_cinny_path_prefix` variable exists for tweaking the path-prefix, it's [not supported anymore](https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/3701), because Cinny requires an application rebuild (with a tweaked build config) to be functional under a custom path.
|
||||
|
||||
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
Example additional configuration for your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Switch to a different domain (`app.example.com`) than the default one (`cinny.example.com`)
|
||||
|
@ -29,7 +29,7 @@ Note that for a custom theme to work well, all Element Web instances that you us
|
||||
|
||||
#### Define themes manually
|
||||
|
||||
You can also define your own themes manually by adding and adjusting the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
You can also define your own themes manually by adding and adjusting the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Controls the `setting_defaults.custom_themes` setting of the Element Web configuration.
|
||||
@ -46,7 +46,7 @@ By default, this playbook installs Element Web on the `element.` subdomain (`ele
|
||||
|
||||
By tweaking the `matrix_client_element_hostname` and `matrix_client_element_path_prefix` variables, you can easily make the service available at a **different hostname and/or path** than the default one.
|
||||
|
||||
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
Example additional configuration for your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Switch to the domain used for Matrix services (`matrix.example.com`),
|
||||
@ -66,7 +66,7 @@ Take a look at:
|
||||
- `roles/custom/matrix-client-element/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
|
||||
- `roles/custom/matrix-client-element/templates/config.json.j2` for the component's default configuration. You can override settings (even those that don't have dedicated playbook variables) using the `matrix_client_element_configuration_extension_json` variable
|
||||
|
||||
For example, to override some Element Web settings, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
For example, to override some Element Web settings, add the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Your custom JSON configuration for Element Web should go to `matrix_client_element_configuration_extension_json`.
|
||||
@ -94,7 +94,7 @@ If you've decided to reuse the `matrix.` domain, you won't need to do any extra
|
||||
|
||||
## Disabling Element Web
|
||||
|
||||
If you'd like for the playbook to not install Element Web (or to uninstall it if it was previously installed), add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
If you'd like for the playbook to not install Element Web (or to uninstall it if it was previously installed), add the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_client_element_enabled: false
|
||||
|
@ -18,7 +18,7 @@ By default, this playbook installs Hydrogen on the `hydrogen.` subdomain (`hydro
|
||||
|
||||
By tweaking the `matrix_client_hydrogen_hostname` and `matrix_client_hydrogen_path_prefix` variables, you can easily make the service available at a **different hostname and/or path** than the default one.
|
||||
|
||||
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
Example additional configuration for your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Switch to the domain used for Matrix services (`matrix.example.com`),
|
||||
|
@ -22,7 +22,7 @@ You can change the look of SchildiChat Web by pulling themes provided by the [aa
|
||||
|
||||
#### Use themes by `element-themes`
|
||||
|
||||
To pull the themes from the `element-themes` project and use them for your SchildiChat Web instance, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
To pull the themes from the `element-themes` project and use them for your SchildiChat Web instance, add the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_client_schildichat_themes_enabled: true
|
||||
@ -34,7 +34,7 @@ Note that for a custom theme to work well, all SchildiChat Web instances that yo
|
||||
|
||||
#### Define themes manually
|
||||
|
||||
You can also define your own themes manually by adding and adjusting the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
You can also define your own themes manually by adding and adjusting the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Controls the `setting_defaults.custom_themes` setting of the SchildiChat Web configuration.
|
||||
@ -51,7 +51,7 @@ By default, this playbook installs SchildiChat Web on the `schildichat.` subdoma
|
||||
|
||||
By tweaking the `matrix_client_schildichat_hostname` and `matrix_client_schildichat_path_prefix` variables, you can easily make the service available at a **different hostname and/or path** than the default one.
|
||||
|
||||
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
Example additional configuration for your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Switch to the domain used for Matrix services (`matrix.example.com`),
|
||||
@ -71,7 +71,7 @@ Take a look at:
|
||||
- `roles/custom/matrix-client-schildichat/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
|
||||
- `roles/custom/matrix-client-schildichat/templates/config.json.j2` for the component's default configuration. You can override settings (even those that don't have dedicated playbook variables) using the `matrix_client_schildichat_configuration_extension_json` variable
|
||||
|
||||
For example, to override some SchildiChat Web settings, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
For example, to override some SchildiChat Web settings, add the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Your custom JSON configuration for SchildiChat Web should go to `matrix_client_schildichat_configuration_extension_json`.
|
||||
|
@ -29,7 +29,7 @@ Take a look at:
|
||||
- `roles/custom/matrix-conduit/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
|
||||
- `roles/custom/matrix-conduit/templates/conduit.toml.j2` for the server's default configuration
|
||||
|
||||
If you'd like to have your own different configuration, feel free to copy and paste the original files into your inventory (e.g. in `inventory/host_vars/matrix.example.com/`) and then change the specific host's `vars.yaml` file like this:
|
||||
If you'd like to have your own different configuration, feel free to copy and paste the original files into your inventory (e.g. in `inventory/host_vars/matrix.example.com/`) and then change the specific host's `vars.yml` file like this:
|
||||
|
||||
```yaml
|
||||
matrix_conduit_template_conduit_config: "{{ playbook_dir }}/inventory/host_vars/matrix.example.com/conduit.toml.j2"
|
||||
|
@ -29,7 +29,7 @@ Take a look at:
|
||||
- `roles/custom/matrix-dendrite/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
|
||||
- `roles/custom/matrix-dendrite/templates/dendrite.yaml.j2` for the server's default configuration. You can override settings (even those that don't have dedicated playbook variables) using the `matrix_dendrite_configuration_extension_yaml` variable
|
||||
|
||||
For example, to override some Dendrite settings, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
For example, to override some Dendrite settings, add the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_dendrite_configuration_extension_yaml: |
|
||||
|
@ -48,7 +48,7 @@ matrix_dimension_access_token: "ACCESS_TOKEN_HERE"
|
||||
|
||||
### Define admin users
|
||||
|
||||
To define admin users who can modify the integrations this Dimension supports, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
To define admin users who can modify the integrations this Dimension supports, add the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_dimension_admins:
|
||||
@ -64,7 +64,7 @@ By default, this playbook installs Dimension on the `dimension.` subdomain (`dim
|
||||
|
||||
By tweaking the `matrix_dimension_hostname` and `matrix_dimension_path_prefix` variables, you can easily make the service available at a **different hostname and/or path** than the default one.
|
||||
|
||||
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
Example additional configuration for your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Switch to the domain used for Matrix services (`matrix.example.com`),
|
||||
|
@ -56,7 +56,7 @@ Take note of each room's room ID (different clients show the room ID in a differ
|
||||
|
||||
## Adjusting the playbook configuration
|
||||
|
||||
To enable Email2Matrix, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file. Make sure to replace `ACCESS_TOKEN_FOR_EMAIL2MATRIX1_HERE` and `ACCESS_TOKEN_FOR_EMAIL2MATRIX2_HERE` with the ones created [above](#obtain-an-access-token).
|
||||
To enable Email2Matrix, add the following configuration to your `vars.yml` file. Make sure to replace `ACCESS_TOKEN_FOR_EMAIL2MATRIX1_HERE` and `ACCESS_TOKEN_FOR_EMAIL2MATRIX2_HERE` with the ones created [above](#obtain-an-access-token).
|
||||
|
||||
```yaml
|
||||
matrix_email2matrix_enabled: true
|
||||
|
@ -22,7 +22,7 @@ By default, this playbook installs Etherpad on the `etherpad.` subdomain (`ether
|
||||
|
||||
By tweaking the `etherpad_hostname` and `etherpad_path_prefix` variables, you can easily make the service available at a **different hostname and/or path** than the default one.
|
||||
|
||||
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
Example additional configuration for your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Switch to the domain used for Matrix services (`matrix.example.com`),
|
||||
|
@ -20,7 +20,7 @@ If you wish to disable federation, you can do that with an empty list (`[]`), or
|
||||
|
||||
By default, your server's public rooms directory is not exposed to other servers via federation.
|
||||
|
||||
To expose it, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
To expose it, add the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_synapse_allow_public_rooms_over_federation: true
|
||||
@ -28,7 +28,7 @@ matrix_synapse_allow_public_rooms_over_federation: true
|
||||
|
||||
## Disabling federation
|
||||
|
||||
To completely disable federation, isolating your server from the rest of the Matrix network, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
To completely disable federation, isolating your server from the rest of the Matrix network, add the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_homeserver_federation_enabled: false
|
||||
@ -52,7 +52,7 @@ matrix_synapse_reverse_proxy_companion_federation_api_enabled: false
|
||||
|
||||
Why? This change could be useful for people running small Synapse instances on small severs/VPSes to avoid being impacted by a simple DOS/DDOS when bandwidth, RAM, an CPU resources are limited and if your hosting provider does not provide a DOS/DDOS protection.
|
||||
|
||||
To make it possible to proxy the federation through a CDN such as CloudFlare or any other, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
To make it possible to proxy the federation through a CDN such as CloudFlare or any other, add the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_synapse_http_listener_resource_names: ["client","federation"]
|
||||
|
@ -27,7 +27,7 @@ By default, this playbook installs Jitsi on the `jitsi.` subdomain (`jitsi.examp
|
||||
|
||||
By tweaking the `jitsi_hostname` variable, you can easily make the service available at a **different hostname** than the default one.
|
||||
|
||||
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
Example additional configuration for your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Change the default hostname
|
||||
@ -56,7 +56,7 @@ Currently, there are three supported authentication modes: 'internal' (default),
|
||||
|
||||
The default authentication mechanism is 'internal' auth, which requires jitsi-accounts to be setup and is the recommended setup, as it also works in federated rooms. 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 lines to your `inventory/host_vars/matrix.example.com/vars.yml` configuration:
|
||||
Add the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
jitsi_enable_auth: true
|
||||
@ -118,9 +118,7 @@ By default the Jitsi Meet instance does not work with a client in LAN (Local Are
|
||||
|
||||
The reason is the Jitsi VideoBridge git to LAN client the IP address of the docker image instead of the host. The [documentation](https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-docker/#running-behind-nat-or-on-a-lan-environment) of Jitsi in docker suggest to add `JVB_ADVERTISE_IPS` in enviornment variable to make it work.
|
||||
|
||||
Here is how to do it in the playbook.
|
||||
|
||||
Add these two lines to your `inventory/host_vars/matrix.example.com/vars.yml` configuration:
|
||||
To enable it, add the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
jitsi_jvb_container_extra_arguments:
|
||||
@ -129,7 +127,7 @@ jitsi_jvb_container_extra_arguments:
|
||||
|
||||
## Fine tune Jitsi (optional)
|
||||
|
||||
Sample **additional** `inventory/host_vars/matrix.example.com/vars.yml` configuration to save up resources (explained below):
|
||||
If you'd like to have Jitsi save up resources, add the following configuration to your `vars.yml` file (adapt to your needs):
|
||||
|
||||
```yaml
|
||||
jitsi_web_custom_config_extension: |
|
||||
@ -175,7 +173,7 @@ For this role to work you will need an additional section in the ansible hosts f
|
||||
<your jvb hosts> ansible_host=<ip address of the jvb host>
|
||||
```
|
||||
|
||||
Each JVB will require a server ID to be set so that it can be uniquely identified and this allows Jitsi to keep track of which conferences are on which JVB. The server ID is set with the variable `jitsi_jvb_server_id` which ends up as the JVB_WS_SERVER_ID environment variables in the JVB docker container. This variable can be set via the host file, a parameter to the ansible command or in the `vars.yaml` for the host which will have the additional JVB. For example:
|
||||
Each JVB will require a server ID to be set so that it can be uniquely identified and this allows Jitsi to keep track of which conferences are on which JVB. The server ID is set with the variable `jitsi_jvb_server_id` which ends up as the JVB_WS_SERVER_ID environment variables in the JVB docker container. This variable can be set via the host file, a parameter to the ansible command or in the `vars.yml` for the host which will have the additional JVB. For example:
|
||||
|
||||
```yaml
|
||||
jitsi_jvb_server_id: 'jvb-2'
|
||||
|
@ -39,7 +39,7 @@ To ensure maximum discovery, you can make your identity server also forward look
|
||||
|
||||
Enabling this is discouraged and you'd better [learn more](https://github.com/ma1uta/ma1sd/blob/master/docs/features/identity.md#lookups) before proceeding.
|
||||
|
||||
To enable matrix.org forwarding, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
To enable matrix.org forwarding, add the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_ma1sd_matrixorg_forwarding_enabled: true
|
||||
@ -79,7 +79,7 @@ To use the [Registration](https://github.com/ma1uta/ma1sd/blob/master/docs/featu
|
||||
|
||||
[Authentication](https://github.com/ma1uta/ma1sd/blob/master/docs/features/authentication.md) provides the possibility to use your own [Identity Stores](https://github.com/ma1uta/ma1sd/blob/master/docs/stores/README.md) (for example LDAP) to authenticate users on your Homeserver.
|
||||
|
||||
To enable authentication against an LDAP server, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
To enable authentication against an LDAP server, add the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_synapse_ext_password_provider_rest_auth_enabled: true
|
||||
@ -150,7 +150,7 @@ If email address validation emails sent by ma1sd are not reaching you, you shoul
|
||||
|
||||
If you'd like additional logging information, temporarily enable verbose logging for ma1sd.
|
||||
|
||||
To enable it, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
To enable it, add the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_ma1sd_verbose_logging: true
|
||||
|
@ -123,7 +123,7 @@ By default, this playbook installs the Matrix Authentication Service on the `mat
|
||||
|
||||
By tweaking the `matrix_authentication_service_hostname` and `matrix_authentication_service_path_prefix` variables, you can easily make the service available at a **different hostname and/or path** than the default one.
|
||||
|
||||
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
Example additional configuration for your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Change the default hostname and path prefix
|
||||
@ -146,7 +146,7 @@ The playbook exposes a `matrix_authentication_service_config_upstream_oauth2_pro
|
||||
<details>
|
||||
<summary>Click to expand the example configuration:</summary>
|
||||
|
||||
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
Example additional configuration for your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_authentication_service_config_upstream_oauth2_providers:
|
||||
@ -361,7 +361,7 @@ If in `matrix_synapse_oidc_providers` your provider `idp_id` is (was) named `key
|
||||
|
||||
The same OIDC provider may have an `id` of `01HFVBY12TMNTYTBV8W921M5FA` on the MAS side, as defined in `matrix_authentication_service_config_upstream_oauth2_providers` (see the [Upstream OAuth2 configuration](#upstream-oauth2-configuration) section above).
|
||||
|
||||
To tell `syn2mas` how the Synapse-configured OIDC provider maps to the new MAS-configured OIDC provider, add this additional configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
To tell `syn2mas` how the Synapse-configured OIDC provider maps to the new MAS-configured OIDC provider, add this additional configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Adjust the mapping below to match your provider IDs on the Synapse side and the MAS side.
|
||||
|
@ -31,7 +31,7 @@ By default, this playbook installs the matrix-registration on the `matrix.` subd
|
||||
|
||||
By tweaking the `matrix_registration_hostname` and `matrix_registration_path_prefix` variables, you can easily make the service available at a **different hostname and/or path** than the default one.
|
||||
|
||||
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
Example additional configuration for your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Change the default hostname and path prefix
|
||||
|
@ -34,7 +34,7 @@ By default, this playbook installs ntfy on the `ntfy.` subdomain (`ntfy.example.
|
||||
|
||||
By tweaking the `ntfy_hostname` variable, you can easily make the service available at a **different hostname** than the default one.
|
||||
|
||||
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
Example additional configuration for your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Change the default hostname
|
||||
|
@ -38,7 +38,7 @@ By default, this playbook installs Grafana web user-interface on the `stats.` su
|
||||
|
||||
By tweaking the `grafana_hostname` variable, you can easily make the service available at a **different hostname** than the default one.
|
||||
|
||||
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
Example additional configuration for your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Change the default hostname
|
||||
|
@ -32,7 +32,7 @@ By default, this playbook installs rageshake on the `rageshake.` subdomain (`rag
|
||||
|
||||
By tweaking the `matrix_rageshake_hostname` and `matrix_rageshake_path_prefix` variables, you can easily make the service available at a **different hostname and/or path** than the default one.
|
||||
|
||||
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
Example additional configuration for your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Switch to the domain used for Matrix services (`matrix.example.com`),
|
||||
|
@ -20,7 +20,7 @@ By default, this playbook installs the Sliding Sync proxy on the `matrix.` subdo
|
||||
|
||||
By tweaking the `matrix_sliding_sync_hostname` and `matrix_sliding_sync_path_prefix` variables, you can easily make the service available at a **different hostname and/or path** than the default one.
|
||||
|
||||
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
Example additional configuration for your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Change the default hostname and path prefix
|
||||
|
@ -18,7 +18,7 @@ traefik_config_certificatesResolvers_acme_use_staging: true
|
||||
|
||||
For testing or other purposes, you may wish to install services without SSL termination and have services exposed to `http://` instead of `https://`.
|
||||
|
||||
Add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
Add the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
traefik_config_entrypoint_web_secure_enabled: false
|
||||
|
@ -56,7 +56,7 @@ By default, this playbook installs Sygnal on the `sygnal.` subdomain (`sygnal.ex
|
||||
|
||||
By tweaking the `matrix_sygnal_hostname` and `matrix_sygnal_path_prefix` variables, you can easily make the service available at a **different hostname and/or path** than the default one.
|
||||
|
||||
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
Example additional configuration for your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Switch to the domain used for Matrix services (`matrix.example.com`),
|
||||
|
@ -29,7 +29,7 @@ By default, this playbook installs Synapse Admin on the `matrix.` subdomain, at
|
||||
|
||||
By tweaking the `matrix_synapse_admin_hostname` and `matrix_synapse_admin_path_prefix` variables, you can easily make the service available at a **different hostname and/or path** than the default one.
|
||||
|
||||
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
Example additional configuration for your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Change the default hostname and path prefix
|
||||
|
@ -31,7 +31,7 @@ By default, this playbook installs synapse-usage-exporter on the `matrix.` subdo
|
||||
|
||||
By tweaking the `matrix_synapse_usage_exporter_hostname` and `matrix_synapse_usage_exporter_path_prefix` variables, you can easily make the service available at a **different hostname and/or path** than the default one.
|
||||
|
||||
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
Example additional configuration for your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Change the default hostname and path prefix
|
||||
|
@ -108,7 +108,7 @@ If template customization is enabled, the playbook will build a custom container
|
||||
|
||||
Your custom templates need to live in a public or private git repository. This repository will be cloned during Synapse image customization (during the playbook run).
|
||||
|
||||
To enable template customizations, use a configuration (`inventory/host_vars/matrix.example.com/vars.yml`) like this:
|
||||
To enable template customizations, add the following configuration to your `vars.yml` file (adapt to your needs):
|
||||
|
||||
```yaml
|
||||
# If you'd like to ensure that the customized image is built each time the playbook runs, enable this.
|
||||
|
@ -113,7 +113,7 @@ matrix_conduit_container_extra_arguments: []
|
||||
# Specifies which template files to use when configuring Conduit.
|
||||
# If you'd like to have your own different configuration, feel free to copy and paste
|
||||
# the original files into your inventory (e.g. in `inventory/host_vars/matrix.example.com/`)
|
||||
# and then change the specific host's `vars.yaml` file like this:
|
||||
# and then change the specific host's `vars.yml` file like this:
|
||||
# matrix_conduit_template_conduit_config: "{{ playbook_dir }}/inventory/host_vars/matrix.example.com/conduit.toml.j2"
|
||||
matrix_conduit_template_conduit_config: "{{ role_path }}/templates/conduit.toml.j2"
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user