mirror of
https://github.com/spantaleev/matrix-docker-ansible-deploy.git
synced 2026-03-29 19:31:25 +03:00
Compare commits
2 Commits
copilot/up
...
element-ca
| Author | SHA1 | Date | |
|---|---|---|---|
|
69e33575e2 | ||
|
|
64f7c2187d |
@@ -1,2 +0,0 @@
|
||||
[codespell]
|
||||
ignore-words-list = aNULL,brose,doub,Udo,re-use,re-used,registr,shema
|
||||
11
.github/renovate.json
vendored
11
.github/renovate.json
vendored
@@ -9,8 +9,8 @@
|
||||
"customManagers": [
|
||||
{
|
||||
"customType": "regex",
|
||||
"managerFilePatterns": [
|
||||
"/defaults/main.yml$/"
|
||||
"fileMatch": [
|
||||
"defaults/main.yml$"
|
||||
],
|
||||
"matchStrings": [
|
||||
"# renovate: datasource=(?<datasource>[a-z-.]+?) depName=(?<depName>[^\\s]+?)(?: (?:lookupName|packageName)=(?<packageName>[^\\s]+?))?(?: versioning=(?<versioning>[a-z-0-9]+?))?\\s+[A-Za-z0-9_]+?(?:_version|_tag)\\s*:\\s*[\"']?(?<currentValue>.+?)[\"']?\\s"
|
||||
@@ -20,14 +20,13 @@
|
||||
"packageRules": [
|
||||
{
|
||||
"ignoreUnstable": false,
|
||||
"versioning": "loose",
|
||||
"matchSourceUrls": [
|
||||
"https://github.com/devture/com.devture.ansible.role{/,}**",
|
||||
"https://github.com/mother-of-all-self-hosting{/,}**"
|
||||
]
|
||||
}
|
||||
],
|
||||
"pre-commit": {
|
||||
"enabled": true
|
||||
}
|
||||
"ignoreDeps": [
|
||||
"ghcr.io/matrixgpt/matrix-chatgpt-bot"
|
||||
]
|
||||
}
|
||||
|
||||
2
.github/workflows/close-stale-issues.yml
vendored
2
.github/workflows/close-stale-issues.yml
vendored
@@ -19,7 +19,7 @@ jobs:
|
||||
if: github.repository == 'spantaleev/matrix-docker-ansible-deploy'
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/stale@v10
|
||||
- uses: actions/stale@v9
|
||||
with:
|
||||
######################################################################
|
||||
# Issues/PRs
|
||||
|
||||
2
.github/workflows/lock-threads.yml
vendored
2
.github/workflows/lock-threads.yml
vendored
@@ -23,7 +23,7 @@ jobs:
|
||||
if: github.repository == 'spantaleev/matrix-docker-ansible-deploy'
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: dessant/lock-threads@v6
|
||||
- uses: dessant/lock-threads@v5
|
||||
with:
|
||||
add-issue-labels: 'outdated'
|
||||
process-only: 'issues, prs'
|
||||
|
||||
24
.github/workflows/matrix.yml
vendored
24
.github/workflows/matrix.yml
vendored
@@ -7,7 +7,9 @@
|
||||
---
|
||||
name: Matrix CI
|
||||
|
||||
on: [push, pull_request] # yamllint disable-line rule:truthy
|
||||
on: # yamllint disable-line rule:truthy
|
||||
push:
|
||||
pull_request:
|
||||
|
||||
jobs:
|
||||
yamllint:
|
||||
@@ -15,7 +17,7 @@ jobs:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Check out
|
||||
uses: actions/checkout@v6
|
||||
uses: actions/checkout@v4
|
||||
- name: Run yamllint
|
||||
uses: frenck/action-yamllint@v1.5.0
|
||||
ansible-lint:
|
||||
@@ -23,20 +25,8 @@ jobs:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Check out
|
||||
uses: actions/checkout@v6
|
||||
|
||||
uses: actions/checkout@v4
|
||||
- name: Run ansible-lint
|
||||
uses: ansible/ansible-lint@v26.1.1
|
||||
uses: ansible-community/ansible-lint-action@v6.17.0
|
||||
with:
|
||||
args: "roles/custom"
|
||||
setup_python: "true"
|
||||
working_directory: ""
|
||||
requirements_file: requirements.yml
|
||||
precommit:
|
||||
name: Run pre-commit
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Checkout code
|
||||
uses: actions/checkout@v6
|
||||
- name: Run pre-commit
|
||||
uses: pre-commit/action@v3.0.1
|
||||
path: roles/custom
|
||||
|
||||
20
.github/workflows/reuse.yml
vendored
Normal file
20
.github/workflows/reuse.yml
vendored
Normal file
@@ -0,0 +1,20 @@
|
||||
# SPDX-FileCopyrightText: 2022 Free Software Foundation Europe e.V. <https://fsfe.org>
|
||||
#
|
||||
# SPDX-License-Identifier: CC0-1.0
|
||||
---
|
||||
name: REUSE Compliance Check
|
||||
|
||||
on: [push, pull_request] # yamllint disable-line rule:truthy
|
||||
|
||||
permissions:
|
||||
contents: read
|
||||
|
||||
jobs:
|
||||
reuse-compliance-check:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@v4
|
||||
|
||||
- name: REUSE Compliance Check
|
||||
uses: fsfe/reuse-action@v5
|
||||
52
.github/workflows/update-translations.yml
vendored
52
.github/workflows/update-translations.yml
vendored
@@ -1,52 +0,0 @@
|
||||
# SPDX-FileCopyrightText: 2024 Suguru Hirahara
|
||||
#
|
||||
# SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
|
||||
---
|
||||
name: Update translations
|
||||
|
||||
on: # yamllint disable-line rule:truthy
|
||||
push:
|
||||
branches:
|
||||
- master
|
||||
paths: # See include_patterns on conf.py
|
||||
- 'docs/*.md'
|
||||
- 'i18n/README.md'
|
||||
- '*.md'
|
||||
|
||||
permissions:
|
||||
contents: write
|
||||
pull-requests: write
|
||||
|
||||
jobs:
|
||||
update:
|
||||
if: github.repository == 'spantaleev/matrix-docker-ansible-deploy'
|
||||
name: Update translations
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v6
|
||||
|
||||
- uses: actions/setup-python@v6
|
||||
with:
|
||||
python-version: '3.14'
|
||||
|
||||
# Setting up recommended prerequisites
|
||||
# See: i18n/README.md
|
||||
- uses: astral-sh/setup-uv@v7
|
||||
- uses: extractions/setup-just@v3
|
||||
|
||||
# TODO: optimize when we start publishing translations and integrate a Weblate instance
|
||||
- name: Update translation catalog templates (POT) files
|
||||
run: just --justfile i18n/justfile extract-translation-templates
|
||||
|
||||
- name: Create Pull Request
|
||||
uses: peter-evans/create-pull-request@v8.1.0
|
||||
with:
|
||||
author: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> # Same as committer
|
||||
body: This is an automatic pull request to update translation files.
|
||||
branch: create-pull-request/i18n
|
||||
commit-message: Automatic translations update
|
||||
delete-branch: true
|
||||
labels: docs
|
||||
sign-commits: true
|
||||
title: Automatic translations update
|
||||
@@ -1,26 +0,0 @@
|
||||
---
|
||||
default_install_hook_types: [pre-push]
|
||||
|
||||
exclude: "LICENSES/"
|
||||
|
||||
# See: https://pre-commit.com/hooks.html
|
||||
repos:
|
||||
- repo: https://github.com/pre-commit/pre-commit-hooks
|
||||
rev: v6.0.0
|
||||
hooks:
|
||||
# - id: check-executables-have-shebangs
|
||||
- id: check-added-large-files
|
||||
- id: check-case-conflict
|
||||
- id: check-json
|
||||
- id: check-toml
|
||||
- id: trailing-whitespace
|
||||
- id: end-of-file-fixer
|
||||
- repo: https://github.com/codespell-project/codespell
|
||||
rev: v2.4.1
|
||||
hooks:
|
||||
- id: codespell
|
||||
args: ["--skip=*.po,*.pot,i18n/"]
|
||||
- repo: https://github.com/fsfe/reuse-tool # https://reuse.software/dev/#pre-commit-hook
|
||||
rev: v6.2.0
|
||||
hooks:
|
||||
- id: reuse
|
||||
402
CHANGELOG.md
402
CHANGELOG.md
@@ -1,357 +1,3 @@
|
||||
# 2026-02-21
|
||||
|
||||
## (BC Break) coturn is no longer auto-enabled by default
|
||||
|
||||
By default, the [coturn](./docs/configuring-playbook-turn.md) TURN server component is no longer enabled for every deployment.
|
||||
|
||||
This reduces resources and attach surface for deployments which:
|
||||
|
||||
- either don't need calls at all
|
||||
- or use the modern [Matrix RTC](docs/configuring-playbook-matrix-rtc.md)/[Element Call](docs/configuring-playbook-element-call.md) stack.
|
||||
|
||||
Coturn is still auto-enabled when [Jitsi](./docs/configuring-playbook-jitsi.md) is enabled (`jitsi_enabled: true`), because Jitsi still depends on TURN for legacy Matrix integration.
|
||||
|
||||
Additionally, Coturn (when enabled) now defaults to using automatic IP detection of your server's external IP address, instead of assuming your Ansible inventory (`ansible_host`) points to a public address and using it for configuring `coturn_turn_external_ip_address`.
|
||||
|
||||
To restore the old behavior (needed for legacy call setups), add the following configuration to your `vars.yml`:
|
||||
|
||||
```yml
|
||||
coturn_enabled: true
|
||||
|
||||
# If you'd like explicit control over the external IP address (like before), keep this too.
|
||||
coturn_turn_external_ip_address: "{{ ansible_host }}"
|
||||
```
|
||||
|
||||
## LiveKit TURN TLS is now automatically fronted by playbook-managed Traefik
|
||||
|
||||
For deployments that use the playbook-managed Traefik reverse-proxy, LiveKit TURN over TCP is now SSL-terminated at Traefik and passed as plain TCP to LiveKit (`turn.external_tls = true`) by default.
|
||||
|
||||
To disable this behavior, set `livekit_server_config_turn_external_tls: false` and the playbook will revert to the old behavior - using traefik-certs-dumper to extract SSL certificates out of Traefik and pass them to LiveKit for explicit SSL termination there.
|
||||
|
||||
If you are using `other-traefik-container` or [another reverse-proxy](./configuring-playbook-own-webserver.md), this change does **not** switch behavior automatically. That mode remains using certificate files in the container (Traefik certificates dumper flow) unless you explicitly set the TURN-Traefik mode variables to opt in.
|
||||
|
||||
# 2026-02-17
|
||||
|
||||
## (BC Break) prometheus-nginxlog-exporter role has been relocated and variable names need adjustments
|
||||
|
||||
The role for prometheus-nginxlog-exporter has been relocated to the [mother-of-all-self-hosting](https://github.com/mother-of-all-self-hosting) organization.
|
||||
|
||||
Along with the relocation, the `matrix_prometheus_nginxlog_exporter_` prefix on its variable names has been renamed to `prometheus_nginxlog_exporter_`, so you need to adjust your `vars.yml` configuration.
|
||||
|
||||
As always, the playbook would let you know about this and point out any variables you may have missed.
|
||||
|
||||
## synapse-auto-invite-accept has been removed from the playbook
|
||||
|
||||
[synapse-auto-invite-accept](./docs/configuring-playbook-synapse-auto-accept-invite.md) has been removed from the playbook, as the same functionality [has been integrated](https://github.com/element-hq/synapse/pull/17147) to Synapse since [v1.109.0](https://github.com/element-hq/synapse/releases/tag/v1.109.0).
|
||||
|
||||
See [this section](./docs/configuring-playbook-synapse-auto-accept-invite.md#native-alternative) for details about how to enable the function on Synapse.
|
||||
|
||||
If you're using any `matrix_synapse_ext_synapse_auto_accept_invite_*` variables, the playbook will let you know which one you'll need to remove from `vars.yml`.
|
||||
|
||||
# 2026-02-16
|
||||
|
||||
## matrix-appservice-slack has been removed from the playbook
|
||||
|
||||
[matrix-appservice-slack](./docs/configuring-playbook-bridge-appservice-slack.md) has been removed from the playbook, as it has been discontinued because the public Matrix.org Slack bridge has been decommissioned on January 14th, 2026.
|
||||
|
||||
The playbook will let you know if you're using any `matrix_appservice_slack_*` variables. You'll need to remove them from `vars.yml` and potentially [uninstall the component manually](./docs/configuring-playbook-bridge-appservice-slack.md#uninstalling-the-component-manually).
|
||||
|
||||
**Note**: Bridging to [Slack](https://slack.com) can also happen via the [mautrix-slack](./docs/configuring-playbook-bridge-mautrix-slack.md) bridge supported by the playbook.
|
||||
|
||||
# 2026-02-13
|
||||
|
||||
## Conditional service restart for `install-*` commands
|
||||
|
||||
When running `install-all` or `install-service` (whether via `just` or raw `ansible-playbook`), only services whose configuration or container image actually changed during the playbook run will now be restarted. Unchanged services are left running (or get started if they were stopped). This reduces unnecessary downtime — particularly for services like Traefik (the reverse proxy), which previously caused brief connectivity interruptions on every playbook run even when nothing changed.
|
||||
|
||||
When running with `setup-*` tags (e.g. `setup-all`, `setup-synapse`), all services continue to be unconditionally restarted as before.
|
||||
|
||||
Currently, only Traefik tracks its own changes and benefits from conditional restart. All other services default to being restarted (the previous behavior). This is just the beginning — as more roles gain change-tracking support, playbook performance will improve and downtime will decrease dramatically, especially for `install-all` runs where most services haven't changed.
|
||||
|
||||
Some benchmarks for `just install-service traefik` when Traefik settings did not change:
|
||||
|
||||
- **Before**:
|
||||
- total time: ~56 seconds 🐌
|
||||
- Traefik restarted: yes (unnecessarily) ❌
|
||||
- dependent services restarted: yes, all of them ❌
|
||||
- **After**:
|
||||
- total time: ~27 seconds ⚡
|
||||
- Traefik restarted: no ✅
|
||||
- dependent services restarted: no ✅
|
||||
|
||||
This behavior can be overridden via `--extra-vars='devture_systemd_service_manager_conditional_restart_enabled=false'` to force unconditional restarts. See [Conditional service restart](docs/just.md#conditional-service-restart) for details.
|
||||
|
||||
|
||||
# 2026-02-12
|
||||
|
||||
## Dimension integration manager has been removed from the playbook
|
||||
|
||||
The [Dimension integration manager](./docs/configuring-playbook-dimension.md) has been removed from the playbook, as it has been unmaintained.
|
||||
|
||||
The playbook will let you know if you're using any `matrix_dimension_*` variables. You'll need to remove them from `vars.yml` and potentially [uninstall the component manually](./docs/configuring-playbook-dimension.md#uninstalling-the-component-manually).
|
||||
|
||||
## (BC Break) Hydrogen role has been relocated and variable names need adjustments
|
||||
|
||||
The role for Hydrogen has been relocated to the [mother-of-all-self-hosting](https://github.com/mother-of-all-self-hosting) organization.
|
||||
|
||||
Along with the relocation, the `matrix_client_hydrogen_` prefix was dropped from its variable names, so you need to adjust your `vars.yml` configuration.
|
||||
|
||||
You need to do the following replacement:
|
||||
|
||||
- `matrix_client_hydrogen_` -> `hydrogen_`
|
||||
|
||||
As always, the playbook would let you know about this and point out any variables you may have missed.
|
||||
|
||||
# 2026-02-11
|
||||
|
||||
## (BC Break) coturn role has been relocated and variable names need adjustments
|
||||
|
||||
The role for coturn has been relocated to the [mother-of-all-self-hosting](https://github.com/mother-of-all-self-hosting) organization.
|
||||
|
||||
Along with the relocation, the `matrix_coturn_` prefix on its variable names has been renamed to `coturn_`, so you need to adjust your `vars.yml` configuration.
|
||||
|
||||
As always, the playbook would let you know about this and point out any variables you may have missed.
|
||||
|
||||
## conduwuit has been removed from the playbook
|
||||
|
||||
[conduwuit](./docs/configuring-playbook-conduwuit.md) has been removed from the playbook, as it has been abandoned.
|
||||
|
||||
The playbook will let you know if you're using any `matrix_conduwuit_*` variables. You'll need to remove them from `vars.yml` and potentially [uninstall the service manually](./docs/configuring-playbook-conduwuit.md#uninstalling-the-service-manually).
|
||||
|
||||
Since [Continuwuity](configuring-playbook-continuwuity.md) is a drop-in replacement for conduwuit, migration is possible. Please refer to [this section](./configuring-playbook-continuwuity.md#migrating-from-conduwuit) for details.
|
||||
|
||||
# 2026-02-09
|
||||
|
||||
## (BC Break) matrix-media-repo datastore IDs are now required in `vars.yml`
|
||||
|
||||
**Affects**: users with [matrix-media-repo](docs/configuring-playbook-matrix-media-repo.md) enabled (`matrix_media_repo_enabled: true`)
|
||||
|
||||
The `matrix_media_repo_datastore_file_id` and `matrix_media_repo_datastore_s3_id` variables are no longer auto-configured with values. They must now be explicitly defined in your `vars.yml` file. The playbook will fail with a helpful error if they are not set (when needed).
|
||||
|
||||
These were never meant to be auto-configured. They were derived from `matrix_homeserver_generic_secret_key`, which is intended for secrets that are OK to change subsequently (and Ansible would assist in propagating these changes). matrix-media-repo datastore IDs are not secrets — they are static identifiers linking media to storage backends, and **must not change** after first use.
|
||||
|
||||
**For existing installations**, retrieve your current values from the server:
|
||||
|
||||
```sh
|
||||
grep 'id:' /matrix/media-repo/config/media-repo.yaml
|
||||
```
|
||||
|
||||
Then add to your `vars.yml`:
|
||||
|
||||
```yaml
|
||||
matrix_media_repo_datastore_file_id: "YOUR_FILE_DATASTORE_ID_HERE"
|
||||
|
||||
# Only if you use S3 storage:
|
||||
# matrix_media_repo_datastore_s3_id: "YOUR_S3_DATASTORE_ID_HERE"
|
||||
```
|
||||
|
||||
**Why do this?**: This change allows us to **remove the [passlib](https://passlib.readthedocs.io/en/stable/index.html) Python library** from the [prerequisites](docs/prerequisites.md), as it was the last component that depended on it.
|
||||
|
||||
# 2026-02-08
|
||||
|
||||
## Zulip bridge has been removed from the playbook
|
||||
|
||||
Zulip bridge has been removed from the playbook, as it doesn't work, and the maintainer seems to have abandoned it. See [this issue](https://github.com/GearKite/MatrixZulipBridge/issues/23) for more context.
|
||||
|
||||
## Switched to faster secret derivation for service passwords
|
||||
|
||||
We've switched the method used for deriving service passwords (database passwords, appservice tokens, etc.) from the `matrix_homeserver_generic_secret_key` variable.
|
||||
|
||||
The old method used `password_hash('sha512', rounds=655555)` (655,555 rounds of SHA-512 hashing), which was designed for protecting low-entropy human passwords against brute-force attacks. For deriving secrets from an already high-entropy secret key, this many rounds provide no additional security - the secret key's entropy is what protects the derived passwords, not the computational cost of hashing.
|
||||
|
||||
The new method uses a single-round `hash('sha512')` with a unique salt per service. This is equally secure for this use case (SHA-512 remains preimage-resistant; brute-forcing a high-entropy key is infeasible regardless of rounds), while being dramatically faster.
|
||||
|
||||
On a fast mini PC, evaluating `postgres_managed_databases` (which references multiple database passwords) dropped from **~10.7 seconds to ~0.6 seconds**. The Postgres role evaluates this variable multiple times during a run, so the cumulative savings are significant. All other roles that reference derived passwords also benefit.
|
||||
|
||||
**What this means for users**: all derived service passwords (database passwords, appservice tokens, etc.) will change on the next playbook run. The main/superuser database password (`postgres_connection_password`) is not affected, as it is hardcoded in inventory variables rather than derived via hashing. All services will receive their new passwords as part of the same run, so this should be a seamless, non-user-impacting change.
|
||||
|
||||
## (BC Break) Dynamic DNS role has been relocated and variable names need adjustments
|
||||
|
||||
The role for Dynamic DNS has been relocated to the [mother-of-all-self-hosting](https://github.com/mother-of-all-self-hosting) organization.
|
||||
|
||||
Along with the relocation, the `matrix_dynamic_dns_` prefix on its variable names has been renamed to `ddclient_`, so you need to adjust your `vars.yml` configuration.
|
||||
|
||||
As always, the playbook would let you know about this and point out any variables you may have missed.
|
||||
|
||||
## ma1sd has been removed from the playbook
|
||||
|
||||
[ma1sd](./docs/configuring-playbook-ma1sd.md) has been removed from the playbook, as it has been unmaintained for a long time.
|
||||
|
||||
The playbook will let you know if you're using any `matrix_ma1sd_*` variables. You'll need to remove them from `vars.yml` and potentially [uninstall the component manually](./docs/configuring-playbook-ma1sd.md#uninstalling-the-component-manually).
|
||||
|
||||
Please note that some of the functions can be achieved with other components. For example, if you wish to implement LDAP integration, you might as well check out [the LDAP provider module for Synapse](./docs/configuring-playbook-ldap-auth.md) instead.
|
||||
|
||||
# 2026-02-07
|
||||
|
||||
## (BC Break) Cinny role has been relocated and variable names need adjustments
|
||||
|
||||
The role for Cinny has been relocated to the [mother-of-all-self-hosting](https://github.com/mother-of-all-self-hosting) organization.
|
||||
|
||||
Along with the relocation, the `matrix_client_cinny_` prefix was dropped from its variable names, so you need to adjust your `vars.yml` configuration.
|
||||
|
||||
You need to do the following replacement:
|
||||
|
||||
- `matrix_client_cinny_` -> `cinny_`
|
||||
|
||||
As always, the playbook would let you know about this and point out any variables you may have missed.
|
||||
|
||||
## The Sliding Sync proxy has been removed from the playbook
|
||||
|
||||
The [Sliding Sync proxy](./docs/configuring-playbook-sliding-sync-proxy.md) has been removed from the playbook, as it's been replaced with a different method (called Simplified Sliding Sync) integrated to newer homeservers by default (**Conduit** homeserver from version `0.6.0` or **Synapse** from version `1.114`).
|
||||
|
||||
The playbook will let you know if you're using any `matrix_sliding_sync_*` variables. You'll need to remove them from `vars.yml` and potentially [uninstall the proxy manually](./docs/configuring-playbook-sliding-sync-proxy.md#uninstalling-the-proxy-manually).
|
||||
|
||||
# 2026-02-04
|
||||
|
||||
## baibot now supports OpenAI's built-in tools (Web Search and Code Interpreter)
|
||||
|
||||
**TLDR**: if you're using the [OpenAI provider](https://github.com/etkecc/baibot/blob/main/docs/providers.md#openai) with [baibot](docs/configuring-playbook-bot-baibot.md), you can now enable [built-in tools](https://github.com/etkecc/baibot/blob/61d18b2/docs/features.md#%EF%B8%8F-built-in-tools-openai-only) (`web_search` and `code_interpreter`) to extend the model's capabilities.
|
||||
|
||||
These tools are **disabled by default** and can be enabled via Ansible variables for static agent configurations:
|
||||
|
||||
```yaml
|
||||
matrix_bot_baibot_config_agents_static_definitions_openai_config_text_generation_tools_web_search: true
|
||||
matrix_bot_baibot_config_agents_static_definitions_openai_config_text_generation_tools_code_interpreter: true
|
||||
```
|
||||
|
||||
Users who define agents dynamically at runtime will need to [update their agents](https://github.com/etkecc/baibot/blob/61d18b2/docs/agents.md#updating-agents) to enable these tools. See the [baibot v1.14.0 changelog](https://github.com/etkecc/baibot/blob/61d18b2/CHANGELOG.md) for details.
|
||||
|
||||
## Whoami-based sync worker routing for improved sticky sessions for Synapse
|
||||
|
||||
Deployments using [Synapse workers](./docs/configuring-playbook-synapse.md#load-balancing-with-workers) now benefit from improved sync worker routing via a new whoami-based mechanism (making use of the [whoami Matrix Client-Server API](https://spec.matrix.org/v1.17/client-server-api/#get_matrixclientv3accountwhoami)).
|
||||
|
||||
Previously, sticky routing for sync workers relied on parsing usernames from access tokens, which only worked with native Synapse tokens (`syt_<base64 username>_...`). This approach failed for [Matrix Authentication Service](docs/configuring-playbook-matrix-authentication-service.md) (MAS) deployments, where tokens are opaque and don't contain username information. This resulted in device-level stickiness (same token → same worker) rather than user-level stickiness (same user → same worker regardless of device), leading to suboptimal cache utilization on sync workers.
|
||||
|
||||
The new implementation calls Synapse's `/whoami` endpoint to resolve access tokens to usernames, enabling proper user-level sticky routing regardless of the authentication system in use (native Synapse auth, MAS, etc.). Results are cached to minimize overhead.
|
||||
|
||||
This change:
|
||||
- **Automatically enables** when sync workers are configured (no action required)
|
||||
- **Works universally** with any authentication system
|
||||
- **Replaces the old implementation** entirely to keep the codebase simple
|
||||
- **Adds minimal overhead** (one cached internal subrequest per sync request) for non-MAS deployments
|
||||
|
||||
For debugging, you can enable verbose logging and/or response headers showing routing decisions:
|
||||
|
||||
```yaml
|
||||
# Logs cache hits/misses and routing decisions to the container's stderr
|
||||
matrix_synapse_reverse_proxy_companion_whoami_sync_worker_router_logging_enabled: true
|
||||
|
||||
# Adds X-Sync-Worker-Router-User-Identifier and X-Sync-Worker-Router-Upstream headers to sync responses
|
||||
matrix_synapse_reverse_proxy_companion_whoami_sync_worker_router_debug_headers_enabled: true
|
||||
```
|
||||
|
||||
|
||||
# 2025-12-09
|
||||
|
||||
## Traefik Cert Dumper upgrade
|
||||
|
||||
The variable `traefik_certs_dumper_ssl_dir_path` was renamed to `traefik_certs_dumper_ssl_path`. Users who use [their own webserver with Traefik](docs/configuring-playbook-own-webserver.md) may need to adjust their configuration.
|
||||
|
||||
The variable `traefik_certs_dumper_dumped_certificates_dir_path` was renamed to `traefik_certs_dumper_dumped_certificates_path`. Users who use [SRV Server Delegation](docs/howto-srv-server-delegation.md) may need to adjust their configuration.
|
||||
|
||||
# 2025-11-23
|
||||
|
||||
## Matrix.to support
|
||||
|
||||
The playbook now supports [Matrix.to](https://github.com/matrix-org/matrix.to) — a simple URL redirection service which powers [matrix.to](https://matrix.to).
|
||||
|
||||
To learn more, see our [Setting up Matrix.to](docs/configuring-playbook-matrixto.md) documentation page.
|
||||
|
||||
# 2025-11-09
|
||||
|
||||
## matrix-appservice-webhooks has been removed from the playbook
|
||||
|
||||
[matrix-appservice-webhooks](./docs/configuring-playbook-bridge-appservice-webhooks.md) has been removed from the playbook, as it has been deprecated since more than several years.
|
||||
|
||||
The playbook will let you know if you're using any `matrix_appservice_webhooks_*` variables. You'll need to remove them from `vars.yml` and potentially [uninstall the bridge manually](./docs/configuring-playbook-bridge-appservice-webhooks.md#uninstalling-the-bridge-manually).
|
||||
|
||||
## mautrix-facebook and mautrix-instagram have been removed from the playbook
|
||||
|
||||
[mautrix-facebook](./docs/configuring-playbook-bridge-mautrix-facebook.md) and [mautrix-instagram](./docs/configuring-playbook-bridge-mautrix-instagram.md) have been removed from the playbook, as they have been deprecated in favor of the [mautrix-meta](https://github.com/mautrix/meta) Messenger/Instagram bridge, integrated to the playbook at [2024-02-19](#2024-02-19).
|
||||
|
||||
The playbook will let you know if you're using any variables for those bridges:
|
||||
|
||||
- `matrix_mautrix_facebook_*`
|
||||
- `matrix_mautrix_instagram_*`
|
||||
|
||||
You'll need to remove them from `vars.yml` and potentially uninstall them manually. Consult pages below for details:
|
||||
|
||||
- [Instruction for mautrix-facebook](./docs/configuring-playbook-bridge-mautrix-facebook.md#uninstalling-the-bridge-manually)
|
||||
- [Instruction for mautrix-instagram](./docs/configuring-playbook-bridge-mautrix-instagram.md#uninstalling-the-bridge-manually)
|
||||
|
||||
# 2025-11-08
|
||||
|
||||
## MatrixZulipBridge support
|
||||
|
||||
Thanks to [Suguru Hirahara](https://github.com/luixxiul), the playbook now supports the [GearKite/MatrixZulipBridge](https://github.com/GearKite/MatrixZulipBridg) bridge for bridging Matrix to [Zulip](https://zulip.com/).
|
||||
|
||||
To learn more, see our [Setting up Zulip bridging](docs/configuring-playbook-bridge-zulip.md) documentation page.
|
||||
|
||||
# 2025-11-07
|
||||
|
||||
## The matrix-chatgpt-bot has been removed from the playbook
|
||||
|
||||
The [matrix-bot-chatgpt](./docs/configuring-playbook-bot-chatgpt.md) has been removed from the playbook, as it has been deprecated since September 2024.
|
||||
|
||||
The playbook will let you know if you're using any `matrix_bot_chatgpt_*` variables. You'll need to remove them from `vars.yml` and potentially [uninstall the bot manually](./docs/configuring-playbook-bot-chatgpt.md#uninstalling-matrix-chatgpt-bot-manually).
|
||||
|
||||
# 2025-11-05
|
||||
|
||||
## The MX Puppet bridges for Discord, Instagram, Slack, and Twitter have been removed from the playbook
|
||||
|
||||
The MX Puppet bridges for Discord, Instagram, Slack, and Twitter have been removed from the playbook, as they have been unmaintained for more than several years and do not support important features like authenticated media. See [this issue](https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/3867) for the context.
|
||||
|
||||
The playbook will let you know if you're using any variables for those bridges:
|
||||
|
||||
- `matrix_mx_puppet_discord_*`
|
||||
- `matrix_mx_puppet_instagram_*`
|
||||
- `matrix_mx_puppet_slack_*`
|
||||
- `matrix_mx_puppet_twitter_*`
|
||||
|
||||
You'll need to remove them from `vars.yml` and potentially uninstall them manually. Consult pages below for details:
|
||||
|
||||
- [Instruction for MX Puppet Discord bridge](./docs/configuring-playbook-bridge-mx-puppet-discord.md#uninstalling-the-bridge-manually)
|
||||
- [Instruction for MX Puppet Instagram bridge](./docs/configuring-playbook-bridge-mx-puppet-instagram.md#uninstalling-the-bridge-manually)
|
||||
- [Instruction for MX Puppet Slack bridge](./docs/configuring-playbook-bridge-mx-puppet-slack.md#uninstalling-the-bridge-manually)
|
||||
- [Instruction for MX Puppet Twitter bridge](./docs/configuring-playbook-bridge-mx-puppet-twitter.md#uninstalling-the-bridge-manually)
|
||||
|
||||
# 2025-11-04
|
||||
|
||||
## The Go Skype bridge has been removed from the playbook
|
||||
|
||||
The [go-skype-bridge](./docs/configuring-playbook-bridge-go-skype-bridge.md) has been removed from the playbook, as Skype has been discontinued since the May 2025.
|
||||
|
||||
The playbook will let you know if you're using any `matrix_go_skype_bridge_*` variables. You'll need to remove them from `vars.yml` and potentially [uninstall the bridge manually](./docs/configuring-playbook-bridge-go-skype-bridge.md#uninstalling-the-bridge-manually).
|
||||
|
||||
# 2025-10-02
|
||||
|
||||
## Element Admin support
|
||||
|
||||
The playbook now supports [Element Admin](./docs/configuring-playbook-element-admin.md) - a new web-based administration panel for Synapse and [Matrix Authentication Service](./docs/configuring-playbook-matrix-authentication-service.md).
|
||||
|
||||
Deployments based on Matrix Authentication Service may find it useful to run both Synapse Admin and Element Admin at the same time.
|
||||
|
||||
Deployments that don't rely on Matrix Authentication Service are unlikely to find anything useful in Element Admin right now (it's too basic in its current form).
|
||||
|
||||
|
||||
# 2025-04-26
|
||||
|
||||
## Continuwuity support
|
||||
|
||||
Thanks to [Virkkunen](https://github.com/Virkkunen), we now have optional experimental [Continuwuity](./docs/configuring-playbook-continuwuity.md) homeserver support.
|
||||
|
||||
Continuwuity is a fork of [conduwuit](./docs/configuring-playbook-conduwuit.md), which the playbook also supports. It appears that conduwuit has been abandoned and various forks (like Continuwuity, [Tuwunel](https://github.com/matrix-construct/tuwunel) and possibly others) are continuing in its path.
|
||||
|
||||
Existing installations do **not** need to be updated. **Synapse is still the default homeserver implementation** installed by the playbook.
|
||||
|
||||
People that used to run conduwuit, may wish to:
|
||||
|
||||
- either [migrate from conduwuit to Continuwuity](./docs/configuring-playbook-continuwuity.md#migrating-from-conduwuit)
|
||||
- or wait for some of the other forks to progress and for support for them to get added to the playbook
|
||||
|
||||
**The homeserver implementation of an existing server cannot be changed** (e.g. from Synapse/Conduit/Dendrite to Continuwuity) without data loss.
|
||||
|
||||
|
||||
# 2025-04-09
|
||||
|
||||
## Element Call frontend installation is now optional
|
||||
@@ -436,7 +82,7 @@ In light of this new information, you have 2 options:
|
||||
- Consider closing the STUN/UDP port with the following configuration:
|
||||
|
||||
```yaml
|
||||
coturn_container_stun_plain_host_bind_port_udp: ""
|
||||
matrix_coturn_container_stun_plain_host_bind_port_udp: ""
|
||||
```
|
||||
|
||||
- Consider keeping `3478/udp` blocked in your external firewall (if you have one)
|
||||
@@ -492,21 +138,21 @@ To **completely eliminate the problem** of DDoS amplification attacks done throu
|
||||
|
||||
The playbook now **only exposes the Coturn STUN port (`3478`) over TCP by default**.
|
||||
|
||||
💡 Users may wish to further remove the (now unnecessary) firewall rule allowing access to `3478/udp`.
|
||||
💡 Users may wish to further remove the (now unnnecessary) firewall rule allowing access to `3478/udp`.
|
||||
|
||||
If you'd like the Coturn STUN port to be exposed over UDP like before, you can revert to the previous behavior by using the following configuration in your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
coturn_container_stun_plain_host_bind_port_udp: "3478"
|
||||
matrix_coturn_container_stun_plain_host_bind_port_udp: "3478"
|
||||
```
|
||||
|
||||
> [!WARNING]
|
||||
> People running Coturn directly on the `host` network (using `coturn_container_network: host`) will still have the STUN port exposed over UDP, as port exposure is done directly via Coturn and not via Docker. In such cases, the playbook cannot prevent `3478/udp` port exposure and you'd need to do it in another way (separate firewall rule, etc).
|
||||
> People running Coturn directly on the `host` network (using `matrix_coturn_container_network: host`) will still have the STUN port exposed over UDP, as port exposure is done directly via Coturn and not via Docker. In such cases, the playbook cannot prevent `3478/udp` port exposure and you'd need to do it in another way (separate firewall rule, etc).
|
||||
|
||||
|
||||
# 2025-02-17
|
||||
|
||||
## FluffyChat Web support
|
||||
## FluffyChat Web suport
|
||||
|
||||
Thanks to [Aine](https://gitlab.com/etke.cc) of [etke.cc](https://etke.cc/), the playbook now supports [FluffyChat Web](https://github.com/krille-chan/fluffychat) as an additional Matrix client you can self-host.
|
||||
|
||||
@@ -528,7 +174,7 @@ The playbook will let you know if you're using any `matrix_mautrix_hangouts_*` v
|
||||
|
||||
## Redis and KeyDB are no longer part of the playbook
|
||||
|
||||
**TLDR**: The playbook now exclusively uses Valkey as its Redis-compatible memorystore implementation, removing support for Redis and KeyDB. Most users are unaffected by this change unless they explicitly configured Redis or KeyDB variables. Only users that were explicitly defining `redis_*` or `keydb_*` variables will need to update their configuration to use `valkey_*` variables instead.
|
||||
**TLDR**: The playbook now exclusively uses Valkey as its Redis-compatible memorystore implementation, removing support for Redis and KeyDB. Most users are unaffected by this change unless they explicitly configured Redis or KeyDB variables. Only users that were explicitly definining `redis_*` or `keydb_*` variables will need to update their configuration to use `valkey_*` variables instead.
|
||||
|
||||
The playbook has gone through several iterations of memorystore implementations:
|
||||
|
||||
@@ -754,8 +400,8 @@ If upstream synapse-admin picks up the pace and improves, the etke.cc fork may d
|
||||
If you'd like to switch back to the original synapse-admin software, you can do so by adding the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_synapse_admin_container_image: "{{ matrix_synapse_admin_container_image_registry_prefix }}awesometechnologies/synapse-admin:{{ matrix_synapse_admin_version }}"
|
||||
matrix_synapse_admin_container_image_registry_prefix_upstream: docker.io/
|
||||
matrix_synapse_admin_docker_image: "{{ matrix_synapse_admin_docker_image_registry_prefix }}awesometechnologies/synapse-admin:{{ matrix_synapse_admin_version }}"
|
||||
matrix_synapse_admin_docker_image_registry_prefix_upstream: docker.io/
|
||||
|
||||
matrix_synapse_admin_version: 0.10.3
|
||||
|
||||
@@ -1081,7 +727,7 @@ For people building commercial products on top of Synapse, they may have to eith
|
||||
|
||||
We're no lawyers and this changelog entry does not aim to give you the best legal advice, so please research on your own!
|
||||
|
||||
If you'd like to continue using the old Apache-2.0-licensed Synapse (for a while longer anyway), the playbook makes it possible by introducing a new Ansible variable. You can do it like this:
|
||||
If you'd like to continue using the old Apache-2.0-licensed Synapse (for a while longer anyway), the playbook makes it possible by intruducing a new Ansible variable. You can do it like this:
|
||||
|
||||
```yaml
|
||||
# Switch the organization that Synapse container images (or source code for self-building) are pulled from.
|
||||
@@ -1164,7 +810,7 @@ Despite these downsides (which the playbook manages automatically), we believe i
|
||||
|
||||
People running the default Traefik setup do not need to do anything to make Traefik take on this extra job. Your Traefik configuration will be updated automatically.
|
||||
|
||||
**People running their own Traefik reverse-proxy need to do [minor adjustments](#people-managing-their-own-traefik-instance-need-to-do-minor-changes)**, as described in the section below.
|
||||
**People runnning their own Traefik reverse-proxy need to do [minor adjustments](#people-managing-their-own-traefik-instance-need-to-do-minor-changes)**, as described in the section below.
|
||||
|
||||
You may disable Traefik acting as an intermediary by explicitly setting `matrix_playbook_public_matrix_federation_api_traefik_entrypoint_enabled` to `false`. Services would then be configured to talk to the homeserver directly, giving you a slight performance boost and a "simpler" Traefik setup. However, such a configuration is less tested and will cause troubles, especially if you enable more services (like `matrix-media-repo`, etc.) in the future. As such, it's not recommended.
|
||||
|
||||
@@ -1844,12 +1490,12 @@ Other roles which aren't strictly related to Matrix are likely to follow this fa
|
||||
|
||||
## coturn can now use host-networking
|
||||
|
||||
Large coturn deployments (with a huge range of ports specified via `coturn_turn_udp_min_port` and `coturn_turn_udp_max_port`) experience a huge slowdown with how Docker publishes all these ports (setting up firewall forwarding rules), which leads to a very slow coturn service startup and shutdown.
|
||||
Large coturn deployments (with a huge range of ports specified via `matrix_coturn_turn_udp_min_port` and `matrix_coturn_turn_udp_max_port`) experience a huge slowdown with how Docker publishes all these ports (setting up firewall forwarding rules), which leads to a very slow coturn service startup and shutdown.
|
||||
|
||||
Such deployments don't need to run coturn within a private container network anymore. coturn can now run with host-networking by using configuration like this:
|
||||
|
||||
```yaml
|
||||
coturn_container_network: host
|
||||
matrix_coturn_container_network: host
|
||||
```
|
||||
|
||||
With such a configuration, **Docker no longer needs to configure thousands of firewall forwarding rules** each time coturn starts and stops. This, however, means that **you will need to ensure these ports are open** in your firewall yourself.
|
||||
@@ -1858,11 +1504,11 @@ Thanks to us [tightening coturn security](#backward-compatibility-tightening-cot
|
||||
|
||||
## (Backward Compatibility) Tightening coturn security can lead to connectivity issues
|
||||
|
||||
**TLDR**: users who run and access their Matrix server on a private network (likely a small minority of users) may experience connectivity issues with our new default coturn blocklists. They may need to override `coturn_denied_peer_ips` and remove some IP ranges from it.
|
||||
**TLDR**: users who run and access their Matrix server on a private network (likely a small minority of users) may experience connectivity issues with our new default coturn blocklists. They may need to override `matrix_coturn_denied_peer_ips` and remove some IP ranges from it.
|
||||
|
||||
Inspired by [this security article](https://www.rtcsec.com/article/cve-2020-26262-bypass-of-coturns-access-control-protection/), we've decided to make use of coturn's `denied-peer-ip` functionality to prevent relaying network traffic to certain private IP subnets. This ensures that your coturn server won't accidentally try to forward traffic to certain services running on your local networks. We run coturn in a container and in a private container network by default, which should prevent such access anyway, but having additional block layers in place is better.
|
||||
|
||||
If you access your Matrix server from a local network and need coturn to relay to private IP addresses, you may observe that relaying is now blocked due to our new default `denied-peer-ip` lists (specified in `coturn_denied_peer_ips`). If you experience such connectivity problems, consider overriding this setting in your `vars.yml` file and removing certain networks from it.
|
||||
If you access your Matrix server from a local network and need coturn to relay to private IP addresses, you may observe that relaying is now blocked due to our new default `denied-peer-ip` lists (specified in `matrix_coturn_denied_peer_ips`). If you experience such connectivity problems, consider overriding this setting in your `vars.yml` file and removing certain networks from it.
|
||||
|
||||
We've also added `no-multicast-peers` to the default coturn configuration, but we don't expect this to cause trouble for most people.
|
||||
|
||||
@@ -2648,8 +2294,8 @@ To improve security, we've [removed TLSv1 and TLSv1.1 support](https://github.co
|
||||
If you need to support old clients, you can re-enable both (or whichever one you need) with the following configuration:
|
||||
|
||||
```yaml
|
||||
coturn_tls_v1_enabled: true
|
||||
coturn_tls_v1_1_enabled: true
|
||||
matrix_coturn_tls_v1_enabled: true
|
||||
matrix_coturn_tls_v1_1_enabled: true
|
||||
```
|
||||
|
||||
|
||||
@@ -3150,7 +2796,7 @@ See our [Migrating to Element Web](docs/configuring-playbook-riot-web.md#migrati
|
||||
|
||||
## Steam bridging support via mx-puppet-steam
|
||||
|
||||
Thanks to [Hugues Morisset](https://github.com/izissise)'s efforts, the playbook now supports bridging to [Steam](https://steamapp.com/) via the [mx-puppet-steam](https://codeberg.org/icewind/mx-puppet-steam) bridge. See our [Setting up MX Puppet Steam bridging](docs/configuring-playbook-bridge-mx-puppet-steam.md) documentation page for getting started.
|
||||
Thanks to [Hugues Morisset](https://github.com/izissise)'s efforts, the playbook now supports bridging to [Steam](https://steamapp.com/) via the [mx-puppet-steam](https://github.com/icewind1991/mx-puppet-steam) bridge. See our [Setting up MX Puppet Steam bridging](docs/configuring-playbook-bridge-mx-puppet-steam.md) documentation page for getting started.
|
||||
|
||||
|
||||
# 2020-07-01
|
||||
@@ -3187,7 +2833,7 @@ As always, re-running the playbook is enough to get the updated bits.
|
||||
|
||||
## SMS bridging requires db reset
|
||||
|
||||
The current version of [matrix-sms-bridge](https://github.com/benkuly/matrix-sms-bridge) needs you to delete the database to work as expected. Just remove `/matrix/matrix-sms-bridge/database/*`. It also adds a new required var `matrix_sms_bridge_default_region`.
|
||||
The current version of [matrix-sms-bridge](https://github.com/benkuly/matrix-sms-bridge) needs you to delete the database to work as expected. Just remove `/matrix/matrix-sms-bridge/database/*`. It also adds a new requried var `matrix_sms_bridge_default_region`.
|
||||
|
||||
To reuse your existing rooms, invite `@smsbot:yourServer` to the room or write a message. You are also able to use automated room creation with telephonenumers by writing `sms send -t 01749292923 "Hello World"` in a room with `@smsbot:yourServer`. See [the docs](https://github.com/benkuly/matrix-sms-bridge) for more information.
|
||||
|
||||
@@ -3219,7 +2865,7 @@ Until the issue gets fixed, we're making User Directory search not go to ma1sd b
|
||||
|
||||
This upgrades matrix-appservice-irc from 0.14.1 to 0.16.0. Upstream
|
||||
made a change to how you define manual mappings. If you added a
|
||||
`mapping` to your configuration, you will need to update it according
|
||||
`mapping` to your configuration, you will need to update it accoring
|
||||
to the [upstream
|
||||
instructions](https://github.com/matrix-org/matrix-appservice-irc/blob/master/CHANGELOG.md#0150-2020-02-05). If you did not include `mappings` in your configuration for IRC, no
|
||||
change is necessary. `mappings` is not part of the default
|
||||
@@ -3382,7 +3028,7 @@ As per this [advisory blog post](https://matrix.org/blog/2019/11/09/avoiding-unw
|
||||
|
||||
Our general goal is to favor privacy and security when running personal (family & friends) and corporate homeservers. Both of these likely benefit from having a more secure default of **not showing the room directory without authentication** and **not publishing the room directory over federation**.
|
||||
|
||||
As with anything else, these new defaults can be overridden by changing the `matrix_synapse_allow_public_rooms_without_auth` and `matrix_synapse_allow_public_rooms_over_federation` variables, respectively.
|
||||
As with anything else, these new defaults can be overriden by changing the `matrix_synapse_allow_public_rooms_without_auth` and `matrix_synapse_allow_public_rooms_over_federation` variables, respectively.
|
||||
|
||||
|
||||
# 2019-10-05
|
||||
@@ -3928,7 +3574,7 @@ Because people like using the playbook's components independently (outside of th
|
||||
With the new changes, **all roles are now only dependent on the minimal `matrix-base` role**. They are no longer dependent among themselves.
|
||||
|
||||
In addition, the following components can now be completely disabled (for those who want/need to):
|
||||
- `matrix-coturn` by using `coturn_enabled: false`
|
||||
- `matrix-coturn` by using `matrix_coturn_enabled: false`
|
||||
- `matrix-mailer` by using `matrix_mailer_enabled: false`
|
||||
- `matrix-postgres` by using `matrix_postgres_enabled: false`
|
||||
|
||||
@@ -3936,7 +3582,7 @@ The following changes had to be done:
|
||||
|
||||
- glue variables had to be introduced to the playbook, so it can wire together the various components. Those glue vars are stored in the [`group_vars/matrix-servers`](group_vars/matrix-servers) file. When overriding variables for a given component (role), you need to be aware of both the role defaults (`role/ROLE/defaults/main.yml`) and the role's corresponding section in the [`group_vars/matrix-servers`](group_vars/matrix-servers) file.
|
||||
|
||||
- `matrix_postgres_use_external` has been superseded by the more consistently named `matrix_postgres_enabled` variable and a few other `matrix_synapse_database_` variables. See the [Using an external PostgreSQL server (optional)](docs/configuring-playbook-external-postgres.md) documentation page for an up-to-date replacement.
|
||||
- `matrix_postgres_use_external` has been superceeded by the more consistently named `matrix_postgres_enabled` variable and a few other `matrix_synapse_database_` variables. See the [Using an external PostgreSQL server (optional)](docs/configuring-playbook-external-postgres.md) documentation page for an up-to-date replacement.
|
||||
|
||||
- Postgres tools (`matrix-postgres-cli` and `matrix-make-user-admin`) are no longer installed if you're not enabling the `matrix-postgres` role (`matrix_postgres_enabled: false`)
|
||||
|
||||
@@ -4125,7 +3771,7 @@ matrix_riot_web_integrations_jitsi_widget_url: "https://dimension.t2bot.io/widge
|
||||
|
||||
There's now a new `matrix_nginx_proxy_ssl_protocols` playbook variable, which controls the SSL protocols used to serve Riot and Synapse. Its default value is `TLSv1.1 TLSv1.2`. This playbook previously used `TLSv1 TLSv1.1 TLSv1.2` to serve Riot and Synapse.
|
||||
|
||||
You may wish to re-enable TLSv1 if you need to access Riot in older browsers.
|
||||
You may wish to reenable TLSv1 if you need to access Riot in older browsers.
|
||||
|
||||
Note: Currently the dockerized nginx doesn't support TLSv1.3. See https://github.com/nginxinc/docker-nginx/issues/190 for more details.
|
||||
|
||||
@@ -4148,7 +3794,7 @@ The following playbook variables were renamed:
|
||||
- from `matrix_docker_image_mautrix_telegram` to `matrix_mautrix_telegram_docker_image`
|
||||
- from `matrix_docker_image_mautrix_whatsapp` to `matrix_mautrix_whatsapp_docker_image`
|
||||
- from `matrix_docker_image_mailer` to `matrix_mailer_docker_image`
|
||||
- from `matrix_docker_image_coturn` to `coturn_container_image`
|
||||
- from `matrix_docker_image_coturn` to `matrix_coturn_docker_image`
|
||||
- from `matrix_docker_image_goofys` to `matrix_s3_goofys_docker_image`
|
||||
- from `matrix_docker_image_riot` to `matrix_riot_web_docker_image`
|
||||
- from `matrix_docker_image_nginx` to `matrix_nginx_proxy_docker_image`
|
||||
|
||||
19
README.md
19
README.md
@@ -1,4 +1,4 @@
|
||||
[](https://matrix.to/#/#matrix-docker-ansible-deploy:devture.com) [](https://liberapay.com/s.pantaleev/donate) [](https://api.reuse.software/info/github.com/spantaleev/matrix-docker-ansible-deploy)
|
||||
[](https://matrix.to/#/#matrix-docker-ansible-deploy:devture.com) [](https://liberapay.com/s.pantaleev/donate) [](https://api.reuse.software/info/github.com/spantaleev/matrix-docker-ansible-deploy)
|
||||
|
||||
# Matrix (An open network for secure, decentralized communication) server setup using Ansible and Docker
|
||||
|
||||
@@ -52,7 +52,7 @@ The homeserver is the backbone of your Matrix system. Choose one from the follow
|
||||
| ---- | -------- | ----------- | ------------- |
|
||||
| [Synapse](https://github.com/element-hq/synapse) | ✅ | Storing your data and managing your presence in the [Matrix](http://matrix.org/) network | [Link](docs/configuring-playbook-synapse.md) |
|
||||
| [Conduit](https://conduit.rs) | ❌ | Storing your data and managing your presence in the [Matrix](http://matrix.org/) network. Conduit is a lightweight open-source server implementation of the Matrix Specification with a focus on easy setup and low system requirements | [Link](docs/configuring-playbook-conduit.md) |
|
||||
| [continuwuity](https://continuwuity.org) | ❌ | Storing your data and managing your presence in the [Matrix](http://matrix.org/) network. | [Link](docs/configuring-playbook-continuwuity.md) |
|
||||
| [conduwuit](https://conduwuit.puppyirl.gay/) | ❌ | Storing your data and managing your presence in the [Matrix](http://matrix.org/) network. conduwuit is a fork of Conduit. | [Link](docs/configuring-playbook-conduwuit.md) |
|
||||
| [Dendrite](https://github.com/element-hq/dendrite) | ❌ | Storing your data and managing your presence in the [Matrix](http://matrix.org/) network. Dendrite is a second-generation Matrix homeserver written in Go, an alternative to Synapse. | [Link](docs/configuring-playbook-dendrite.md) |
|
||||
|
||||
### Clients
|
||||
@@ -74,10 +74,11 @@ Services that run on the server to make the various parts of your installation w
|
||||
| Name | Default? | Description | Documentation |
|
||||
| ---- | -------- | ----------- | ------------- |
|
||||
| [PostgreSQL](https://www.postgresql.org/)| ✅ | Database for Synapse. [Using an external PostgreSQL server](docs/configuring-playbook-external-postgres.md) is also possible. | [Link](docs/configuring-playbook-external-postgres.md) |
|
||||
| [coturn](https://github.com/coturn/coturn) | ❌ | STUN/TURN server for WebRTC audio/video calls | [Link](docs/configuring-playbook-turn.md) |
|
||||
| [coturn](https://github.com/coturn/coturn) | ✅ | STUN/TURN server for WebRTC audio/video calls | [Link](docs/configuring-playbook-turn.md) |
|
||||
| [Traefik](https://doc.traefik.io/traefik/) | ✅ | Web server, listening on ports 80, 443 and 8448 - standing in front of all the other services. [Using your own webserver](docs/configuring-playbook-own-webserver.md) is also possible. | [Link](docs/configuring-playbook-traefik.md) |
|
||||
| [Let's Encrypt](https://letsencrypt.org/) | ✅ | Free SSL certificate, which secures the connection to all components | [Link](docs/configuring-playbook-ssl-certificates.md) |
|
||||
| [Exim](https://www.exim.org/) | ✅ | Mail server, through which all Matrix services send outgoing email (can be configured to relay through another SMTP server) | [Link](docs/configuring-playbook-email.md) |
|
||||
| [ma1sd](https://github.com/ma1uta/ma1sd) | ❌ | Matrix Identity Server | [Link](docs/configuring-playbook-ma1sd.md)
|
||||
| [ddclient](https://github.com/linuxserver/docker-ddclient) | ❌ | Dynamic DNS | [Link](docs/configuring-playbook-dynamic-dns.md) |
|
||||
| [LiveKit Server](https://github.com/livekit/livekit) | ❌ | WebRTC server for audio/video calls | [Link](docs/configuring-playbook-livekit-server.md) |
|
||||
| [Livekit JWT Service](https://github.com/livekit/livekit-jwt-service) | ❌ | JWT service for integrating [Element Call](./configuring-playbook-element-call.md) with [LiveKit Server](./configuring-playbook-livekit-server.md) | [Link](docs/configuring-playbook-livekit-jwt-service.md) |
|
||||
@@ -127,13 +128,18 @@ Bridges can be used to connect your Matrix installation with third-party communi
|
||||
| [matrix-appservice-irc](https://github.com/matrix-org/matrix-appservice-irc) | ❌ | Bridge to [IRC](https://wikipedia.org/wiki/Internet_Relay_Chat) | [Link](docs/configuring-playbook-bridge-appservice-irc.md) |
|
||||
| [matrix-appservice-kakaotalk](https://src.miscworks.net/fair/matrix-appservice-kakaotalk) | ❌ | Bridge to [Kakaotalk](https://www.kakaocorp.com/page/service/service/KakaoTalk?lang=ENG) | [Link](docs/configuring-playbook-bridge-appservice-kakaotalk.md) |
|
||||
| [matrix-appservice-discord](https://github.com/matrix-org/matrix-appservice-discord) | ❌ | Bridge to [Discord](https://discordapp.com/) | [Link](docs/configuring-playbook-bridge-appservice-discord.md) |
|
||||
| [matrix-appservice-slack](https://github.com/matrix-org/matrix-appservice-slack) | ❌ | Bridge to [Slack](https://slack.com/) | [Link](docs/configuring-playbook-bridge-appservice-slack.md) |
|
||||
| [matrix-hookshot](https://github.com/matrix-org/matrix-hookshot) | ❌ | Bridge for generic webhooks and multiple project management services, such as GitHub, GitLab, Figma, and Jira in particular | [Link](docs/configuring-playbook-bridge-hookshot.md) |
|
||||
| [matrix-sms-bridge](https://github.com/benkuly/matrix-sms-bridge) | ❌ | Bridge to SMS | [Link](docs/configuring-playbook-bridge-matrix-bridge-sms.md) |
|
||||
| [matrix-steam-bridge](https://github.com/jasonlaguidice/matrix-steam-bridge) | ❌ | Bridge to [Steam](https://steampowered.com/) | [Link](docs/configuring-playbook-bridge-steam.md) |
|
||||
| [matrix-wechat](https://github.com/duo/matrix-wechat) | ❌ | Bridge to [WeChat](https://www.wechat.com/) | [Link](docs/configuring-playbook-bridge-wechat.md) |
|
||||
| [Heisenbridge](https://github.com/hifi/heisenbridge) | ❌ | Bouncer-style bridge to [IRC](https://wikipedia.org/wiki/Internet_Relay_Chat) | [Link](docs/configuring-playbook-bridge-heisenbridge.md) |
|
||||
| [go-skype-bridge](https://github.com/kelaresg/go-skype-bridge) | ❌ | Bridge to [Skype](https://www.skype.com) | [Link](docs/configuring-playbook-bridge-go-skype-bridge.md) |
|
||||
| [mx-puppet-slack](https://gitlab.com/mx-puppet/slack/mx-puppet-slack) | ❌ | Bridge to [Slack](https://slack.com) | [Link](docs/configuring-playbook-bridge-mx-puppet-slack.md) |
|
||||
| [mx-puppet-instagram](https://github.com/Sorunome/mx-puppet-instagram) | ❌ | Bridge for Instagram-DMs ([Instagram](https://www.instagram.com/)) | [Link](docs/configuring-playbook-bridge-mx-puppet-instagram.md) |
|
||||
| [mx-puppet-twitter](https://github.com/Sorunome/mx-puppet-twitter) | ❌ | Bridge for Twitter-DMs ([Twitter](https://twitter.com/)) | [Link](docs/configuring-playbook-bridge-mx-puppet-twitter.md) |
|
||||
| [mx-puppet-discord](https://gitlab.com/mx-puppet/discord/mx-puppet-discord) | ❌ | Bridge to [Discord](https://discordapp.com/) | [Link](docs/configuring-playbook-bridge-mx-puppet-discord.md) |
|
||||
| [mx-puppet-groupme](https://gitlab.com/xangelix-pub/matrix/mx-puppet-groupme) | ❌ | Bridge to [GroupMe](https://groupme.com/) | [Link](docs/configuring-playbook-bridge-mx-puppet-groupme.md) |
|
||||
| [mx-puppet-steam](https://codeberg.org/icewind/mx-puppet-steam) | ❌ | Bridge to [Steam](https://steamapp.com/) | [Link](docs/configuring-playbook-bridge-mx-puppet-steam.md) |
|
||||
| [mx-puppet-steam](https://github.com/icewind1991/mx-puppet-steam) | ❌ | Bridge to [Steam](https://steamapp.com/) | [Link](docs/configuring-playbook-bridge-mx-puppet-steam.md) |
|
||||
| [Postmoogle](https://github.com/etkecc/postmoogle) | ❌ | Email to Matrix bridge | [Link](docs/configuring-playbook-bridge-postmoogle.md) |
|
||||
|
||||
### Bots
|
||||
@@ -171,9 +177,10 @@ Various services that don't fit any other categories.
|
||||
|
||||
| Name | Default? | Description | Documentation |
|
||||
| ---- | -------- | ----------- | ------------- |
|
||||
| [sliding-sync](https://github.com/matrix-org/sliding-sync)| ❌ | (Superseded by Simplified Sliding Sync integrated into Synapse > `1.114` and Conduit > `0.6.0`) Sliding Sync support for clients which require it (e.g. old Element X versions before Simplified Sliding Sync was developed) | [Link](docs/configuring-playbook-sliding-sync-proxy.md) |
|
||||
| [synapse_auto_accept_invite](https://github.com/matrix-org/synapse-auto-accept-invite) | ❌ | Synapse module to automatically accept invites | [Link](docs/configuring-playbook-synapse-auto-accept-invite.md) |
|
||||
| [synapse_auto_compressor](https://github.com/matrix-org/rust-synapse-compress-state/#automated-tool-synapse_auto_compressor) | ❌ | Cli tool that automatically compresses `state_groups` database table in background | [Link](docs/configuring-playbook-synapse-auto-compressor.md) |
|
||||
| [Matrix Corporal](https://github.com/devture/matrix-corporal) (advanced) | ❌ | Reconciliator and gateway for a managed Matrix server | [Link](docs/configuring-playbook-matrix-corporal.md) |
|
||||
| [Matrix.to](https://github.com/matrix-org/matrix.to) | ❌ | Simple URL redirection service for the Matrix ecosystem | [Link](docs/configuring-playbook-matrixto.md) |
|
||||
| [Etherpad](https://etherpad.org) | ❌ | Open source collaborative text editor | [Link](docs/configuring-playbook-etherpad.md) |
|
||||
| [Jitsi](https://jitsi.org/) | ❌ | Open source video-conferencing platform | [Link](docs/configuring-playbook-jitsi.md) |
|
||||
| [Cactus Comments](https://cactus.chat) | ❌ | Federated comment system built on Matrix | [Link](docs/configuring-playbook-cactus-comments.md) |
|
||||
|
||||
@@ -13,12 +13,10 @@ path = [
|
||||
"i18n/PUBLISHED_LANGUAGES",
|
||||
"i18n/requirements.txt",
|
||||
"roles/custom/**/*.repo",
|
||||
".codespellrc",
|
||||
".editorconfig",
|
||||
".envrc",
|
||||
".gitattributes",
|
||||
".gitignore",
|
||||
".pre-commit-config.yaml",
|
||||
".yamllint",
|
||||
"ansible.cfg",
|
||||
"flake.lock",
|
||||
|
||||
@@ -11,7 +11,7 @@ SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
|
||||
2023 is probably [the year of AI](https://journal.everypixel.com/2023-the-year-of-ai), with millions of people jumping aboard [OpenAI](https://openai.com/)'s [ChatGPT](https://openai.com/chatgpt) train. matrix-docker-ansible-deploy is no stranger to this and 2023 began with a PR from [bertybuttface](https://github.com/bertybuttface) who added support for [matrix-chatgpt-bot](https://github.com/matrixgpt/matrix-chatgpt-bot) (see the [changelog entry](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#chatgpt-support)). While OpenAI's chat GPT website was frequently overloaded in the past, their API was up which made using this bot both convenient and more reliable.
|
||||
|
||||
AI aside, with the playbook's focus being containers, we're **doubling down on being "container native"** and becoming more interoperable for people hosting other containers on the Matrix server. In [2022](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/YEAR-IN-REVIEW.md#2022), we've announced a few sibling Ansible playbooks, their use of [Traefik](https://doc.traefik.io/traefik/) and the possibility of matrix-docker-ansible-deploy also switching to this reverse-proxy. This prediction materialized quickly. The **largest change** in the playbook in 2023 happened way back in February - matrix-docker-ansible-deploy [starting the switch from nginx to Traefik](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#backward-compatibility-reverse-proxy-configuration-changes-and-initial-traefik-support) and then quickly [making Treafik the default reverse-proxy](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#traefik-is-the-default-reverse-proxy-now). As noted in the changelog entries, we envisioned a quick and complete elimination of `matrix-nginx-proxy`, but at the end of 2023, it hasn't happened yet. The playbook is already using Traefik as the front-most reverse-proxy, but nginx (via `matrix-nginx-proxy`) is still around - it has taken a step back and is only used internally for new setups. Work got to a stall due to:
|
||||
AI aside, with the playbook's focus being containers, we're **doubling down on being "container native"** and becoming more interoperable for people hosting other containers on the Matrix server. In [2022](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/YEAR-IN-REVIEW.md#2022), we've announced a few sibling Ansible playbooks, their use of [Traefik](https://doc.traefik.io/traefik/) and the possiblity of matrix-docker-ansible-deploy also switching to this reverse-proxy. This prediction materialized quickly. The **largest change** in the playbook in 2023 happened way back in February - matrix-docker-ansible-deploy [starting the switch from nginx to Traefik](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#backward-compatibility-reverse-proxy-configuration-changes-and-initial-traefik-support) and then quickly [making Treafik the default reverse-proxy](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#traefik-is-the-default-reverse-proxy-now). As noted in the changelog entries, we envisioned a quick and complete elimination of `matrix-nginx-proxy`, but at the end of 2023, it hasn't happened yet. The playbook is already using Traefik as the front-most reverse-proxy, but nginx (via `matrix-nginx-proxy`) is still around - it has taken a step back and is only used internally for new setups. Work got to a stall due to:
|
||||
|
||||
* complexity: untangling the overly large and messy `matrix-nginx-proxy` component is difficult
|
||||
* the current setup became "good enough" because nginx has become an internal implementation detail for those who have migrated to Traefik. Traefik is already the default public reverse-proxy and gives better possibilities to people wishing to run other web-exposed containers on their Matrix server via [Docker Compose](https://docs.docker.com/compose/), other Ansible playbooks like [mash-playbook](https://github.com/mother-of-all-self-hosting/mash-playbook) (more about this one, below) or any other way.
|
||||
|
||||
@@ -9,7 +9,7 @@ SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
|
||||
# Table of Contents
|
||||
|
||||
## ⬇️ Installation guides <!-- NOTE: the 🚀 emoji is used by "Getting started" on README.md -->
|
||||
## ⬇️ Installaton guides <!-- NOTE: the 🚀 emoji is used by "Getting started" on README.md -->
|
||||
|
||||
There are two installation guides available for beginners and advanced users.
|
||||
|
||||
|
||||
@@ -20,13 +20,10 @@ To manually check which version of Ansible you're on, run: `ansible --version`.
|
||||
|
||||
For the **best experience**, we recommend getting the **latest version of Ansible available**.
|
||||
|
||||
We're not sure what's the minimum version of Ansible that can run this playbook successfully. The lowest version that we suspect (on 2025-09-03) to be working fine is: `ansible-core` (`2.15.1`).
|
||||
We're not sure what's the minimum version of Ansible that can run this playbook successfully. The lowest version that we've confirmed (on 2022-11-26) to be working fine is: `ansible-core` (`2.11.7`) combined with `ansible` (`4.10.0`).
|
||||
|
||||
If your distro ships with an Ansible version older than this, you may run into issues. Consider [Upgrading Ansible](#upgrading-ansible) or [using Ansible via Docker](#using-ansible-via-docker).
|
||||
|
||||
> [!WARNING]
|
||||
> One reason for the version requirement being as such is that the playbook by default installs Docker for you using [this Docker role](https://github.com/geerlingguy/ansible-role-docker) which [has a hard requirement on Ansible v2.15.1](https://github.com/geerlingguy/ansible-role-docker/commit/7f44a1d9ad8132819ea9852918bca5dab8757cd0). If you install Docker yourself another way, you can tell the playbook to skip running this role (by adding `matrix_playbook_docker_installation_enabled: false` to your `vars.yml` configuration). It may then be possible to get the playbook running on an older version of Ansible. Still, this is a complication and your mileage may vary. We recommend [upgrading Ansible](#upgrading-ansible) instead of going into uncharted territory.
|
||||
|
||||
## Upgrading Ansible
|
||||
|
||||
Depending on your distribution, you may be able to upgrade Ansible in a few different ways:
|
||||
@@ -74,7 +71,7 @@ docker run \
|
||||
-w /work \
|
||||
--mount type=bind,src=`pwd`,dst=/work \
|
||||
--entrypoint=/bin/sh \
|
||||
ghcr.io/devture/ansible:11.6.0-r0-0
|
||||
ghcr.io/devture/ansible:11.1.0-r0-0
|
||||
```
|
||||
|
||||
Once you execute the above command, you'll be dropped into a `/work` directory inside a Docker container. The `/work` directory contains the playbook's code.
|
||||
@@ -93,9 +90,9 @@ docker run \
|
||||
--rm \
|
||||
-w /work \
|
||||
--mount type=bind,src=`pwd`,dst=/work \
|
||||
--mount type=bind,src=$HOME/.ssh/id_ed25519,dst=/root/.ssh/id_ed25519,ro \
|
||||
--mount type=bind,src$HOME/.ssh/id_ed25519,dst=/root/.ssh/id_ed25519,ro \
|
||||
--entrypoint=/bin/sh \
|
||||
ghcr.io/devture/ansible:11.6.0-r0-0
|
||||
ghcr.io/devture/ansible:11.1.0-r0-0
|
||||
```
|
||||
|
||||
The above command tries to mount an SSH key (`$HOME/.ssh/id_ed25519`) into the container (at `/root/.ssh/id_ed25519`). If your SSH key is at a different path (not in `$HOME/.ssh/id_ed25519`), adjust that part.
|
||||
@@ -120,7 +117,7 @@ Then, to be asked for the password whenever running an `ansible-playbook` comman
|
||||
|
||||
#### Resolve directory ownership issues
|
||||
|
||||
Because you're `root` in the container running Ansible and this likely differs from the owner (your regular user account) of the playbook directory outside of the container, certain playbook features which use `git` locally may report warnings such as:
|
||||
Because you're `root` in the container running Ansible and this likely differs fom the owner (your regular user account) of the playbook directory outside of the container, certain playbook features which use `git` locally may report warnings such as:
|
||||
|
||||
> fatal: unsafe repository ('/work' is owned by someone else)
|
||||
> To add an exception for this directory, call:
|
||||
|
||||
@@ -95,13 +95,13 @@ ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
|
||||
|
||||
## Usage
|
||||
|
||||
If you made it through all the steps above and your main control room was joined by a user called `@draupnir-main:example.com` you have successfully installed Draupnir for All and can now start using it.
|
||||
If you made it through all the steps above and your main control room was joined by a user called `@draupnir-main:example.com` you have succesfully installed Draupnir for All and can now start using it.
|
||||
|
||||
The installation of Draupnir for all in this playbook is very much Alpha quality. Usage-wise, Draupnir for all is almost identical to Draupnir bot mode.
|
||||
|
||||
### Granting Users the ability to use D4A
|
||||
|
||||
Draupnir for all includes several security measures like that it only allows users that are on its allow list to ask for a bot. To add a user to this list we have 2 primary options. Using the chat to tell Draupnir to do this for us or if you want to automatically do it by sending `m.policy.rule.user` events that target the subject you want to allow provisioning for with the `org.matrix.mjolnir.allow` recommendation. Using the chat is recommended.
|
||||
Draupnir for all includes several security measures like that it only allows users that are on its allow list to ask for a bot. To add a user to this list we have 2 primary options. Using the chat to tell Draupnir to do this for us or if you want to automatically do it by sending `m.policy.rule.user` events that target the subject you want to allow provisioning for with the `org.matrix.mjolnir.allow` recomendation. Using the chat is recomended.
|
||||
|
||||
The bot requires a powerlevel of 50 in the management room to control who is allowed to use the bot. The bot does currently not say anything if this is true or false. (This is considered a bug and is documented in issue [#297](https://github.com/the-draupnir-project/Draupnir/issues/297))
|
||||
|
||||
|
||||
@@ -242,13 +242,7 @@ matrix_bot_baibot_config_agents_static_definitions_openai_config_api_key: "YOUR_
|
||||
# matrix_bot_baibot_config_agents_static_definitions_openai_config_text_generation_prompt: "{{ matrix_bot_baibot_config_agents_static_definitions_prompt }}"
|
||||
|
||||
# If you'd like to use another text-generation agent, uncomment and adjust:
|
||||
# matrix_bot_baibot_config_agents_static_definitions_openai_config_text_generation_model_id: gpt-4.1
|
||||
|
||||
# Uncomment below to enable OpenAI's built-in tools.
|
||||
# These tools are disabled by default. Enabling them may incur additional costs.
|
||||
# See: https://github.com/etkecc/baibot/blob/61d18b2/docs/features.md#%EF%B8%8F-built-in-tools-openai-only
|
||||
# matrix_bot_baibot_config_agents_static_definitions_openai_config_text_generation_tools_web_search: true
|
||||
# matrix_bot_baibot_config_agents_static_definitions_openai_config_text_generation_tools_code_interpreter: true
|
||||
# matrix_bot_baibot_config_agents_static_definitions_openai_config_text_generation_model_id: gpt-4o
|
||||
```
|
||||
|
||||
Because this is a [statically](https://github.com/etkecc/baibot/blob/main/docs/configuration/README.md#static-configuration)-defined agent, it will be given a `static/` ID prefix and will be named `static/openai`.
|
||||
|
||||
@@ -1,25 +1,98 @@
|
||||
<!--
|
||||
SPDX-FileCopyrightText: 2019 - 2025 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2022 Dennis Ciba
|
||||
SPDX-FileCopyrightText: 2022 Nikita Chernyi
|
||||
SPDX-FileCopyrightText: 2023 - 2024 MDAD project contributors
|
||||
SPDX-FileCopyrightText: 2023 - 2024 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2023 MDAD project contributors
|
||||
SPDX-FileCopyrightText: 2024 - 2025 Suguru Hirahara
|
||||
|
||||
SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
-->
|
||||
|
||||
# Setting up matrix-chatgpt-bot (optional, removed)
|
||||
# Setting up matrix-bot-chatgpt (optional, unmaintained)
|
||||
|
||||
🪦 The playbook used to be able to install and configure [matrix-chatgpt-bot](https://github.com/matrixgpt/matrix-chatgpt-bot), but no longer includes this component.
|
||||
**Note**: [matrix-chatgpt-bot](https://github.com/matrixgpt/matrix-chatgpt-bot) is now an archived (**unmaintained**) project. Talking to ChatGPT (and many other LLM providers) can happen via the much more featureful [baibot](https://github.com/etkecc/baibot), which can be [installed using this playbook](configuring-playbook-bot-baibot.md). Consider using that bot instead of this one.
|
||||
|
||||
While not a 1:1 replacement, the bot's author suggests taking a look at [baibot](https://github.com/etkecc/baibot) as a replacement, which can also be [installed using this playbook](configuring-playbook-bot-baibot.md).
|
||||
The playbook can install and configure [matrix-chatgpt-bot](https://github.com/matrixgpt/matrix-chatgpt-bot) for you.
|
||||
|
||||
## Uninstalling matrix-chatgpt-bot manually
|
||||
Talk to [ChatGPT](https://openai.com/blog/chatgpt/) via your favourite Matrix client!
|
||||
|
||||
If you still have the matrix-chatgpt-bot component installed on your Matrix server, the playbook can no longer help you uninstall it and you will need to do it manually. To uninstall manually, run these commands on the server:
|
||||
See the project's [documentation](https://github.com/matrixgpt/matrix-chatgpt-bot/blob/main/README.md) to learn what it does and why it might be useful to you.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
### Obtain an OpenAI API key
|
||||
|
||||
To use the bot, you'd need to obtain an API key from [https://platform.openai.com/account/api-keys](https://platform.openai.com/account/api-keys).
|
||||
|
||||
### Register the bot account
|
||||
|
||||
The playbook does not automatically create users for you. You **need to register the bot user manually** before setting up the bot.
|
||||
|
||||
Generate a strong password for the bot. You can create one with a command like `pwgen -s 64 1`.
|
||||
|
||||
You can use the playbook to [register a new user](registering-users.md):
|
||||
|
||||
```sh
|
||||
systemctl disable --now matrix-bot-chatgpt.service
|
||||
|
||||
rm -rf /matrix/chatgpt
|
||||
ansible-playbook -i inventory/hosts setup.yml --extra-vars='username=bot.chatgpt password=PASSWORD_FOR_THE_BOT admin=no' --tags=register-user
|
||||
```
|
||||
|
||||
### Obtain an access token and create encryption keys
|
||||
|
||||
The bot requires an access token to be able to connect to your homeserver. Refer to the documentation on [how to obtain an access token](obtaining-access-tokens.md).
|
||||
|
||||
> [!WARNING]
|
||||
> Access tokens are sensitive information. Do not include them in any bug reports, messages, or logs. Do not share the access token with anyone.
|
||||
|
||||
To make sure the bot can read encrypted messages, it will need an encryption key, just like any other new user. While obtaining the access token, follow the prompts to setup a backup key. More information can be found in the [Element documentation](https://element.io/help#encryption6).
|
||||
|
||||
## 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 `API_KEY_HERE` with the API key retrieved [here](#obtain-an-openai-api-key) and `ACCESS_TOKEN_HERE` with the access token created [here](#obtain-an-access-token-and-create-encryption-keys), respectively.
|
||||
|
||||
```yaml
|
||||
matrix_bot_chatgpt_enabled: true
|
||||
|
||||
matrix_bot_chatgpt_openai_api_key: 'API_KEY_HERE'
|
||||
|
||||
# Uncomment and adjust this part if you'd like to use a username different than the default
|
||||
# matrix_bot_chatgpt_matrix_bot_username_localpart: 'bot.chatgpt'
|
||||
|
||||
matrix_bot_chatgpt_matrix_access_token: 'ACCESS_TOKEN_HERE'
|
||||
|
||||
# Configuring the system promt used, needed if the bot is used for special tasks.
|
||||
# More information: https://github.com/mustvlad/ChatGPT-System-Prompts
|
||||
matrix_bot_chatgpt_matrix_bot_prompt_prefix: 'Instructions:\nYou are ChatGPT, a large language model trained by OpenAI.'
|
||||
```
|
||||
|
||||
### Extending the configuration
|
||||
|
||||
There are some additional things you may wish to configure about the bot.
|
||||
|
||||
Take a look at:
|
||||
|
||||
- `roles/custom/matrix-bot-chatgpt/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
|
||||
|
||||
## Installing
|
||||
|
||||
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
|
||||
|
||||
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
|
||||
```sh
|
||||
ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,ensure-matrix-users-created,start
|
||||
```
|
||||
|
||||
**Notes**:
|
||||
|
||||
- The `ensure-matrix-users-created` playbook tag makes the playbook automatically create the bot's user account.
|
||||
|
||||
- The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
|
||||
|
||||
`just install-all` is useful for maintaining your setup quickly ([2x-5x faster](../CHANGELOG.md#2x-5x-performance-improvements-in-playbook-runtime) than `just setup-all`) when its components remain unchanged. If you adjust your `vars.yml` to remove other components, you'd need to run `just setup-all`, or these components will still remain installed.
|
||||
|
||||
## Usage
|
||||
|
||||
To use the bot, invite it to the room you specified on your `vars.yml` file (`/invite @bot.chatgpt:example.com` where `example.com` is your base domain, not the `matrix.` domain).
|
||||
|
||||
After the bot joins the room, you can send a message to it. When you do so, use the prefix if you configured it or mention the bot.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-bot-chatgpt`.
|
||||
|
||||
@@ -145,20 +145,6 @@ The bot can intercept the report API endpoint of the client-server API, which re
|
||||
matrix_bot_draupnir_config_web_abuseReporting: true
|
||||
```
|
||||
|
||||
### Enabling synapse-http-antispam support
|
||||
|
||||
Certain protections in Draupnir require the [synapse-http-antispam](https://github.com/maunium/synapse-http-antispam) module and a Synapse homeserver plus homeserver admin status to function. This module can be enabled in the playbook via setting `matrix_bot_draupnir_config_web_synapseHTTPAntispam_enabled` to `true` and making sure that Draupnir admin API access is enabled.
|
||||
|
||||
```yaml
|
||||
# Enables the integration between Draupnir and synapse-http-antispam module.
|
||||
matrix_bot_draupnir_config_web_synapseHTTPAntispam_enabled: true
|
||||
|
||||
# Enables draupnir to access Synapse admin APIs. This is required for the module functionality to take full effect.
|
||||
matrix_bot_draupnir_admin_api_enabled: true
|
||||
```
|
||||
|
||||
These protections need to be manually activated and consulting the [enabling protections](#enabling-built-in-protections) guide can be helpful or consulting upstream documentation.
|
||||
|
||||
<!--
|
||||
NOTE: this is unsupported by the playbook due to the admin API being inaccessible from containers currently.
|
||||
|
||||
@@ -242,12 +228,9 @@ For Draupnir to do its job, you need to [give it permissions](https://the-draupn
|
||||
|
||||
We recommend **subscribing to a public [policy list](https://the-draupnir-project.github.io/draupnir-documentation/concepts/policy-lists)** using the [watch command](https://the-draupnir-project.github.io/draupnir-documentation/moderator/managing-policy-lists#using-draupnirs-watch-command-to-subscribe-to-policy-rooms).
|
||||
|
||||
Policy lists are maintained in Matrix rooms. Popular ones maintained in the public are:
|
||||
Polcy lists are maintained in Matrix rooms. A popular policy list is maintained in the public `#community-moderation-effort-bl:neko.dev` room.
|
||||
|
||||
- `#community-moderation-effort-bl:neko.dev`
|
||||
- `#huginn-muninn-active-threats:feline.support`
|
||||
|
||||
You can tell Draupnir to subscribe to each of these by sending the following command to the Management Room: `!draupnir watch POLICY_LIST_ADDRESS_HERE` (e.g. `!draupnir watch #community-moderation-effort-bl:neko.dev`)
|
||||
You can tell Draupnir to subscribe to it by sending the following command to the Management Room: `!draupnir watch #community-moderation-effort-bl:neko.dev`
|
||||
|
||||
#### Creating your own policy lists and rules
|
||||
|
||||
@@ -262,7 +245,7 @@ The simplest and most useful entity to target is `user`. Below are a few example
|
||||
To create rules, you run commands in the Management Room (**not** in the policy list room).
|
||||
|
||||
- (ban a single user on a given homeserver): `!draupnir ban @charles:example.com my-bans Rude to others`
|
||||
- (ban all users on a given homeserver by using a [wildcard](https://the-draupnir-project.github.io/draupnir-documentation/moderator/managing-users#wildcards)): `!draupnir ban @*:example.org my-bans Spam server, all users are fake`
|
||||
- (ban all users on a given homeserver by using a [wildcard](https://the-draupnir-project.github.io/draupnir-documentation/moderator/managing-users#wildcards)): `!draupnir ban @*:example.org my-bans Spam server - all users are fake`
|
||||
|
||||
As a result of running these commands, you may observe:
|
||||
|
||||
@@ -273,14 +256,14 @@ You can undo bans with the [unban command](https://the-draupnir-project.github.i
|
||||
|
||||
### Enabling built-in protections
|
||||
|
||||
You can also **turn on various built-in [protections](https://the-draupnir-project.github.io/draupnir-documentation/protections)** like `JoinWaveShortCircuitProtection` ("If X amount of users join in Y time, set the room to invite-only").
|
||||
You can also **turn on various built-in [protections](https://the-draupnir-project.github.io/draupnir-documentation/protections)** like `JoinWaveShortCircuit` ("If X amount of users join in Y time, set the room to invite-only").
|
||||
|
||||
To **see which protections are available and which are enabled**, send a `!draupnir protections` command to the Management Room.
|
||||
|
||||
To [**see the configuration options for a given protection**](https://the-draupnir-project.github.io/draupnir-documentation/protections/configuring-protections#displaying-the-protection-settings), send a `!draupnir protections show PROTECTION_NAME` (e.g. `!draupnir protections show JoinWaveShortCircuitProtection`).
|
||||
To **see the configuration options for a given protection**, send a `!draupnir protections show PROTECTION_NAME` (e.g. `!draupnir protections show JoinWaveShortCircuit`).
|
||||
|
||||
To [**set a specific option for a given protection**](https://the-draupnir-project.github.io/draupnir-documentation/protections/configuring-protections#changing-protection-settings), send a command like this: `!draupnir protections config set PROTECTION_NAME OPTION VALUE` (e.g. `!draupnir protections config set JoinWaveShortCircuitProtection timescaleMinutes 30`).
|
||||
To **set a specific option for a given protection**, send a command like this: `!draupnir config set PROTECTION_NAME.OPTION VALUE` (e.g. `!draupnir config set JoinWaveShortCircuit.timescaleMinutes 30`).
|
||||
|
||||
To [**enable a given protection**](https://the-draupnir-project.github.io/draupnir-documentation/protections/block-invitations-on-server-protection#enabling-the-protection), send a command like this: `!draupnir protections enable PROTECTION_NAME` (e.g. `!draupnir protections enable JoinWaveShortCircuitProtection`).
|
||||
To **enable a given protection**, send a command like this: `!draupnir enable PROTECTION_NAME` (e.g. `!draupnir enable JoinWaveShortCircuit`).
|
||||
|
||||
To **disable a given protection**, send a command like this: `!draupnir protections disable PROTECTION_NAME` (e.g. `!draupnir protections disable JoinWaveShortCircuitProtection`).
|
||||
To **disable a given protection**, send a command like this: `!draupnir disable PROTECTION_NAME` (e.g. `!draupnir disable JoinWaveShortCircuit`).
|
||||
|
||||
@@ -37,10 +37,6 @@ matrix_synapse_enable_registration: true
|
||||
|
||||
# Restrict registration to users with a token
|
||||
matrix_synapse_registration_requires_token: true
|
||||
|
||||
# Set an optional command prefix for the bot. This can be any arbitrary string, including whitespace.
|
||||
# Example: "!regbot "
|
||||
matrix_bot_matrix_registration_bot_bot_prefix: ""
|
||||
```
|
||||
|
||||
The bot account will be created automatically.
|
||||
@@ -81,7 +77,7 @@ Send `help` to the bot to see the available commands.
|
||||
|
||||
You can also refer to the upstream [Usage documentation](https://github.com/moan0s/matrix-registration-bot#supported-commands).
|
||||
|
||||
If you have any questions, or if you need help setting it up, read the [troubleshooting guide](https://github.com/moan0s/matrix-registration-bot/blob/main/docs/troubleshooting.md) or join [#matrix-registration-bot:hyteck.de](https://matrix.to/#/#matrix-registration-bot:hyteck.de).
|
||||
If you have any questions, or if you need help setting it up, read the [troublshooting guide](https://github.com/moan0s/matrix-registration-bot/blob/main/docs/troubleshooting.md) or join [#matrix-registration-bot:hyteck.de](https://matrix.to/#/#matrix-registration-bot:hyteck.de).
|
||||
|
||||
To clean the cache (session & encryption data) after you changed the bot's username, changed the login method from access_token to password etc… you can use:
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
|
||||
# Setting up Appservice Discord bridging (optional)
|
||||
|
||||
**Note**: bridging to [Discord](https://discordapp.com/) can also happen via the [mautrix-discord](configuring-playbook-bridge-mautrix-discord.md) bridge supported by the playbook.
|
||||
**Note**: bridging to [Discord](https://discordapp.com/) can also happen via the [mx-puppet-discord](configuring-playbook-bridge-mx-puppet-discord.md) and [mautrix-discord](configuring-playbook-bridge-mautrix-discord.md) bridges supported by the playbook.
|
||||
- For using as a Bot we are recommend the Appservice Discord bridge (the one being discussed here), because it supports plumbing.
|
||||
- For personal use we recommend the [mautrix-discord](configuring-playbook-bridge-mautrix-discord.md) bridge, because it is the most fully-featured and stable of the 3 Discord bridges supported by the playbook.
|
||||
|
||||
|
||||
@@ -1,38 +1,157 @@
|
||||
<!--
|
||||
SPDX-FileCopyrightText: 2019 Edgars Voroboks
|
||||
SPDX-FileCopyrightText: 2019 Eduardo Beltrame
|
||||
SPDX-FileCopyrightText: 2019-2025 MDAD project contributors
|
||||
SPDX-FileCopyrightText: 2019-2025 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2020 Chris van Dijk
|
||||
SPDX-FileCopyrightText: 2020 Tulir Asokan
|
||||
SPDX-FileCopyrightText: 2019 - 2022 MDAD project contributors
|
||||
SPDX-FileCopyrightText: 2020 Udo Rader
|
||||
SPDX-FileCopyrightText: 2020 jens quade
|
||||
SPDX-FileCopyrightText: 2021 - 2024 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2021 Joel Bennett
|
||||
SPDX-FileCopyrightText: 2022 Dennis Ciba
|
||||
SPDX-FileCopyrightText: 2022 Kim Brose
|
||||
SPDX-FileCopyrightText: 2022 Travis Ralston
|
||||
SPDX-FileCopyrightText: 2022 Vladimir Panteleev
|
||||
SPDX-FileCopyrightText: 2022 Yan Minagawa
|
||||
SPDX-FileCopyrightText: 2024 - 2025 Suguru Hirahara
|
||||
SPDX-FileCopyrightText: 2024 Fabio Bonelli
|
||||
SPDX-FileCopyrightText: 2024-2026 Suguru Hirahara
|
||||
|
||||
SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
-->
|
||||
|
||||
# Setting up Appservice Slack bridging (optional, removed)
|
||||
# Setting up Appservice Slack bridging (optional)
|
||||
|
||||
🪦 The playbook used to be able to install and configure [matrix-appservice-slack](https://github.com/matrix-org/matrix-appservice-slack), but no longer includes this component, as it had been unavailable for new installation since 2024, and was finally abandoned because the public Matrix.org Slack bridge has been decommissioned on January 14th, 2026.
|
||||
**Notes**:
|
||||
- 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.
|
||||
- Currently (as of November, 2024) **this component is not available for new installation unless you have already created a classic Slack application** (which the bridge makes use of in order to enable bridging between Slack and Matrix), because the creation of classic Slack applications has been discontinued since June 4 2024. The author of the bridge claims [here](https://github.com/matrix-org/matrix-appservice-slack/issues/789#issuecomment-2172947787) that he plans to support the modern Slack application and until then "the best (and only) option for new installations is to use the webhook bridging".
|
||||
|
||||
**Note**: Bridging to [Slack](https://slack.com) can also happen via the [mautrix-slack](configuring-playbook-bridge-mautrix-slack.md) bridge supported by the playbook.
|
||||
The playbook can install and configure [matrix-appservice-slack](https://github.com/matrix-org/matrix-appservice-slack) for you.
|
||||
|
||||
## Uninstalling the component manually
|
||||
See the project's [documentation](https://github.com/matrix-org/matrix-appservice-slack/blob/master/README.md) to learn what it does and why it might be useful to you.
|
||||
|
||||
If you still have matrix-appservice-slack installed on your Matrix server, the playbook can no longer help you uninstall it and you will need to do it manually. To uninstall manually, run these commands on the server:
|
||||
## Prerequisites
|
||||
|
||||
```sh
|
||||
systemctl disable --now matrix-appservice-slack.service
|
||||
### Create a Classic Slack App
|
||||
|
||||
rm -rf /matrix/appservice-slack
|
||||
First, you need to create a Classic Slack App [here](https://api.slack.com/apps?new_classic_app=1).
|
||||
|
||||
/matrix/postgres/bin/cli-non-interactive -c 'DROP DATABASE matrix_appservice_slack;'
|
||||
Name the app "matrixbot" (or anything else you'll remember). Select the team/workspace this app will belong to. Click on bot users and add a new bot user. We will use this account to bridge the the rooms.
|
||||
|
||||
Then, click on Event Subscriptions and enable them and use the request url: `https://matrix.example.com/appservice-slack`.
|
||||
|
||||
Add the following events as `Bot User Events` and save:
|
||||
|
||||
- team_domain_change
|
||||
- message.channels
|
||||
- message.groups (if you want to bridge private channels)
|
||||
- reaction_added
|
||||
- reaction_removed
|
||||
|
||||
Next, click on "OAuth & Permissions" and add the following scopes:
|
||||
|
||||
- chat:write:bot
|
||||
- users:read
|
||||
- reactions:write
|
||||
- files:write:user (if you want to bridge files)
|
||||
|
||||
**Note**: In order to make Slack files visible to Matrix users, this bridge will make Slack files visible to anyone with the url (including files in private channels). This is different than the current behavior in Slack, which only allows authenticated access to media posted in private channels. See MSC701 for details.
|
||||
|
||||
Click on "Install App" and "Install App to Workspace". Note the access tokens shown. You will need the Bot User OAuth Access Token and if you want to bridge files, the OAuth Access Token whenever you link a room.
|
||||
|
||||
### Create an administration control room on Matrix
|
||||
|
||||
Create a new Matrix room to act as the administration control room.
|
||||
|
||||
Note its internal room ID. This can be done in Element Web by sending a message, opening the options for that message and choosing "view source". The room ID will be displayed near the top.
|
||||
|
||||
## Adjusting the playbook configuration
|
||||
|
||||
To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_appservice_slack_enabled: true
|
||||
matrix_appservice_slack_control_room_id: "Your Matrix admin room ID"
|
||||
|
||||
# Uncomment to enable puppeting (optional, but recommended)
|
||||
# matrix_appservice_slack_puppeting_enabled: true
|
||||
# matrix_appservice_slack_puppeting_slackapp_client_id: "Your Classic Slack App Client ID"
|
||||
# matrix_appservice_slack_puppeting_slackapp_client_secret: "Your Classic Slack App Client Secret"
|
||||
|
||||
# Uncomment to enable Team Sync (optional)
|
||||
# See https://matrix-appservice-slack.readthedocs.io/en/latest/team_sync/
|
||||
# matrix_appservice_slack_team_sync_enabled: true
|
||||
```
|
||||
|
||||
### Extending the configuration
|
||||
|
||||
There are some additional things you may wish to configure about the bridge.
|
||||
|
||||
Take a look at:
|
||||
|
||||
- `roles/custom/matrix-bridge-appservice-slack/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
|
||||
- `roles/custom/matrix-bridge-appservice-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_appservice_slack_configuration_extension_yaml` variable
|
||||
|
||||
For example, to change the bot's username from `slackbot`, add the following configuration to your `vars.yml` file. Replace `examplebot` with your own.
|
||||
|
||||
```yaml
|
||||
matrix_appservice_slack_configuration_extension_yaml: |
|
||||
bot_username: "examplebot"
|
||||
```
|
||||
|
||||
## Installing
|
||||
|
||||
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
|
||||
|
||||
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
|
||||
```sh
|
||||
ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
|
||||
```
|
||||
|
||||
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
|
||||
|
||||
`just install-all` is useful for maintaining your setup quickly ([2x-5x faster](../CHANGELOG.md#2x-5x-performance-improvements-in-playbook-runtime) than `just setup-all`) when its components remain unchanged. If you adjust your `vars.yml` to remove other components, you'd need to run `just setup-all`, or these components will still remain installed. Note these shortcuts run the `ensure-matrix-users-created` tag too.
|
||||
|
||||
## Usage
|
||||
|
||||
To use the bridge, you need to send `/invite @slackbot:example.com` to invite the bridge bot user into the admin room.
|
||||
|
||||
If Team Sync is not enabled, for each channel you would like to bridge, perform the following steps:
|
||||
|
||||
- Create a Matrix room in the usual manner for your client. Take a note of its Matrix room ID — it will look something like `!qporfwt:example.com`.
|
||||
- Invite the bot user to both the Slack and Matrix channels you would like to bridge using `/invite @matrixbot` for Slack and `/invite @slackbot:example.com` for Matrix.
|
||||
- Determine the "channel ID" that Slack uses to identify the channel. You can see it when you open a given Slack channel in a browser. The URL reads like this: `https://app.slack.com/client/XXX/<the channel ID>/details/`.
|
||||
- Issue a link command in the administration control room with these collected values as arguments:
|
||||
|
||||
with file bridging:
|
||||
|
||||
```
|
||||
link --channel_id CHANNELID --room !qporfwt:example.com --slack_bot_token xoxb-xxxxxxxxxx-xxxxxxxxxxxxxxxxxxxx --slack_user_token xoxp-xxxxxxxx-xxxxxxxxx-xxxxxxxx-xxxxxxxx
|
||||
```
|
||||
|
||||
without file bridging:
|
||||
|
||||
```
|
||||
link --channel_id CHANNELID --room !qporfwt:example.com --slack_bot_token xoxb-xxxxxxxxxx-xxxxxxxxxxxxxxxxxxxx
|
||||
```
|
||||
|
||||
These arguments can be shortened to single-letter forms:
|
||||
|
||||
```
|
||||
link -I CHANNELID -R !qporfwt:example.com -t xoxb-xxxxxxxxxx-xxxxxxxxxxxxxxxxxxxx
|
||||
```
|
||||
|
||||
### Unlinking
|
||||
|
||||
Channels can be unlinked again by sending this:
|
||||
|
||||
```
|
||||
unlink --room !qporfwt:example.com
|
||||
```
|
||||
|
||||
Unlinking doesn't only disconnect the bridge, but also makes the slackbot leave the bridged Matrix room. So in case you want to re-link later, don't forget to re-invite the slackbot into this room again.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-appservice-slack`.
|
||||
|
||||
### Linking: "Room is now pending-name"
|
||||
|
||||
This typically means that you haven't used the correct Slack channel ID. Unlink the room and recheck 'Determine the "channel ID"' from above.
|
||||
|
||||
### Messages work from Matrix to Slack, but not the other way around
|
||||
|
||||
Check the logs, and if you find the message like below, unlink your room, reinvite the bot and re-link it again.
|
||||
|
||||
`WARN SlackEventHandler Ignoring message from unrecognised Slack channel ID : %s (%s) <the channel ID> <some other ID>`
|
||||
|
||||
This may particularly hit you, if you tried to unsuccessfully link your room multiple times without unlinking it after each failed attempt.
|
||||
|
||||
@@ -1,30 +1,113 @@
|
||||
<!--
|
||||
SPDX-FileCopyrightText: 2019 - 2025 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2019 Eduardo Beltrame
|
||||
SPDX-FileCopyrightText: 2020 - 2023 MDAD project contributors
|
||||
SPDX-FileCopyrightText: 2020 Björn Marten
|
||||
SPDX-FileCopyrightText: 2020 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2020 iLyas Bakouch
|
||||
SPDX-FileCopyrightText: 2020 Tulir Asokan
|
||||
SPDX-FileCopyrightText: 2022 Dennis Ciba
|
||||
SPDX-FileCopyrightText: 2022 Kim Brose
|
||||
SPDX-FileCopyrightText: 2022 Vladimir Panteleev
|
||||
SPDX-FileCopyrightText: 2024 - 2025 Suguru Hirahara
|
||||
|
||||
SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
-->
|
||||
|
||||
# Setting up Appservice Webhooks bridging (optional, removed)
|
||||
# Setting up Appservice Webhooks bridging (optional, deprecated)
|
||||
|
||||
🪦 The playbook used to be able to install and configure [matrix-appservice-webhooks](https://github.com/turt2live/matrix-appservice-webhooks), but no longer includes this component, as it has been deprecated since more than several years.
|
||||
**Note**: This bridge has been deprecated. We recommend not bothering with installing it. While not a 1:1 replacement, the bridge's author suggests taking a look at [matrix-hookshot](https://github.com/matrix-org/matrix-hookshot) as a replacement, which can also be [installed using this playbook](configuring-playbook-bridge-hookshot.md). Consider using that bridge instead of this one.
|
||||
|
||||
You may wish to use [matrix-hookshot](https://github.com/matrix-org/matrix-hookshot) instead.
|
||||
The playbook can install and configure [matrix-appservice-webhooks](https://github.com/turt2live/matrix-appservice-webhooks) for you. This bridge provides support for Slack-compatible webhooks.
|
||||
|
||||
## Uninstalling the bridge manually
|
||||
See the project's [documentation](https://github.com/turt2live/matrix-appservice-webhooks/blob/master/README.md) to learn what it does and why it might be useful to you.
|
||||
|
||||
If you still have matrix-appservice-webhooks installed on your Matrix server, the playbook can no longer help you uninstall it and you will need to do it manually. To uninstall manually, run these commands on the server:
|
||||
## Adjusting the playbook configuration
|
||||
|
||||
To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_appservice_webhooks_enabled: true
|
||||
matrix_appservice_webhooks_api_secret: '<your_secret>'
|
||||
|
||||
# As of Synapse 1.90.0, uncomment to enable the backwards compatibility (https://matrix-org.github.io/synapse/latest/upgrade#upgrading-to-v1900) that this bridge needs.
|
||||
# Note: This deprecated method is considered insecure.
|
||||
#
|
||||
# matrix_synapse_configuration_extension_yaml: |
|
||||
# use_appservice_legacy_authorization: true
|
||||
```
|
||||
|
||||
### Extending the configuration
|
||||
|
||||
There are some additional things you may wish to configure about the bridge.
|
||||
|
||||
Take a look at:
|
||||
|
||||
- `roles/custom/matrix-bridge-appservice-webhooks/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
|
||||
- `roles/custom/matrix-bridge-appservice-webhooks/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_appservice_webhooks_configuration_extension_yaml` variable
|
||||
|
||||
## Installing
|
||||
|
||||
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
|
||||
|
||||
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
|
||||
```sh
|
||||
ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
|
||||
```
|
||||
|
||||
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
|
||||
|
||||
`just install-all` is useful for maintaining your setup quickly ([2x-5x faster](../CHANGELOG.md#2x-5x-performance-improvements-in-playbook-runtime) than `just setup-all`) when its components remain unchanged. If you adjust your `vars.yml` to remove other components, you'd need to run `just setup-all`, or these components will still remain installed. Note these shortcuts run the `ensure-matrix-users-created` tag too.
|
||||
|
||||
## Usage
|
||||
|
||||
To use the bridge, you need to invite the bridge bot user to your room in either way.
|
||||
|
||||
- Send `/invite @_webhook:example.com` (**Note**: Make sure you have administration permissions in your room)
|
||||
- Add the bridge bot to a private channel (personal channels imply you being an administrator)
|
||||
|
||||
You then need to send a message to the bridge bot to receive a private message including the webhook link:
|
||||
|
||||
```
|
||||
!webhook
|
||||
```
|
||||
|
||||
The JSON body for posting messages will have to look like this:
|
||||
|
||||
```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
|
||||
systemctl disable --now matrix-appservice-webhooks.service
|
||||
|
||||
rm -rf /matrix/appservice-webhooks
|
||||
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 webhook link you've gotten from the bridge bot>
|
||||
```
|
||||
|
||||
### Setting Webhooks with Dimension integration manager
|
||||
|
||||
If you're using the [Dimension integration manager](configuring-playbook-dimension.md), you can configure the Webhooks bridge with it.
|
||||
|
||||
To configure it, open the Dimension integration manager, and go to "Settings" and "Bridges", then select edit action for "Webhook Bridge".
|
||||
|
||||
On the UI, press "Add self-hosted Bridge" button and populate "Provisioning URL" and "Shared Secret" values from `/matrix/appservice-webhooks/config/config.yaml` file's homeserver URL value and provisioning secret value, respectively.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-appservice-webhooks`.
|
||||
|
||||
### Increase logging verbosity
|
||||
|
||||
The default logging level for this component is `info`. If you want to increase the verbosity, add the following configuration to your `vars.yml` file and re-run the playbook:
|
||||
|
||||
```yaml
|
||||
# Valid values: info, verbose
|
||||
matrix_appservice_webhooks_log_level: 'verbose'
|
||||
```
|
||||
|
||||
@@ -1,26 +1,68 @@
|
||||
<!--
|
||||
SPDX-FileCopyrightText: 2019 - 2025 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2019 Eduardo Beltrame
|
||||
SPDX-FileCopyrightText: 2021 MDAD project contributors
|
||||
SPDX-FileCopyrightText: 2022 Dennis Ciba
|
||||
SPDX-FileCopyrightText: 2022 Vladimir Panteleev
|
||||
SPDX-FileCopyrightText: 2024 - 2025 Suguru Hirahara
|
||||
|
||||
SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
-->
|
||||
|
||||
# Setting up Go Skype Bridge bridging (optional, removed)
|
||||
# Setting up Go Skype Bridge bridging (optional)
|
||||
|
||||
🪦 The playbook used to be able to install and configure [go-skype-bridge](https://github.com/kelaresg/go-skype-bridge), but no longer includes this component, as Skype has been discontinued since May 2025.
|
||||
The playbook can install and configure [go-skype-bridge](https://github.com/kelaresg/go-skype-bridge) for you, for bridging to [Skype](https://www.skype.com/). This bridge was created based on [mautrix-whatsapp](https://github.com/mautrix/whatsapp) and can be configured in a similar way to it.
|
||||
|
||||
## Uninstalling the bridge manually
|
||||
See the project's [documentation](https://github.com/kelaresg/go-skype-bridge/blob/master/README.md) to learn what it does and why it might be useful to you.
|
||||
|
||||
If you still have the Go Skype bridge installed on your Matrix server, the playbook can no longer help you uninstall it and you will need to do it manually. To uninstall manually, run these commands on the server:
|
||||
## Prerequisite (optional)
|
||||
|
||||
```sh
|
||||
systemctl disable --now matrix-go-skype-bridge.service
|
||||
### Enable Shared Secret Auth
|
||||
|
||||
rm -rf /matrix/go-skype-bridge
|
||||
If you want to set up [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do) for this bridge automatically, you need to have enabled [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) for this playbook.
|
||||
|
||||
/matrix/postgres/bin/cli-non-interactive -c 'DROP DATABASE matrix_go_skype_bridge;'
|
||||
See [this section](configuring-playbook-bridge-mautrix-bridges.md#set-up-double-puppeting-optional) on the [common guide for configuring mautrix bridges](configuring-playbook-bridge-mautrix-bridges.md) for details about setting up Double Puppeting.
|
||||
|
||||
**Note**: double puppeting with the Shared Secret Auth works at the time of writing, but is deprecated and will stop working in the future.
|
||||
|
||||
## Adjusting the playbook configuration
|
||||
|
||||
To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_go_skype_bridge_enabled: true
|
||||
```
|
||||
|
||||
### Extending the configuration
|
||||
|
||||
There are some additional things you may wish to configure about the bridge.
|
||||
|
||||
See [this section](configuring-playbook-bridge-mautrix-bridges.md#extending-the-configuration) on the [common guide for configuring mautrix bridges](configuring-playbook-bridge-mautrix-bridges.md) for details about variables that you can customize and the bridge's default configuration, including [bridge permissions](configuring-playbook-bridge-mautrix-bridges.md#configure-bridge-permissions-optional), [encryption support](configuring-playbook-bridge-mautrix-bridges.md#enable-encryption-optional), [relay mode](configuring-playbook-bridge-mautrix-bridges.md#enable-relay-mode-optional), [bot's username](configuring-playbook-bridge-mautrix-bridges.md#set-the-bots-username-optional), etc.
|
||||
|
||||
**Note**: when following the guide to configure the bridge, make sure to replace `_mautrix_SERVICENAME_` in the variable names with `_go_skype_bridge_`.
|
||||
|
||||
## Installing
|
||||
|
||||
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
|
||||
|
||||
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
|
||||
```sh
|
||||
ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
|
||||
```
|
||||
|
||||
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
|
||||
|
||||
`just install-all` is useful for maintaining your setup quickly ([2x-5x faster](../CHANGELOG.md#2x-5x-performance-improvements-in-playbook-runtime) than `just setup-all`) when its components remain unchanged. If you adjust your `vars.yml` to remove other components, you'd need to run `just setup-all`, or these components will still remain installed. Note these shortcuts run the `ensure-matrix-users-created` tag too.
|
||||
|
||||
## Usage
|
||||
|
||||
To use the bridge, you need to start a chat with `@skypebridgebot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-go-skype-bridge`.
|
||||
|
||||
### Increase logging verbosity
|
||||
|
||||
The default logging level for this component is `warn`. If you want to increase the verbosity, add the following configuration to your `vars.yml` file and re-run the playbook:
|
||||
|
||||
```yaml
|
||||
# Valid values: fatal, error, warn, info, debug
|
||||
matrix_go_skype_bridge_log_level: 'info'
|
||||
```
|
||||
|
||||
@@ -16,6 +16,8 @@ Hookshot can bridge [Webhooks](https://en.wikipedia.org/wiki/Webhook) from softw
|
||||
|
||||
See the project's [documentation](https://matrix-org.github.io/matrix-hookshot/latest/hookshot.html) to learn what it does and why it might be useful to you.
|
||||
|
||||
**Note**: the playbook also supports [matrix-appservice-webhooks](configuring-playbook-bridge-appservice-webhooks.md), which however was deprecated by its author.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
### Download GitHub app private key (optional)
|
||||
@@ -33,7 +35,7 @@ matrix_hookshot_enabled: true
|
||||
|
||||
# Uncomment to enable end-to-bridge encryption.
|
||||
# See: https://matrix-org.github.io/matrix-hookshot/latest/advanced/encryption.html
|
||||
# matrix_hookshot_encryption_enabled: true
|
||||
# matrix_hookshot_experimental_encryption_enabled: true
|
||||
|
||||
# Uncomment and paste the contents of GitHub app private key to enable GitHub bridge.
|
||||
# Alternatively, you can use one of the other methods explained below on the "Manage GitHub Private Key with aux role" section.
|
||||
@@ -101,6 +103,7 @@ Unless indicated otherwise, the following endpoints are reachable on your `matri
|
||||
| github oauth | `/hookshot/webhooks/oauth` | `matrix_hookshot_github_oauth_endpoint` | GitHub "Callback URL" |
|
||||
| jira oauth | `/hookshot/webhooks/jira/oauth` | `matrix_hookshot_jira_oauth_endpoint` | Jira OAuth |
|
||||
| figma endpoint | `/hookshot/webhooks/figma/webhook` | `matrix_hookshot_figma_endpoint` | Figma |
|
||||
| provisioning | `/hookshot/v1/` | `matrix_hookshot_provisioning_endpoint` | Dimension [provisioning](#provisioning-api) |
|
||||
| appservice | `/hookshot/_matrix/app/` | `matrix_hookshot_appservice_endpoint` | Matrix server |
|
||||
| widgets | `/hookshot/widgetapi/` | `matrix_hookshot_widgets_endpoint` | Widgets |
|
||||
|
||||
@@ -123,12 +126,20 @@ aux_file_definitions:
|
||||
- dest: "{{ matrix_hookshot_base_path }}/{{ matrix_hookshot_github_private_key_file }}"
|
||||
content: "{{ lookup('file', '/path/to/your-github-private-key.pem') }}"
|
||||
mode: '0400'
|
||||
owner: "{{ matrix_user_name }}"
|
||||
group: "{{ matrix_group_name }}"
|
||||
owner: "{{ matrix_user_username }}"
|
||||
group: "{{ matrix_user_groupname }}"
|
||||
```
|
||||
|
||||
For more information, see the documentation in the [default configuration of the aux role](https://github.com/mother-of-all-self-hosting/ansible-role-aux/blob/main/defaults/main.yml).
|
||||
|
||||
### Provisioning API
|
||||
|
||||
The provisioning API will be enabled automatically if you set `matrix_dimension_enabled: true` and provided a `matrix_hookshot_provisioning_secret`, unless you override it either way. To use hookshot with Dimension, you will need to enter as "Provisioning URL": `http://matrix-hookshot:9002`, which is made up of the variables `matrix_hookshot_container_url` and `matrix_hookshot_provisioning_port`.
|
||||
|
||||
### Collision with matrix-appservice-webhooks
|
||||
|
||||
If you are also running [matrix-appservice-webhooks](configuring-playbook-bridge-appservice-webhooks.md), it reserves its namespace by the default setting `matrix_appservice_webhooks_user_prefix: '_webhook_'`. You should take care if you modify its or hookshot's prefix that they do not collide with each other's namespace (default `matrix_hookshot_generic_userIdPrefix: '_webhooks_'`).
|
||||
|
||||
### Enable metrics
|
||||
|
||||
The playbook can enable and configure the metrics of the service for you.
|
||||
@@ -161,7 +172,7 @@ To `matrix_hookshot_container_labels_metrics_middleware_basic_auth_users`, set t
|
||||
|
||||
#### Enable Grafana (optional)
|
||||
|
||||
Probably you wish to enable Grafana along with Prometheus for generating graphs of the metrics.
|
||||
Probably you wish to enable Grafana along with Prometheus for generating graphs of the metics.
|
||||
|
||||
To enable Grafana, see [this section](configuring-playbook-prometheus-grafana.md#adjusting-the-playbook-configuration-grafana) for instructions.
|
||||
|
||||
|
||||
@@ -24,7 +24,7 @@ To enable the bridge, add the following configuration to your `inventory/host_va
|
||||
matrix_mautrix_SERVICENAME_enabled: true
|
||||
```
|
||||
|
||||
**Note**: for bridging to Meta's Messenger or Instagram, you would need to add `meta` with an underscore symbol (`_`) or hyphen (`-`) based on the context as prefix to each `SERVICENAME`; add `_` to variables (as in `matrix_mautrix_meta_messenger_configuration_extension_yaml` for example) and `-` to paths of the configuration files (as in `roles/custom/matrix-bridge-mautrix-meta-messenger/templates/config.yaml.j2`), respectively.
|
||||
**Note**: for bridging to Meta's Messenger or Instagram, you would need to add `meta` with an underscore symbol (`_`) or hyphen (`-`) based on the context as prefix to each `SERVICENAME`; add `_` to variables (as in `matrix_mautrix_meta_messenger_configuration_extension_yaml` for example) and `-` to paths of the configuration files (as in `roles/custom/matrix-bridge-mautrix-meta-messenger/templates/config.yaml.j2`), respectively. **`matrix_mautrix_facebook_*` and `matrix_mautrix_instagram_*` variables belong to the deprecated components and do not control the new bridge** ([mautrix-meta](https://github.com/mautrix/meta)), which can be [installed using this playbook](configuring-playbook-bridge-mautrix-meta-messenger.md).
|
||||
|
||||
There are some additional things you may wish to configure about the bridge before you continue. Each bridge may have additional requirements besides `_enabled: true`. For example, the mautrix-telegram bridge (our documentation page about it is [here](configuring-playbook-bridge-mautrix-telegram.md)) requires the `matrix_mautrix_telegram_api_id` and `matrix_mautrix_telegram_api_hash` variables to be defined. Refer to each bridge's individual documentation page for details about enabling bridges.
|
||||
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
<!--
|
||||
SPDX-FileCopyrightText: 2018 - 2024 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2018 Hugues Morisset
|
||||
SPDX-FileCopyrightText: 2018-2024 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2021, 2022 MDAD project contributors
|
||||
SPDX-FileCopyrightText: 2021 - 2022 MDAD project contributors
|
||||
SPDX-FileCopyrightText: 2022 Abílio Costa
|
||||
SPDX-FileCopyrightText: 2022 Dennis Ciba
|
||||
SPDX-FileCopyrightText: 2022 Marko Weltzer
|
||||
SPDX-FileCopyrightText: 2024-2026 Suguru Hirahara
|
||||
SPDX-FileCopyrightText: 2024 - 2025 Suguru Hirahara
|
||||
|
||||
SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
-->
|
||||
@@ -14,7 +14,9 @@ SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
|
||||
<sup>Refer the common guide for configuring mautrix bridges: [Setting up a Generic Mautrix Bridge](configuring-playbook-bridge-mautrix-bridges.md)</sup>
|
||||
|
||||
**Note**: bridging to [Discord](https://discordapp.com/) can also happen via the [matrix-appservice-discord](configuring-playbook-bridge-appservice-discord.md) bridge supported by the playbook.
|
||||
**Note**: bridging to [Discord](https://discordapp.com/) can also happen via the [mx-puppet-discord](configuring-playbook-bridge-mx-puppet-discord.md) and [matrix-appservice-discord](configuring-playbook-bridge-appservice-discord.md) bridges supported by the playbook.
|
||||
- For using as a Bot we recommend the [Appservice Discord](configuring-playbook-bridge-appservice-discord.md), because it supports plumbing.
|
||||
- For personal use with a discord account we recommend the `mautrix-discord` bridge (the one being discussed here), because it is the most fully-featured and stable of the 3 Discord bridges supported by the playbook.
|
||||
|
||||
The playbook can install and configure [mautrix-discord](https://github.com/mautrix/discord) for you.
|
||||
|
||||
@@ -22,9 +24,9 @@ See the project's [documentation](https://docs.mau.fi/bridges/go/discord/index.h
|
||||
|
||||
## Prerequisites
|
||||
|
||||
There are 3 ways to login to discord using this bridge, either by [scanning a QR code](https://docs.mau.fi/bridges/go/discord/authentication.html#qr-login) using the Discord mobile app, by using a [Discord token](https://docs.mau.fi/bridges/go/discord/authentication.html#token-login), **or** by using a [Discord bot token](https://docs.mau.fi/bridges/go/discord/authentication.html#bot-token-login).
|
||||
There are 2 ways to login to discord using this bridge, either by [scanning a QR code](#method-1-login-using-qr-code-recommended) using the Discord mobile app **or** by using a [Discord token](#method-2-login-using-discord-token-not-recommended).
|
||||
|
||||
⚠️ QR code login is considered a self-bot and is forbidden by Discord. It can result in an account termination. See the [Discord policy](https://support.discord.com/hc/en-us/articles/115002192352-Automated-User-Accounts-Self-Bots).
|
||||
If this is a dealbreaker for you, consider using one of the other Discord bridges supported by the playbook: [mx-puppet-discord](configuring-playbook-bridge-mx-puppet-discord.md) or [matrix-appservice-discord](configuring-playbook-bridge-appservice-discord.md). These come with their own complexity and limitations, however, so we recommend that you proceed with this one if possible.
|
||||
|
||||
### Enable Appservice Double Puppet or Shared Secret Auth (optional)
|
||||
|
||||
@@ -78,14 +80,6 @@ After bridging, spaces will be created automatically, and rooms will be created
|
||||
|
||||
If you want to manually bridge channels, invite the bot to the room you want to bridge, and run `!discord bridge CHANNEL_ID_HERE` to bridge the room. Make sure to replace `CHANNEL_ID_HERE` with the channel's ID.
|
||||
|
||||
### Enable relay
|
||||
|
||||
The bridge supports using Discord's webhook feature to relay messages from Matrix users who haven't logged into the bridge.
|
||||
|
||||
In a room that has already been bridged, run `!discord set-relay --create`. The bridge will then create a webhook in the bridged discord channel and begin relaying messages. If the discord user does not have access to manage webhooks, run `!discord set-relay --url <url>` with the url of an already created webhook. (See Discords [Intro to webhooks](https://support.discord.com/hc/en-us/articles/228383668-Intro-to-Webhooks))
|
||||
|
||||
More information on relaying is available on the [official documentation](https://docs.mau.fi/bridges/go/discord/relay.html).
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-mautrix-discord`.
|
||||
@@ -98,7 +92,3 @@ The default logging level for this component is `warn`. If you want to increase
|
||||
# Valid values: fatal, error, warn, info, debug, trace
|
||||
matrix_mautrix_discord_logging_level: 'debug'
|
||||
```
|
||||
|
||||
### Command requires room admin rights when user is creator
|
||||
|
||||
[MSC4289](https://github.com/matrix-org/matrix-spec-proposals/blob/main/proposals/4289-privilege-creators.md), introduced in [room version 12](https://spec.matrix.org/unstable/rooms/v12/), gives creators an infinitley high powerlevel. At the time of implementation, mautrix-discord and similar applications may not identify creators as or above admins. Either a separate admin user will need to manage the bridge or the room version should be less than version 12.
|
||||
|
||||
@@ -1,32 +1,100 @@
|
||||
<!--
|
||||
SPDX-FileCopyrightText: 2019 - 2025 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2019 Eduardo Beltrame
|
||||
SPDX-FileCopyrightText: 2019 - 2024 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2019 Hugues Morisset
|
||||
SPDX-FileCopyrightText: 2020 Tulir Asokan
|
||||
SPDX-FileCopyrightText: 2021 - 2022 MDAD project contributors
|
||||
SPDX-FileCopyrightText: 2021 Aaron Raimist
|
||||
SPDX-FileCopyrightText: 2022 Dennis Ciba
|
||||
SPDX-FileCopyrightText: 2022 László Várady
|
||||
SPDX-FileCopyrightText: 2022 Vladimir Panteleev
|
||||
SPDX-FileCopyrightText: 2024 - 2025 Suguru Hirahara
|
||||
SPDX-FileCopyrightText: 2024 Suguru Hirahara
|
||||
|
||||
SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
-->
|
||||
|
||||
# Setting up Mautrix Facebook bridging (optional, removed)
|
||||
# Setting up Mautrix Facebook bridging (optional, deprecated)
|
||||
|
||||
🪦 The playbook used to be able to install and configure [mautrix-facebook](https://github.com/mautrix/facebook), but no longer includes this component, as it has been deprecated in favor of the [mautrix-meta](https://github.com/mautrix/meta) Messenger/Instagram bridge.
|
||||
<sup>Refer the common guide for configuring mautrix bridges: [Setting up a Generic Mautrix Bridge](configuring-playbook-bridge-mautrix-bridges.md)</sup>
|
||||
|
||||
The mautrix-meta bridge can be [installed using this playbook](configuring-playbook-bridge-mautrix-meta-messenger.md).
|
||||
**Note**: This bridge has been deprecated in favor of the [mautrix-meta](https://github.com/mautrix/meta) Messenger/Instagram bridge, which can be [installed using this playbook](configuring-playbook-bridge-mautrix-meta-messenger.md). Consider using that bridge instead of this one.
|
||||
|
||||
## Uninstalling the bridge manually
|
||||
The playbook can install and configure [mautrix-facebook](https://github.com/mautrix/facebook) for you.
|
||||
|
||||
If you still have the bridge installed on your Matrix server, the playbook can no longer help you uninstall it and you will need to do it manually. To uninstall manually, run these commands on the server:
|
||||
See the project's [documentation](https://github.com/mautrix/facebook/blob/master/README.md) to learn what it does and why it might be useful to you.
|
||||
|
||||
## Prerequisite (optional)
|
||||
|
||||
### Enable Shared Secret Auth
|
||||
|
||||
If you want to set up [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do) for this bridge automatically, you need to have enabled [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) for this playbook.
|
||||
|
||||
See [this section](configuring-playbook-bridge-mautrix-bridges.md#set-up-double-puppeting-optional) on the [common guide for configuring mautrix bridges](configuring-playbook-bridge-mautrix-bridges.md) for details about setting up Double Puppeting.
|
||||
|
||||
**Note**: double puppeting with the Shared Secret Auth works at the time of writing, but is deprecated and will stop working in the future.
|
||||
|
||||
## Adjusting the playbook configuration
|
||||
|
||||
To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_mautrix_facebook_enabled: true
|
||||
```
|
||||
|
||||
### Extending the configuration
|
||||
|
||||
There are some additional things you may wish to configure about the bridge.
|
||||
|
||||
See [this section](configuring-playbook-bridge-mautrix-bridges.md#extending-the-configuration) on the [common guide for configuring mautrix bridges](configuring-playbook-bridge-mautrix-bridges.md) for details about variables that you can customize and the bridge's default configuration, including [bridge permissions](configuring-playbook-bridge-mautrix-bridges.md#configure-bridge-permissions-optional), [encryption support](configuring-playbook-bridge-mautrix-bridges.md#enable-encryption-optional), [relay mode](configuring-playbook-bridge-mautrix-bridges.md#enable-relay-mode-optional), [bot's username](configuring-playbook-bridge-mautrix-bridges.md#set-the-bots-username-optional), etc.
|
||||
|
||||
## Installing
|
||||
|
||||
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
|
||||
|
||||
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
|
||||
```sh
|
||||
ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
|
||||
```
|
||||
|
||||
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
|
||||
|
||||
`just install-all` is useful for maintaining your setup quickly ([2x-5x faster](../CHANGELOG.md#2x-5x-performance-improvements-in-playbook-runtime) than `just setup-all`) when its components remain unchanged. If you adjust your `vars.yml` to remove other components, you'd need to run `just setup-all`, or these components will still remain installed. Note these shortcuts run the `ensure-matrix-users-created` tag too.
|
||||
|
||||
## Usage
|
||||
|
||||
To use the bridge, you need to start a chat with `@facebookbot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
|
||||
|
||||
You then need to send `login YOUR_FACEBOOK_EMAIL_ADDRESS` to the bridge bot to enable bridging for your Facebook Messenger account.
|
||||
|
||||
If you run into trouble, check the [Troubleshooting](#troubleshooting) section below.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-mautrix-facebook`.
|
||||
|
||||
### Increase logging verbosity
|
||||
|
||||
The default logging level for this component is `WARNING`. If you want to increase the verbosity, add the following configuration to your `vars.yml` file and re-run the playbook:
|
||||
|
||||
```yaml
|
||||
matrix_mautrix_facebook_logging_level: DEBUG
|
||||
```
|
||||
|
||||
### Facebook rejecting login attempts and forcing you to change password
|
||||
|
||||
If your Matrix server is in a wildly different location than where you usually use your Facebook account from, the bridge's login attempts may be outright rejected by Facebook. Along with that, Facebook may even force you to change the account's password.
|
||||
|
||||
If you happen to run into this problem while [setting up bridging](#usage), try to first get a successful session up by logging in to Facebook through the Matrix server's IP address.
|
||||
|
||||
The easiest way to do this may be to use [sshuttle](https://sshuttle.readthedocs.io/) to proxy your traffic through the Matrix server.
|
||||
|
||||
Example command for proxying your traffic through the Matrix server:
|
||||
|
||||
```sh
|
||||
systemctl disable --now matrix-mautrix-facebook.service
|
||||
|
||||
rm -rf /matrix/mautrix-facebook
|
||||
|
||||
/matrix/postgres/bin/cli-non-interactive -c 'DROP DATABASE matrix_mautrix_facebook;'
|
||||
sshuttle -r root@matrix.example.com:22 0/0
|
||||
```
|
||||
|
||||
Once connected, you should be able to verify that you're browsing the web through the Matrix server's IP by checking [icanhazip](https://icanhazip.com/).
|
||||
|
||||
Then proceed to log in to [Facebook/Messenger](https://www.facebook.com/).
|
||||
|
||||
Once logged in, proceed to [set up bridging](#usage).
|
||||
|
||||
If that doesn't work, enable 2FA (see: [Facebook help page on enabling 2FA](https://www.facebook.com/help/148233965247823)) and try to login again with a new password, and entering the 2FA code when prompted, it may take more then one try, in between attempts, check facebook.com to see if they are requiring another password change
|
||||
|
||||
@@ -23,5 +23,5 @@ systemctl disable --now matrix-mautrix-hangouts.service
|
||||
|
||||
rm -rf /matrix/mautrix-hangouts
|
||||
|
||||
/matrix/postgres/bin/cli-non-interactive -c 'DROP DATABASE matrix_mautrix_hangouts;'
|
||||
/matrix/postgres/bin/cli-non-interactive 'DROP DATABASE matrix_mautrix_hangouts;'
|
||||
```
|
||||
|
||||
@@ -1,33 +1,63 @@
|
||||
<!--
|
||||
SPDX-FileCopyrightText: 2019 - 2025 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2019 Eduardo Beltrame
|
||||
SPDX-FileCopyrightText: 2019 Hugues Morisset
|
||||
SPDX-FileCopyrightText: 2020 Tulir Asokan
|
||||
SPDX-FileCopyrightText: 2021 - 2022 MDAD project contributors
|
||||
SPDX-FileCopyrightText: 2021 Aaron Raimist
|
||||
SPDX-FileCopyrightText: 2021 Marcus Proest
|
||||
SPDX-FileCopyrightText: 2022 Dennis Ciba
|
||||
SPDX-FileCopyrightText: 2022 László Várady
|
||||
SPDX-FileCopyrightText: 2022 Vladimir Panteleev
|
||||
SPDX-FileCopyrightText: 2022 - 2024 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2024 - 2025 Suguru Hirahara
|
||||
|
||||
SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
-->
|
||||
|
||||
# Setting up Mautrix Instagram bridging (optional, removed)
|
||||
# Setting up Mautrix Instagram bridging (optional, deprecated)
|
||||
|
||||
🪦 The playbook used to be able to install and configure [mautrix-instagram](https://github.com/mautrix/instagram), but no longer includes this component, as it has been deprecated in favor of the [mautrix-meta](https://github.com/mautrix/meta) Messenger/Instagram bridge.
|
||||
<sup>Refer the common guide for configuring mautrix bridges: [Setting up a Generic Mautrix Bridge](configuring-playbook-bridge-mautrix-bridges.md)</sup>
|
||||
|
||||
The mautrix-meta bridge can be [installed using this playbook](configuring-playbook-bridge-mautrix-meta-messenger.md).
|
||||
**Note**: This bridge has been deprecated in favor of the [mautrix-meta](https://github.com/mautrix/meta) Messenger/Instagram bridge, which can be [installed using this playbook](configuring-playbook-bridge-mautrix-meta-instagram.md). Consider using that bridge instead of this one.
|
||||
|
||||
## Uninstalling the bridge manually
|
||||
The playbook can install and configure [mautrix-instagram](https://github.com/mautrix/instagram) for you.
|
||||
|
||||
If you still have the bridge installed on your Matrix server, the playbook can no longer help you uninstall it and you will need to do it manually. To uninstall manually, run these commands on the server:
|
||||
See the project's [documentation](https://github.com/mautrix/instagram/blob/master/README.md) to learn what it does and why it might be useful to you.
|
||||
|
||||
```sh
|
||||
systemctl disable --now matrix-mautrix-instagram.service
|
||||
## Adjusting the playbook configuration
|
||||
|
||||
rm -rf /matrix/mautrix-instagram
|
||||
To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
|
||||
/matrix/postgres/bin/cli-non-interactive -c 'DROP DATABASE matrix_mautrix_instagram;'
|
||||
```yaml
|
||||
matrix_mautrix_instagram_enabled: true
|
||||
```
|
||||
|
||||
### Extending the configuration
|
||||
|
||||
There are some additional things you may wish to configure about the bridge.
|
||||
|
||||
See [this section](configuring-playbook-bridge-mautrix-bridges.md#extending-the-configuration) on the [common guide for configuring mautrix bridges](configuring-playbook-bridge-mautrix-bridges.md) for details about variables that you can customize and the bridge's default configuration, including [bridge permissions](configuring-playbook-bridge-mautrix-bridges.md#configure-bridge-permissions-optional), [encryption support](configuring-playbook-bridge-mautrix-bridges.md#enable-encryption-optional), [relay mode](configuring-playbook-bridge-mautrix-bridges.md#enable-relay-mode-optional), [bot's username](configuring-playbook-bridge-mautrix-bridges.md#set-the-bots-username-optional), etc.
|
||||
|
||||
## Installing
|
||||
|
||||
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
|
||||
|
||||
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
|
||||
```sh
|
||||
ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
|
||||
```
|
||||
|
||||
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
|
||||
|
||||
`just install-all` is useful for maintaining your setup quickly ([2x-5x faster](../CHANGELOG.md#2x-5x-performance-improvements-in-playbook-runtime) than `just setup-all`) when its components remain unchanged. If you adjust your `vars.yml` to remove other components, you'd need to run `just setup-all`, or these components will still remain installed. Note these shortcuts run the `ensure-matrix-users-created` tag too.
|
||||
|
||||
## Usage
|
||||
|
||||
To use the bridge, you need to start a chat with `@instagrambot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
|
||||
|
||||
You then need to send `login YOUR_INSTAGRAM_EMAIL_ADDRESS YOUR_INSTAGRAM_PASSWORD` to the bridge bot to enable bridging for your instagram/Messenger account.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-mautrix-instagram`.
|
||||
|
||||
### Increase logging verbosity
|
||||
|
||||
The default logging level for this component is `WARNING`. If you want to increase the verbosity, add the following configuration to your `vars.yml` file and re-run the playbook:
|
||||
|
||||
```yaml
|
||||
matrix_mautrix_instagram_logging_level: DEBUG
|
||||
```
|
||||
|
||||
@@ -11,6 +11,10 @@ SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
|
||||
<sup>Refer the common guide for configuring mautrix bridges: [Setting up a Generic Mautrix Bridge](configuring-playbook-bridge-mautrix-bridges.md)</sup>
|
||||
|
||||
**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. Note that it is not available for new installation unless you have already created a classic Slack application, because the creation of classic Slack applications, which this bridge makes use of, has been discontinued.
|
||||
- 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.
|
||||
@@ -21,7 +25,7 @@ See the [features and roadmap](https://github.com/mautrix/slack/blob/main/ROADMA
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
### Enable Appservice Double Puppet (optional)
|
||||
|
||||
@@ -41,7 +45,8 @@ matrix_mautrix_slack_enabled: true
|
||||
|
||||
There are some additional things you may wish to configure about the bridge.
|
||||
|
||||
See [this section](configuring-playbook-bridge-mautrix-bridges.md#extending-the-configuration) on the [common guide for configuring mautrix bridges](configuring-playbook-bridge-mautrix-bridges.md) for details about variables that you can customize and the bridge's default configuration, including [bridge permissions](configuring-playbook-bridge-mautrix-bridges.md#configure-bridge-permissions-optional), [encryption support](configuring-playbook-bridge-mautrix-bridges.md#enable-encryption-optional), [relay mode](configuring-playbook-bridge-mautrix-bridges.md#enable-relay-mode-optional), [bot's username](configuring-playbook-bridge-mautrix-bridges.md#set-the-bots-username-optional), etc.
|
||||
<!-- NOTE: relay mode is not supported for this bridge -->
|
||||
See [this section](configuring-playbook-bridge-mautrix-bridges.md#extending-the-configuration) on the [common guide for configuring mautrix bridges](configuring-playbook-bridge-mautrix-bridges.md) for details about variables that you can customize and the bridge's default configuration, including [bridge permissions](configuring-playbook-bridge-mautrix-bridges.md#configure-bridge-permissions-optional), [encryption support](configuring-playbook-bridge-mautrix-bridges.md#enable-encryption-optional), [bot's username](configuring-playbook-bridge-mautrix-bridges.md#set-the-bots-username-optional), etc.
|
||||
|
||||
## Installing
|
||||
|
||||
|
||||
@@ -11,6 +11,8 @@ SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
|
||||
<sup>Refer the common guide for configuring mautrix bridges: [Setting up a Generic Mautrix Bridge](configuring-playbook-bridge-mautrix-bridges.md)</sup>
|
||||
|
||||
**Note**: bridging to [Twitter](https://twitter.com/) can also happen via the [mx-puppet-twitter](configuring-playbook-bridge-mx-puppet-twitter.md) bridge supported by the playbook.
|
||||
|
||||
The playbook can install and configure [mautrix-twitter](https://github.com/mautrix/twitter) for you.
|
||||
|
||||
See the project's [documentation](https://github.com/mautrix/twitter/blob/master/README.md) to learn what it does and why it might be useful to you.
|
||||
|
||||
@@ -70,7 +70,7 @@ The shortcut commands with the [`just` program](just.md) are also available: `ju
|
||||
|
||||
## Usage
|
||||
|
||||
Follow the [mautrix-imessage documentation](https://docs.mau.fi/bridges/go/imessage/index.html) for running `android-sms` and/or `matrix-imessage` on your device(s).
|
||||
Follow the [mautrix-imessage documenation](https://docs.mau.fi/bridges/go/imessage/index.html) for running `android-sms` and/or `matrix-imessage` on your device(s).
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
|
||||
@@ -1,31 +1,51 @@
|
||||
<!--
|
||||
SPDX-FileCopyrightText: 2019 - 2025 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2019 Eduardo Beltrame
|
||||
SPDX-FileCopyrightText: 2020 - 2022 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2020 Hugues Morisset
|
||||
SPDX-FileCopyrightText: 2020 Tulir Asokan
|
||||
SPDX-FileCopyrightText: 2021 - 2022 MDAD project contributors
|
||||
SPDX-FileCopyrightText: 2022 Dennis Ciba
|
||||
SPDX-FileCopyrightText: 2022 MDAD project contributors
|
||||
SPDX-FileCopyrightText: 2022 Vladimir Panteleev
|
||||
SPDX-FileCopyrightText: 2024 - 2025 Suguru Hirahara
|
||||
|
||||
SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
-->
|
||||
|
||||
# Setting up MX Puppet Discord bridging (optional, removed)
|
||||
# Setting up MX Puppet Discord bridging (optional)
|
||||
|
||||
🪦 The playbook used to be able to install and configure [mx-puppet-discord](https://gitlab.com/mx-puppet/discord/mx-puppet-discord), but no longer includes this component, as it has been unmaintained for a long time.
|
||||
**Note**: bridging to [Discord](https://discordapp.com/) can also happen via the [matrix-appservice-discord](configuring-playbook-bridge-appservice-discord.md)and [mautrix-discord](configuring-playbook-bridge-mautrix-discord.md) bridges supported by the playbook.
|
||||
- For using as a Bot we recommend the [Appservice Discord](configuring-playbook-bridge-appservice-discord.md), because it supports plumbing.
|
||||
- For personal use with a discord account we recommend the [mautrix-discord](configuring-playbook-bridge-mautrix-discord.md) bridge, because it is the most fully-featured and stable of the 3 Discord bridges supported by the playbook.
|
||||
|
||||
You may wish to use the [Mautrix Discord bridge](https://github.com/mautrix/discord) instead.
|
||||
The playbook can install and configure [mx-puppet-discord](https://gitlab.com/mx-puppet/discord/mx-puppet-discord) for you.
|
||||
|
||||
## Uninstalling the bridge manually
|
||||
See the project's [documentation](https://gitlab.com/mx-puppet/discord/mx-puppet-discord/blob/master/README.md) to learn what it does and why it might be useful to you.
|
||||
|
||||
If you still have the MX Puppet Discord bridge installed on your Matrix server, the playbook can no longer help you uninstall it and you will need to do it manually. To uninstall manually, run these commands on the server:
|
||||
## Adjusting the playbook configuration
|
||||
|
||||
```sh
|
||||
systemctl disable --now matrix-mx-puppet-discord.service
|
||||
To enable the [Discord](https://discordapp.com/) bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
|
||||
rm -rf /matrix/mx-puppet-discord
|
||||
|
||||
/matrix/postgres/bin/cli-non-interactive -c 'DROP DATABASE matrix_mx_puppet_discord;'
|
||||
```yaml
|
||||
matrix_mx_puppet_discord_enabled: true
|
||||
```
|
||||
|
||||
## Installing
|
||||
|
||||
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
|
||||
|
||||
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
|
||||
```sh
|
||||
ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
|
||||
```
|
||||
|
||||
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
|
||||
|
||||
`just install-all` is useful for maintaining your setup quickly ([2x-5x faster](../CHANGELOG.md#2x-5x-performance-improvements-in-playbook-runtime) than `just setup-all`) when its components remain unchanged. If you adjust your `vars.yml` to remove other components, you'd need to run `just setup-all`, or these components will still remain installed. Note these shortcuts run the `ensure-matrix-users-created` tag too.
|
||||
|
||||
## Usage
|
||||
|
||||
To use the bridge, you need to start a chat with `Discord Puppet Bridge` with the handle `@_discordpuppet_bot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
|
||||
|
||||
Three authentication methods are available, Legacy Token, OAuth and xoxc token. See mx-puppet-discord [documentation](https://gitlab.com/mx-puppet/discord/mx-puppet-discord) for more information about how to configure the bridge.
|
||||
|
||||
Once logged in, send `list` to the bot user to list the available rooms.
|
||||
|
||||
Clicking rooms in the list will result in you receiving an invitation to the bridged room.
|
||||
|
||||
Send `help` to the bot to see the available commands.
|
||||
|
||||
@@ -1,30 +1,51 @@
|
||||
<!--
|
||||
SPDX-FileCopyrightText: 2019 - 2025 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2019 Eduardo Beltrame
|
||||
SPDX-FileCopyrightText: 2020 Hugues Morisset
|
||||
SPDX-FileCopyrightText: 2020 Tulir Asokan
|
||||
SPDX-FileCopyrightText: 2021 - 2022 MDAD project contributors
|
||||
SPDX-FileCopyrightText: 2022 Dennis Ciba
|
||||
SPDX-FileCopyrightText: 2022 Vladimir Panteleev
|
||||
SPDX-FileCopyrightText: 2021 MDAD project contributors
|
||||
SPDX-FileCopyrightText: 2024 - 2025 Suguru Hirahara
|
||||
|
||||
SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
-->
|
||||
|
||||
# Setting up MX Puppet Instagram bridging (optional, removed)
|
||||
# Setting up MX Puppet Instagram bridging (optional)
|
||||
|
||||
🪦 The playbook used to be able to install and configure [mx-puppet-instagram](https://gitlab.com/mx-puppet/instagram/mx-puppet-instagram), but no longer includes this component, as it has been unmaintained for a long time.
|
||||
The playbook can install and configure [mx-puppet-instagram](https://github.com/Sorunome/mx-puppet-instagram) for you.
|
||||
|
||||
You may wish to use the [Mautrix Meta](https://github.com/mautrix/meta) Messenger/Instagram bridge instead.
|
||||
This allows you to bridge Instagram DirectMessages into Matrix.
|
||||
|
||||
## Uninstalling the bridge manually
|
||||
## Adjusting the playbook configuration
|
||||
|
||||
If you still have the MX Puppet Instagram bridge installed on your Matrix server, the playbook can no longer help you uninstall it and you will need to do it manually. To uninstall manually, run these commands on the server:
|
||||
To enable the [Instagram](https://www.instagram.com/) bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
|
||||
```sh
|
||||
systemctl disable --now matrix-mx-puppet-instagram.service
|
||||
|
||||
rm -rf /matrix/mx-puppet-instagram
|
||||
|
||||
/matrix/postgres/bin/cli-non-interactive -c 'DROP DATABASE matrix_mx_puppet_instagram;'
|
||||
```yaml
|
||||
matrix_mx_puppet_instagram_enabled: true
|
||||
```
|
||||
|
||||
## Installing
|
||||
|
||||
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
|
||||
|
||||
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
|
||||
```sh
|
||||
ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
|
||||
```
|
||||
|
||||
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
|
||||
|
||||
`just install-all` is useful for maintaining your setup quickly ([2x-5x faster](../CHANGELOG.md#2x-5x-performance-improvements-in-playbook-runtime) than `just setup-all`) when its components remain unchanged. If you adjust your `vars.yml` to remove other components, you'd need to run `just setup-all`, or these components will still remain installed. Note these shortcuts run the `ensure-matrix-users-created` tag too.
|
||||
|
||||
## Usage
|
||||
|
||||
To use the bridge, you need to start a chat with `Instagram Puppet Bridge` with the handle `@_instagrampuppet_bot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
|
||||
|
||||
Send `link <username> <password>` to the bridge bot to link your instagram account.
|
||||
|
||||
The `list` commands shows which accounts are linked and which `puppetId` is associated.
|
||||
|
||||
For double-puppeting, you probably want to issue these commands:
|
||||
|
||||
- `settype $puppetId puppet` to enable puppeting for the link (instead of relaying)
|
||||
- `setautoinvite $puppetId 1` to automatically invite you to chats
|
||||
- `setmatrixtoken $accessToken` to set the access token to enable puppeting from the other side (the "double" in double puppeting)
|
||||
|
||||
If you are linking only one Instagram account, your `$puppetId` is probably 1, but use the `list` command find out.
|
||||
|
||||
Send `help` to the bot to see the available commands. At the time of writing, not every command is fully implemented.
|
||||
|
||||
@@ -10,4 +10,4 @@ SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
|
||||
🪦 The playbook used to be able to install and configure [mx-puppet-skype](https://github.com/Sorunome/mx-puppet-skype), but no longer includes this component, because it has been broken and unmaintained for a long time.
|
||||
|
||||
The playbook used to be able to install and configure [go-skype-bridge](configuring-playbook-bridge-go-skype-bridge.md) as alternative to this bridge, but no longer includes this component, because Skype has been discontinued since May 2025.
|
||||
Bridging to [Skype](https://www.skype.com/) can also happen via the [go-skype-bridge](configuring-playbook-bridge-go-skype-bridge.md) bridge supported by the playbook.
|
||||
|
||||
@@ -1,33 +1,58 @@
|
||||
<!--
|
||||
SPDX-FileCopyrightText: 2019 - 2025 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2019 Eduardo Beltrame
|
||||
SPDX-FileCopyrightText: 2020 - 2023 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2020 Rodrigo Belem
|
||||
SPDX-FileCopyrightText: 2020 Tulir Asokan
|
||||
SPDX-FileCopyrightText: 2021 Marcel Ackermann
|
||||
SPDX-FileCopyrightText: 2021 MDAD project contributors
|
||||
SPDX-FileCopyrightText: 2022 Dennis Ciba
|
||||
SPDX-FileCopyrightText: 2022 Jim Myhrberg
|
||||
SPDX-FileCopyrightText: 2022 Nikita Chernyi
|
||||
SPDX-FileCopyrightText: 2022 Vladimir Panteleev
|
||||
SPDX-FileCopyrightText: 2024 - 2025 Suguru Hirahara
|
||||
|
||||
SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
-->
|
||||
|
||||
# Setting up MX Puppet Slack bridging (optional, removed)
|
||||
# Setting up MX Puppet Slack bridging (optional)
|
||||
|
||||
🪦 The playbook used to be able to install and configure [mx-puppet-slack](https://gitlab.com/mx-puppet/slack/mx-puppet-slack), but no longer includes this component, as it has been unmaintained for a long time.
|
||||
**Note**: bridging to [Slack](https://slack.com) can also happen via the [matrix-appservice-slack](configuring-playbook-bridge-appservice-slack.md) and [mautrix-slack](configuring-playbook-bridge-mautrix-slack.md) bridges supported by the playbook. Note that `matrix-appservice-slack` is not available for new installation unless you have already created a classic Slack application, because the creation of classic Slack applications, which this bridge makes use of, has been discontinued.
|
||||
|
||||
You may wish to use the [Mautrix Slack bridge](https://github.com/mautrix/slack) instead.
|
||||
The playbook can install and configure [mx-puppet-slack](https://gitlab.com/mx-puppet/slack/mx-puppet-slack) for you.
|
||||
|
||||
## Uninstalling the bridge manually
|
||||
See the project's [documentation](https://gitlab.com/mx-puppet/slack/mx-puppet-slack/blob/master/README.md) to learn what it does and why it might be useful to you.
|
||||
|
||||
If you still have the MX Puppet Slack bridge installed on your Matrix server, the playbook can no longer help you uninstall it and you will need to do it manually. To uninstall manually, run these commands on the server:
|
||||
## Prerequisite
|
||||
|
||||
```sh
|
||||
systemctl disable --now matrix-mx-puppet-slack.service
|
||||
Follow the [OAuth credentials](https://gitlab.com/mx-puppet/slack/mx-puppet-slack#option-2-oauth) instructions to create a new Slack app, setting the redirect URL to `https://matrix.example.com/slack/oauth`.
|
||||
|
||||
rm -rf /matrix/mx-puppet-slack
|
||||
## Adjusting the playbook configuration
|
||||
|
||||
/matrix/postgres/bin/cli-non-interactive -c 'DROP DATABASE matrix_mx_puppet_slack;'
|
||||
To enable the [Slack](https://slack.com/) bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_mx_puppet_slack_enabled: true
|
||||
# Client ID must be quoted so YAML does not parse it as a float.
|
||||
matrix_mx_puppet_slack_oauth_client_id: "<SLACK_APP_CLIENT_ID>"
|
||||
matrix_mx_puppet_slack_oauth_client_secret: "<SLACK_APP_CLIENT_SECRET>"
|
||||
```
|
||||
|
||||
## Installing
|
||||
|
||||
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
|
||||
|
||||
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
|
||||
```sh
|
||||
ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
|
||||
```
|
||||
|
||||
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
|
||||
|
||||
`just install-all` is useful for maintaining your setup quickly ([2x-5x faster](../CHANGELOG.md#2x-5x-performance-improvements-in-playbook-runtime) than `just setup-all`) when its components remain unchanged. If you adjust your `vars.yml` to remove other components, you'd need to run `just setup-all`, or these components will still remain installed. Note these shortcuts run the `ensure-matrix-users-created` tag too.
|
||||
|
||||
## Usage
|
||||
|
||||
To use the bridge, you need to start a chat with `Slack Puppet Bridge` with the handle `@_slackpuppet_bot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
|
||||
|
||||
Three authentication methods are available, Legacy Token, OAuth and xoxc token. See mx-puppet-slack [documentation](https://gitlab.com/mx-puppet/slack/mx-puppet-slack) for more information about how to configure the bridge.
|
||||
|
||||
Once logged in, send `list` to the bot user to list the available rooms.
|
||||
|
||||
Clicking rooms in the list will result in you receiving an invitation to the bridged room.
|
||||
|
||||
Send `help` to the bot to see the available commands.
|
||||
|
||||
@@ -7,13 +7,11 @@ SPDX-FileCopyrightText: 2024 - 2025 Suguru Hirahara
|
||||
SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
-->
|
||||
|
||||
# Setting up MX Puppet Steam bridging (optional, deprecated)
|
||||
# Setting up MX Puppet Steam bridging (optional)
|
||||
|
||||
**Note**: This bridge has been deprecated in favor of the [matrix-steam-bridge](https://github.com/jasonlaguidice/matrix-steam-bridge) bridge for Steam, which can be [installed using this playbook](configuring-playbook-bridge-steam.md). Consider using that bridge instead of this one.
|
||||
The playbook can install and configure [mx-puppet-steam](https://github.com/icewind1991/mx-puppet-steam) for you.
|
||||
|
||||
The playbook can install and configure [mx-puppet-steam](https://codeberg.org/icewind/mx-puppet-steam) for you.
|
||||
|
||||
See the project's [documentation](https://codeberg.org/icewind/mx-puppet-steam/blob/master/README.md) to learn what it does and why it might be useful to you.
|
||||
See the project's [documentation](https://github.com/icewind1991/mx-puppet-steam/blob/master/README.md) to learn what it does and why it might be useful to you.
|
||||
|
||||
## Adjusting the playbook configuration
|
||||
|
||||
@@ -40,7 +38,7 @@ The shortcut commands with the [`just` program](just.md) are also available: `ju
|
||||
|
||||
To use the bridge, you need to start a chat with `Steam Puppet Bridge` with the handle `@_steampuppet_bot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
|
||||
|
||||
Three authentication methods are available, Legacy Token, OAuth and xoxc token. See mx-puppet-steam [documentation](https://codeberg.org/icewind/mx-puppet-steam) for more information about how to configure the bridge.
|
||||
Three authentication methods are available, Legacy Token, OAuth and xoxc token. See mx-puppet-steam [documentation](https://github.com/icewind1991/mx-puppet-steam) for more information about how to configure the bridge.
|
||||
|
||||
Once logged in, send `list` to the bot user to list the available rooms.
|
||||
|
||||
|
||||
@@ -1,29 +1,57 @@
|
||||
<!--
|
||||
SPDX-FileCopyrightText: 2019 - 2025 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2019 Eduardo Beltrame
|
||||
SPDX-FileCopyrightText: 2020 Tulir Asokan
|
||||
SPDX-FileCopyrightText: 2021 MDAD project contributors
|
||||
SPDX-FileCopyrightText: 2022 Dennis Ciba
|
||||
SPDX-FileCopyrightText: 2022 Vladimir Panteleev
|
||||
SPDX-FileCopyrightText: 2021 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2024 - 2025 Suguru Hirahara
|
||||
|
||||
SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
-->
|
||||
|
||||
# Setting up MX Puppet Twitter bridging (optional, removed)
|
||||
# Setting up MX Puppet Twitter bridging (optional)
|
||||
|
||||
🪦 The playbook used to be able to install and configure [mx-puppet-twitter](https://github.com/Sorunome/mx-puppet-twitter), but no longer includes this component, as it has been unmaintained for a long time.
|
||||
**Note**: bridging to [Twitter](https://twitter.com/) can also happen via the [mautrix-twitter](configuring-playbook-bridge-mautrix-twitter.md) bridge supported by the playbook.
|
||||
|
||||
You may wish to use the [Mautrix Twitter bridge](https://github.com/mautrix/twitter) instead.
|
||||
The playbook can install and configure [mx-puppet-twitter](https://github.com/Sorunome/mx-puppet-twitter) for you.
|
||||
|
||||
## Uninstalling the bridge manually
|
||||
See the project's [documentation](https://github.com/Sorunome/mx-puppet-twitter/blob/master/README.md) to learn what it does and why it might be useful to you.
|
||||
|
||||
If you still have the MX Puppet Twitter bridge installed on your Matrix server, the playbook can no longer help you uninstall it and you will need to do it manually. To uninstall manually, run these commands on the server:
|
||||
## Prerequisite
|
||||
|
||||
```sh
|
||||
systemctl disable --now matrix-mx-puppet-twitter.service
|
||||
Make an app on [developer.twitter.com](https://developer.twitter.com/en/apps).
|
||||
|
||||
rm -rf /matrix/mx-puppet-twitter
|
||||
## Adjusting the playbook configuration
|
||||
|
||||
/matrix/postgres/bin/cli-non-interactive -c 'DROP DATABASE matrix_mx_puppet_twitter;'
|
||||
To enable the [Twitter](https://twitter.com) bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_mx_puppet_twitter_enabled: true
|
||||
matrix_mx_puppet_twitter_consumer_key: ''
|
||||
matrix_mx_puppet_twitter_consumer_secret: ''
|
||||
matrix_mx_puppet_twitter_access_token: ''
|
||||
matrix_mx_puppet_twitter_access_token_secret: ''
|
||||
matrix_mx_puppet_twitter_environment: ''
|
||||
```
|
||||
|
||||
## Installing
|
||||
|
||||
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
|
||||
|
||||
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
|
||||
```sh
|
||||
ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
|
||||
```
|
||||
|
||||
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
|
||||
|
||||
`just install-all` is useful for maintaining your setup quickly ([2x-5x faster](../CHANGELOG.md#2x-5x-performance-improvements-in-playbook-runtime) than `just setup-all`) when its components remain unchanged. If you adjust your `vars.yml` to remove other components, you'd need to run `just setup-all`, or these components will still remain installed. Note these shortcuts run the `ensure-matrix-users-created` tag too.
|
||||
|
||||
## Usage
|
||||
|
||||
To use the bridge, you need to start a chat with `Twitter Puppet Bridge` with the handle `@_twitterpuppet_bot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
|
||||
|
||||
To log in, use `link` and click the link.
|
||||
|
||||
Once logged in, send `list` to the bot user to list the available rooms.
|
||||
|
||||
Clicking rooms in the list will result in you receiving an invitation to the bridged room.
|
||||
|
||||
Send `help` to the bot to see the available commands.
|
||||
|
||||
@@ -1,48 +0,0 @@
|
||||
<!--
|
||||
SPDX-FileCopyrightText: 2025 Jason LaGuidice
|
||||
|
||||
SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
-->
|
||||
|
||||
# Setting up Steam bridging (optional)
|
||||
|
||||
The playbook can install and configure [matrix-steam-bridge](https://github.com/jasonlaguidice/matrix-steam-bridge) for you.
|
||||
|
||||
See the project's [documentation](https://github.com/jasonlaguidice/matrix-steam-bridge/blob/main/README.md) to learn what it does and why it might be useful to you.
|
||||
|
||||
## Adjusting the playbook configuration
|
||||
|
||||
To enable the [Steam](https://steampowered.com/) bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_steam_bridge_enabled: true
|
||||
```
|
||||
|
||||
## Installing
|
||||
|
||||
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
|
||||
|
||||
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
|
||||
```sh
|
||||
ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
|
||||
```
|
||||
|
||||
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` and `just setup-all`
|
||||
|
||||
`just install-all` is useful for maintaining your setup quickly ([2x-5x faster](../CHANGELOG.md#2x-5x-performance-improvements-in-playbook-runtime) than `just setup-all`) when its components remain unchanged. If you adjust your `vars.yml` to remove other components, you'd need to run `just setup-all`, or these components will still remain installed. Note these shortcuts run the `ensure-matrix-users-created` tag too.
|
||||
|
||||
The tag for `just` commands for this bridge is `matrix-steam-bridge` - for example: `just install-service matrix-steam-bridge`
|
||||
|
||||
## Usage
|
||||
|
||||
To use the bridge, you need to start a chat with `Steam bridge bot` with the handle `@steambot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
|
||||
|
||||
The bridge supports QR code and password-based login as well as SteamGuard codes via app, SMS, or e-mail. See matrix-steam-bridge [documentation](https://github.com/jasonlaguidice/matrix-steam-bridge) for more information about how to configure the bridge.
|
||||
|
||||
To login, send `login [flow ID]` where possible flow IDs are `password` or `qr`
|
||||
|
||||
Once logged in, send `search [name]` to search through recognized Steam friends. You can send a user name, display name, or all forms of Steam ID. Send `start-chat [identifier]` to request the bridge bot to open a chat room with a user.
|
||||
|
||||
Chat rooms will automatically be opened as new messages are received.
|
||||
|
||||
Send `help` to the bot to see the available commands.
|
||||
@@ -27,26 +27,26 @@ When setting, replace `example.com` with your own.
|
||||
To enable Cinny, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
|
||||
```yaml
|
||||
cinny_enabled: true
|
||||
matrix_client_cinny_enabled: true
|
||||
```
|
||||
|
||||
### Adjusting the Cinny URL (optional)
|
||||
|
||||
By tweaking the `cinny_hostname` variable, you can easily make the service available at a **different hostname** than the default one.
|
||||
By tweaking the `matrix_client_cinny_hostname` variable, you can easily make the service available at a **different hostname** than the default one.
|
||||
|
||||
Example additional configuration for your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Switch to a different domain (`app.example.com`) than the default one (`cinny.example.com`)
|
||||
cinny_hostname: "app.{{ matrix_domain }}"
|
||||
matrix_client_cinny_hostname: "app.{{ matrix_domain }}"
|
||||
|
||||
# Expose under the /cinny subpath
|
||||
# cinny_path_prefix: /cinny
|
||||
# matrix_client_cinny_path_prefix: /cinny
|
||||
```
|
||||
|
||||
After changing the domain, **you may need to adjust your DNS** records to point the Cinny domain to the Matrix server.
|
||||
|
||||
**Note**: while there is a `cinny_path_prefix` variable for changing the path where Cinny is served, overriding it is [not possible](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. You'd need to serve Cinny at a dedicated subdomain.
|
||||
**Note**: while there is a `matrix_client_cinny_path_prefix` variable for changing the path where Cinny is served, overriding it is [not possible](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. You'd need to serve Cinny at a dedicated subdomain.
|
||||
|
||||
### Extending the configuration
|
||||
|
||||
@@ -54,8 +54,8 @@ There are some additional things you may wish to configure about the component.
|
||||
|
||||
Take a look at:
|
||||
|
||||
- `roles/galaxy/cinny/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
|
||||
- `roles/galaxy/cinny/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 `cinny_configuration_extension_json` variable
|
||||
- `roles/custom/matrix-client-cinny/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
|
||||
- `roles/custom/matrix-client-cinny/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_cinny_configuration_extension_json` variable
|
||||
|
||||
## Installing
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ FluffyChat Web is a cute cross-platform (web, iOS, Android) messenger for Matrix
|
||||
|
||||
💡 **Note**: the latest version of FluffyChat Web is also available on the web, hosted by 3rd parties. If you trust giving your credentials to the following 3rd party Single Page Application, you can consider using it from there:
|
||||
|
||||
- [fluffychat.im](https://fluffychat.im/web), hosted by the [FluffyChat](https://fluffy.chat/) developers
|
||||
- [fluffychat.im](https://fluffychat.im/web), hosted by the [FluffyChat](https://fluffychat.im/) developers
|
||||
|
||||
## Adjusting DNS records
|
||||
|
||||
|
||||
@@ -24,22 +24,22 @@ When setting, replace `example.com` with your own.
|
||||
To enable Hydrogen, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
|
||||
```yaml
|
||||
hydrogen_enabled: true
|
||||
matrix_client_hydrogen_enabled: true
|
||||
```
|
||||
|
||||
### Adjusting the Hydrogen URL (optional)
|
||||
|
||||
By tweaking the `hydrogen_hostname` and `hydrogen_path_prefix` variables, you can easily make the service available at a **different hostname and/or path** than the default one.
|
||||
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 `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Switch to the domain used for Matrix services (`matrix.example.com`),
|
||||
# so we won't need to add additional DNS records for Hydrogen.
|
||||
hydrogen_hostname: "{{ matrix_server_fqn_matrix }}"
|
||||
matrix_client_hydrogen_hostname: "{{ matrix_server_fqn_matrix }}"
|
||||
|
||||
# Expose under the /hydrogen subpath
|
||||
hydrogen_path_prefix: /hydrogen
|
||||
matrix_client_hydrogen_path_prefix: /hydrogen
|
||||
```
|
||||
|
||||
After changing the domain, **you may need to adjust your DNS** records to point the Hydrogen domain to the Matrix server.
|
||||
@@ -52,8 +52,8 @@ There are some additional things you may wish to configure about the client.
|
||||
|
||||
Take a look at:
|
||||
|
||||
- `roles/galaxy/hydrogen/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
|
||||
- `roles/galaxy/hydrogen/templates/config.json.j2` for the client's default configuration. You can override settings (even those that don't have dedicated playbook variables) using the `hydrogen_configuration_extension_json` variable
|
||||
- `roles/custom/matrix-client-hydrogen/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
|
||||
- `roles/custom/matrix-client-hydrogen/templates/config.json.j2` for the client's default configuration. You can override settings (even those that don't have dedicated playbook variables) using the `matrix_client_hydrogen_configuration_extension_json` variable
|
||||
|
||||
## Installing
|
||||
|
||||
|
||||
@@ -13,6 +13,8 @@ See the project's [documentation](https://docs.conduit.rs/) to learn what it doe
|
||||
|
||||
By default, the playbook installs [Synapse](https://github.com/element-hq/synapse) as it's the only full-featured Matrix server at the moment. If that's okay, you can skip this document.
|
||||
|
||||
💡 **Note**: The playbook also supports installing a (currently) faster-moving Conduit fork called [conduwuit](./configuring-playbook-conduwuit.md).
|
||||
|
||||
> [!WARNING]
|
||||
> - **You can't switch an existing Matrix server's implementation** (e.g. Synapse -> Conduit). Proceed below only if you're OK with losing data or you're dealing with a server on a new domain name, which hasn't participated in the Matrix federation yet.
|
||||
> - **Homeserver implementations other than Synapse may not be fully functional**. The playbook may also not assist you in an optimal way (like it does with Synapse). Make yourself familiar with the downsides before proceeding
|
||||
@@ -63,7 +65,6 @@ Find the `registration.yaml` in the `/matrix` directory, for example `/matrix/ma
|
||||
```
|
||||
as_token: <token>
|
||||
de.sorunome.msc2409.push_ephemeral: true
|
||||
receive_ephemeral: true
|
||||
hs_token: <token>
|
||||
id: signal
|
||||
namespaces:
|
||||
|
||||
@@ -1,45 +1,104 @@
|
||||
<!--
|
||||
SPDX-FileCopyrightText: 2019 Eduardo Beltrame
|
||||
SPDX-FileCopyrightText: 2019-2025 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2020 Tulir Asokan
|
||||
SPDX-FileCopyrightText: 2021, 2024 MDAD project contributors
|
||||
SPDX-FileCopyrightText: 2022 Dennis Ciba
|
||||
SPDX-FileCopyrightText: 2022 Vladimir Panteleev
|
||||
SPDX-FileCopyrightText: 2023 Justin Croonenberghs
|
||||
SPDX-FileCopyrightText: 2023 Kuba Orlik
|
||||
SPDX-FileCopyrightText: 2023 Pierre 'McFly' Marty
|
||||
SPDX-FileCopyrightText: 2023 Samuel Meenzen
|
||||
SPDX-FileCopyrightText: 2024 Fabio Bonelli
|
||||
SPDX-FileCopyrightText: 2024-2026 Suguru Hirahara
|
||||
SPDX-FileCopyrightText: 2025 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2025 Suguru Hirahara
|
||||
|
||||
SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
-->
|
||||
|
||||
# Configuring conduwuit (optional, removed)
|
||||
# Configuring conduwuit (optional)
|
||||
|
||||
🪦 The playbook used to be able to install and configure the [conduwuit](https://conduwuit.puppyirl.gay/) Matrix server, but no longer includes this component, as it's been abandoned and unmaintained.
|
||||
The playbook can install and configure the [conduwuit](https://conduwuit.puppyirl.gay/) Matrix server for you.
|
||||
|
||||
## Uninstalling the service manually
|
||||
See the project's [documentation](https://conduwuit.puppyirl.gay/) to learn what it does and why it might be useful to you.
|
||||
|
||||
If you still have conduwuit installed on your Matrix server, the playbook can no longer help you uninstall it and you will need to do it manually.
|
||||
By default, the playbook installs [Synapse](https://github.com/element-hq/synapse) as it's the only full-featured Matrix server at the moment. If that's okay, you can skip this document.
|
||||
|
||||
To uninstall the service, run the command below on the server:
|
||||
💡 **Note**: conduwuit is a fork of [Conduit](./configuring-playbook-conduit.md), which the playbook also supports. See [Differences from upstream Conduit](https://conduwuit.puppyirl.gay/differences.html).
|
||||
|
||||
```sh
|
||||
systemctl disable --now matrix-conduwuit.service
|
||||
> [!WARNING]
|
||||
> - **You can't switch an existing Matrix server's implementation** (e.g. Synapse -> conduwuit). Proceed below only if you're OK with losing data or you're dealing with a server on a new domain name, which hasn't participated in the Matrix federation yet.
|
||||
> - **Homeserver implementations other than Synapse may not be fully functional**. The playbook may also not assist you in an optimal way (like it does with Synapse). Make yourself familiar with the downsides before proceeding
|
||||
|
||||
## Adjusting the playbook configuration
|
||||
|
||||
To use conduwuit, you **generally** need to adjust the `matrix_homeserver_implementation: synapse` configuration on your `inventory/host_vars/matrix.example.com/vars.yml` file as below:
|
||||
|
||||
```yaml
|
||||
matrix_homeserver_implementation: conduwuit
|
||||
|
||||
# Registering users can only happen via the API,
|
||||
# so it makes sense to enable it, at least initially.
|
||||
matrix_conduwuit_config_allow_registration: true
|
||||
|
||||
# Generate a strong registration token to protect the registration endpoint from abuse.
|
||||
# You can create one with a command like `pwgen -s 64 1`.
|
||||
matrix_conduwuit_config_registration_token: ''
|
||||
```
|
||||
|
||||
## Migrating to Continuwuity
|
||||
### Extending the configuration
|
||||
|
||||
Since [Continuwuity](configuring-playbook-continuwuity.md) is a drop-in replacement for conduwuit, migration is possible. Please refer to [this section](./configuring-playbook-continuwuity.md#migrating-from-conduwuit) for details.
|
||||
There are some additional things you may wish to configure about the server.
|
||||
|
||||
## Removing data manually
|
||||
Take a look at:
|
||||
|
||||
If you are not going to migrate to [Continuwuity](configuring-playbook-continuwuity.md), you can remove data by running the command on the server:
|
||||
- `roles/custom/matrix-conduwuit/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
|
||||
- `roles/custom/matrix-conduwuit/templates/conduwuit.toml.j2` for the server's default configuration
|
||||
|
||||
```sh
|
||||
rm -rf /matrix/conduwuit
|
||||
There are various Ansible variables that control settings in the `conduwuit.toml` file.
|
||||
|
||||
If a specific setting you'd like to change does not have a dedicated Ansible variable, you can either submit a PR to us to add it, or you can [override the setting using an environment variable](https://conduwuit.puppyirl.gay/configuration.html#environment-variables) using `matrix_conduwuit_environment_variables_extension`. For example:
|
||||
|
||||
```yaml
|
||||
matrix_conduwuit_environment_variables_extension: |
|
||||
CONDUWUIT_MAX_REQUEST_SIZE=50000000
|
||||
CONDUWUIT_REQUEST_TIMEOUT=60
|
||||
```
|
||||
|
||||
>[!WARNING]
|
||||
> Once you removing the path, there is no going back. Your data on the homeserver (including chat history, rooms, etc.) will be deleted and not be possible to restore them. Please be certain.
|
||||
## Creating the first user account
|
||||
|
||||
Unlike other homeserver implementations (like Synapse and Dendrite), conduwuit does not support creating users via the command line or via the playbook.
|
||||
|
||||
If you followed the instructions above (see [Adjusting the playbook configuration](#adjusting-the-playbook-configuration)), you should have registration enabled and protected by a registration token.
|
||||
|
||||
This should allow you to create the first user account via any client (like [Element Web](./configuring-playbook-client-element-web.md)) which supports creating users.
|
||||
|
||||
The **first user account that you create will be marked as an admin** and **will be automatically invited to an admin room**.
|
||||
|
||||
|
||||
## Configuring bridges / appservices
|
||||
|
||||
For other homeserver implementations (like Synapse and Dendrite), the playbook automatically registers appservices (for bridges, bots, etc.) with the homeserver.
|
||||
|
||||
For conduwuit, you will have to manually register appservices using the [`!admin appservices register` command](https://conduwuit.puppyirl.gay/appservices.html#set-up-the-appservice---general-instructions) sent to the server bot account.
|
||||
|
||||
The server's bot account has a Matrix ID of `@conduit:example.com` (not `@conduwuit:example.com`!) due to conduwuit's historical legacy.
|
||||
Your first user account would already have been invited to an admin room with this bot.
|
||||
|
||||
Find the appservice file you'd like to register. This can be any `registration.yaml` file found in the `/matrix` directory, for example `/matrix/mautrix-signal/bridge/registration.yaml`.
|
||||
|
||||
Then, send its content to the existing admin room:
|
||||
|
||||
!admin appservices register
|
||||
|
||||
```
|
||||
as_token: <token>
|
||||
de.sorunome.msc2409.push_ephemeral: true
|
||||
hs_token: <token>
|
||||
id: signal
|
||||
namespaces:
|
||||
aliases:
|
||||
- exclusive: true
|
||||
regex: ^#signal_.+:example\.org$
|
||||
users:
|
||||
- exclusive: true
|
||||
regex: ^@signal_.+:example\.org$
|
||||
- exclusive: true
|
||||
regex: ^@signalbot:example\.org$
|
||||
rate_limited: false
|
||||
sender_localpart: _bot_signalbot
|
||||
url: http://matrix-mautrix-signal:29328
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-conduwuit`.
|
||||
|
||||
@@ -1,122 +0,0 @@
|
||||
<!--
|
||||
SPDX-FileCopyrightText: 2025 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2025 Suguru Hirahara
|
||||
|
||||
SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
-->
|
||||
|
||||
# Configuring Continuwuity (optional)
|
||||
|
||||
The playbook can install and configure the [Continuwuity](https://continuwuity.org) Matrix server for you.
|
||||
|
||||
See the project's [documentation](https://continuwuity.org) to learn what it does and why it might be useful to you.
|
||||
|
||||
By default, the playbook installs [Synapse](https://github.com/element-hq/synapse) as it's the only full-featured Matrix server at the moment. If that's okay, you can skip this document.
|
||||
|
||||
💡 **Note**: continuwuity is a fork of [conduwuit](./configuring-playbook-conduwuit.md), which the playbook has supported.
|
||||
|
||||
> [!WARNING]
|
||||
> - **You can't switch an existing Matrix server's implementation** (e.g. Synapse -> Continuwuity). Proceed below only if you're OK with losing data or you're dealing with a server on a new domain name, which hasn't participated in the Matrix federation yet.
|
||||
> - **Homeserver implementations other than Synapse may not be fully functional**. The playbook may also not assist you in an optimal way (like it does with Synapse). Make yourself familiar with the downsides before proceeding
|
||||
|
||||
## Adjusting the playbook configuration
|
||||
|
||||
To use Continuwuity, you **generally** need to adjust the `matrix_homeserver_implementation: synapse` configuration on your `inventory/host_vars/matrix.example.com/vars.yml` file as below:
|
||||
|
||||
```yaml
|
||||
matrix_homeserver_implementation: continuwuity
|
||||
|
||||
# Registering users can only happen via the API,
|
||||
# so it makes sense to enable it, at least initially.
|
||||
matrix_continuwuity_config_allow_registration: true
|
||||
|
||||
# Generate a strong registration token to protect the registration endpoint from abuse.
|
||||
# You can create one with a command like `pwgen -s 64 1`.
|
||||
matrix_continuwuity_config_registration_token: ''
|
||||
```
|
||||
|
||||
### Extending the configuration
|
||||
|
||||
There are some additional things you may wish to configure about the server.
|
||||
|
||||
Take a look at:
|
||||
|
||||
- `roles/custom/matrix-continuwuity/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
|
||||
- `roles/custom/matrix-continuwuity/templates/continuwuity.toml.j2` for the server's default configuration
|
||||
|
||||
There are various Ansible variables that control settings in the `continuwuity.toml` file.
|
||||
|
||||
If a specific setting you'd like to change does not have a dedicated Ansible variable, you can either submit a PR to us to add it, or you can [override the setting using an environment variable](https://continuwuity.org/configuration#environment-variables) using `matrix_continuwuity_environment_variables_extension`. For example:
|
||||
|
||||
```yaml
|
||||
matrix_continuwuity_environment_variables_extension: |
|
||||
CONTINUWUITY_MAX_REQUEST_SIZE=50000000
|
||||
CONTINUWUITY_REQUEST_TIMEOUT=60
|
||||
```
|
||||
|
||||
## Creating the first user account
|
||||
|
||||
Unlike other homeserver implementations (like Synapse and Dendrite), continuwuity does not support creating users via the command line or via the playbook.
|
||||
|
||||
On first startup, Continuwuity creates a special one-time-use registration token and logs it to the server's console. To access this, you will need to SSH into the server and run the following command:
|
||||
|
||||
```sh
|
||||
# Adjust the duration if necessary or remove the whole --since argument
|
||||
journalctl -u matrix-continuwuity.service --since="10 minutes ago"
|
||||
```
|
||||
|
||||
Find the token, highlight it, and copy it (ctrl+shift+C). This token should allow you to create the first user account via any client (like [Element Web](./configuring-playbook-client-element-web.md)) which supports creating users.
|
||||
|
||||
The **first user account that you create will be marked as an admin** and **will be automatically invited to an admin room**.
|
||||
|
||||
|
||||
## Configuring bridges / appservices
|
||||
|
||||
For other homeserver implementations (like Synapse and Dendrite), the playbook automatically registers appservices (for bridges, bots, etc.) with the homeserver.
|
||||
|
||||
For continuwuity, you will have to manually register appservices using the [`!admin appservices register` command](https://continuwuity.org/appservices.html#set-up-the-appservice---general-instructions) sent to the server bot account.
|
||||
|
||||
The server's bot account has a Matrix ID of `@conduit:example.com` (not `@continuwuity:example.com`!) due to continuwuity's historical legacy.
|
||||
Your first user account would already have been invited to an admin room with this bot.
|
||||
|
||||
Find the appservice file you'd like to register. This can be any `registration.yaml` file found in the `/matrix` directory, for example `/matrix/mautrix-signal/bridge/registration.yaml`.
|
||||
|
||||
Then, send its content to the existing admin room:
|
||||
|
||||
!admin appservices register
|
||||
|
||||
```
|
||||
as_token: <token>
|
||||
de.sorunome.msc2409.push_ephemeral: true
|
||||
receive_ephemeral: true
|
||||
hs_token: <token>
|
||||
id: signal
|
||||
namespaces:
|
||||
aliases:
|
||||
- exclusive: true
|
||||
regex: ^#signal_.+:example\.org$
|
||||
users:
|
||||
- exclusive: true
|
||||
regex: ^@signal_.+:example\.org$
|
||||
- exclusive: true
|
||||
regex: ^@signalbot:example\.org$
|
||||
rate_limited: false
|
||||
sender_localpart: _bot_signalbot
|
||||
url: http://matrix-mautrix-signal:29328
|
||||
```
|
||||
|
||||
## Migrating from conduwuit
|
||||
|
||||
Since Continuwuity is a drop-in replacement for [conduwuit](configuring-playbook-conduwuit.md), migration is possible.
|
||||
|
||||
1. Make sure that Continuwuity is properly set up on your `vars.yml` as described above
|
||||
|
||||
2. Make sure that Conduwuit references are removed from your `vars.yml` file
|
||||
|
||||
3. Run the installation in a way that installs new services and uninstalls old ones (e.g. `just setup-all`)
|
||||
|
||||
4. Run the playbook with the `continuwuity-migrate-from-conduwuit` tag (e.g. `just run-tags continuwuity-migrate-from-conduwuit`). This migrates data from `/matrix/conduwuit` to `/matrix/continuwuity`
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-continuwuity`.
|
||||
@@ -1,33 +1,144 @@
|
||||
<!--
|
||||
SPDX-FileCopyrightText: 2019 - 2024 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2019 - 2025 MDAD project contributors
|
||||
SPDX-FileCopyrightText: 2019 Edgars Voroboks
|
||||
SPDX-FileCopyrightText: 2019 Eduardo Beltrame
|
||||
SPDX-FileCopyrightText: 2019-2025 MDAD project contributors
|
||||
SPDX-FileCopyrightText: 2019-2025 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2020 Chris van Dijk
|
||||
SPDX-FileCopyrightText: 2020 Tulir Asokan
|
||||
SPDX-FileCopyrightText: 2020 jens quade
|
||||
SPDX-FileCopyrightText: 2022 Dennis Ciba
|
||||
SPDX-FileCopyrightText: 2022 Kim Brose
|
||||
SPDX-FileCopyrightText: 2022 Travis Ralston
|
||||
SPDX-FileCopyrightText: 2022 Vladimir Panteleev
|
||||
SPDX-FileCopyrightText: 2022 Yan Minagawa
|
||||
SPDX-FileCopyrightText: 2024-2026 Suguru Hirahara
|
||||
SPDX-FileCopyrightText: 2024 - 2025 Suguru Hirahara
|
||||
|
||||
SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
-->
|
||||
|
||||
# Setting up Dimension integration manager (optional, removed)
|
||||
# Setting up Dimension integration manager (optional, unmaintained)
|
||||
|
||||
🪦 The playbook used to be able to install and configure [Dimension](https://dimension.t2bot.io) integration manager, but no longer includes this component, as it has been unmaintained.
|
||||
**Notes**:
|
||||
- Dimension is **[officially unmaintained](https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/2806#issuecomment-1673559299)**. We recommend not bothering with installing it.
|
||||
- This playbook now supports running Dimension in both a federated and [unfederated](https://github.com/turt2live/matrix-dimension/blob/master/docs/unfederated.md) environments. This is handled automatically based on the value of `matrix_homeserver_federation_enabled`.
|
||||
|
||||
## Uninstalling the component manually
|
||||
The playbook can install and configure the [Dimension](https://dimension.t2bot.io) integration manager for you.
|
||||
|
||||
If you still have the Dimension integration manager installed on your Matrix server, the playbook can no longer help you uninstall it and you will need to do it manually. To uninstall manually, run these commands on the server:
|
||||
See the project's [documentation](https://github.com/turt2live/matrix-dimension/blob/master/README.md) to learn what it does and why it might be useful to you.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
### Open Matrix Federation port
|
||||
|
||||
Enabling the Dimension service will automatically reconfigure your Synapse homeserver to expose the `openid` API endpoints on the Matrix Federation port (usually `8448`), even if [federation](configuring-playbook-federation.md) is disabled. If you enable the component, make sure that the port is accessible.
|
||||
|
||||
### Install Matrix services
|
||||
|
||||
Dimension can only be installed after Matrix services are installed and running. If you're just installing Matrix services for the first time, please continue with the [Configuration](configuring-playbook.md) / [Installation](installing.md) and come back here later.
|
||||
|
||||
### Register a dedicated Matrix user (optional, recommended)
|
||||
|
||||
We recommend that you create a dedicated Matrix user for Dimension (`dimension` is a good username).
|
||||
|
||||
Generate a strong password for the user. You can create one with a command like `pwgen -s 64 1`.
|
||||
|
||||
You can use the playbook to [register a new user](registering-users.md):
|
||||
|
||||
```sh
|
||||
systemctl disable --now matrix-dimension.service
|
||||
|
||||
rm -rf /matrix/dimension
|
||||
|
||||
/matrix/postgres/bin/cli-non-interactive -c 'DROP DATABASE matrix_dimension;'
|
||||
ansible-playbook -i inventory/hosts setup.yml --extra-vars='username=dimension password=PASSWORD_FOR_THE_USER admin=no' --tags=register-user
|
||||
```
|
||||
|
||||
### Obtain an access token
|
||||
|
||||
Dimension requires an access token to be able to connect to your homeserver. Refer to the documentation on [how to obtain an access token](obtaining-access-tokens.md).
|
||||
|
||||
> [!WARNING]
|
||||
> Access tokens are sensitive information. Do not include them in any bug reports, messages, or logs. Do not share the access token with anyone.
|
||||
|
||||
## Adjusting DNS records
|
||||
|
||||
By default, this playbook installs Dimension on the `dimension.` subdomain (`dimension.example.com`) and requires you to create a CNAME record for `dimension`, which targets `matrix.example.com`.
|
||||
|
||||
When setting, replace `example.com` with your own.
|
||||
|
||||
## Adjusting the playbook configuration
|
||||
|
||||
To enable Dimension, 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).
|
||||
|
||||
```yaml
|
||||
matrix_dimension_enabled: true
|
||||
|
||||
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 `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_dimension_admins:
|
||||
- "@alice:{{ matrix_domain }}"
|
||||
- "@bob:{{ matrix_domain }}"
|
||||
```
|
||||
|
||||
The admin interface is accessible within Element Web by accessing it in any room and clicking the cog wheel/settings icon in the top right. Currently, Dimension can be opened in Element Web by the "Add widgets, bridges, & bots" link in the room information.
|
||||
|
||||
### Adjusting the Dimension URL (optional)
|
||||
|
||||
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 `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Switch to the domain used for Matrix services (`matrix.example.com`),
|
||||
# so we won't need to add additional DNS records for Dimension.
|
||||
matrix_dimension_hostname: "{{ matrix_server_fqn_matrix }}"
|
||||
|
||||
# Expose under the /dimension subpath
|
||||
# matrix_dimension_path_prefix: /dimension
|
||||
```
|
||||
|
||||
After changing the domain, **you may need to adjust your DNS** records to point the Dimension domain to the Matrix server.
|
||||
|
||||
If you've decided to reuse the `matrix.` domain, you won't need to do any extra DNS configuration.
|
||||
|
||||
**Note**: while there is a `matrix_dimension_path_prefix` variable for changing the path where Dimension is served, overriding it is not possible due to [this Dimension issue](https://github.com/turt2live/matrix-dimension/issues/510). You'd need to serve Dimension at a dedicated subdomain.
|
||||
|
||||
### Extending the configuration
|
||||
|
||||
There are some additional things you may wish to configure about the component.
|
||||
|
||||
Take a look at:
|
||||
|
||||
- `roles/custom/matrix-dimension/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
|
||||
- `roles/custom/matrix-dimension/templates/config.yaml.j2` for the component's default configuration. You can override settings (even those that don't have dedicated playbook variables) using the `matrix_dimension_configuration_extension_yaml` variable
|
||||
|
||||
You can find all configuration options on [GitHub page of Dimension project](https://github.com/turt2live/matrix-dimension/blob/master/config/default.yaml).
|
||||
|
||||
## Installing
|
||||
|
||||
After configuring the playbook and potentially [adjusting your DNS records](#adjusting-dns-records), run the playbook with [playbook tags](playbook-tags.md) as below:
|
||||
|
||||
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
|
||||
```sh
|
||||
ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
|
||||
```
|
||||
|
||||
**Notes**:
|
||||
|
||||
- The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
|
||||
|
||||
`just install-all` is useful for maintaining your setup quickly ([2x-5x faster](../CHANGELOG.md#2x-5x-performance-improvements-in-playbook-runtime) than `just setup-all`) when its components remain unchanged. If you adjust your `vars.yml` to remove other components, you'd need to run `just setup-all`, or these components will still remain installed. Note these shortcuts run the `ensure-matrix-users-created` tag too.
|
||||
|
||||
## Usage
|
||||
|
||||
After Dimension has been installed you may need to log out and log back in for it to pick up the new integration manager. Then you can access integrations in Element Web by opening a room, clicking the room info button (`i`) on the top right corner, and then clicking the "Add widgets, bridges, & bots" link.
|
||||
|
||||
### Set up a Jitsi widget
|
||||
|
||||
By default Dimension will use [jitsi.riot.im](https://jitsi.riot.im/) as the `conferenceDomain` of [Jitsi](https://jitsi.org/) audio/video conference widgets. For users running [a self-hosted Jitsi instance](configuring-playbook-jitsi.md), you will likely want the widget to use your own Jitsi instance.
|
||||
|
||||
To set up the widget, an admin user needs to configure the domain via the admin UI once Dimension is running. In Element Web, go to *Manage Integrations* → *Settings* → *Widgets* → *Jitsi Conference Settings* and set *Jitsi Domain* and *Jitsi Script URL* appropriately.
|
||||
|
||||
There is unfortunately no way to configure the widget via the playbook. See [this issue](https://github.com/turt2live/matrix-dimension/issues/345) for details.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-dimension`.
|
||||
|
||||
@@ -1,20 +1,7 @@
|
||||
<!--
|
||||
SPDX-FileCopyrightText: 2020 Aaron Raimist
|
||||
SPDX-FileCopyrightText: 2020 Chris van Dijk
|
||||
SPDX-FileCopyrightText: 2020 Dominik Zajac
|
||||
SPDX-FileCopyrightText: 2020 Mickaël Cornière
|
||||
SPDX-FileCopyrightText: 2020 Scott Crossen
|
||||
SPDX-FileCopyrightText: 2020-2024 MDAD project contributors
|
||||
SPDX-FileCopyrightText: 2020-2024 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2022 François Darveau
|
||||
SPDX-FileCopyrightText: 2022 Julian Foad
|
||||
SPDX-FileCopyrightText: 2022 Warren Bailey
|
||||
SPDX-FileCopyrightText: 2023 Antonis Christofides
|
||||
SPDX-FileCopyrightText: 2023 Felix Stupp
|
||||
SPDX-FileCopyrightText: 2023 Julian-Samuel Gebühr
|
||||
SPDX-FileCopyrightText: 2023 Pierre 'McFly' Marty
|
||||
SPDX-FileCopyrightText: 2024 Tiz
|
||||
SPDX-FileCopyrightText: 2024-2026 Suguru Hirahara
|
||||
SPDX-FileCopyrightText: 2020 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2024 - 2025 Suguru Hirahara
|
||||
|
||||
SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
-->
|
||||
@@ -25,10 +12,6 @@ The playbook can configure Dynamic DNS with [ddclient](https://github.com/ddc
|
||||
|
||||
Most cloud providers / ISPs will charge you extra for a static IP address. If you're not hosting a highly reliable homeserver you can workaround this via dynamic DNS.
|
||||
|
||||
For details about configuring the [Ansible role for ddclient](https://github.com/mother-of-all-self-hosting/ansible-role-ddclient), you can check them via:
|
||||
- 🌐 [the role's documentation](https://github.com/mother-of-all-self-hosting/ansible-role-ddclient/blob/main/docs/configuring-ddclient.md) online
|
||||
- 📁 `roles/galaxy/ddclient/docs/configuring-ddclient.md` locally, if you have [fetched the Ansible roles](../installing.md)
|
||||
|
||||
## Prerequisite
|
||||
|
||||
You'll need to authenticate with your DNS provider somehow, in most cases this is simply a username and password but can differ from provider to provider. Please consult with your providers documentation and the upstream [ddclient documentation](https://github.com/ddclient/ddclient/blob/main/ddclient.conf.in) to determine what you'll need to provide to authenticate.
|
||||
@@ -38,23 +21,17 @@ You'll need to authenticate with your DNS provider somehow, in most cases this i
|
||||
To enable dynamic DNS, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
|
||||
```yaml
|
||||
ddclient_enabled: true
|
||||
matrix_dynamic_dns_enabled: true
|
||||
|
||||
ddclient_domain_configurations:
|
||||
matrix_dynamic_dns_domain_configurations:
|
||||
- provider: example.net
|
||||
protocol: dyndns2
|
||||
protocol: dyndn2
|
||||
username: YOUR_USERNAME_HERE
|
||||
password: YOUR_PASSWORD_HERE
|
||||
domain: "{{ matrix_domain }}"
|
||||
```
|
||||
|
||||
Keep in mind that certain providers may require a different configuration of the `ddclient_domain_configurations` variable, for provider specific examples see the [upstream documentation](https://github.com/ddclient/ddclient/blob/main/ddclient.conf.in).
|
||||
|
||||
### Configuring the endpoint to obtain IP address (optional)
|
||||
|
||||
The playbook sets the default endpoint for obtaining the IP address to `https://cloudflare.com/cdn-cgi/trace`. You can replace it by specifying yours to `ddclient_web` and `ddclient_web_skip` if necessary.
|
||||
|
||||
Refer to [this section](https://github.com/mother-of-all-self-hosting/ansible-role-ddclient/blob/main/docs/configuring-ddclient.md#setting-the-endpoint-to-obtain-ip-address-optional) for more information.
|
||||
Keep in mind that certain providers may require a different configuration of the `matrix_dynamic_dns_domain_configurations` variable, for provider specific examples see the [upstream documentation](https://github.com/ddclient/ddclient/blob/main/ddclient.conf.in).
|
||||
|
||||
### Extending the configuration
|
||||
|
||||
@@ -62,7 +39,7 @@ There are some additional things you may wish to configure about the component.
|
||||
|
||||
Take a look at:
|
||||
|
||||
- `roles/galaxy/ddclient/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
|
||||
- `roles/custom/matrix-dynamic-dns/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
|
||||
|
||||
## Installing
|
||||
|
||||
@@ -86,4 +63,4 @@ Additional resources:
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
See [this section](https://github.com/mother-of-all-self-hosting/ansible-role-ddclient/blob/main/docs/configuring-ddclient.md#troubleshooting) on the role's documentation for details.
|
||||
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-dynamic-dns`. However, due to an [upstream issue](https://github.com/linuxserver/docker-ddclient/issues/54#issuecomment-1153143132) the logging output is not always complete. For advanced debugging purposes running the `ddclient` tool outside of the container is useful via the following: `ddclient -file ./ddclient.conf -daemon=0 -debug -verbose -noquiet`.
|
||||
|
||||
@@ -1,67 +0,0 @@
|
||||
<!--
|
||||
SPDX-FileCopyrightText: 2024 wjbeckett
|
||||
SPDX-FileCopyrightText: 2024 - 2025 Slavi Pantaleev
|
||||
|
||||
SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
-->
|
||||
|
||||
# Setting up Element Admin (optional)
|
||||
|
||||
The playbook can install and configure [Element Admin](https://github.com/element-hq/element-admin) for you.
|
||||
|
||||
Element Admin is a web-based administration panel for Synapse and [Matrix Authentication Service](./configuring-playbook-matrix-authentication-service.md).
|
||||
|
||||
See the project's [documentation](https://github.com/element-hq/element-admin) to learn more.
|
||||
|
||||
💡 **Note**: This project is still very young and doesn't have many features. For now, it's recommended to use [Synapse Admin](./configuring-playbook-synapse-admin.md) instead. Deployments that use [Matrix Authentication Service](./configuring-playbook-matrix-authentication-service.md) can use Element Admin for user-management (something that Synapse Admin can't do), while continuing to use Synapse Admin for all other purposes.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- A [Synapse](configuring-playbook-synapse.md) homeserver with its Admin API enabled (the playbook automatically enables it for you when you enable Element Admin)
|
||||
- [Matrix Authentication Service](./configuring-playbook-matrix-authentication-service.md) with its Admin API enabled (the playbook automatically enables it for you when you enable Element Admin)
|
||||
|
||||
## Decide on a domain and path
|
||||
|
||||
By default, the Element Admin is configured to be served on the `admin.element.example.com` domain.
|
||||
|
||||
If you'd like to run Element Admin on another hostname, see the [Adjusting the Element Admin URL](#adjusting-the-element-admin-url-optional) section below.
|
||||
|
||||
## Adjusting DNS records (optional)
|
||||
|
||||
By default, this playbook installs Element Admin on the `admin.element.` subdomain (`admin.element.example.com`) and requires you to create a `CNAME` record for `admin.element`, which targets `matrix.example.com`.
|
||||
|
||||
When setting these values, replace `example.com` with your own.
|
||||
|
||||
## Adjusting the playbook configuration
|
||||
|
||||
Add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_element_admin_enabled: true
|
||||
```
|
||||
|
||||
### Adjusting the Element Admin URL (optional)
|
||||
|
||||
By tweaking the `matrix_element_admin_hostname` variable, you can easily make the service available at a **different hostname** than the default one.
|
||||
|
||||
Example additional configuration for your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_element_admin_hostname: element-admin.example.com
|
||||
```
|
||||
|
||||
> [!WARNING]
|
||||
> A `matrix_element_admin_path_prefix` variable is also available and mean to let you configure a path prefix for the Element Admin service, but **Element Admin does not support running under a sub-path yet**.
|
||||
|
||||
## Installing
|
||||
|
||||
After configuring the playbook and potentially [adjusting your DNS records](#adjusting-dns-records), run the playbook with [playbook tags](playbook-tags.md) as below:
|
||||
|
||||
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
|
||||
```sh
|
||||
ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
|
||||
```
|
||||
|
||||
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
|
||||
|
||||
`just install-all` is useful for maintaining your setup quickly ([2x-5x faster](../CHANGELOG.md#2x-5x-performance-improvements-in-playbook-runtime) than `just setup-all`) when its components remain unchanged. If you adjust your `vars.yml` to remove other components, you'd need to run `just setup-all`, or these components will still remain installed. Note these shortcuts run the `ensure-matrix-users-created` tag too.
|
||||
@@ -16,9 +16,8 @@ See the project's [documentation](https://github.com/element-hq/element-call) to
|
||||
## Prerequisites
|
||||
|
||||
- A [Synapse](configuring-playbook-synapse.md) homeserver (see the warning below)
|
||||
- The [Matrix RTC (Real-Time Communication) stack](configuring-playbook-matrix-rtc.md) (automatically done when Element Call is enabled)
|
||||
- The [Matrix RTC (Real-Time Communication) stack](configuring-playbook-matrix-rtc.md)
|
||||
- A client compatible with Element Call. As of 2025-03-15, that's just [Element Web](configuring-playbook-client-element-web.md) and the Element X mobile clients (iOS and Android).
|
||||
- (Optional) Guest accounts being enabled for your Matrix server, if you'd like guests to be able to use Element Call. See [Allowing guests to use Element Call](#allowing-guests-to-use-element-call-optional)
|
||||
|
||||
> [!WARNING]
|
||||
> Because Element Call [requires](https://github.com/element-hq/element-call/blob/93ae2aed9841e0b066d515c56bd4c122d2b591b2/docs/self-hosting.md#a-matrix-homeserver) a few experimental features in the Matrix protocol, it's **very likely that it only works with the Synapse homeserver**.
|
||||
@@ -28,9 +27,9 @@ See the project's [documentation](https://github.com/element-hq/element-call) to
|
||||
All clients that can currently use Element Call (Element Web and Element X on mobile) already embed the Element Call frontend within them.
|
||||
These **clients will use their own embedded Element Call frontend**, so **self-hosting the Element Call frontend by the playbook is largely unnecessary**.
|
||||
|
||||
💡 A reason you may wish to continue installing the Element Call frontend (despite Matrix clients not making use of it), is if you need to use it standalone - directly via a browser (without a Matrix client). Note that unless you [allow guest accounts to use Element Call](#allowing-guests-to-use-element-call-optional), you will still need a Matrix user account **on the same homeserver** to be able to use Element Call.
|
||||
💡 A reason you may wish to continue installing the Element Call frontend (despite Matrix clients not making use of it), is if you need to use it standalone - directly via a browser (without a Matrix client).
|
||||
|
||||
The playbook makes a distinction between enabling Element Call (`matrix_element_call_enabled`) and enabling the Matrix RTC Stack (`matrix_rtc_enabled`). Enabling Element Call automatically enables the Matrix RTC stack. Because installing the Element Call frontend is now unnecessary, **we recommend only installing the Matrix RTC stack, without the Element Call frontend**.
|
||||
The playbook makes a distiction between enabling Element Call (`matrix_element_call_enabled`) and enabling the Matrix RTC Stack (`matrix_rtc_enabled`). Enabling Element Call automatically enables the Matrix RTC stack. Because installing the Element Call frontend is now unnecessary, **we recommend only installing the Matrix RTC stack, without the Element Call frontend**.
|
||||
|
||||
| Description / Variable | Element Call frontend | [LiveKit Server](configuring-playbook-livekit-server.md) | [LiveKit JWT Service](configuring-playbook-livekit-jwt-service.md) |
|
||||
|------------------------|-----------------------|----------------|---------------------|
|
||||
@@ -82,28 +81,6 @@ matrix_element_call_hostname: element-call.example.com
|
||||
> [!WARNING]
|
||||
> A `matrix_element_call_path_prefix` variable is also available and mean to let you configure a path prefix for the Element Call service, but [Element Call does not support running under a sub-path yet](https://github.com/element-hq/element-call/issues/3084).
|
||||
|
||||
### Allowing guests to use Element Call (optional)
|
||||
|
||||
By default, Element Call can only be used by people having accounts on your Matrix server.
|
||||
|
||||
If you'd like guests to be able to use Element Call as well, you need to enable guest accounts support for your homeserver.
|
||||
|
||||
> [!WARNING]
|
||||
> Enabling guest accounts means that your homeserver's user database may get polluted with guest account signups (potentially made by bots).
|
||||
> Guest accounts should be limited in what (damage) they can do to your server and the rest of the Matrix ecosystem, but it's better to not enable them unless necessary.
|
||||
|
||||
For [Synapse](configuring-playbook-synapse.md) (the default homeserver implementation), the configuration is like this:
|
||||
|
||||
```yml
|
||||
matrix_synapse_allow_guest_access: true
|
||||
```
|
||||
|
||||
For [Dendrite](configuring-playbook-dendrite.md), the configuration is like this:
|
||||
|
||||
```yml
|
||||
matrix_dendrite_guests_disabled: false
|
||||
```
|
||||
|
||||
## Installing
|
||||
|
||||
After configuring the playbook and potentially [adjusting your DNS records](#adjusting-dns-records) and [adjusting firewall rules](#adjusting-firewall-rules), run the playbook with [playbook tags](playbook-tags.md) as below:
|
||||
|
||||
@@ -17,16 +17,6 @@ The [Ansible role for exim-relay](https://github.com/mother-of-all-self-hosting/
|
||||
- 🌐 [the role's documentation at the MASH project](https://github.com/mother-of-all-self-hosting/ansible-role-exim-relay/blob/main/docs/configuring-exim-relay.md) online
|
||||
- 📁 `roles/galaxy/exim_relay/docs/configuring-exim-relay.md` locally, if you have [fetched the Ansible roles](installing.md#update-ansible-roles)
|
||||
|
||||
## Why use exim-relay?
|
||||
|
||||
**Benefits of using exim-relay** instead of configuring SMTP directly in each service:
|
||||
|
||||
1. **Final delivery capability**: Can deliver emails directly if you don't have an SMTP server
|
||||
|
||||
2. **Centralized configuration**: Configure your upstream SMTP server once in exim-relay, then point all services ([Synapse](configuring-playbook-synapse.md), [Matrix Authentication Service](configuring-playbook-matrix-authentication-service.md), etc.) there—no need to configure SMTP in each component
|
||||
|
||||
3. **Local spooling**: Stores messages locally and retries delivery if your upstream SMTP server is temporarily unavailable
|
||||
|
||||
## Firewall settings
|
||||
|
||||
No matter whether you send email directly (the default) or you relay email through another host, you'll probably need to allow outgoing traffic for TCP ports 25/587 (depending on configuration).
|
||||
|
||||
@@ -44,7 +44,7 @@ matrix_homeserver_federation_enabled: false
|
||||
|
||||
With that, your server's users will only be able to talk among themselves, but not to anyone who is on another server.
|
||||
|
||||
**Disabling federation does not necessarily disable the federation port** (`8448`). Even if you disable federation and only if necessary, we may still be exposing the federation port and serving the `openid` APIs there. To override this and completely disable Synapse's federation port use:
|
||||
**Disabling federation does not necessarily disable the federation port** (`8448`). Services like [Dimension](configuring-playbook-dimension.md) and [ma1sd](configuring-playbook-ma1sd.md) normally rely on `openid` APIs exposed on that port. Even if you disable federation and only if necessary, we may still be exposing the federation port and serving the `openid` APIs there. To override this and completely disable Synapse's federation port use:
|
||||
|
||||
```yaml
|
||||
matrix_homeserver_federation_enabled: false
|
||||
|
||||
@@ -18,9 +18,6 @@ SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
|
||||
The playbook can install and configure the [Jitsi](https://jitsi.org/) video-conferencing platform for you.
|
||||
|
||||
Because Jitsi still requires a TURN server, enabling Jitsi
|
||||
automatically enables coturn (`coturn_enabled: true`) unless you explicitly disable it.
|
||||
|
||||
Jitsi is an open source video-conferencing platform. It can not only be integrated with Element clients ([Element Web](configuring-playbook-client-element-web.md)/Desktop, Android and iOS) as a widget, but also be used as standalone web app.
|
||||
|
||||
💡 If you're into experimental technology, you may also be interested in trying out [Element Call](configuring-playbook-element-call.md) - a native Matrix video conferencing application.
|
||||
@@ -73,7 +70,7 @@ By default the Jitsi Meet instance **does not require for anyone to log in, and
|
||||
|
||||
If you would like to control who is allowed to start meetings on your instance, you'd need to enable Jitsi's authentication and optionally guests mode.
|
||||
|
||||
See [this section](https://github.com/mother-of-all-self-hosting/ansible-role-jitsi/blob/main/docs/configuring-jitsi.md#configure-jitsi-authentication-and-guests-mode-optional) on the role's documentation for details about how to configure the authentication and guests mode. The recommended authentication method is `internal` as it also works in federated rooms. If you want to enable authentication with Matrix OpenID making use of [Matrix User Verification Service (UVS)](configuring-playbook-user-verification-service.md), see [here](https://github.com/mother-of-all-self-hosting/ansible-role-jitsi/blob/main/docs/configuring-jitsi.md#authenticate-using-matrix-openid-auth-type-matrix) for details about how to set it up.
|
||||
See [this section](https://github.com/mother-of-all-self-hosting/ansible-role-jitsi/blob/main/docs/configuring-jitsi.md#configure-jitsi-authentication-and-guests-mode-optional) on the role's documentation for details about how to configure the authentication and guests mode. The recommended authentication method is `internal` as it also works in federated rooms. If you want to enable authentication with Matrix OpenID making use of [Matrix User Verification Service (UVS)](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/master/docs/configuring-playbook-user-verification-service.md), see [here](https://github.com/mother-of-all-self-hosting/ansible-role-jitsi/blob/main/docs/configuring-jitsi.md#authenticate-using-matrix-openid-auth-type-matrix) for details about how to set it up.
|
||||
|
||||
### Enable Gravatar (optional)
|
||||
|
||||
|
||||
@@ -15,4 +15,4 @@ This is a helper component which is part of the [Matrix RTC stack](configuring-p
|
||||
Take a look at:
|
||||
|
||||
- `roles/custom/matrix-livekit-jwt-service/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
|
||||
- `roles/custom/matrix-livekit-jwt-service/templates/env.j2` for the component's default configuration.
|
||||
- `roles/custom/matrix-livekit-jwt-service/templates/env.j2` for the component's default configuration.
|
||||
@@ -31,39 +31,8 @@ To ensure LiveKit Server functions correctly, the following firewall rules and p
|
||||
|
||||
💡 The suggestions above are inspired by the upstream [Ports and Firewall](https://docs.livekit.io/home/self-hosting/ports-firewall/) documentation based on how LiveKit is configured in the playbook. If you've using custom configuration for the LiveKit Server role, you may need to adjust the firewall rules accordingly.
|
||||
|
||||
## TURN TLS handling
|
||||
|
||||
When `matrix_playbook_reverse_proxy_type` is `playbook-managed-traefik` (which is the default for this playbook), TURN over TCP is terminated by Traefik and forwarded to LiveKit with `turn.external_tls = true`. In this playbook default, this mode is enabled automatically when SSL is enabled and TURN is enabled.
|
||||
|
||||
- The playbook installs a dedicated Traefik TCP entrypoint for TURN (`matrix-livekit-turn`) by default and binds it to `tcp/5350`.
|
||||
- `livekit_server_config_turn_external_tls` is automatically enabled for this setup.
|
||||
- Because Traefik handles TLS, LiveKit no longer needs certificate-file paths for TURN in this mode.
|
||||
|
||||
To opt out and keep TURN TLS termination in LiveKit itself, set:
|
||||
|
||||
```yml
|
||||
livekit_server_config_turn_external_tls: false
|
||||
```
|
||||
|
||||
In this playbook, certificate paths are managed automatically via `group_vars/matrix_servers` when certificate dumping is enabled.
|
||||
|
||||
If your setup uses `other-traefik-container` or [another reverse-proxy](./configuring-playbook-own-webserver.md), behavior is unchanged by default and still relies on certificates being available inside the container as before.
|
||||
|
||||
Deployments using `other-traefik-container` can opt into the same Traefik-terminated mode there, by setting:
|
||||
|
||||
```yml
|
||||
livekit_server_config_turn_external_tls: true
|
||||
livekit_server_container_labels_turn_traefik_enabled: true
|
||||
livekit_server_container_labels_turn_traefik_entrypoints: "<your-livekit-turn-traffic-entrypoint>"
|
||||
```
|
||||
|
||||
and configuring their own Traefik TCP entrypoint dedicated to LiveKit TURN traffic.
|
||||
|
||||
## Limitations
|
||||
|
||||
LiveKit Server's TURN listener behavior depends on where TLS is terminated:
|
||||
For some reason, LiveKit Server's TURN ports (`3479/udp` and `5350/tcp`) are not reachable over IPv6 regardless of whether you've [enabled IPv6](./configuring-ipv6.md) for your server.
|
||||
|
||||
- Direct LiveKit TURN listeners (`livekit_server_config_turn_external_tls: false`) still use IPv4-only sockets for `3479/udp` and `5350/tcp`, so IPv6 connectivity to these endpoints is not possible.
|
||||
- With [TURN TLS handling](#turn-tls-handling) (`livekit_server_config_turn_external_tls: true`), the playbook's dedicated `matrix-livekit-turn` TCP entrypoint can still listen on both IPv4 and IPv6. Traefik then forwards TURN/TCP to LiveKit.
|
||||
|
||||
It appears that LiveKit Server intentionally only listens on `udp4` and `tcp4` in direct mode, as seen [here](https://github.com/livekit/livekit/blob/154b4d26b769c68a03c096124094b97bf61a996f/pkg/service/turn.go#L128) and [here](https://github.com/livekit/livekit/blob/154b4d26b769c68a03c096124094b97bf61a996f/pkg/service/turn.go#L92).
|
||||
It seems like LiveKit Server intentionally only listens on `udp4` and `tcp4` as seen [here](https://github.com/livekit/livekit/blob/154b4d26b769c68a03c096124094b97bf61a996f/pkg/service/turn.go#L128) and [here](https://github.com/livekit/livekit/blob/154b4d26b769c68a03c096124094b97bf61a996f/pkg/service/turn.go#L92).
|
||||
@@ -1,37 +1,176 @@
|
||||
<!--
|
||||
SPDX-FileCopyrightText: 2018-2025 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2019 Eduardo Beltrame
|
||||
SPDX-FileCopyrightText: 2018 - 2024 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2019 - 2020 MDAD project contributors
|
||||
SPDX-FileCopyrightText: 2019 Noah Fleischmann
|
||||
SPDX-FileCopyrightText: 2019-2022, 2024 MDAD project contributors
|
||||
SPDX-FileCopyrightText: 2020 Hugues Morisset
|
||||
SPDX-FileCopyrightText: 2020 Justin Croonenberghs
|
||||
SPDX-FileCopyrightText: 2020 Marcel Partap
|
||||
SPDX-FileCopyrightText: 2020 Tulir Asokan
|
||||
SPDX-FileCopyrightText: 2020, 2023 Justin Croonenberghs
|
||||
SPDX-FileCopyrightText: 2022 Dennis Ciba
|
||||
SPDX-FileCopyrightText: 2022 Vladimir Panteleev
|
||||
SPDX-FileCopyrightText: 2023 Kuba Orlik
|
||||
SPDX-FileCopyrightText: 2023 Pierre 'McFly' Marty
|
||||
SPDX-FileCopyrightText: 2023 Samuel Meenzen
|
||||
SPDX-FileCopyrightText: 2024 Fabio Bonelli
|
||||
SPDX-FileCopyrightText: 2024-2026 Suguru Hirahara
|
||||
SPDX-FileCopyrightText: 2024 - 2025 Suguru Hirahara
|
||||
|
||||
SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
-->
|
||||
|
||||
# Setting up ma1sd Identity Server (optional, removed)
|
||||
# Setting up ma1sd Identity Server (optional)
|
||||
|
||||
🪦 The playbook used to be able to install and configure the [ma1sd](https://github.com/ma1uta/ma1sd) Identity Server, but no longer includes this component, as it has been unmaintained for a long time.
|
||||
> [!WARNING]
|
||||
> Since ma1sd has been unmaintained for years (the latest commit and release being from 2021) and the future of identity server's role in the Matrix specification is uncertain, **we recommend not bothering with installing it unless it's the only way you can do what you need to do**.
|
||||
>
|
||||
> Please note that certain things can be achieved with other components. For example, if you wish to implement LDAP integration, you might as well check out [the LDAP provider module for Synapse](./configuring-playbook-ldap-auth.md) instead.
|
||||
|
||||
Please note that some of the functions can be achieved with other components. For example, if you wish to implement LDAP integration, you might as well check out [the LDAP provider module for Synapse](./configuring-playbook-ldap-auth.md) instead.
|
||||
The playbook can configure the [ma1sd](https://github.com/ma1uta/ma1sd) Identity Server for you. It is a fork of [mxisd](https://github.com/kamax-io/mxisd) which was pronounced end of life 2019-06-21.
|
||||
|
||||
## Uninstalling the component manually
|
||||
ma1sd is used for 3PIDs (3rd party identifiers like E-mail and phone numbers) and some [enhanced features](https://github.com/ma1uta/ma1sd/#features). It is private by default, potentially at the expense of user discoverability.
|
||||
|
||||
If you still have the ma1sd Identity Server installed on your Matrix server, the playbook can no longer help you uninstall it and you will need to do it manually. To uninstall manually, run these commands on the server:
|
||||
See the project's [documentation](https://github.com/ma1uta/ma1sd/blob/master/README.md) to learn what it does and why it might be useful to you.
|
||||
|
||||
```sh
|
||||
systemctl disable --now matrix-ma1sd.service
|
||||
## Prerequisites
|
||||
|
||||
rm -rf /matrix/ma1sd
|
||||
### Open Matrix Federation port
|
||||
|
||||
/matrix/postgres/bin/cli-non-interactive 'DROP DATABASE matrix_ma1sd;'
|
||||
Enabling the ma1sd service will automatically reconfigure your Synapse homeserver to expose the `openid` API endpoints on the Matrix Federation port (usually `8448`), even if [federation](configuring-playbook-federation.md) is disabled. If you enable the component, make sure that the port is accessible.
|
||||
|
||||
## Adjusting DNS records
|
||||
|
||||
To make the ma1sd Identity Server enable its federation features, set up a SRV record that looks like this:
|
||||
|
||||
- Name: `_matrix-identity._tcp` (use this text as-is)
|
||||
- Content: `10 0 443 matrix.example.com` (replace `example.com` with your own)
|
||||
|
||||
See [ma1sd's documentation](https://github.com/ma1uta/ma1sd/wiki/mxisd-and-your-privacy#choices-are-never-easy) for information on the privacy implications of setting up this SRV record.
|
||||
|
||||
When setting up a SRV record, if you are asked for a service and protocol instead of a hostname split the host value from the table where the period is. For example use service as `_matrix-identity` and protocol as `_tcp`.
|
||||
|
||||
**Note**: This `_matrix-identity._tcp` SRV record for the identity server is different from the `_matrix._tcp` that can be used for Synapse delegation. See [howto-server-delegation.md](howto-server-delegation.md) for more information about delegation.
|
||||
|
||||
## Adjusting the playbook configuration
|
||||
|
||||
To enable ma1sd, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_ma1sd_enabled: true
|
||||
```
|
||||
|
||||
### Matrix.org lookup forwarding
|
||||
|
||||
To ensure maximum discovery, you can make your identity server also forward lookups to the central matrix.org Identity server (at the cost of potentially leaking all your contacts information).
|
||||
|
||||
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 `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_ma1sd_matrixorg_forwarding_enabled: true
|
||||
```
|
||||
|
||||
### Extending the configuration
|
||||
|
||||
There are some additional things you may wish to configure about the component.
|
||||
|
||||
Take a look at:
|
||||
|
||||
- `roles/custom/matrix-ma1sd/defaults/main.yml` for some variables that you can customize via your `vars.yml` file. You can override settings (even those that don't have dedicated playbook variables) using the `matrix_ma1sd_configuration_extension_yaml` variable
|
||||
|
||||
You can refer to the [ma1sd website](https://github.com/ma1uta/ma1sd) for more details and configuration options.
|
||||
|
||||
#### Customizing email templates
|
||||
|
||||
If you'd like to change the default email templates used by ma1sd, take a look at the `matrix_ma1sd_threepid_medium_email_custom_` variables (in the `roles/custom/matrix-ma1sd/defaults/main.yml` file.
|
||||
|
||||
#### ma1sd-controlled Registration
|
||||
|
||||
To use the [Registration](https://github.com/ma1uta/ma1sd/blob/master/docs/features/registration.md) feature of ma1sd, you can make use of the following variables:
|
||||
|
||||
- `matrix_synapse_enable_registration` — to enable user-initiated registration in Synapse
|
||||
|
||||
- `matrix_synapse_enable_registration_captcha` — to validate registering users using reCAPTCHA, as described in the [enabling reCAPTCHA](configuring-captcha.md) documentation.
|
||||
|
||||
- `matrix_synapse_registrations_require_3pid` — a list of 3pid types (among `'email'`, `'msisdn'`) required by the Synapse server for registering
|
||||
|
||||
- variables prefixed with `matrix_ma1sd_container_labels_` (e.g. `matrix_ma1sd_container_labels_matrix_client_3pid_registration_enabled`) — to configure the Traefik reverse-proxy to capture and send registration requests to ma1sd (instead of Synapse), so it can apply its additional functionality
|
||||
|
||||
- `matrix_ma1sd_configuration_extension_yaml` — to configure ma1sd as required. See the [Registration feature's docs](https://github.com/ma1uta/ma1sd/blob/master/docs/features/registration.md) for inspiration. Also see the [Additional features](#additional-features) section below to learn more about how to use `matrix_ma1sd_configuration_extension_yaml`.
|
||||
|
||||
**Note**: For this to work, either the homeserver needs to [federate](configuring-playbook-federation.md) or the `openid` APIs need to exposed on the federation port. When federation is disabled and ma1sd is enabled, we automatically expose the `openid` APIs (only!) on the federation port. Make sure the federation port (usually `https://matrix.example.com:8448`) is whitelisted in your firewall (even if you don't actually use/need federation).
|
||||
|
||||
#### Authentication
|
||||
|
||||
[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 `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_synapse_ext_password_provider_rest_auth_enabled: true
|
||||
|
||||
# matrix-ma1sd is the hostname of the ma1sd Docker container
|
||||
matrix_synapse_ext_password_provider_rest_auth_endpoint: "http://matrix-ma1sd:8090"
|
||||
|
||||
matrix_ma1sd_configuration_extension_yaml: |
|
||||
ldap:
|
||||
enabled: true
|
||||
connection:
|
||||
host: ldapHostnameOrIp
|
||||
tls: false
|
||||
port: 389
|
||||
baseDNs: ['OU=Users,DC=example,DC=org']
|
||||
bindDn: CN=My ma1sd User,OU=Users,DC=example,DC=org
|
||||
bindPassword: TheUserPassword
|
||||
```
|
||||
|
||||
#### Example: SMS verification
|
||||
|
||||
If your use case requires mobile verification, it is quite simple to integrate ma1sd with [Twilio](https://www.twilio.com/), an online telephony services gateway. Their prices are reasonable for low-volume projects and integration can be done with the following configuration:
|
||||
|
||||
```yaml
|
||||
matrix_ma1sd_configuration_extension_yaml: |
|
||||
threepid:
|
||||
medium:
|
||||
msisdn:
|
||||
connectors:
|
||||
twilio:
|
||||
account_sid: '<secret-SID>'
|
||||
auth_token: '<secret-token>'
|
||||
number: '+<msisdn-number>'
|
||||
```
|
||||
|
||||
#### Example: Open Registration for every Domain
|
||||
|
||||
If you want to open registration for any domain, you have to setup the allowed domains with ma1sd's `blacklist` and `whitelist`. The default behavior when neither the `blacklist`, nor the `whitelist` match, is to allow registration. Beware: you can't block toplevel domains (aka `.xy`) because the internal architecture of ma1sd doesn't allow that.
|
||||
|
||||
```yaml
|
||||
matrix_ma1sd_configuration_extension_yaml: |
|
||||
register:
|
||||
policy:
|
||||
allowed: true
|
||||
threepid:
|
||||
email:
|
||||
domain:
|
||||
blacklist: ~
|
||||
whitelist: ~
|
||||
```
|
||||
|
||||
## Installing
|
||||
|
||||
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
|
||||
|
||||
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
|
||||
```sh
|
||||
ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
|
||||
```
|
||||
|
||||
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
|
||||
|
||||
`just install-all` is useful for maintaining your setup quickly ([2x-5x faster](../CHANGELOG.md#2x-5x-performance-improvements-in-playbook-runtime) than `just setup-all`) when its components remain unchanged. If you adjust your `vars.yml` to remove other components, you'd need to run `just setup-all`, or these components will still remain installed. Note these shortcuts run the `ensure-matrix-users-created` tag too.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
If email address validation emails sent by ma1sd are not reaching you, you should look into [Adjusting email-sending settings](configuring-playbook-email.md).
|
||||
|
||||
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-ma1sd`.
|
||||
|
||||
### Increase logging verbosity
|
||||
|
||||
If you want to increase the verbosity, add the following configuration to your `vars.yml` file and re-run the playbook:
|
||||
|
||||
```yaml
|
||||
# See: https://github.com/ma1uta/ma1sd/blob/master/docs/troubleshooting.md#increase-verbosity
|
||||
matrix_ma1sd_verbose_logging: true
|
||||
```
|
||||
|
||||
@@ -41,7 +41,7 @@ Below, we'll try to **highlight some potential reasons for switching** to Matrix
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- ⚠️ the [Synapse](configuring-playbook-synapse.md) homeserver implementation (which is the default for this playbook). Other homeserver implementations ([Dendrite](./configuring-playbook-dendrite.md), [Conduit](./configuring-playbook-conduit.md), etc.) do not support integrating with Matrix Authentication Service yet.
|
||||
- ⚠️ the [Synapse](configuring-playbook-synapse.md) homeserver implementation (which is the default for this playbook). Other homeserver implementations ([Dendrite](./configuring-playbook-dendrite.md), [Conduit](./configuring-playbook-conduit.md), etc.) do not support integrating wtih Matrix Authentication Service yet.
|
||||
|
||||
- ❌ **disabling all password providers** for Synapse (things like [shared-secret-auth](./configuring-playbook-shared-secret-auth.md), [rest-auth](./configuring-playbook-rest-auth.md), [LDAP auth](./configuring-playbook-ldap-auth.md), etc.) More details about this are available in the [Expectations](#expectations) section below.
|
||||
|
||||
@@ -51,12 +51,10 @@ This section details what you can expect when switching to the Matrix Authentica
|
||||
|
||||
- ❌ **Synapse password providers will need to be disabled**. You can no longer use [shared-secret-auth](./configuring-playbook-shared-secret-auth.md), [rest-auth](./configuring-playbook-rest-auth.md), [LDAP auth](./configuring-playbook-ldap-auth.md), etc. When the authentication flow is handled by MAS (not by Synapse anymore), it doesn't make sense to extend the Synapse authentication flow with additional modules. Many bridges used to rely on shared-secret-auth for doing double-puppeting (impersonating other users), but most (at least the mautrix bridges) nowadays use [Appservice Double Puppet](./configuring-playbook-appservice-double-puppet.md) as a better alternative. Older/maintained bridges may still rely on shared-secret-auth, as do other services like [matrix-corporal](./configuring-playbook-matrix-corporal.md).
|
||||
|
||||
- ❌ Certain **tools like [Synapse Admin](./configuring-playbook-synapse-admin.md) do not have full compatibility with MAS yet**. Synapse Admin already supports OIDC auth, browsing users (which Synapse will internally fetch from MAS) and updating user avatars. However, editing users (passwords, etc.) now needs to happen directly against MAS using the [MAS Admin API](https://element-hq.github.io/matrix-authentication-service/api/index.html), which Synapse Admin cannot interact with yet. You may be interested in using [Element Admin](./configuring-playbook-element-admin.md) for these purposes.
|
||||
- ❌ Certain **tools like [synapse-admin](./configuring-playbook-synapse-admin.md) do not have full compatibility with MAS yet**. synapse-admin already supports [login with access token](https://github.com/etkecc/synapse-admin/pull/58), browsing users (which Synapse will internally fetch from MAS) and updating user avatars. However, editing users (passwords, etc.) now needs to happen directly against MAS using the [MAS Admin API](https://element-hq.github.io/matrix-authentication-service/api/index.html), which synapse-admin cannot interact with yet.
|
||||
|
||||
- ❌ **Some services experience issues when authenticating via MAS**:
|
||||
|
||||
- [Reminder bot](configuring-playbook-bot-matrix-reminder-bot.md) seems to be losing some of its state on each restart and may reschedule old reminders once again
|
||||
|
||||
- [Postmoogle](./configuring-playbook-bridge-postmoogle.md) works the first time around, but it consistently fails after restarting:
|
||||
|
||||
> cannot initialize matrix bot error="olm account is marked as shared, keys seem to have disappeared from the server"
|
||||
@@ -65,7 +63,7 @@ This section details what you can expect when switching to the Matrix Authentica
|
||||
|
||||
- ⚠️ [Migrating an existing Synapse homeserver to Matrix Authentication Service](#migrating-an-existing-synapse-homeserver-to-matrix-authentication-service) is **possible**, but requires **some playbook-assisted manual work**. Migration is **reversible with no or minor issues if done quickly enough**, but 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.
|
||||
|
||||
- ⚠️ Delegating user authentication to MAS causes **your Synapse server to be completely dependent on one more service** for its operations. MAS is quick & lightweight and should be stable enough already, but this is something to keep in mind when making the switch.
|
||||
- ⚠️ Delegating user authentication to MAS causes **your Synapse server to be completely dependant on one more service** for its operations. MAS is quick & lightweight and should be stable enough already, but this is something to keep in mind when making the switch.
|
||||
|
||||
- ⚠️ If you've got [OIDC configured in Synapse](./configuring-playbook-synapse.md#synapse--openid-connect-for-single-sign-on), you will need to migrate your OIDC configuration to MAS by adding an [Upstream OAuth2 configuration](#upstream-oauth2-configuration).
|
||||
|
||||
@@ -89,7 +87,7 @@ For new homeservers (which don't have any users in their Synapse database yet),
|
||||
|
||||
### Existing homeserver
|
||||
|
||||
Other homeserver implementations ([Dendrite](./configuring-playbook-dendrite.md), [Conduit](./configuring-playbook-conduit.md), etc.) do not support integrating with Matrix Authentication Service yet.
|
||||
Other homeserver implementations ([Dendrite](./configuring-playbook-dendrite.md), [Conduit](./configuring-playbook-conduit.md), etc.) do not support integrating wtih Matrix Authentication Service yet.
|
||||
|
||||
For existing Synapse homeservers:
|
||||
|
||||
@@ -161,10 +159,6 @@ matrix_authentication_service_config_upstream_oauth2_providers:
|
||||
- # A unique identifier for the provider
|
||||
# Must be a valid ULID
|
||||
id: 01HFVBY12TMNTYTBV8W921M5FA
|
||||
# This can be set if you're migrating an existing (legacy) Synapse OIDC configuration.
|
||||
# The value used here would most likely be "oidc" or "oidc-provider".
|
||||
# See: https://element-hq.github.io/matrix-authentication-service/setup/migration.html#map-any-upstream-sso-providers
|
||||
synapse_idp_id: null
|
||||
# The issuer URL, which will be used to discover the provider's configuration.
|
||||
# If discovery is enabled, this *must* exactly match the `issuer` field
|
||||
# advertised in `<issuer>/.well-known/openid-configuration`.
|
||||
@@ -312,7 +306,7 @@ ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
|
||||
|
||||
Our migration guide is loosely based on the upstream [Migrating an existing homeserver](https://element-hq.github.io/matrix-authentication-service/setup/migration.html) guide.
|
||||
|
||||
Migration is done via a sub-command called `syn2mas`, which the playbook could run for you (in a container).
|
||||
Migration is done via a tool called `syn2mas`, which the playbook could run for you (in a container).
|
||||
|
||||
The installation + migration steps are like this:
|
||||
|
||||
@@ -328,7 +322,7 @@ The installation + migration steps are like this:
|
||||
|
||||
- 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 command 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.
|
||||
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.
|
||||
|
||||
4. [Migrate your data from Synapse to Matrix Authentication Service using syn2mas](#migrate-your-data-from-synapse-to-matrix-authentication-service-using-syn2mas)
|
||||
|
||||
@@ -348,7 +342,9 @@ The installation + migration steps are like this:
|
||||
|
||||
### Migrate your data from Synapse to Matrix Authentication Service using syn2mas
|
||||
|
||||
You can invoke the `syn2mas` tool via the playbook by running the playbook's `matrix-authentication-service-mas-cli-syn2mas` tag. We recommend first doing a [dry-run](#performing-a-syn2mas-dry-run) and then a [real migration](#performing-a-real-syn2mas-migration).
|
||||
We **don't** ask you to [run the `syn2mas` migration advisor command](https://element-hq.github.io/matrix-authentication-service/setup/migration.html#run-the-migration-advisor), because it only gives you the green light if your Synapse configuration (`homeserver.yaml`) is configured in a way that's compatible with MAS (delegating authentication to MAS; disabling Synapse's password config; etc.). Until we migrate your data with the `syn2mas` tool, we intentionally avoid doing these changes to allow existing user sessions to work.
|
||||
|
||||
You can invoke the `syn2mas` tool via the playbook by running the playbook's `matrix-authentication-service-syn2mas` tag. We recommend first doing a [dry-run](#performing-a-syn2mas-dry-run) and then a [real migration](#performing-a-real-syn2mas-migration).
|
||||
|
||||
#### Configuring syn2mas
|
||||
|
||||
@@ -360,9 +356,26 @@ When you're done with potentially configuring `syn2mas`, proceed to doing a [dry
|
||||
|
||||
##### Configuring upstream OIDC provider mapping for syn2mas
|
||||
|
||||
Since Matrix Authentication Service v0.16.0 (which replaced the standalone `syn2mas` tool with a `mas-cli syn2mas` sub-command), OIDC configuration (mapping from your old OIDC configuration to your new one, etc) is meant to be configured in the Matrix Authentication Service configuration (via `matrix_authentication_service_config_upstream_oauth2_providers`) as a `synapse_idp_id` property for each provider.
|
||||
If you have existing OIDC users in your Synapse user database (which will be the case if when using [OIDC with Synapse](./configuring-playbook-synapse.md#synapse--openid-connect-for-single-sign-on)), you may need to pass an additional `--upstreamProviderMapping` argument to the `syn2mas` tool to tell it which provider (on the Synapse side) maps to which other provider on the MAS side.
|
||||
|
||||
You can refer to the [Map any upstream SSO providers](https://element-hq.github.io/matrix-authentication-service/setup/migration.html#map-any-upstream-sso-providers) section of the MAS documentation for figuring out how to set the `synapse_idp_id` value in `matrix_authentication_service_config_upstream_oauth2_providers` correctly.
|
||||
If you don't do this, `syn2mas` would report errors like this one:
|
||||
|
||||
> [FATAL] migrate - [Failed to import external id 4264b0f0-4f11-4ddd-aedb-b500e4d07c25 with oidc-keycloak for user @alice:example.com: Error: Unknown upstream provider oidc-keycloak]
|
||||
|
||||
Below is an example situation and a guide for how to solve it.
|
||||
|
||||
If in `matrix_synapse_oidc_providers` your provider `idp_id` is (was) named `keycloak`, in the Synapse database users would be associated with the `oidc-keycloak` provider (note the `oidc-` prefix that was added automatically by Synapse to your `idp_id` value).
|
||||
|
||||
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 `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Adjust the mapping below to match your provider IDs on the Synapse side and the MAS side.
|
||||
# Don't forget that Synapse automatically adds an `oidc-` prefix to provider ids defined in its configuration.
|
||||
matrix_authentication_service_syn2mas_process_extra_arguments:
|
||||
- "--upstreamProviderMapping oidc-keycloak:01HFVBY12TMNTYTBV8W921M5FA"
|
||||
```
|
||||
|
||||
#### Performing a syn2mas dry-run
|
||||
|
||||
@@ -373,7 +386,7 @@ A dry-run would not cause downtime, because it avoids stopping Synapse.
|
||||
To perform a dry-run, run:
|
||||
|
||||
```sh
|
||||
just run-tags matrix-authentication-service-mas-cli-syn2mas -e matrix_authentication_service_syn2mas_migrate_dry_run=true
|
||||
just run-tags matrix-authentication-service-syn2mas -e matrix_authentication_service_syn2mas_dry_run=true
|
||||
```
|
||||
|
||||
Observe the command output (especially the last line of the the syn2mas output). If you are confident that the migration will work out as expected, you can proceed with a [real migration](#performing-a-real-syn2mas-migration).
|
||||
@@ -392,13 +405,13 @@ Before performing a real migration make sure:
|
||||
|
||||
- you've performed a [syn2mas dry-run](#performing-a-syn2mas-dry-run) and don't see any issues in its output
|
||||
|
||||
To perform a real migration, run the `matrix-authentication-service-mas-cli-syn2mas` tag **without** the `matrix_authentication_service_syn2mas_migrate_dry_run` variable:
|
||||
To perform a real migration, run the `matrix-authentication-service-syn2mas` tag **without** the `matrix_authentication_service_syn2mas_dry_run` variable:
|
||||
|
||||
```sh
|
||||
just run-tags matrix-authentication-service-mas-cli-syn2mas
|
||||
just run-tags matrix-authentication-service-syn2mas
|
||||
```
|
||||
|
||||
Having performed a `syn2mas` migration once, trying to do it again will report errors (e.g. "Error: The MAS database is not empty: rows found in at least `users`. Please drop and recreate the database, then try again.").
|
||||
Having performed a `syn2mas` migration once, trying to do it again will report errors for users that were already migrated (e.g. "Error: Unknown upstream provider oauth-delegated").
|
||||
|
||||
## Verify that Matrix Authentication Service is installed correctly
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
|
||||
The playbook can install and configure [matrix-corporal](https://github.com/devture/matrix-corporal) for you.
|
||||
|
||||
In short, it's a sort of automation and firewalling service, which is helpful if you're installing Matrix services in a controlled corporate environment.
|
||||
In short, it's a sort of automation and firewalling service, which is helpful if you're instaling Matrix services in a controlled corporate environment.
|
||||
|
||||
See the project's [documentation](https://github.com/devture/matrix-corporal/blob/main/README.md) to learn what it does and why it might be useful to you.
|
||||
|
||||
|
||||
@@ -24,21 +24,8 @@ To enable matrix-media-repo, add the following configuration to your `inventory/
|
||||
|
||||
```yaml
|
||||
matrix_media_repo_enabled: true
|
||||
|
||||
# Any unique alphanumeric string. Cannot be changed after first use.
|
||||
# For new installations, generate one with: pwgen -s 64 1
|
||||
# For existing installations, see below.
|
||||
matrix_media_repo_datastore_file_id: "CHANGE_ME_TO_A_UNIQUE_VALUE"
|
||||
```
|
||||
|
||||
**For existing installations**: retrieve the current datastore ID from the server's config file before proceeding:
|
||||
|
||||
```sh
|
||||
grep 'id:' /matrix/media-repo/config/media-repo.yaml
|
||||
```
|
||||
|
||||
Then use that value for `matrix_media_repo_datastore_file_id`. This is not a secret — it is a plain identifier used by matrix-media-repo to link media files to their storage backend.
|
||||
|
||||
By default, the media-repo will use the local filesystem for data storage. You can alternatively use a `s3` cloud backend as well. Access token caching is also enabled by default since the logout endpoints are proxied through the media repo.
|
||||
|
||||
### Enable metrics
|
||||
@@ -73,7 +60,7 @@ To `matrix_media_repo_container_labels_traefik_metrics_middleware_basic_auth_use
|
||||
|
||||
#### Enable Grafana (optional)
|
||||
|
||||
Probably you wish to enable Grafana along with Prometheus for generating graphs of the metrics.
|
||||
Probably you wish to enable Grafana along with Prometheus for generating graphs of the metics.
|
||||
|
||||
To enable Grafana, see [this section](configuring-playbook-prometheus-grafana.md#adjusting-the-playbook-configuration-grafana) for instructions.
|
||||
|
||||
@@ -122,11 +109,6 @@ matrix_media_repo_admins: []
|
||||
matrix_media_repo_datastore_file_for_kinds: ["thumbnails", "remote_media", "local_media", "archives"]
|
||||
matrix_media_repo_datastore_s3_for_kinds: []
|
||||
|
||||
# Required when S3 storage is enabled (matrix_media_repo_datastore_s3_for_kinds is non-empty).
|
||||
# Any unique alphanumeric string. Cannot be changed after first use.
|
||||
# For new installations, generate one with: pwgen -s 64 1
|
||||
# matrix_media_repo_datastore_s3_id: ""
|
||||
|
||||
# The s3 uploader needs a temporary location to buffer files to reduce memory usage on
|
||||
# small file uploads. If the file size is unknown, the file is written to this location
|
||||
# before being uploaded to s3 (then the file is deleted). If you aren't concerned about
|
||||
|
||||
@@ -16,6 +16,7 @@ The Matrix RTC stack is a set of supporting components ([LiveKit Server](configu
|
||||
## Prerequisites
|
||||
|
||||
- A [Synapse](configuring-playbook-synapse.md) homeserver (see the warning below)
|
||||
- [Federation](configuring-playbook-federation.md) being enabled for your Matrix homeserver (federation is enabled by default, unless you've explicitly disabled it), because [LiveKit JWT Service](configuring-playbook-livekit-jwt-service.md) currently [requires it](https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3562#issuecomment-2725250554) ([relevant source code](https://github.com/element-hq/lk-jwt-service/blob/f5f5374c4bdcc00a4fb13d27c0b28e20e4c62334/main.go#L135-L146))
|
||||
- Various experimental features for the Synapse homeserver which Element Call [requires](https://github.com/element-hq/element-call/blob/93ae2aed9841e0b066d515c56bd4c122d2b591b2/docs/self-hosting.md#a-matrix-homeserver) (automatically done when Element Call is enabled)
|
||||
- A [LiveKit Server](configuring-playbook-livekit-server.md) (automatically installed when [Element Call or the Matrix RTC stack is enabled](#decide-between-element-call-vs-just-the-matrix-rtc-stack))
|
||||
- The [LiveKit JWT Service](configuring-playbook-livekit-jwt-service.md) (automatically installed when [Element Call or the Matrix RTC stack is enabled](#decide-between-element-call-vs-just-the-matrix-rtc-stack))
|
||||
@@ -55,4 +56,4 @@ The shortcut commands with the [`just` program](just.md) are also available: `ju
|
||||
|
||||
Once installed, Matrix clients which support Element Call (like [Element Web](configuring-playbook-client-element-web.md) and Element X on mobile (iOS and Android)) will automatically use the Matrix RTC stack.
|
||||
|
||||
These clients typically embed the Element Call frontend UI within them, so installing [Element Call](configuring-playbook-element-call.md) is only necessary if you'd like to use it standalone - directly via a browser.
|
||||
These clients typically embed the Element Call frontend UI within them, so installing [Element Call](configuring-playbook-element-call.md) is only necessary if you'd like to use it standalone - directly via a browser.
|
||||
@@ -1,68 +0,0 @@
|
||||
<!--
|
||||
SPDX-FileCopyrightText: 2023 - 2024 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2024 - 2025 Suguru Hirahara
|
||||
|
||||
SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
-->
|
||||
|
||||
# Setting up Matrix.to (optional)
|
||||
|
||||
The playbook can install and configure the [Matrix.to](https://github.com/matrix-org/matrix.to) URL redirection service for you.
|
||||
|
||||
See the project's [documentation](https://github.com/matrix-org/matrix.to/blob/main/README.md) to learn what it does and why it might be useful to you.
|
||||
|
||||
## Adjusting DNS records
|
||||
|
||||
By default, this playbook installs Matrix.to on the `mt.` subdomain (`mt.example.com`) and requires you to create a CNAME record for `mt`, which targets `matrix.example.com`.
|
||||
|
||||
When setting, replace `example.com` with your own.
|
||||
|
||||
## Adjusting the playbook configuration
|
||||
|
||||
To enable Matrix.to, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_matrixto_enabled: true
|
||||
```
|
||||
|
||||
### Adjusting the Matrix.to URL (optional)
|
||||
|
||||
By tweaking the `matrix_matrixto_hostname` variable, you can easily make the service available at a **different hostname** than the default one.
|
||||
|
||||
Example additional configuration for your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Change the default hostname
|
||||
matrix_matrixto_hostname: t.example.com
|
||||
```
|
||||
|
||||
After changing the domain, **you may need to adjust your DNS** records to point the Matrix.to domain to the Matrix server.
|
||||
|
||||
### Extending the configuration
|
||||
|
||||
There are some additional things you may wish to configure about the server.
|
||||
|
||||
Take a look at:
|
||||
|
||||
- `roles/custom/matrix-matrixto/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
|
||||
|
||||
## Installing
|
||||
|
||||
After configuring the playbook and potentially [adjusting your DNS records](#adjusting-dns-records), run the playbook with [playbook tags](playbook-tags.md) as below:
|
||||
|
||||
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
|
||||
```sh
|
||||
ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
|
||||
```
|
||||
|
||||
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
|
||||
|
||||
`just install-all` is useful for maintaining your setup quickly ([2x-5x faster](../CHANGELOG.md#2x-5x-performance-improvements-in-playbook-runtime) than `just setup-all`) when its components remain unchanged. If you adjust your `vars.yml` to remove other components, you'd need to run `just setup-all`, or these components will still remain installed. Note these shortcuts run the `ensure-matrix-users-created` tag too.
|
||||
|
||||
## Usage
|
||||
|
||||
Refer to the project's [documentation](https://github.com/matrix-org/matrix.to/blob/main/README.md) for available parameters, etc.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-matrixto`.
|
||||
@@ -115,7 +115,7 @@ The shortcut commands with the [`just` program](just.md) are also available: `ju
|
||||
|
||||
## Usage
|
||||
|
||||
To receive push notifications with UnifiedPush from the ntfy server, you need to **install [the ntfy Android app](https://docs.ntfy.sh/subscribe/phone/)** which works as the Distributor, **log in to the account on the ntfy app** if you have enabled the access control, and then **configure a UnifiedPush-compatible Matrix client**. After setting up the ntfy Android app, the Matrix client listens to it, and push notifications are "distributed" from it.
|
||||
To receive push notifications with UnifiedPush from the ntfy server, you need to **install [the ntfy Android app](https://docs.ntfy.sh/subscribe/phone/)** which works as the Distrubutor, **log in to the account on the ntfy app** if you have enabled the access control, and then **configure a UnifiedPush-compatible Matrix client**. After setting up the ntfy Android app, the Matrix client listens to it, and push notitications are "distributed" from it.
|
||||
|
||||
For details about installing and configuring the ntfy Android app, take a look at [this section](https://github.com/mother-of-all-self-hosting/ansible-role-ntfy/blob/main/docs/configuring-ntfy.md#install-the-ntfy-androidios-app) on the role's documentation.
|
||||
|
||||
|
||||
@@ -51,7 +51,7 @@ matrix_playbook_reverse_proxy_type: other-traefik-container
|
||||
# Adjust to point to your Traefik container
|
||||
matrix_playbook_reverse_proxy_hostname: name-of-your-traefik-container
|
||||
|
||||
traefik_certs_dumper_ssl_path: "/path/to/your/traefiks/acme.json/directory"
|
||||
traefik_certs_dumper_ssl_dir_path: "/path/to/your/traefiks/acme.json/directory"
|
||||
|
||||
# Uncomment and adjust the variable below if the name of your federation entrypoint is different
|
||||
# than the default value (matrix-federation).
|
||||
|
||||
@@ -83,7 +83,7 @@ See the project's [documentation](https://github.com/martin-helmich/prometheus-n
|
||||
To enable it, add the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
prometheus_nginxlog_exporter_enabled: true
|
||||
matrix_prometheus_nginxlog_exporter_enabled: true
|
||||
```
|
||||
|
||||
If you enable Grafana, a dedicated `NGINX PROXY` Grafana dashboard will be created.
|
||||
@@ -95,8 +95,8 @@ If you enable Grafana, a dedicated `NGINX PROXY` Grafana dashboard will be creat
|
||||
At the moment of writing only images for `amd64` and `arm64` architectures are available. The playbook currently does not support [self-building](./self-building.md) a container image on other architectures. You can however use a custom-build image by setting:
|
||||
|
||||
```yaml
|
||||
prometheus_nginxlog_exporter_container_image_arch_check_enabled: false
|
||||
prometheus_nginxlog_exporter_container_image: path/to/docker/image:tag
|
||||
matrix_prometheus_nginxlog_exporter_docker_image_arch_check_enabled: false
|
||||
matrix_prometheus_nginxlog_exporter_docker_image: path/to/docker/image:tag
|
||||
```
|
||||
|
||||
### Extending the configuration
|
||||
@@ -106,7 +106,7 @@ There are some additional things you may wish to configure about Prometheus and
|
||||
Take a look at:
|
||||
|
||||
- [Prometheus role](https://github.com/mother-of-all-self-hosting/ansible-role-prometheus)'s [`defaults/main.yml`](https://github.com/mother-of-all-self-hosting/ansible-role-prometheus/blob/main/defaults/main.yml) for some variables that you can customize via your `vars.yml` file. You can override settings (even those that don't have dedicated playbook variables) using the `prometheus_configuration_extension_yaml` variable
|
||||
- `roles/galaxy/prometheus_nginxlog_exporter/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
|
||||
- `roles/custom/matrix-prometheus-nginxlog-exporter/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
|
||||
|
||||
## Adjusting the playbook configuration — Grafana
|
||||
|
||||
@@ -181,8 +181,8 @@ Name | Description
|
||||
`prometheus_node_exporter_container_labels_traefik_enabled`|Set this to `true` to expose the node (general system stats) metrics on `https://matrix.example.com/metrics/node-exporter`.
|
||||
`prometheus_postgres_exporter_enabled`|Set this to `true` to enable the [Postgres exporter](#enable-metrics-and-graphs-for-postgres-optional) (locally, on the container network).
|
||||
`prometheus_postgres_exporter_container_labels_traefik_enabled`|Set this to `true` to expose the [Postgres exporter](#enable-metrics-and-graphs-for-postgres-optional) metrics on `https://matrix.example.com/metrics/postgres-exporter`.
|
||||
`prometheus_nginxlog_exporter_enabled`|Set this to `true` to enable the [prometheus-nginxlog-exporter](#enable-metrics-and-graphs-for-nginx-logs-optional) (locally, on the container network).
|
||||
`prometheus_nginxlog_exporter_container_labels_traefik_enabled`|Set this to `true` to expose the [prometheus-nginxlog-exporter](#enable-metrics-and-graphs-for-nginx-logs-optional) metrics on `https://matrix.example.com/metrics/nginxlog`.
|
||||
`matrix_prometheus_nginxlog_exporter_enabled`|Set this to `true` to enable the [nginx Log exporter](#enable-metrics-and-graphs-for-nginx-logs-optional) (locally, on the container network).
|
||||
`matrix_prometheus_nginxlog_exporter_metrics_proxying_enabled`|Set this to `true` to expose the [nginx Log exporter](#enable-metrics-and-graphs-for-nginx-logs-optional) metrics on `https://matrix.example.com/metrics/nginxlog`.
|
||||
|
||||
### Expose metrics of other services/roles
|
||||
|
||||
@@ -258,4 +258,4 @@ As with all other services, you can find the logs in [systemd-journald](https://
|
||||
- [The Prometheus scraping rules](https://github.com/element-hq/synapse/tree/master/contrib/prometheus) (we use v2)
|
||||
- [The Synapse Grafana dashboard](https://github.com/element-hq/synapse/tree/master/contrib/grafana)
|
||||
- [The Node Exporter dashboard](https://github.com/rfrail3/grafana-dashboards) (for generic non-synapse performance graphs)
|
||||
- [The PostgreSQL dashboard](https://grafana.com/grafana/dashboards/9628) (generic Postgres dashboard)
|
||||
- [The PostgresSQL dashboard](https://grafana.com/grafana/dashboards/9628) (generic Postgres dashboard)
|
||||
|
||||
@@ -18,7 +18,7 @@ Add the following configuration to your `inventory/host_vars/matrix.example.com/
|
||||
|
||||
```yaml
|
||||
matrix_synapse_ext_password_provider_rest_auth_enabled: true
|
||||
matrix_synapse_ext_password_provider_rest_auth_endpoint: SET_YOUR_ENDPOINT_HERE
|
||||
matrix_synapse_ext_password_provider_rest_auth_endpoint: "http://matrix-ma1sd:8090"
|
||||
matrix_synapse_ext_password_provider_rest_auth_registration_enforce_lowercase: false
|
||||
matrix_synapse_ext_password_provider_rest_auth_registration_profile_name_autofill: true
|
||||
matrix_synapse_ext_password_provider_rest_auth_login_profile_name_autofill: false
|
||||
@@ -47,4 +47,9 @@ The shortcut commands with the [`just` program](just.md) are also available: `ju
|
||||
|
||||
## Usage
|
||||
|
||||
This module does not provide direct integration with any backend. Please prepare one by yourself for it.
|
||||
### Use ma1sd Identity Server for the backend (not recommended)
|
||||
|
||||
This module does not provide direct integration with any backend. For the backend you can use [ma1sd](https://github.com/ma1uta/ma1sd) Identity Server, which can be configured with the playbook.
|
||||
|
||||
> [!WARNING]
|
||||
> We recommend not bothering with installing ma1sd as it has been unmaintained for years. If you wish to install it anyway, consult the [ma1sd Identity Server configuration](configuring-playbook-ma1sd.md).
|
||||
|
||||
@@ -22,11 +22,13 @@ Finally, [set up S3 storage for Synapse](#setting-up) (with [Goofys](configuring
|
||||
|
||||
## Choosing an Object Storage provider
|
||||
|
||||
You can create [Amazon S3](https://aws.amazon.com/s3/) or another S3-compatible object storage like [Backblaze B2](https://www.backblaze.com/b2/cloud-storage.html), [Wasabi](https://wasabi.com), [Digital Ocean Spaces](https://www.digitalocean.com/products/spaces), [Storj](https://storj.io), etc.
|
||||
You can create [Amazon S3](https://aws.amazon.com/s3/) or another S3-compatible object storage like [Backblaze B2](https://www.backblaze.com/b2/cloud-storage.html), [Storj](https://storj.io), [Wasabi](https://wasabi.com), [Digital Ocean Spaces](https://www.digitalocean.com/products/spaces), etc.
|
||||
|
||||
Amazon S3 and Backblaze B2 are pay-as-you with no minimum charges for storing too little data. Note that Backblaze egress is free, but for only certain users for up to 3x the amount of data stored. Beyond that you will pay $0.01/GB of egress.
|
||||
Amazon S3, Backblaze B2, and Storj are pay-as-you with no minimum charges for storing too little data.
|
||||
|
||||
Wasabi has a minimum charge of 1TB if you're storing less than 1TB, which becomes expensive if you need to store less data than that. Likewise, Digital Ocean Spaces has also a minimum charge of 250GB ($5/month as of 2022-10). Though Storj does not set minimum amount of data to be stored, it also charges $5 minimum monthly usage fee since July 1, 2025, if your monthly usage (storage, bandwidth, and segments) totals less than $5.
|
||||
All these providers have different prices, with Storj appearing to be the cheapest (as of 2024-10, storage fee is $0.004 per GB/month, and egress fee is $0.007 per GB; check actual pricing [here](https://storj.dev/dcs/pricing)). Backblaze egress is free, but for only certain users for up to 3x the amount of data stored. Beyond that you will pay $0.01/GB of egress.
|
||||
|
||||
Wasabi has a minimum charge of 1TB if you're storing less than 1TB, which becomes expensive if you need to store less data than that. Likewise, Digital Ocean Spaces has also a minimum charge of 250GB ($5/month as of 2022-10).
|
||||
|
||||
Here are some of the important aspects of choosing the right provider:
|
||||
|
||||
|
||||
@@ -1,32 +1,95 @@
|
||||
<!--
|
||||
SPDX-FileCopyrightText: 2019 Eduardo Beltrame
|
||||
SPDX-FileCopyrightText: 2019-2025 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2020 Tulir Asokan
|
||||
SPDX-FileCopyrightText: 2021, 2024 MDAD project contributors
|
||||
SPDX-FileCopyrightText: 2022 Dennis Ciba
|
||||
SPDX-FileCopyrightText: 2022 Vladimir Panteleev
|
||||
SPDX-FileCopyrightText: 2023 - 2024 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2023 Justin Croonenberghs
|
||||
SPDX-FileCopyrightText: 2023 Kuba Orlik
|
||||
SPDX-FileCopyrightText: 2023 Pierre 'McFly' Marty
|
||||
SPDX-FileCopyrightText: 2023 Samuel Meenzen
|
||||
SPDX-FileCopyrightText: 2024 - 2025 Suguru Hirahara
|
||||
SPDX-FileCopyrightText: 2024 Fabio Bonelli
|
||||
SPDX-FileCopyrightText: 2024-2026 Suguru Hirahara
|
||||
SPDX-FileCopyrightText: 2024 MDAD project contributors
|
||||
|
||||
SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
-->
|
||||
|
||||
# Setting up the Sliding Sync proxy (optional, removed)
|
||||
# Setting up the Sliding Sync proxy (optional)
|
||||
|
||||
🪦 The playbook used to be able to install and configure the [sliding-sync](https://github.com/matrix-org/sliding-sync) proxy, but no longer includes this component, as it's been replaced with a different method (called Simplified Sliding Sync) integrated to newer homeservers by default (**Conduit** homeserver from version `0.6.0` or **Synapse** from version `1.114`).
|
||||
**Note**: The sliding-sync proxy is **not required** anymore as it's been replaced with a different method (called Simplified Sliding Sync) which is integrated into newer homeservers by default (**Conduit** homeserver from version `0.6.0` or **Synapse** from version `1.114`). This component and documentation remain here for historical purposes, but **installing this old sliding-sync proxy is generally not recommended anymore**.
|
||||
|
||||
## Uninstalling the proxy manually
|
||||
The playbook can install and configure [sliding-sync](https://github.com/matrix-org/sliding-sync) proxy for you.
|
||||
|
||||
If you still have the Sliding Sync proxy installed on your Matrix server, the playbook can no longer help you uninstall it and you will need to do it manually. To uninstall manually, run these commands on the server:
|
||||
Sliding Sync is an implementation of [MSC3575](https://github.com/matrix-org/matrix-spec-proposals/blob/kegan/sync-v3/proposals/3575-sync.md) and a prerequisite for running Element X clients ([Element X iOS](https://github.com/element-hq/element-x-ios) and [Element X Android](https://github.com/element-hq/element-x-android)). See the project's [documentation](https://github.com/matrix-org/sliding-sync) to learn more.
|
||||
|
||||
```sh
|
||||
systemctl disable --now matrix-sliding-sync.service
|
||||
## Adjusting DNS records (optional)
|
||||
|
||||
rm -rf /matrix/sliding-sync
|
||||
By default, this playbook installs the Sliding Sync proxy on the `matrix.` subdomain, at the `/sliding-sync` path (https://matrix.example.com/sliding-sync). This makes it easy to install it, because it **doesn't require additional DNS records to be set up**. If that's okay, you can skip this section.
|
||||
|
||||
/matrix/postgres/bin/cli-non-interactive -c 'DROP DATABASE matrix_sliding_sync;'
|
||||
If you wish to adjust it, see the section [below](#adjusting-the-sliding-sync-proxy-url-optional) for details about DNS configuration.
|
||||
|
||||
## Adjusting the playbook configuration
|
||||
|
||||
To enable Sliding Sync proxy, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_sliding_sync_enabled: true
|
||||
```
|
||||
|
||||
### Adjusting the Sliding Sync proxy URL (optional)
|
||||
|
||||
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 `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
# Change the default hostname and path prefix
|
||||
matrix_sliding_sync_hostname: ss.example.com
|
||||
matrix_sliding_sync_path_prefix: /
|
||||
```
|
||||
|
||||
If you've changed the default hostname, you may need to create a CNAME record for the Sliding Sync proxy domain (`ss.example.com`), which targets `matrix.example.com`.
|
||||
|
||||
When setting, replace `example.com` with your own.
|
||||
|
||||
### Extending the configuration
|
||||
|
||||
There are some additional things you may wish to configure about the component.
|
||||
|
||||
Take a look at:
|
||||
|
||||
- `roles/custom/matrix-sliding-sync/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
|
||||
|
||||
## Installing
|
||||
|
||||
After configuring the playbook and potentially [adjusting your DNS records](#adjusting-dns-records), run the playbook with [playbook tags](playbook-tags.md) as below:
|
||||
|
||||
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
|
||||
```sh
|
||||
ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
|
||||
```
|
||||
|
||||
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
|
||||
|
||||
`just install-all` is useful for maintaining your setup quickly ([2x-5x faster](../CHANGELOG.md#2x-5x-performance-improvements-in-playbook-runtime) than `just setup-all`) when its components remain unchanged. If you adjust your `vars.yml` to remove other components, you'd need to run `just setup-all`, or these components will still remain installed. Note these shortcuts run the `ensure-matrix-users-created` tag too.
|
||||
|
||||
### External databases
|
||||
|
||||
Please note that, if your setup utilizes an external database, you must also establish configuration for the sliding sync proxy. Alter the defaults below to suit your configuration:
|
||||
|
||||
```yaml
|
||||
matrix_sliding_sync_database_username: 'matrix_sliding_sync'
|
||||
matrix_sliding_sync_database_password: ''
|
||||
matrix_sliding_sync_database_hostname: ''
|
||||
matrix_sliding_sync_database_port: 5432
|
||||
matrix_sliding_sync_database_name: 'matrix_sliding_sync'
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
You **don't need to do anything special** to make use of the Sliding Sync proxy. Simply open your client which supports Sliding Sync (like Element X) and log in.
|
||||
|
||||
When the Sliding Sync proxy is [installed](#installing), your `/.well-known/matrix/client` file is also updated. A new `org.matrix.msc3575.proxy` section and `url` property are added there and made to point to your Sliding Sync proxy's base URL (e.g. `https://matrix.example.com/sliding-sync`).
|
||||
|
||||
This allows clients which support Sliding Sync to detect the Sliding Sync proxy's URL and make use of it.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-sliding-sync`.
|
||||
|
||||
@@ -15,9 +15,9 @@ By default, the playbook retrieves and automatically renews free SSL certificate
|
||||
|
||||
**Notes**:
|
||||
- This guide is intended to be referred for configuring the integrated Traefik server with regard to SSL certificates retrieval. If you're using [your own webserver](configuring-playbook-own-webserver.md), consult its documentation about how to configure it.
|
||||
- Let's Encrypt ends the expiration notification email service on June 4, 2025 (see: [the official announcement](https://letsencrypt.org/2025/01/22/ending-expiration-emails/)), and it recommends using a third party service for those who want to receive expiration notifications. If you are looking for a self-hosting service, you may be interested in a monitoring tool such as [Update Kuma](https://github.com/louislam/uptime-kuma/).
|
||||
- Let's Encrypt ends the expiration notification email service on June 4, 2025 (see: [the official announcement](https://letsencrypt.org/2025/01/22/ending-expiration-emails/)), and it recommends using a third party service for those who want to receive expiriation notifications. If you are looking for a self-hosting service, you may be interested in a monitoring tool such as [Update Kuma](https://github.com/louislam/uptime-kuma/).
|
||||
|
||||
The [Mother-of-All-Self-Hosting (MASH)](https://github.com/mother-of-all-self-hosting/mash-playbook) Ansible playbook can be used to install and manage an Uptime Kuma instance. See [this page](https://github.com/mother-of-all-self-hosting/mash-playbook/blob/main/docs/services/uptime-kuma.md) for the instruction to install it with the playbook. If you are wondering how to use it for your Matrix server, refer to [this page](https://github.com/mother-of-all-self-hosting/mash-playbook/blob/main/docs/setting-up-services-on-mdad-server.md) for the overview.
|
||||
The [Mother-of-All-Self-Hosting (MASH)](https://github.com/mother-of-all-self-hosting/mash-playbook) Ansible playbook can be used to install and manage an Uptime Kuma instance. See [this page](https://github.com/mother-of-all-self-hosting/mash-playbook/blob/main/docs/services/uptime-kuma.md) for the instruction to install it with the MASH playbook. If you are wondering how to use the MASH playbook for your Matrix server, refer [this page](https://github.com/mother-of-all-self-hosting/mash-playbook/blob/main/docs/setting-up-services-on-mdad-server.md).
|
||||
|
||||
## Use staging Let's Encrypt certificates
|
||||
|
||||
|
||||
@@ -49,8 +49,8 @@ aux_file_definitions:
|
||||
content
|
||||
here
|
||||
mode: '0600'
|
||||
owner: "{{ matrix_user_name }}"
|
||||
group: "{{ matrix_group_name }}"
|
||||
owner: "{{ matrix_user_username }}"
|
||||
group: "{{ matrix_user_groupname }}"
|
||||
```
|
||||
|
||||
Configuring [GCM/FCM](https://firebase.google.com/docs/cloud-messaging/) is easier, as it only requires that you provide some config values.
|
||||
|
||||
@@ -1,26 +1,22 @@
|
||||
<!--
|
||||
SPDX-FileCopyrightText: 2020-2024 MDAD project contributors
|
||||
SPDX-FileCopyrightText: 2020-2024 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2020 - 2024 MDAD project contributors
|
||||
SPDX-FileCopyrightText: 2020 - 2024 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2021 Aaron Raimist
|
||||
SPDX-FileCopyrightText: 2023 Christian González
|
||||
SPDX-FileCopyrightText: 2024 - 2025 Suguru Hirahara
|
||||
SPDX-FileCopyrightText: 2024 Nikita Chernyi
|
||||
SPDX-FileCopyrightText: 2024 Uğur İLTER
|
||||
SPDX-FileCopyrightText: 2024-2026 Suguru Hirahara
|
||||
|
||||
SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
-->
|
||||
|
||||
# Setting up Synapse Admin (optional)
|
||||
|
||||
The playbook can install and configure Synapse Admin for you.
|
||||
The playbook can install and configure [etkecc/synapse-admin](https://github.com/etkecc/synapse-admin) (a [feature-rich](https://github.com/etkecc/synapse-admin#fork-differences) fork of [Awesome-Technologies/synapse-admin](https://github.com/Awesome-Technologies/synapse-admin), community room: [#synapse-admin:etke.cc](https://matrix.to/#/#synapse-admin:etke.cc)) for you.
|
||||
|
||||
Synapse Admin is a web UI tool you can use to **administrate users, rooms, media, etc. on your Matrix homeserver**. This playbook is configured to install [etkecc/synapse-admin](https://github.com/etkecc/synapse-admin), which is a [feature-rich](https://github.com/etkecc/synapse-admin#fork-differences) fork of [Awesome-Technologies/synapse-admin](https://github.com/Awesome-Technologies/synapse-admin).
|
||||
synapse-admin is a web UI tool you can use to **administrate users, rooms, media, etc. on your Matrix server**. It's designed to work with the Synapse homeserver implementation and WON'T work with Dendrite because [Dendrite Admin API](https://element-hq.github.io/dendrite/administration/adminapi) differs from [Synapse Admin API](https://element-hq.github.io/synapse/latest/usage/administration/admin_api/).
|
||||
|
||||
>[!NOTE]
|
||||
>
|
||||
> - Synapse Admin does not work with other homeserver implementations than Synapse due to API's incompatibility.
|
||||
> - The latest version of Synapse Admin is hosted by [etke.cc](https://etke.cc/) at [admin.etke.cc](https://admin.etke.cc/). If you only need this service occasionally and trust giving your admin credentials to a 3rd party Single Page Application, you can consider using it from there and avoiding the (small) overhead of self-hosting.
|
||||
> - This playbook also supports an alternative management UI in the shape of [Element Admin](./configuring-playbook-element-admin.md). Please note that it's currently less feature-rich than Synapse Admin and requires [Matrix Authentication Service](./configuring-playbook-matrix-authentication-service.md).
|
||||
💡 **Note**: the latest version of synapse-admin is hosted by [etke.cc](https://etke.cc/) at [admin.etke.cc](https://admin.etke.cc/). If you only need this service occasionally and trust giving your admin credentials to a 3rd party Single Page Application, you can consider using it from there and avoiding the (small) overhead of self-hosting.
|
||||
|
||||
## Adjusting DNS records (optional)
|
||||
|
||||
@@ -43,6 +39,9 @@ matrix_synapse_admin_enabled: true
|
||||
|
||||
By default, synapse-admin installation will be [restricted to only work with one homeserver](https://github.com/etkecc/synapse-admin/blob/e21e44362c879ac41f47c580b04210842b6ff3d7/README.md#restricting-available-homeserver) — the one managed by the playbook. To adjust these restrictions, tweak the `matrix_synapse_admin_config_restrictBaseUrl` variable.
|
||||
|
||||
> [!WARNING]
|
||||
> If you're using [Matrix Authentication Service](./configuring-playbook-matrix-authentication-service.md) (MAS) for authentication, you will be able to [log into synapse-admin with an access token](https://github.com/etkecc/synapse-admin/pull/58), but certain synapse-admin features (especially those around user management) will be limited or not work at all.
|
||||
|
||||
### Adjusting the Synapse Admin URL (optional)
|
||||
|
||||
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.
|
||||
@@ -89,5 +88,3 @@ To use Synapse Admin, you need to have [registered at least one administrator ac
|
||||
## Troubleshooting
|
||||
|
||||
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-synapse-admin`.
|
||||
|
||||
If you have questions, you can join this community room and feel free to ask: [#synapse-admin:etke.cc](https://matrix.to/#/#synapse-admin:etke.cc)
|
||||
|
||||
@@ -1,26 +1,45 @@
|
||||
<!--
|
||||
SPDX-FileCopyrightText: 2019 Eduardo Beltrame
|
||||
SPDX-FileCopyrightText: 2019-2025 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2020 Tulir Asokan
|
||||
SPDX-FileCopyrightText: 2021, 2024 MDAD project contributors
|
||||
SPDX-FileCopyrightText: 2022 Dennis Ciba
|
||||
SPDX-FileCopyrightText: 2022 Vladimir Panteleev
|
||||
SPDX-FileCopyrightText: 2023 Justin Croonenberghs
|
||||
SPDX-FileCopyrightText: 2023 Kuba Orlik
|
||||
SPDX-FileCopyrightText: 2023 Pierre 'McFly' Marty
|
||||
SPDX-FileCopyrightText: 2023 Samuel Meenzen
|
||||
SPDX-FileCopyrightText: 2024 Fabio Bonelli
|
||||
SPDX-FileCopyrightText: 2024-2026 Suguru Hirahara
|
||||
SPDX-FileCopyrightText: 2024 MDAD project contributors
|
||||
SPDX-FileCopyrightText: 2024 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2024 Suguru Hirahara
|
||||
|
||||
SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
-->
|
||||
|
||||
# Setting up Synapse Auto Invite Accept (optional, removed)
|
||||
# Setting up Synapse Auto Invite Accept (optional)
|
||||
|
||||
🪦 The playbook used to be able to install and configure [synapse-auto-invite-accept](https://github.com/matrix-org/synapse-auto-accept-invite), but no longer includes this component, as the same functionality [has been integrated](https://github.com/element-hq/synapse/pull/17147) to Synapse since [v1.109.0](https://github.com/element-hq/synapse/releases/tag/v1.109.0).
|
||||
The playbook can install and configure [synapse-auto-invite-accept](https://github.com/matrix-org/synapse-auto-accept-invite) for you.
|
||||
|
||||
In short, it automatically accepts room invites. You can specify that only 1:1 room invites are auto-accepted. Defaults to false if not specified.
|
||||
|
||||
See the project's [documentation](https://github.com/matrix-org/synapse-auto-accept-invite/blob/main/README.md) to learn what it does and why it might be useful to you.
|
||||
|
||||
**Note**: Synapse [v1.109.0](https://github.com/element-hq/synapse/releases/tag/v1.109.0), the same feature [has been merged](https://github.com/element-hq/synapse/pull/17147) into Synapse (see the [Native alternative](#native-alternative) section below). You'd better use the native feature, instead of the [synapse-auto-invite-accept](https://github.com/matrix-org/synapse-auto-accept-invite) 3rd party module.
|
||||
|
||||
## Adjusting the playbook configuration
|
||||
|
||||
If you decide that you'd like to let this playbook install the [synapse-auto-invite-accept](https://github.com/matrix-org/synapse-auto-accept-invite module for you, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
|
||||
|
||||
```yaml
|
||||
matrix_synapse_ext_synapse_auto_accept_invite_enabled: true
|
||||
|
||||
matrix_synapse_ext_synapse_auto_accept_invite_accept_invites_only_direct_messages: true
|
||||
```
|
||||
|
||||
### Synapse worker deployments
|
||||
|
||||
In a [workerized Synapse deployment](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/c9a842147e09647c355799ca024d65a5de66b099/docs/configuring-playbook-synapse.md#load-balancing-with-workers) it is possible to run this module on a worker to reduce the load on the main process (Default is `null`). For example, add this to your configuration:
|
||||
|
||||
```yaml
|
||||
matrix_synapse_ext_synapse_auto_accept_invite_worker_to_run_on: 'matrix-synapse-worker-generic-0'
|
||||
```
|
||||
|
||||
There might be an [issue with federation](https://github.com/matrix-org/synapse-auto-accept-invite/issues/18).
|
||||
|
||||
## Native alternative
|
||||
|
||||
Since Synapse [v1.109.0](https://github.com/element-hq/synapse/releases/tag/v1.109.0), the functionality provided by the [synapse-auto-invite-accept](https://github.com/matrix-org/synapse-auto-accept-invite) 3rd party module [has been made](https://github.com/element-hq/synapse/pull/17147) part of Synapse.
|
||||
|
||||
Here's example configuration for using the **native** Synapse feature:
|
||||
|
||||
```yaml
|
||||
|
||||
@@ -9,7 +9,7 @@ SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
|
||||
The playbook can install and configure [synapse-simple-antispam](https://github.com/t2bot/synapse-simple-antispam) for you.
|
||||
|
||||
It lets you fight invite-spam by automatically blocking invitations from a list of servers specified by you (blacklisting).
|
||||
It lets you fight invite-spam by automatically blocking invitiations from a list of servers specified by you (blacklisting).
|
||||
|
||||
See the project's [documentation](https://github.com/t2bot/synapse-simple-antispam/blob/master/README.md) to learn what it does and why it might be useful to you.
|
||||
|
||||
|
||||
@@ -53,7 +53,7 @@ You may also consider [tweaking the number of workers of each type](#controlling
|
||||
|
||||
##### Specialized workers
|
||||
|
||||
The playbook now supports a smarter **specialized load-balancing** inspired by [Tom Foster](https://github.com/tcpipuk)'s [Synapse homeserver guide](https://tcpipuk.github.io/synapse/index.html). Instead of routing requests to one or more [generic workers](#generic-workers) based only on the requester's IP address, specialized load-balancing routes to **4 different types of specialized workers** based on **smarter criteria** — the access token (username) of the requester and/or on the resource (room, etc.) being requested.
|
||||
The playbook now supports a smarter **specialized load-balancing** inspired by [Tom Foster](https://github.com/tcpipuk)'s [Synapse homeserver guide](https://tcpipuk.github.io/synapse/index.html). Instead of routing requests to one or more [generic workers](#generic-workers) based only on the requestor's IP adddress, specialized load-balancing routes to **4 different types of specialized workers** based on **smarter criteria** — the access token (username) of the requestor and/or on the resource (room, etc.) being requested.
|
||||
|
||||
The playbook supports these **4 types** of specialized workers:
|
||||
|
||||
@@ -80,29 +80,6 @@ A separate Ansible role (`matrix-synapse-reverse-proxy-companion`) and component
|
||||
|
||||
In case any problems occur, make sure to have a look at the [list of synapse issues about workers](https://github.com/element-hq/synapse/issues?q=workers+in%3Atitle) and your `journalctl --unit 'matrix-*'`.
|
||||
|
||||
### Limit joining heavy rooms on constrained hosts
|
||||
|
||||
If your server is underpowered, joining heavy rooms can cause Synapse to consume a lot of resources and be unavailable for long (while it catches up).
|
||||
|
||||
To avoid this, Synapse can be configured to reject joins for remote rooms that are too complex before users enter them.
|
||||
|
||||
Complexity is computed as `current_state_events / 500` (Synapse state event count for current room state). When the resulting value is higher than `matrix_synapse_limit_remote_rooms_complexity` and `matrix_synapse_limit_remote_rooms_enabled` is `true`, Synapse blocks joining the room.
|
||||
|
||||
We recommend using this as a guardrail on low-resource servers:
|
||||
|
||||
```yaml
|
||||
matrix_synapse_limit_remote_rooms_enabled: true
|
||||
|
||||
# Tweak as necessary
|
||||
matrix_synapse_limit_remote_rooms_complexity: 1.0
|
||||
|
||||
# Uncomment and tweak if necessary
|
||||
# matrix_synapse_limit_remote_rooms_complexity_error: "Your homeserver is unable to join rooms this large or complex. Please speak to your server administrator, or upgrade your instance to join this room."
|
||||
|
||||
# If you'd like your admins to be exempt from this limit, uncomment the line below
|
||||
# matrix_synapse_limit_remote_rooms_admins_can_join: true
|
||||
```
|
||||
|
||||
### Synapse + OpenID Connect for Single-Sign-On
|
||||
|
||||
💡 An alternative to setting up OIDC in Synapse is to use [Matrix Authentication Service](./configuring-playbook-matrix-authentication-service.md) (MAS). Newer clients (like Element X) only support SSO-based authentication via MAS and not via the legacy Synapse OIDC setup described below. That said, MAS is still a new experimental service which comes with its own downsides. Consult its documentation to learn if it will be a good fit for your deployment.
|
||||
|
||||
@@ -1,59 +1,39 @@
|
||||
<!--
|
||||
SPDX-FileCopyrightText: 2018-2024 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2020 Aaron Raimist
|
||||
SPDX-FileCopyrightText: 2019 - 2024 Slavi Pantaleev
|
||||
SPDX-FileCopyrightText: 2020 Christian Wolf
|
||||
SPDX-FileCopyrightText: 2020 MDAD project contributors
|
||||
SPDX-FileCopyrightText: 2020 Marcel Partap
|
||||
SPDX-FileCopyrightText: 2020-2024 MDAD project contributors
|
||||
SPDX-FileCopyrightText: 2022 Alejo Diaz
|
||||
SPDX-FileCopyrightText: 2022 Julian Foad
|
||||
SPDX-FileCopyrightText: 2024-2026 Suguru Hirahara
|
||||
SPDX-FileCopyrightText: 2024 - 2025 Suguru Hirahara
|
||||
|
||||
SPDX-License-Identifier: AGPL-3.0-or-later
|
||||
-->
|
||||
|
||||
# Configuring a TURN server (optional, advanced)
|
||||
|
||||
By default, the [coturn](https://github.com/coturn/coturn) TURN server component is enabled automatically only when [Jitsi](configuring-playbook-jitsi.md) is enabled. If you're not using Jitsi, coturn is not enabled by default.
|
||||
By default, this playbook installs and configures the [coturn](https://github.com/coturn/coturn) as a TURN server, through which clients can make audio/video calls even from [NAT](https://en.wikipedia.org/wiki/Network_address_translation)-ed networks. It also configures the Synapse chat server by default, so that it points to the coturn TURN server installed by the playbook. If that's okay, you can skip this document.
|
||||
|
||||
If you explicitly need coturn while not using Jitsi, enable it with:
|
||||
|
||||
```yaml
|
||||
coturn_enabled: true
|
||||
```
|
||||
|
||||
and configure its IP-related settings in the section below.
|
||||
|
||||
If you'd like coturn to stay disabled even when Jitsi is enabled, or if you prefer to use an external TURN provider, see [disabling coturn](#disabling-coturn) section below.
|
||||
|
||||
When Coturn is not enabled, homeservers (like Synapse) would not point to TURN servers and *legacy* audio/video call functionality may fail. If you're using [Matrix RTC](configuring-playbook-rtc.md) (for [Element Call](configuring-playbook-element-call.md)), you likely don't have a need to enable coturn.
|
||||
|
||||
## Adjusting firewall rules
|
||||
|
||||
To ensure Coturn functions correctly, the following firewall rules and port forwarding settings are required when coturn is enabled:
|
||||
|
||||
- `3478/tcp`: STUN/TURN over TCP
|
||||
- `3478/udp`: STUN/TURN over UDP
|
||||
- `5349/tcp`: TURN over TCP
|
||||
- `5349/udp`: TURN over UDP
|
||||
- `49152-49172/udp`: TURN/UDP relay range
|
||||
|
||||
💡 Docker configures the server's internal firewall for you. In most cases, you don't need to do anything special on the host itself.
|
||||
If you'd like to stop the playbook installing the server, see the section [below](#disabling-coturn) to check the configuration for disabling it.
|
||||
|
||||
## Adjusting the playbook configuration
|
||||
|
||||
### Define public IP manually (optional)
|
||||
|
||||
If you enable coturn (either via Jitsi or manually), we recommend that you configure the public IP addresses of your server in the `vars.yml` file:
|
||||
In the `hosts` file we explicitly ask for your server's external IP address when defining `ansible_host`, because the same value is used for configuring coturn.
|
||||
|
||||
If you'd rather use a local IP for `ansible_host`, add the following configuration to your `vars.yml` file. Make sure to replace `YOUR_PUBLIC_IP` with the pubic IP used by the server.
|
||||
|
||||
```yaml
|
||||
# You can define multiple IP addresses if your server has multiple external IP addresses
|
||||
coturn_turn_external_ip_addresses: ["YOUR_PUBLIC_IP"]
|
||||
matrix_coturn_turn_external_ip_address: "YOUR_PUBLIC_IP"
|
||||
```
|
||||
|
||||
If you'd like to rely on external IP address auto-detection (not recommended unless you need it), avoid configuring this variable. The playbook will automatically contact an [echoip](https://github.com/mpolden/echoip)-compatible service (`https://ifconfig.co/json` by default) to determine your server's IP address. This API endpoint is configurable via the `coturn_turn_external_ip_address_auto_detection_echoip_service_url` variable.
|
||||
If you'd like to rely on external IP address auto-detection (not recommended unless you need it), set an empty value to the variable. The playbook will automatically contact an [EchoIP](https://github.com/mpolden/echoip)-compatible service (`https://ifconfig.co/json` by default) to determine your server's IP address. This API endpoint is configurable via the `matrix_coturn_turn_external_ip_address_auto_detection_echoip_service_url` variable.
|
||||
|
||||
>[!NOTE]
|
||||
> You can self-host the echoip service by using the [Mother-of-All-Self-Hosting (MASH)](https://github.com/mother-of-all-self-hosting/mash-playbook) Ansible playbook. See [this page](https://github.com/mother-of-all-self-hosting/mash-playbook/blob/main/docs/services/echoip.md) for the instruction to install it with the playbook. If you are wondering how to use it for your Matrix server, refer to [this page](https://github.com/mother-of-all-self-hosting/mash-playbook/blob/main/docs/setting-up-services-on-mdad-server.md) for the overview.
|
||||
If your server has multiple external IP addresses, the coturn role offers a different variable for specifying them:
|
||||
|
||||
```yaml
|
||||
# Note: matrix_coturn_turn_external_ip_addresses is different than matrix_coturn_turn_external_ip_address
|
||||
matrix_coturn_turn_external_ip_addresses: ['1.2.3.4', '4.5.6.7']
|
||||
```
|
||||
|
||||
### Change the authentication mechanism (optional)
|
||||
|
||||
@@ -62,37 +42,20 @@ The playbook uses the [`auth-secret` authentication method](https://github.com/c
|
||||
To do so, add the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
coturn_authentication_method: lt-cred-mech
|
||||
matrix_coturn_authentication_method: lt-cred-mech
|
||||
```
|
||||
|
||||
Regardless of the selected authentication method, the playbook generates secrets automatically and passes them to the homeserver and coturn.
|
||||
|
||||
If [Jitsi](configuring-playbook-jitsi.md) is installed, note that switching to `lt-cred-mech` will disable the integration between Jitsi and your coturn server, as Jitsi seems to support the `auth-secret` authentication method only.
|
||||
|
||||
### Customize the Coturn hostname (optional)
|
||||
|
||||
By default, Coturn uses the same hostname as your Matrix homeserver (the value of `matrix_server_fqn_matrix`, which is typically `matrix.example.com`).
|
||||
|
||||
If you'd like to use a custom subdomain for Coturn (e.g., `turn.example.com` or `t.matrix.example.com`), add the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
coturn_hostname: turn.example.com
|
||||
```
|
||||
|
||||
The playbook will automatically:
|
||||
- Configure Coturn to use this hostname
|
||||
- Obtain an SSL certificate for the custom domain via Traefik
|
||||
- Update all TURN URIs to point to the custom domain
|
||||
|
||||
**Note**: Make sure the custom hostname resolves to your server's IP address via DNS before running the playbook.
|
||||
|
||||
### Use your own external coturn server (optional)
|
||||
|
||||
If you'd like to use another TURN server (be it coturn or some other one), add the following configuration to your `vars.yml` file. Make sure to replace `HOSTNAME_OR_IP` with your own.
|
||||
|
||||
```yaml
|
||||
# Disable integrated coturn server
|
||||
coturn_enabled: false
|
||||
matrix_coturn_enabled: false
|
||||
|
||||
# Point Synapse to your other coturn server
|
||||
matrix_synapse_turn_uris:
|
||||
@@ -113,15 +76,15 @@ You can put multiple host/port combinations if you'd like to.
|
||||
|
||||
### Edit the reloading schedule (optional)
|
||||
|
||||
By default the service is reloaded on 6:30 a.m. every day based on the `coturn_reload_schedule` variable so that new SSL certificates can kick in. It is defined in the format of systemd timer calendar.
|
||||
By default the service is reloaded on 6:30 a.m. every day based on the `matrix_coturn_reload_schedule` variable so that new SSL certificates can kick in. It is defined in the format of systemd timer calendar.
|
||||
|
||||
To edit the schedule, add the following configuration to your `vars.yml` file (adapt to your needs):
|
||||
|
||||
```yaml
|
||||
coturn_reload_schedule: "*-*-* 06:30:00"
|
||||
matrix_coturn_reload_schedule: "*-*-* 06:30:00"
|
||||
```
|
||||
|
||||
**Note**: the actual job may run with a delay. See `coturn_reload_schedule_randomized_delay_sec` for its default value.
|
||||
**Note**: the actual job may run with a delay. See `matrix_coturn_reload_schedule_randomized_delay_sec` for its default value.
|
||||
|
||||
### Extending the configuration
|
||||
|
||||
@@ -129,18 +92,18 @@ There are some additional things you may wish to configure about the TURN server
|
||||
|
||||
Take a look at:
|
||||
|
||||
- `roles/galaxy/coturn/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
|
||||
- `roles/custom/matrix-coturn/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
|
||||
|
||||
## Disabling coturn
|
||||
|
||||
Coturn is only enabled by default when [Jitsi](configuring-playbook-jitsi.md) is enabled. In most instances, you don't need to explicitly disable it.
|
||||
|
||||
To force the playbook to not install Coturn (even when Jitsi is enabled), add the following configuration to your `vars.yml` file:
|
||||
If, for some reason, you'd like for the playbook to not install coturn (or to uninstall it if it was previously installed), add the following configuration to your `vars.yml` file:
|
||||
|
||||
```yaml
|
||||
coturn_enabled: false
|
||||
matrix_coturn_enabled: false
|
||||
```
|
||||
|
||||
In that case, Synapse would not point to any coturn servers and audio/video call functionality may fail.
|
||||
|
||||
## Installing
|
||||
|
||||
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
|
||||
|
||||
@@ -51,7 +51,7 @@ For a more custom setup, see the [Other configuration options](#other-configurat
|
||||
|
||||
- [Configuring Conduit](configuring-playbook-conduit.md), if you've switched to the [Conduit](https://conduit.rs) homeserver implementation
|
||||
|
||||
- [Configuring continuwuity](configuring-playbook-continuwuity.md), if you've switched to the [continuwuity](https://continuwuity.org) homeserver implementation
|
||||
- [Configuring conduwuit](configuring-playbook-conduwuit.md), if you've switched to the [conduwuit](https://conduwuit.puppyirl.gay/) homeserver implementation
|
||||
|
||||
- [Configuring Dendrite](configuring-playbook-dendrite.md), if you've switched to the [Dendrite](https://matrix-org.github.io/dendrite) homeserver implementation
|
||||
|
||||
@@ -68,6 +68,8 @@ For a more custom setup, see the [Other configuration options](#other-configurat
|
||||
|
||||
- [Adjusting email-sending settings](configuring-playbook-email.md)
|
||||
|
||||
- [Setting up ma1sd Identity Server](configuring-playbook-ma1sd.md)
|
||||
|
||||
- [Setting up Dynamic DNS](configuring-playbook-dynamic-dns.md)
|
||||
|
||||
- Server connectivity:
|
||||
@@ -162,18 +164,28 @@ Bridges can be used to connect your Matrix installation with third-party communi
|
||||
|
||||
- [Setting up Appservice Discord bridging](configuring-playbook-bridge-appservice-discord.md)
|
||||
|
||||
- [Setting up Appservice Slack bridging](configuring-playbook-bridge-appservice-slack.md)
|
||||
|
||||
- [Setting up Appservice Kakaotalk bridging](configuring-playbook-bridge-appservice-kakaotalk.md)
|
||||
|
||||
- [Setting up Beeper LinkedIn bridging](configuring-playbook-bridge-beeper-linkedin.md)
|
||||
|
||||
- [Setting up matrix-hookshot](configuring-playbook-bridge-hookshot.md) — a bridge between Matrix and multiple project management services, such as [GitHub](https://github.com), [GitLab](https://about.gitlab.com) and [JIRA](https://www.atlassian.com/software/jira).
|
||||
|
||||
- [Setting up MX Puppet Slack bridging](configuring-playbook-bridge-mx-puppet-slack.md)
|
||||
|
||||
- [Setting up MX Puppet Instagram bridging](configuring-playbook-bridge-mx-puppet-instagram.md)
|
||||
|
||||
- [Setting up MX Puppet Twitter bridging](configuring-playbook-bridge-mx-puppet-twitter.md)
|
||||
|
||||
- [Setting up MX Puppet Discord bridging](configuring-playbook-bridge-mx-puppet-discord.md)
|
||||
|
||||
- [Setting up MX Puppet GroupMe bridging](configuring-playbook-bridge-mx-puppet-groupme.md)
|
||||
|
||||
- [Setting up Steam bridging](configuring-playbook-bridge-steam.md)
|
||||
|
||||
- [Setting up MX Puppet Steam bridging](configuring-playbook-bridge-mx-puppet-steam.md)
|
||||
|
||||
- [Setting up Go Skype Bridge bridging](configuring-playbook-bridge-go-skype-bridge.md)
|
||||
|
||||
- [Setting up Postmoogle email bridging](configuring-playbook-bridge-postmoogle.md)
|
||||
|
||||
- [Setting up Matrix SMS bridging](configuring-playbook-bridge-matrix-bridge-sms.md)
|
||||
@@ -233,12 +245,12 @@ Various services that don't fit any other categories.
|
||||
|
||||
- [Setting up Matrix RTC](configuring-playbook-matrix-rtc.md) (optional)
|
||||
|
||||
- [Setting up Synapse Auto Invite Accept](configuring-playbook-synapse-auto-accept-invite.md)
|
||||
|
||||
- [Setting up synapse-auto-compressor](configuring-playbook-synapse-auto-compressor.md) for compressing the database on Synapse homeservers
|
||||
|
||||
- [Setting up Matrix Corporal](configuring-playbook-matrix-corporal.md) (advanced)
|
||||
|
||||
- [Setting up Matrix.to](configuring-playbook-matrixto.md)
|
||||
|
||||
- [Setting up Etherpad](configuring-playbook-etherpad.md)
|
||||
|
||||
- [Setting up the Jitsi video-conferencing platform](configuring-playbook-jitsi.md)
|
||||
@@ -255,12 +267,8 @@ Various services that don't fit any other categories.
|
||||
|
||||
**Note**: since a deprecated or unmaintained service will not be updated, its bug or vulnerability will be unlikely to get patched. It is recommended to migrate from the service to an alternative if any, and make sure to do your own research before you decide to keep it running nonetheless.
|
||||
|
||||
- [Configuring conduwuit](configuring-playbook-conduwuit.md) (removed; this component has been abandoned and unmaintained)
|
||||
|
||||
- [Setting up the Sliding Sync proxy](configuring-playbook-sliding-sync-proxy.md) for clients which require Sliding Sync support (like old Element X versions, before it got switched to Simplified Sliding Sync)
|
||||
|
||||
- [Setting up Appservice Slack bridging](configuring-playbook-bridge-appservice-slack.md) (removed; this component has been discontinued)
|
||||
|
||||
- [Setting up Appservice Webhooks bridging](configuring-playbook-bridge-appservice-webhooks.md) (deprecated; the bridge's author suggests taking a look at [matrix-hookshot](https://github.com/matrix-org/matrix-hookshot) as a replacement, which can also be [installed using this playbook](configuring-playbook-bridge-hookshot.md))
|
||||
|
||||
- [Setting up the Dimension integration manager](configuring-playbook-dimension.md) ([unmaintained](https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/2806#issuecomment-1673559299); after [installing](installing.md))
|
||||
@@ -269,24 +277,10 @@ Various services that don't fit any other categories.
|
||||
|
||||
- [Setting up Go-NEB](configuring-playbook-bot-go-neb.md) (unmaintained; the bridge's author suggests taking a look at [matrix-hookshot](https://github.com/matrix-org/matrix-hookshot) as a replacement, which can also be [installed using this playbook](configuring-playbook-bridge-hookshot.md))
|
||||
|
||||
- [Setting up Go Skype Bridge bridging](configuring-playbook-bridge-go-skype-bridge.md) (removed; Skype has been discontinued since May 2025)
|
||||
|
||||
- [Setting up ma1sd Identity Server](configuring-playbook-ma1sd.md) (removed; this component has been unmaintained for a long time, so it has been removed from the playbook.)
|
||||
|
||||
- [Setting up matrix-bot-chatgpt](configuring-playbook-bot-chatgpt.md) (unmaintained; the bridge's author suggests taking a look at [baibot](https://github.com/etkecc/baibot) as a replacement, which can also be [installed using this playbook](configuring-playbook-bot-baibot.md))
|
||||
|
||||
- [Setting up Mautrix Facebook bridging](configuring-playbook-bridge-mautrix-facebook.md) (deprecated in favor of the Messenger/Instagram bridge with [mautrix-meta-messenger](configuring-playbook-bridge-mautrix-meta-messenger.md))
|
||||
|
||||
- [Setting up Mautrix Instagram bridging](configuring-playbook-bridge-mautrix-instagram.md) (deprecated in favor of the Messenger/Instagram bridge with [mautrix-meta-instagram](configuring-playbook-bridge-mautrix-meta-instagram.md))
|
||||
|
||||
- [Setting up MX Puppet Discord bridging](configuring-playbook-bridge-mx-puppet-discord.md) (removed; this component has been unmaintained for a long time, so it has been removed from the playbook. Consider [setting up Mautrix Discord bridging](configuring-playbook-bridge-mautrix-discord.md))
|
||||
|
||||
- [Setting up MX Puppet Instagram bridging](configuring-playbook-bridge-mx-puppet-instagram.md) (removed; this component has been unmaintained for a long time, so it has been removed from the playbook. Consider [setting up Instagram bridging via Mautrix Meta](configuring-playbook-bridge-mautrix-meta-instagram.md))
|
||||
|
||||
- [Setting up MX Puppet Skype bridging](configuring-playbook-bridge-mx-puppet-skype.md) (removed; this component has been broken for a long time, so it has been removed from the playbook. Consider [setting up Go Skype Bridge bridging](configuring-playbook-bridge-go-skype-bridge.md))
|
||||
|
||||
- [Setting up MX Puppet Slack bridging](configuring-playbook-bridge-mx-puppet-slack.md) (removed; this component has been unmaintained for a long time, so it has been removed from the playbook. Consider [setting up Mautrix Slack bridging](configuring-playbook-bridge-mautrix-slack.md))
|
||||
|
||||
- [Setting up MX Puppet Twitter bridging](configuring-playbook-bridge-mx-puppet-twitter.md) (removed; this component has been unmaintained for a long time, so it has been removed from the playbook. Consider [setting up Mautrix Twitter bridging](configuring-playbook-bridge-mautrix-twitter.md))
|
||||
|
||||
- [Setting up Synapse Auto Invite Accept](configuring-playbook-synapse-auto-accept-invite.md) (removed; since Synapse [v1.109.0](https://github.com/element-hq/synapse/releases/tag/v1.109.0) the same feature is available natively.)
|
||||
|
||||
@@ -27,7 +27,7 @@ We try to stick to official images (provided by their respective projects) as mu
|
||||
| ------- | --------------- | -------- | ----------- |
|
||||
| [Synapse](configuring-playbook-synapse.md) | [element-hq/synapse](https://ghcr.io/element-hq/synapse) | ✅ | Storing your data and managing your presence in the [Matrix](http://matrix.org/) network |
|
||||
| [Conduit](configuring-playbook-conduit.md) | [matrixconduit/matrix-conduit](https://hub.docker.com/r/matrixconduit/matrix-conduit) | ❌ | Storing your data and managing your presence in the [Matrix](http://matrix.org/) network. Conduit is a lightweight open-source server implementation of the Matrix Specification with a focus on easy setup and low system requirements |
|
||||
| [continuwuity](configuring-playbook-continuwuity.md) | [continuwuation/continuwuity](https://forgejo.ellis.link/continuwuation/continuwuity) | ❌ | Storing your data and managing your presence in the [Matrix](http://matrix.org/) network. continuwuity is a continuation of conduwuit. |
|
||||
| [conduwuit](configuring-playbook-conduwuit.md) | [girlbossceo/conduwuit](https://ghcr.io/girlbossceo/conduwuit) | ❌ | Storing your data and managing your presence in the [Matrix](http://matrix.org/) network. conduwuit is a fork of Conduit. |
|
||||
| [Dendrite](configuring-playbook-dendrite.md) | [matrixdotorg/dendrite-monolith](https://hub.docker.com/r/matrixdotorg/dendrite-monolith/) | ❌ | Storing your data and managing your presence in the [Matrix](http://matrix.org/) network. Dendrite is a second-generation Matrix homeserver written in Go, an alternative to Synapse. |
|
||||
|
||||
## Clients
|
||||
@@ -52,6 +52,7 @@ Services that run on the server to make the various parts of your installation w
|
||||
| [Traefik](configuring-playbook-traefik.md) | [Traefik](https://hub.docker.com/_/traefik/) | ✅ | Web server, listening on ports 80, 443 and 8448 — standing in front of all the other services. [Using your own webserver](configuring-playbook-own-webserver.md) is also possible. |
|
||||
| [Let's Encrypt](configuring-playbook-ssl-certificates.md) | [certbot/certbot](https://hub.docker.com/r/certbot/certbot/) | ✅ | [Certbot](https://certbot.eff.org/) tool for obtaining SSL certificates from [Let's Encrypt](https://letsencrypt.org/) |
|
||||
| [Exim](configuring-playbook-email.md) | [devture/exim-relay](https://hub.docker.com/r/devture/exim-relay/) | ✅ | Mail server, through which all Matrix services send outgoing email (can be configured to relay through another SMTP server) |
|
||||
| [ma1sd](configuring-playbook-ma1sd.md) | [ma1uta/ma1sd](https://hub.docker.com/r/ma1uta/ma1sd/) | ❌ | Matrix Identity Server |
|
||||
| [ddclient](configuring-playbook-dynamic-dns.md) | [linuxserver/ddclient](https://hub.docker.com/r/linuxserver/ddclient) | ❌ | Update dynamic DNS entries for accounts on Dynamic DNS Network Service Provider |
|
||||
| [LiveKit Server](configuring-playbook-livekit-server.md) | [livekit/livekit-server](https://hub.docker.com/r/livekit/livekit-server/) | ❌ | WebRTC server for audio/video calls |
|
||||
| [Livekit JWT Service](configuring-playbook-livekit-jwt-service.md) | [element-hq/lk-jwt-service](https://ghcr.io/element-hq/lk-jwt-service) | ❌ | JWT service for integrating [Element Call](./configuring-playbook-element-call.md) with [LiveKit Server](./configuring-playbook-livekit-server.md) |
|
||||
@@ -101,12 +102,17 @@ Bridges can be used to connect your Matrix installation with third-party communi
|
||||
| [matrix-appservice-irc](configuring-playbook-bridge-appservice-irc.md) | [matrixdotorg/matrix-appservice-irc](https://hub.docker.com/r/matrixdotorg/matrix-appservice-irc) | ❌ | Bridge to [IRC](https://wikipedia.org/wiki/Internet_Relay_Chat) |
|
||||
| [matrix-appservice-kakaotalk](configuring-playbook-bridge-appservice-kakaotalk.md) | Self-building | ❌ | Bridge to [Kakaotalk](https://www.kakaocorp.com/page/service/service/KakaoTalk?lang=ENG) |
|
||||
| [matrix-appservice-discord](configuring-playbook-bridge-appservice-discord.md) | [matrix-org/matrix-appservice-discord](https://ghcr.io/matrix-org/matrix-appservice-discord) | ❌ | Bridge to [Discord](https://discordapp.com/) |
|
||||
| [matrix-appservice-slack](configuring-playbook-bridge-appservice-slack.md) | [matrixdotorg/matrix-appservice-slack](https://hub.docker.com/r/matrixdotorg/matrix-appservice-slack) | ❌ | Bridge to [Slack](https://slack.com/) |
|
||||
| [matrix-hookshot](configuring-playbook-bridge-hookshot.md) | [halfshot/matrix-hookshot](https://hub.docker.com/r/halfshot/matrix-hookshot) | ❌ | Bridge for generic webhooks and multiple project management services, such as GitHub, GitLab, Figma, and Jira in particular |
|
||||
| [matrix-sms-bridge](configuring-playbook-bridge-matrix-bridge-sms.md) | [folivonet/matrix-sms-bridge](https://hub.docker.com/repository/docker/folivonet/matrix-sms-bridge) | ❌ | Bridge to SMS |
|
||||
| [matrix-wechat](configuring-playbook-bridge-wechat.md) | [lxduo/matrix-wechat](https://hub.docker.com/r/lxduo/matrix-wechat) | ❌ | Bridge to [WeChat](https://www.wechat.com/) |
|
||||
| [Heisenbridge](configuring-playbook-bridge-heisenbridge.md) | [hif1/heisenbridge](https://hub.docker.com/r/hif1/heisenbridge) | ❌ | Bouncer-style bridge to [IRC](https://wikipedia.org/wiki/Internet_Relay_Chat) |
|
||||
| [go-skype-bridge](configuring-playbook-bridge-go-skype-bridge.md) | [nodefyme/go-skype-bridge](https://hub.docker.com/r/nodefyme/go-skype-bridge) | ❌ | Bridge to [Skype](https://www.skype.com) |
|
||||
| [mx-puppet-slack](configuring-playbook-bridge-mx-puppet-slack.md) | [mx-puppet/slack/mx-puppet-slack](https://gitlab.com/mx-puppet/slack/mx-puppet-slack/container_registry) | ❌ | Bridge to [Slack](https://slack.com) |
|
||||
| [mx-puppet-instagram](configuring-playbook-bridge-mx-puppet-instagram.md) | [sorunome/mx-puppet-instagram](https://hub.docker.com/r/sorunome/mx-puppet-instagram) | ❌ | Bridge for Instagram-DMs ([Instagram](https://www.instagram.com/)) |
|
||||
| [mx-puppet-twitter](configuring-playbook-bridge-mx-puppet-twitter.md) | [sorunome/mx-puppet-twitter](https://hub.docker.com/r/sorunome/mx-puppet-twitter) | ❌ | Bridge for Twitter-DMs ([Twitter](https://twitter.com/)) |
|
||||
| [mx-puppet-discord](configuring-playbook-bridge-mx-puppet-discord.md) | [mx-puppet/discord/mx-puppet-discord](https://gitlab.com/mx-puppet/discord/mx-puppet-discord/container_registry) | ❌ | Bridge to [Discord](https://discordapp.com/) |
|
||||
| [mx-puppet-groupme](configuring-playbook-bridge-mx-puppet-groupme.md) | [xangelix/mx-puppet-groupme](https://hub.docker.com/r/xangelix/mx-puppet-groupme) | ❌ | Bridge to [GroupMe](https://groupme.com/) |
|
||||
| [matrix-steam-bridge](configuring-playbook-bridge-steam.md) | [jasonlaguidice/matrix-steam-bridge](https://github.com/jasonlaguidice/matrix-steam-bridge/pkgs/container/matrix-steam-bridge) | ❌ | Bridge to [Steam](https://steampowered.com/) |
|
||||
| [mx-puppet-steam](configuring-playbook-bridge-mx-puppet-steam.md) | [icewind1991/mx-puppet-steam](https://hub.docker.com/r/icewind1991/mx-puppet-steam) | ❌ | Bridge to [Steam](https://steamapp.com/) |
|
||||
| [Postmoogle](configuring-playbook-bridge-postmoogle.md) | [etke.cc/postmoogle](https://github.com/etkecc/postmoogle/container_registry) | ❌ | Email to Matrix bridge |
|
||||
|
||||
@@ -149,7 +155,9 @@ Various services that don't fit any other categories.
|
||||
|
||||
| Service | Container image | Default? | Description |
|
||||
| ------- | --------------- | -------- | ----------- |
|
||||
| [synapse_auto_compressor](configuring-playbook-synapse-auto-compressor.md) | [mb-saces/rust-synapse-tools](https://gitlab.com/mb-saces/rust-synapse-tools/container_registry) | ❌ | Cli tool that automatically compresses Synapse's `state_groups` database table in background |
|
||||
| [sliding-sync](configuring-playbook-sliding-sync-proxy.md) | [matrix-org/sliding-sync](https://ghcr.io/matrix-org/sliding-sync) | ❌ | Sliding Sync support for clients which require it (like old Element X versions, before it got switched to Simplified Sliding Sync) |
|
||||
| [synapse_auto_accept_invite](configuring-playbook-synapse-auto-accept-invite.md) | (N/A) | ❌ | Synapse module to automatically accept invites |
|
||||
| [synapse_auto_compressor](configuring-playbook-synapse-auto-compressor.md) | [etke.cc/rust-synapse-compress-state](https://gitlab.com/etke.cc/rust-synapse-compress-state/container_registry) | ❌ | Cli tool that automatically compresses `state_groups` database table in background |
|
||||
| [Matrix Corporal](configuring-playbook-matrix-corporal.md) (advanced) | [devture/matrix-corporal](https://hub.docker.com/r/devture/matrix-corporal/) | ❌ | Reconciliator and gateway for a managed Matrix server |
|
||||
| [Etherpad](configuring-playbook-etherpad.md) | [etherpad/etherpad](https://hub.docker.com/r/etherpad/etherpad/) | ❌ | Open source collaborative text editor |
|
||||
| [Jitsi](configuring-playbook-jitsi.md) | [jitsi/web](https://hub.docker.com/r/jitsi/web) | ❌ | [Jitsi](https://jitsi.org/) web UI |
|
||||
@@ -169,19 +177,10 @@ The list of the deprecated or unmaintained services is available [here](configur
|
||||
|
||||
| Service | Container image | Default? | Description |
|
||||
| ------- | --------------- | -------- | ----------- |
|
||||
| [conduwuit](configuring-playbook-conduwuit.md) | [girlbossceo/conduwuit](https://ghcr.io/girlbossceo/conduwuit) | ❌ | Storing your data and managing your presence in the [Matrix](http://matrix.org/) network. conduwuit was a fork of Conduit. |
|
||||
| [matrix-appservice-webhooks](configuring-playbook-bridge-appservice-webhooks.md) | [turt2live/matrix-appservice-webhooks](https://hub.docker.com/r/turt2live/matrix-appservice-webhooks) | ❌ | Bridge for slack compatible webhooks ([ConcourseCI](https://concourse-ci.org/), [Slack](https://slack.com/) etc. pp.) |
|
||||
| [Dimension](configuring-playbook-dimension.md) | [turt2live/matrix-dimension](https://hub.docker.com/r/turt2live/matrix-dimension) | ❌ | Open source integration manager for Matrix clients |
|
||||
| [Email2Matrix](configuring-playbook-email2matrix.md) | [devture/email2matrix](https://hub.docker.com/r/devture/email2matrix/) | ❌ | Bridge for relaying emails to Matrix rooms |
|
||||
| [Go-NEB](configuring-playbook-bot-go-neb.md) | [matrixdotorg/go-neb](https://hub.docker.com/r/matrixdotorg/go-neb) | ❌ | Multi functional bot written in Go |
|
||||
| [ma1sd](configuring-playbook-ma1sd.md) | [ma1uta/ma1sd](https://hub.docker.com/r/ma1uta/ma1sd/) | ❌ | Matrix Identity Server |
|
||||
| [matrix-appservice-slack](configuring-playbook-bridge-appservice-slack.md) | [matrixdotorg/matrix-appservice-slack](https://hub.docker.com/r/matrixdotorg/matrix-appservice-slack) | ❌ | Bridge to [Slack](https://slack.com/) |
|
||||
| [matrix-appservice-webhooks](configuring-playbook-bridge-appservice-webhooks.md) | [turt2live/matrix-appservice-webhooks](https://hub.docker.com/r/turt2live/matrix-appservice-webhooks) | ❌ | Bridge for slack compatible webhooks ([ConcourseCI](https://concourse-ci.org/), [Slack](https://slack.com/) etc. pp.) |
|
||||
| [matrix-chatgpt-bot](configuring-playbook-bot-chatgpt.md) | [matrixgpt/matrix-chatgpt-bot](https://ghcr.io/matrixgpt/matrix-chatgpt-bot) | ❌ | Accessing ChatGPT via your favourite Matrix client |
|
||||
| [mautrix-facebook](configuring-playbook-bridge-mautrix-facebook.md) | [mautrix/facebook](https://mau.dev/mautrix/facebook/container_registry) | ❌ | Bridge to [Facebook](https://facebook.com/) |
|
||||
| [mautrix-instagram](configuring-playbook-bridge-mautrix-instagram.md) | [mautrix/instagram](https://mau.dev/mautrix/instagram/container_registry) | ❌ | Bridge to [Instagram](https://instagram.com/) |
|
||||
| [mx-puppet-discord](configuring-playbook-bridge-mx-puppet-discord.md) | [mx-puppet/discord/mx-puppet-discord](https://gitlab.com/mx-puppet/discord/mx-puppet-discord/container_registry) | ❌ | Bridge to [Discord](https://discordapp.com/) |
|
||||
| [mx-puppet-instagram](configuring-playbook-bridge-mx-puppet-instagram.md) | [sorunome/mx-puppet-instagram](https://hub.docker.com/r/sorunome/mx-puppet-instagram) | ❌ | Bridge for Instagram-DMs ([Instagram](https://www.instagram.com/)) |
|
||||
| [mx-puppet-slack](configuring-playbook-bridge-mx-puppet-slack.md) | [mx-puppet/slack/mx-puppet-slack](https://gitlab.com/mx-puppet/slack/mx-puppet-slack/container_registry) | ❌ | Bridge to [Slack](https://slack.com) |
|
||||
| [mx-puppet-twitter](configuring-playbook-bridge-mx-puppet-twitter.md) | [sorunome/mx-puppet-twitter](https://hub.docker.com/r/sorunome/mx-puppet-twitter) | ❌ | Bridge for Twitter-DMs ([Twitter](https://twitter.com/)) |
|
||||
| [sliding-sync](configuring-playbook-sliding-sync-proxy.md) | [matrix-org/sliding-sync](https://ghcr.io/matrix-org/sliding-sync) | ❌ | Sliding Sync support for clients which require it (like old Element X versions, before it got switched to Simplified Sliding Sync) |
|
||||
| [synapse_auto_accept_invite](configuring-playbook-synapse-auto-accept-invite.md) | (N/A) | ❌ | Synapse module to automatically accept invites |
|
||||
|
||||
44
docs/faq.md
44
docs/faq.md
@@ -235,7 +235,7 @@ Running Matrix on a server with 1GB of memory is possible (especially if you dis
|
||||
|
||||
**We recommend starting with a server having at least 2GB of memory** and even then using it sparingly. If you know for sure you'll be joining various large rooms, etc., then going for 4GB of memory or more is a good idea.
|
||||
|
||||
Besides the regular Matrix stuff, we also support things like video-conferencing using [Jitsi](configuring-playbook-jitsi.md) and other additional services which (when installed) may use up a lot of memory. Things do add up. Besides the Synapse Matrix server, Jitsi is especially notorious for consuming a lot of resources. If you plan on running Jitsi, we recommend a server with at least 2GB of memory (preferably more). See our [Jitsi documentation page](configuring-playbook-jitsi.md) to learn how to optimize its memory/CPU usage.
|
||||
Besides the regular Matrix stuff, we also support things like video-conferencing using [Jitsi](configuring-playbook-jitsi.md) and other additional services which (when installed) may use up a lot of memory. Things do add up. Besides the Synapse Matrix server, Jitsi is especially notorious for consuming a lot of resources. If you plan on running Jitsi, we recommend a server with at least 2GB of memory (preferrably more). See our [Jitsi documentation page](configuring-playbook-jitsi.md) to learn how to optimize its memory/CPU usage.
|
||||
|
||||
### Can I run this in an LXC container?
|
||||
|
||||
@@ -305,23 +305,18 @@ See [Serving the base domain](configuring-playbook-base-domain-serving.md).
|
||||
|
||||
### How do I optimize this setup for a low-power server?
|
||||
|
||||
For a low-power server, it's best to use an alternative homeserver implementation (other than [Synapse](configuring-playbook-synapse.md)).
|
||||
|
||||
You can disable some not-so-important services to save on memory.
|
||||
|
||||
```yaml
|
||||
# Disabling this will prevent email-notifications and other such things from working.
|
||||
exim_relay_enabled: false
|
||||
```
|
||||
|
||||
If you've installed [Jitsi](configuring-playbook-jitsi.md) (not installed by default), there are additional optimizations listed on its documentation page that you can perform.
|
||||
# You can also disable this to save more RAM,
|
||||
# at the expense of audio/video calls being unreliable.
|
||||
matrix_coturn_enabled: false
|
||||
|
||||
|
||||
#### Synapse-specific optimizations
|
||||
|
||||
If you're using [Synapse](configuring-playbook-synapse.md), you can also consider the following optimizations:
|
||||
|
||||
```yaml
|
||||
# This makes Synapse not keep track of who is online/offline.
|
||||
#
|
||||
# Keeping track of this and announcing such online-status in federated rooms with
|
||||
# hundreds of servers inside is insanely heavy (https://github.com/matrix-org/synapse/issues/3971).
|
||||
#
|
||||
@@ -329,14 +324,18 @@ If you're using [Synapse](configuring-playbook-synapse.md), you can also conside
|
||||
matrix_synapse_presence_enabled: false
|
||||
```
|
||||
|
||||
You can also consider [implementing a restriction on room complexity](configuring-playbook-synapse.md#limit-joining-heavy-rooms-on-constrained-hosts), in order to prevent users from joining very heavy rooms:
|
||||
You can also consider implementing a restriction on room complexity, in order to prevent users from joining very heavy rooms:
|
||||
|
||||
```yaml
|
||||
# See: docs/configuring-playbook-synapse.md#limit-joining-heavy-rooms-on-constrained-hosts
|
||||
matrix_synapse_limit_remote_rooms_enabled: true
|
||||
matrix_synapse_limit_remote_rooms_complexity: 1.0
|
||||
matrix_synapse_configuration_extension_yaml: |
|
||||
limit_remote_rooms:
|
||||
enabled: true
|
||||
complexity: 1.0 # this limits joining complex (~large) rooms, can be
|
||||
# increased, but larger values can require more RAM
|
||||
```
|
||||
|
||||
If you've installed [Jitsi](configuring-playbook-jitsi.md) (not installed by default), there are additional optimizations listed on its documentation page that you can perform.
|
||||
|
||||
### I already have Docker on my server. Can you stop installing Docker via the playbook?
|
||||
|
||||
Yes, we can stop installing Docker ourselves. Just use this in your `vars.yml` file:
|
||||
@@ -363,7 +362,7 @@ Configuration variables are defined in multiple places in this playbook and are
|
||||
|
||||
You can discover the variables you can override in each role (`roles/*/*/defaults/main.yml`).
|
||||
|
||||
As described in [How is the effective configuration determined?](#how-is-the-effective-configuration-determined), these role-defaults may be overridden by values defined in `group_vars/matrix_servers`.
|
||||
As described in [How is the effective configuration determined?](#how-is-the-effective-configuration-determined), these role-defaults may be overriden by values defined in `group_vars/matrix_servers`.
|
||||
|
||||
Refer to both of these for inspiration. Still, as mentioned in [Configuring the playbook](configuring-playbook.md), you're only ever supposed to edit your own `inventory/host_vars/matrix.example.com/vars.yml` file and nothing else inside the playbook (unless you're meaning to contribute new features).
|
||||
|
||||
@@ -441,19 +440,6 @@ To prevent double-logging, Docker logging is disabled by explicitly passing `--l
|
||||
|
||||
See [this section](maintenance-and-troubleshooting.md#how-to-see-the-logs) on the page for maintenance and troubleshooting for more details to see the logs.
|
||||
|
||||
### The server fails to start due to the `Unable to start service matrix-coturn.service` error. Why and how to solve it?
|
||||
|
||||
The error is most likely because Traefik cannot obtain SSL certificates due to certain reasons such as wrong domain name configuration or port 80 being unavailable due to other services.
|
||||
|
||||
If Traefik fails to obtain an SSL certificate for domain names such as `matrix.`, Traefik Certs Dumper cannot extract the SSL certificate out of there, and coturn cannot be started and the error occurs. Refer to these comments for details:
|
||||
|
||||
- <https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/3957#issuecomment-2599590441>
|
||||
- <https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/4570#issuecomment-3364111466>
|
||||
|
||||
If you are not sure what the problem is, at first make sure that you have set the "base domain" (`example.com`, **not `matrix.example.com`**) to `matrix_domain`. You should be able to find it at the top of your `vars.yml`.
|
||||
|
||||
If it is correctly specified, look Traefik's logs (`journalctl -fu matrix-traefik.service`) for errors by Let's Encrypt for troubleshooting.
|
||||
|
||||
## Miscellaneous
|
||||
|
||||
### I would like to see this favorite service of mine integrated and become available on my Matrix server. How can I request it?
|
||||
|
||||
@@ -26,7 +26,7 @@ The up-to-date list can be accessed on [traefik's documentation](https://doc.tra
|
||||
|
||||
**Note**: the changes below instruct you how to do this for a basic Synapse installation. You will need to adapt the variable name and the content of the labels:
|
||||
|
||||
- if you're using another homeserver implementation (e.g. [Conduit](./configuring-playbook-conduit.md), [continuwuity](./configuring-playbook-continuwuity.md) or [Dendrite](./configuring-playbook-dendrite.md))
|
||||
- if you're using another homeserver implementation (e.g. [Conduit](./configuring-playbook-conduit.md), [conduwuit](./configuring-playbook-conduwuit.md) or [Dendrite](./configuring-playbook-dendrite.md))
|
||||
- if you're using [Synapse with workers enabled](./configuring-playbook-synapse.md#load-balancing-with-workers) (`matrix_synapse_workers_enabled: true`). In that case, it's actually the `matrix-synapse-reverse-proxy-companion` service which has Traefik labels attached
|
||||
|
||||
Also, all instructions below are from an older version of the playbook and may not work anymore.
|
||||
@@ -42,7 +42,7 @@ This is because with SRV federation, some servers / tools (one of which being th
|
||||
|
||||
### Tell Traefik which certificate to serve for the federation endpoint
|
||||
|
||||
Now that the federation endpoint is not bound to a domain anymore we need to explicitly tell Traefik to use a wildcard certificate in addition to one containing the base name.
|
||||
Now that the federation endpoint is not bound to a domain anymore we need to explicitely tell Traefik to use a wildcard certificate in addition to one containing the base name.
|
||||
|
||||
This is because the Matrix specification expects the federation endpoint to be served using a certificate compatible with the base domain, however, the other resources on the endpoint still need a valid certificate to work.
|
||||
|
||||
@@ -79,7 +79,7 @@ traefik_configuration_extension_yaml: |
|
||||
- "8.8.8.8:53"
|
||||
storage: {{ traefik_config_certificatesResolvers_acme_storage | to_json }}
|
||||
|
||||
# 2. Configure the environment variables needed by Traefik to automate the ACME DNS Challenge (example for Cloudflare)
|
||||
# 2. Configure the environment variables needed by Rraefik to automate the ACME DNS Challenge (example for Cloudflare)
|
||||
traefik_environment_variables: |
|
||||
CF_API_EMAIL=redacted
|
||||
CF_ZONE_API_TOKEN=redacted
|
||||
@@ -104,24 +104,24 @@ This should not happen again afterwards as Traefik will renew certificates well
|
||||
|
||||
```yaml
|
||||
# Only depend on docker.service, this removes the dependency on the certificate exporter, might imply the need to manually restart coturn on the first installation once the certificates are obtained, afterwards, the reload service should handle things
|
||||
coturn_systemd_required_services_list: ['docker.service']
|
||||
matrix_coturn_systemd_required_services_list: ['docker.service']
|
||||
|
||||
# This changes the path of the loaded certificate, while maintaining the original functionality, we're now loading the wildcard certificate.
|
||||
coturn_container_additional_volumes: |
|
||||
matrix_coturn_container_additional_volumes: |
|
||||
{{
|
||||
(
|
||||
[
|
||||
{
|
||||
'src': (traefik_certs_dumper_dumped_certificates_path + '/*.' + matrix_domain + '/certificate.crt'),
|
||||
'src': (traefik_certs_dumper_dumped_certificates_dir_path + '/*.' + matrix_domain + '/certificate.crt'),
|
||||
'dst': '/certificate.crt',
|
||||
'options': 'ro',
|
||||
},
|
||||
{
|
||||
'src': (traefik_certs_dumper_dumped_certificates_path + '/*.' + matrix_domain + '/privatekey.key'),
|
||||
'src': (traefik_certs_dumper_dumped_certificates_dir_path + '/*.' + matrix_domain + '/privatekey.key'),
|
||||
'dst': '/privatekey.key',
|
||||
'options': 'ro',
|
||||
},
|
||||
] if matrix_playbook_reverse_proxy_type in ['playbook-managed-traefik', 'other-traefik-container'] and traefik_certs_dumper_enabled and coturn_tls_enabled else []
|
||||
] if matrix_playbook_reverse_proxy_type in ['playbook-managed-traefik', 'other-traefik-container'] and traefik_certs_dumper_enabled and matrix_coturn_tls_enabled else []
|
||||
)
|
||||
}}
|
||||
```
|
||||
@@ -165,24 +165,24 @@ traefik_environment_variables: |
|
||||
LEGO_DISABLE_CNAME_SUPPORT=true
|
||||
|
||||
# Only depend on docker.service, this removes the dependency on the certificate exporter, might imply the need to manually restart coturn on the first installation once the certificates are obtained, afterwards, the reload service should handle things
|
||||
coturn_systemd_required_services_list: ['docker.service']
|
||||
matrix_coturn_systemd_required_services_list: ['docker.service']
|
||||
|
||||
# This changes the path of the loaded certificate, while maintaining the original functionality, we're now loading the wildcard certificate.
|
||||
coturn_container_additional_volumes: |
|
||||
matrix_coturn_container_additional_volumes: |
|
||||
{{
|
||||
(
|
||||
[
|
||||
{
|
||||
'src': (traefik_certs_dumper_dumped_certificates_path + '/*.' + matrix_domain + '/certificate.crt'),
|
||||
'src': (traefik_certs_dumper_dumped_certificates_dir_path + '/*.' + matrix_domain + '/certificate.crt'),
|
||||
'dst': '/certificate.crt',
|
||||
'options': 'ro',
|
||||
},
|
||||
{
|
||||
'src': (traefik_certs_dumper_dumped_certificates_path + '/*.' + matrix_domain + '/privatekey.key'),
|
||||
'src': (traefik_certs_dumper_dumped_certificates_dir_path + '/*.' + matrix_domain + '/privatekey.key'),
|
||||
'dst': '/privatekey.key',
|
||||
'options': 'ro',
|
||||
},
|
||||
] if matrix_playbook_reverse_proxy_type in ['playbook-managed-traefik', 'other-traefik-container'] and traefik_certs_dumper_enabled and coturn_tls_enabled else []
|
||||
] if matrix_playbook_reverse_proxy_type in ['playbook-managed-traefik', 'other-traefik-container'] and traefik_certs_dumper_enabled and matrix_coturn_tls_enabled else []
|
||||
)
|
||||
}}
|
||||
```
|
||||
|
||||
@@ -146,7 +146,6 @@ After completing the installation, you can:
|
||||
- or learn how to [maintain your server](faq.md#maintenance)
|
||||
- or join some Matrix rooms:
|
||||
* via the *Explore rooms* feature in Element Web or some other clients, or by discovering them using this [matrix-static list](https://view.matrix.org). **Note**: joining large rooms may overload small servers.
|
||||
For tuning guidance on constrained hosts, see [Limit joining heavy rooms on constrained hosts](configuring-playbook-synapse.md#limit-joining-heavy-rooms-on-constrained-hosts).
|
||||
* or come say Hi in our support room — [#matrix-docker-ansible-deploy:devture.com](https://matrix.to/#/#matrix-docker-ansible-deploy:devture.com). You might learn something or get to help someone else new to Matrix hosting.
|
||||
- or help make this playbook better by contributing (code, documentation, or [coffee/beer](https://liberapay.com/s.pantaleev/donate))
|
||||
|
||||
@@ -158,8 +157,6 @@ The upstream projects, which this playbook makes use of, occasionally if not oft
|
||||
|
||||
Since it is unsafe to keep outdated services running on the server connected to the internet, please consider to update the playbook and re-run it periodically, in order to keep the services up-to-date.
|
||||
|
||||
Also, do not forget to update your system regularly. While this playbook may install basic services, such as Docker, it will not interfere further with system maintenance. Keeping the system itself up-to-date is out of scope for this playbook.
|
||||
|
||||
For more information about upgrading or maintaining services with the playbook, take a look at this page: [Upgrading the Matrix services](maintenance-upgrading-services.md)
|
||||
|
||||
Feel free to **re-run the setup command any time** you think something is wrong with the server configuration. Ansible will take your configuration and update your server to match.
|
||||
|
||||
10
docs/just.md
10
docs/just.md
@@ -43,13 +43,3 @@ For example, these two commands are different:
|
||||
The just recipe runs `ensure-matrix-users-created` and `start` tags after `install-all`, while the latter runs only `install-all` tag. The correct shortcut of the latter is `just run-tags install-all`.
|
||||
|
||||
Such kind of difference sometimes matters. For example, when you install a Matrix server into which you will import old data (see [here](installing.md#installing-a-server-into-which-youll-import-old-data)), you are not supposed to run `just install-all` or `just setup-all`, because these commands start services immediately after installing components, which may prevent you from importing the data.
|
||||
|
||||
## Conditional service restart
|
||||
|
||||
When running `install-all` or `install-service` (whether via `just` or raw `ansible-playbook`), only services whose configuration or container image actually changed during the playbook run will be restarted. Unchanged services are left running (or get started if they were stopped). This reduces unnecessary downtime.
|
||||
|
||||
When running with `setup-*` tags (e.g. `setup-all`, `setup-synapse`), all services are unconditionally restarted regardless of whether changes were detected. This is appropriate for setup's thorough "full setup" semantics.
|
||||
|
||||
`start-all` and `start-group` always restart all targeted services, since no installation tasks run during these commands.
|
||||
|
||||
This behavior is automatically determined based on the playbook tags in use. It can be overridden with the `devture_systemd_service_manager_conditional_restart_enabled` variable. For example, to force unconditional restarts during installation: `just install-all --extra-vars='devture_systemd_service_manager_conditional_restart_enabled=false'`
|
||||
|
||||
@@ -104,12 +104,12 @@ To save disk space in `/tmp`, the dump file is gzipped on the fly at the expense
|
||||
|
||||
PostgreSQL can be [tuned](https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server) to make it run faster. This is done by passing extra arguments to the Postgres process.
|
||||
|
||||
The [Postgres Ansible role](https://github.com/mother-of-all-self-hosting/ansible-role-postgres) **already does some tuning by default**, which matches the [tuning logic](https://github.com/le0pard/pgtune/blob/master/src/features/configuration/configurationSlice.js) done by websites like https://pgtune.leopard.in.ua/. You can manually influence some of the tuning variables. These parameters (variables) are injected via the `postgres_postgres_process_extra_arguments_default` variable.
|
||||
The [Postgres Ansible role](https://github.com/mother-of-all-self-hosting/ansible-role-postgres) **already does some tuning by default**, which matches the [tuning logic](https://github.com/le0pard/pgtune/blob/master/src/features/configuration/configurationSlice.js) done by websites like https://pgtune.leopard.in.ua/. You can manually influence some of the tuning variables. These parameters (variables) are injected via the `postgres_postgres_process_extra_arguments_auto` variable.
|
||||
|
||||
Most users should be fine with the automatically-done tuning. However, you may wish to:
|
||||
|
||||
- **adjust the automatically-determined tuning parameters manually**: change the values for the tuning variables defined in the Postgres role's [default configuration file](https://github.com/mother-of-all-self-hosting/ansible-role-postgres/blob/main/defaults/main.yml) (see `postgres_max_connections`, `postgres_data_storage` etc). These variables are ultimately passed to Postgres via a `postgres_postgres_process_extra_arguments_default` variable
|
||||
- **adjust the automatically-determined tuning parameters manually**: change the values for the tuning variables defined in the Postgres role's [default configuration file](https://github.com/mother-of-all-self-hosting/ansible-role-postgres/blob/main/defaults/main.yml) (see `postgres_max_connections`, `postgres_data_storage` etc). These variables are ultimately passed to Postgres via a `postgres_postgres_process_extra_arguments_auto` variable
|
||||
|
||||
- **turn automatically-performed tuning off**: override it like this: `postgres_postgres_process_extra_arguments_default: []`
|
||||
- **turn automatically-performed tuning off**: override it like this: `postgres_postgres_process_extra_arguments_auto: []`
|
||||
|
||||
- **add additional tuning parameters**: define your additional Postgres configuration parameters in `postgres_postgres_process_extra_arguments_custom`. See `postgres_postgres_process_extra_arguments_default` defined in the Postgres role's [default configuration file](https://github.com/mother-of-all-self-hosting/ansible-role-postgres/blob/main/defaults/main.yml) for inspiration
|
||||
- **add additional tuning parameters**: define your additional Postgres configuration parameters in `postgres_postgres_process_extra_arguments_custom`. See `postgres_postgres_process_extra_arguments_auto` defined in the Postgres role's [default configuration file](https://github.com/mother-of-all-self-hosting/ansible-role-postgres/blob/main/defaults/main.yml) for inspiration
|
||||
|
||||
@@ -83,8 +83,6 @@ You should then be able to browse the adminer database administration GUI at htt
|
||||
|
||||
Synapse's presence feature which tracks which users are online and which are offline can use a lot of processing power. You can disable presence by adding `matrix_synapse_presence_enabled: false` to your `vars.yml` file.
|
||||
|
||||
On smaller servers, consider limiting joins to very complex rooms with [the room complexity guard](configuring-playbook-synapse.md#limit-joining-heavy-rooms-on-constrained-hosts).
|
||||
|
||||
If you have enough compute resources (CPU & RAM), you can make Synapse better use of them by [enabling load-balancing with workers](configuring-playbook-synapse.md#load-balancing-with-workers).
|
||||
|
||||
[Tuning your PostgreSQL database](maintenance-postgres.md#tuning-postgresql) could also improve Synapse performance. The playbook tunes the integrated Postgres database automatically, but based on your needs you may wish to adjust tuning variables manually. If you're using an [external Postgres database](configuring-playbook-external-postgres.md), you will also need to tune Postgres manually.
|
||||
|
||||
@@ -23,6 +23,8 @@ We will be using `example.com` as the domain in the following instruction. Pleas
|
||||
|
||||
- [Ansible](http://ansible.com/) program. It's used to run this playbook and configures your server for you. Take a look at [our guide about Ansible](ansible.md) for more information, as well as [version requirements](ansible.md#supported-ansible-versions) and alternative ways to run Ansible.
|
||||
|
||||
- [passlib](https://passlib.readthedocs.io/en/stable/index.html) Python library. See [this official documentation](https://passlib.readthedocs.io/en/stable/install.html#installation-instructions) for an instruction to install it. On most distros, you need to install some `python-passlib` or `py3-passlib` package, etc.
|
||||
|
||||
- [`git`](https://git-scm.com/) as the recommended way to download the playbook. `git` may also be required on the server if you will be [self-building](self-building.md) components.
|
||||
|
||||
- [`just`](https://github.com/casey/just) for running `just roles`, `just update`, etc. (see [`justfile`](../justfile)), although you can also run these commands manually. Take a look at this documentation for more information: [Running `just` commands](just.md).
|
||||
@@ -47,7 +49,7 @@ We will be using `example.com` as the domain in the following instruction. Pleas
|
||||
|
||||
- [Python](https://www.python.org/). Most distributions install Python by default, but some don't (e.g. Ubuntu 18.04) and require manual installation (something like `apt-get install python3`). On some distros, Ansible may incorrectly [detect the Python version](https://docs.ansible.com/ansible/latest/reference_appendices/interpreter_discovery.html) (2 vs 3) and you may need to explicitly specify the interpreter path in `inventory/hosts` during installation (e.g. `ansible_python_interpreter=/usr/bin/python3`)
|
||||
|
||||
- [sudo](https://www.sudo.ws/), even when you've configured Ansible to log in as `root`, because this Ansible playbook sometimes uses the Ansible [become](https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_privilege_escalation.html) module to perform tasks as another user (e.g. `matrix`) and the `become` module's default implementation uses `sudo`. Some distributions, like a minimal Debian net install, do not include the `sudo` package by default.
|
||||
- [sudo](https://www.sudo.ws/), even when you've configured Ansible to log in as `root`. Some distributions, like a minimal Debian net install, do not include the `sudo` package by default.
|
||||
|
||||
- An HTTPS-capable web server at the base domain name (`example.com`) 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).
|
||||
|
||||
@@ -57,7 +59,12 @@ We will be using `example.com` as the domain in the following instruction. Pleas
|
||||
|
||||
- `80/tcp`: HTTP webserver
|
||||
- `443/tcp` and `443/udp`: HTTPS webserver
|
||||
- `3478/tcp`: STUN/TURN over TCP (used by [coturn](./configuring-playbook-turn.md))
|
||||
- `3478/udp`: STUN/TURN over TCP (used by [coturn](./configuring-playbook-turn.md))
|
||||
- `5349/tcp`: TURN over TCP (used by [coturn](./configuring-playbook-turn.md))
|
||||
- `5349/udp`: TURN over UDP (used by [coturn](./configuring-playbook-turn.md))
|
||||
- `8448/tcp` and `8448/udp`: Matrix Federation API HTTPS webserver. Some components like [Matrix User Verification Service](configuring-playbook-user-verification-service.md#open-matrix-federation-port) require this port to be opened **even with federation disabled**.
|
||||
- the range `49152-49172/udp`: TURN over UDP
|
||||
- potentially some other ports, depending on the additional (non-default) services that you enable in the **configuring the playbook** step (later on). Consult each service's documentation page in `docs/` for that.
|
||||
|
||||
---------------------------------------------
|
||||
|
||||
@@ -161,6 +161,6 @@ You can then proceed to run the query above.
|
||||
|
||||
### Adding/Removing Administrator privileges to an existing user in Matrix Authentication Service
|
||||
|
||||
Promoting/demoting a user in Matrix Authentication Service can be done using the [`mas-cli`](./configuring-playbook-matrix-authentication-service.md#management) management tool's [`manage promote-admin`](https://element-hq.github.io/matrix-authentication-service/reference/cli/manage.html#manage-promote-admin) and [`manage demote-admin`](https://element-hq.github.io/matrix-authentication-service/reference/cli/manage.html#manage-demote-admin) commands. For example: `/matrix/matrix-authentication-service/bin/mas-cli manage promote-admin some.username`.
|
||||
Promoting/demoting a user in Matrix Authentication Service cannot currently (2024-10-19) be done via the [`mas-cli` Management tool](./configuring-playbook-matrix-authentication-service.md#management).
|
||||
|
||||
You can also do it via the [MAS Admin API](https://element-hq.github.io/matrix-authentication-service/api/index.html)'s `POST /api/admin/v1/users/{id}/set-admin` endpoint.
|
||||
You can do it via the [MAS Admin API](https://element-hq.github.io/matrix-authentication-service/api/index.html)'s `POST /api/admin/v1/users/{id}/set-admin` endpoint.
|
||||
|
||||
@@ -28,15 +28,20 @@ Possibly outdated list of roles where self-building the Docker image is currentl
|
||||
- `matrix-synapse`
|
||||
- `matrix-synapse-admin`
|
||||
- `matrix-client-element`
|
||||
- `hydrogen`
|
||||
- `cinny`
|
||||
- `matrix-client-hydrogen`
|
||||
- `matrix-client-cinny`
|
||||
- `matrix-registration`
|
||||
- `coturn`
|
||||
- `matrix-coturn`
|
||||
- `matrix-corporal`
|
||||
- `matrix-dimension`
|
||||
- `matrix-ma1sd`
|
||||
- `exim-relay`
|
||||
- `matrix-bridge-hookshot`
|
||||
- `matrix-bridge-appservice-irc`
|
||||
- `matrix-bridge-appservice-slack`
|
||||
- `matrix-bridge-appservice-webhooks`
|
||||
- `matrix-bridge-beeper-linkedin`
|
||||
- `matrix-bridge-mautrix-facebook`
|
||||
- `matrix-bridge-mautrix-googlechat`
|
||||
- `matrix-bridge-mautrix-telegram`
|
||||
- `matrix-bridge-mautrix-signal`
|
||||
|
||||
@@ -1,3 +1,6 @@
|
||||
# We explicitly ask for your server's external IP address, because the same value is used for configuring coturn.
|
||||
# If you'd rather use a local IP here, make sure to set up `matrix_coturn_turn_external_ip_address`.
|
||||
#
|
||||
# To connect using a non-root user (and elevate to root with sudo later),
|
||||
# replace `ansible_ssh_user=root` with something like this: `ansible_ssh_user=username ansible_become=true ansible_become_user=root`.
|
||||
# If sudo requires a password, either add `ansible_become_password=PASSWORD_HERE` to the host line
|
||||
@@ -15,4 +18,4 @@
|
||||
# to the host line below.
|
||||
|
||||
[matrix_servers]
|
||||
matrix.example.com ansible_host=<your-server's domain name or IP address> ansible_ssh_user=root
|
||||
matrix.example.com ansible_host=<your-server's external IP address> ansible_ssh_user=root
|
||||
|
||||
@@ -19,4 +19,4 @@ To get started, first follow the [front the integrated reverse-proxy webserver w
|
||||
`matrix-domain.conf` contains configuration for the Matrix domain, which handles both the Client-Server API (port `443`) and the Matrix Federation API (port `8448`).
|
||||
|
||||
`matrix-client-element.conf` is an example for when you're hosting Element Web at `element.example.com`.
|
||||
This configuration can also be used as an example for handling other domains, depending on the services you enable with the playbook (e.g. `etherpad.example.com`, etc).
|
||||
This configuration can also be used as an example for handling other domains, depending on the services you enable with the playbook (e.g. `dimension.example.com`, etc).
|
||||
|
||||
@@ -33,12 +33,6 @@
|
||||
ProxyRequests Off
|
||||
ProxyVia On
|
||||
RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
|
||||
ProxyTimeout 86400
|
||||
|
||||
RewriteEngine On
|
||||
RewriteCond %{HTTP:Connection} Upgrade [NC]
|
||||
RewriteCond %{HTTP:Upgrade} websocket [NC]
|
||||
RewriteRule /(.*) ws://127.0.0.1:81/$1 [P,L]
|
||||
|
||||
AllowEncodedSlashes NoDecode
|
||||
ProxyPass / http://127.0.0.1:81/ retry=0 nocanon
|
||||
|
||||
@@ -23,7 +23,7 @@ If Matrix federation is enabled, then you will need to make changes to [NPM's Do
|
||||
|
||||
You'll need to create two proxy hosts in NPM for Matrix web and federation traffic.
|
||||
|
||||
Open the 'Proxy Hosts' page in the NPM web interface and select `Add Proxy Host`, the first being for Matrix web traffic. Apply the proxy's configuration like this:
|
||||
Open the 'Proxy Hosts' page in the NPM web interface and select `Add Proxy Host`, the first being for Matrix web traffic. Apply the proxys configuration like this:
|
||||
|
||||
```md
|
||||
# Details
|
||||
@@ -44,7 +44,7 @@ Custom Nginx Configuration:
|
||||
client_max_body_size 50M;
|
||||
```
|
||||
|
||||
Again, under the 'Proxy Hosts' page select `Add Proxy Host`, this time for your federation traffic. Apply the proxy's configuration like this:
|
||||
Again, under the 'Proxy Hosts' page select `Add Proxy Host`, this time for your federation traffic. Apply the proxys configuration like this:
|
||||
|
||||
```md
|
||||
# Details
|
||||
|
||||
@@ -22,4 +22,4 @@ Copy the [matrix.conf](matrix.conf) file to your nginx server's filesystem, modi
|
||||
|
||||
This configuration **disables SSL certificate retrieval**, so you will **need to obtain SSL certificates manually** (e.g. by using [certbot](https://certbot.eff.org/)) and set the appropriate path in `matrix.conf`. In the example nginx configuration, a single certificate is used for all subdomains (`matrix.example.com`, `element.example.com`, etc.). For your setup, may wish to change this and use separate `server` blocks and separate certificate files for each host.
|
||||
|
||||
Also note that your copy of the `matrix.conf` file has to be adapted to whatever services you are using. For example, remove `element.example.com` from the `server_name` list if you don't use [Element Web](../../../docs/configuring-playbook-client-element-web.md) client or add `etherpad.example.com` to it if you do use [Etherpad](../../../docs/configuring-playbook-etherpad.md).
|
||||
Also note that your copy of the `matrix.conf` file has to be adapted to whatever services you are using. For example, remove `element.example.com` from the `server_name` list if you don't use [Element Web](../../../docs/configuring-playbook-client-element-web.md) client or add `dimension.example.com` to it if you do use the [Dimension](../../../docs/configuring-playbook-dimension.md) integration manager.
|
||||
|
||||
@@ -19,7 +19,7 @@ server {
|
||||
# TODO: add/remove services and their subdomains if you use/don't use them
|
||||
# this example is using hosting something on the base domain and an Element Web client, so example.com and element.example.com are listed in addition to matrix.example.com
|
||||
# if you don't use those, you can remove them
|
||||
# if you use e.g. Etherpad on etherpad.example.com, add etherpad.example.com to the server_name list
|
||||
# if you use e.g. Dimension on dimension.example.com, add dimension.example.com to the server_name list
|
||||
server_name example.com matrix.example.com element.example.com;
|
||||
|
||||
location / {
|
||||
|
||||
@@ -53,10 +53,18 @@ devture_systemd_docker_base_ipv6_enabled: true
|
||||
# The value used here must be shorter than 100 characters.
|
||||
postgres_connection_password: ''
|
||||
|
||||
# You can limit heavy room joins on constrained hosts.
|
||||
# See:
|
||||
# docs/configuring-playbook-synapse.md#limit-joining-heavy-rooms-on-constrained-hosts
|
||||
# By default, we configure coturn's external IP address using the value specified for `ansible_host` in your `inventory/hosts` file.
|
||||
# If this value is an external IP address, you can skip this section.
|
||||
#
|
||||
# matrix_synapse_limit_remote_rooms_enabled: true
|
||||
# matrix_synapse_limit_remote_rooms_complexity: 1.0
|
||||
# matrix_synapse_limit_remote_rooms_admins_can_join: false
|
||||
# If `ansible_host` is not the server's external IP address, you have 2 choices:
|
||||
# 1. Uncomment the line below, to allow IP address auto-detection to happen (more on this below)
|
||||
# 2. Uncomment and adjust the line below to specify an IP address manually
|
||||
#
|
||||
# By default, auto-detection will be attempted using the `https://ifconfig.co/json` API.
|
||||
# Default values for this are specified in `matrix_coturn_turn_external_ip_address_auto_detection_*` variables in the coturn role
|
||||
# (see `roles/custom/matrix-coturn/defaults/main.yml`).
|
||||
#
|
||||
# If your server has multiple IP addresses, you may define them in another variable which allows a list of addresses.
|
||||
# Example: `matrix_coturn_turn_external_ip_addresses: ['1.2.3.4', '4.5.6.7']`
|
||||
#
|
||||
# matrix_coturn_turn_external_ip_address: ''
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -20,7 +20,7 @@ Currently, we support translation of:
|
||||
Organization of this `i18n` directory is as follows:
|
||||
|
||||
- [PUBLISHED_LANGUAGES](PUBLISHED_LANGUAGES): a list of languages that we publish translations for (in the [translations/](translations/) directory)
|
||||
- [.gitignore](.gitignore): a list of files and directories to ignore in the `i18n` directory. We intentionally ignore translated results (`translations/<language>` directories) for languages that are still in progress. We only [publish translations in a new language](#publish-translations-in-a-new-language) when the translation progresses beyond a certain threshold.
|
||||
- [.gitignore](.gitignore): a list of files and directories to ignore in the `i18n` directory. We intentionaly ignore translated results (`translations/<language>` directories) for languages taht are still in progress. We only [publish translations in a new language](#publish-translations-in-a-new-language) when the translation progresses beyond a certain threshold.
|
||||
- [justfile](justfile): a list of recipes for [just](https://github.com/casey/just) command runner
|
||||
- [requirements.txt](requirements.txt): a list of Python packages required to work with translations
|
||||
- [translation-templates/](translation-templates/): a list of English translation templates - strings extracted from Markdown files
|
||||
|
||||
@@ -1,134 +0,0 @@
|
||||
# SOME DESCRIPTIVE TITLE.
|
||||
# Copyright (C) 2018-2025, Slavi Pantaleev, Aine Etke, MDAD community
|
||||
# members
|
||||
# This file is distributed under the same license as the
|
||||
# matrix-docker-ansible-deploy package.
|
||||
# FIRST AUTHOR <EMAIL@ADDRESS>, 2025.
|
||||
#
|
||||
#, fuzzy
|
||||
msgid ""
|
||||
msgstr ""
|
||||
"Project-Id-Version: matrix-docker-ansible-deploy \n"
|
||||
"Report-Msgid-Bugs-To: \n"
|
||||
"POT-Creation-Date: 2025-01-27 09:54+0200\n"
|
||||
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
|
||||
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
|
||||
"Language: bg\n"
|
||||
"Language-Team: bg <LL@li.org>\n"
|
||||
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
|
||||
"MIME-Version: 1.0\n"
|
||||
"Content-Type: text/plain; charset=utf-8\n"
|
||||
"Content-Transfer-Encoding: 8bit\n"
|
||||
"Generated-By: Babel 2.16.0\n"
|
||||
|
||||
#: ../../../docs/configuring-playbook-continuwuity.md:1
|
||||
msgid "Configuring continuwuity (optional)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-continuwuity.md:3
|
||||
msgid "The playbook can install and configure the [continuwuity](https://continuwuity.org/) Matrix server for you."
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-continuwuity.md:5
|
||||
msgid "See the project's [documentation](https://continuwuity.org/) to learn what it does and why it might be useful to you."
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-continuwuity.md:7
|
||||
msgid "By default, the playbook installs [Synapse](https://github.com/element-hq/synapse) as it's the only full-featured Matrix server at the moment. If that's okay, you can skip this document."
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-continuwuity.md:9
|
||||
msgid "💡 **Note**: continuwuity is a fork of [conduwuit](./configuring-playbook-conduwuit.md), which the playbook also supports."
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-continuwuity.md:11
|
||||
msgid "⚠️ **Warnings**:"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-continuwuity.md:13
|
||||
msgid "**You can't switch an existing Matrix server's implementation** (e.g. Synapse -> continuwuity). Proceed below only if you're OK with losing data or you're dealing with a server on a new domain name, which hasn't participated in the Matrix federation yet."
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-continuwuity.md:15
|
||||
msgid "**Homeserver implementations other than Synapse may not be fully functional**. The playbook may also not assist you in an optimal way (like it does with Synapse). Make yourself familiar with the downsides before proceeding"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-continuwuity.md:17
|
||||
msgid "Adjusting the playbook configuration"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-continuwuity.md:19
|
||||
msgid "To use continuwuity, you **generally** need to adjust the `matrix_homeserver_implementation: synapse` configuration on your `inventory/host_vars/matrix.example.com/vars.yml` file as below:"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-continuwuity.md:33
|
||||
msgid "Extending the configuration"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-continuwuity.md:35
|
||||
msgid "There are some additional things you may wish to configure about the server."
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-continuwuity.md:37
|
||||
msgid "Take a look at:"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-continuwuity.md:39
|
||||
msgid "`roles/custom/matrix-continuwuity/defaults/main.yml` for some variables that you can customize via your `vars.yml` file"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-continuwuity.md:40
|
||||
msgid "`roles/custom/matrix-continuwuity/templates/continuwuity.toml.j2` for the server's default configuration"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-continuwuity.md:42
|
||||
msgid "There are various Ansible variables that control settings in the `continuwuity.toml` file."
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-continuwuity.md:44
|
||||
msgid "If a specific setting you'd like to change does not have a dedicated Ansible variable, you can either submit a PR to us to add it, or you can [override the setting using an environment variable](https://continuwuity.org/configuration#environment-variables) using `matrix_continuwuity_environment_variables_extension`. For example:"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-continuwuity.md:52
|
||||
msgid "Creating the first user account"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-continuwuity.md:54
|
||||
msgid "Unlike other homeserver implementations (like Synapse and Dendrite), continuwuity does not support creating users via the command line or via the playbook."
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-continuwuity.md:56
|
||||
msgid "If you followed the instructions above (see [Adjusting the playbook configuration](#adjusting-the-playbook-configuration)), you should have registration enabled and protected by a registration token."
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-continuwuity.md:58
|
||||
msgid "This should allow you to create the first user account via any client (like [Element Web](./configuring-playbook-client-element-web.md)) which supports creating users."
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-continuwuity.md:60
|
||||
msgid "The **first user account that you create will be marked as an admin** and **will be automatically invited to an admin room**."
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-continuwuity.md:63
|
||||
msgid "Configuring bridges / appservices"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-continuwuity.md:65
|
||||
msgid "For other homeserver implementations (like Synapse and Dendrite), the playbook automatically registers appservices (for bridges, bots, etc.) with the homeserver."
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-continuwuity.md:67
|
||||
msgid "For continuwuity, you will have to manually register appservices using the [`!admin appservices register` command](https://continuwuity.org/appservices#set-up-the-appservice---general-instructions) sent to the server bot account."
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-continuwuity.md:69
|
||||
msgid "The server's bot account has a Matrix ID of `@conduit:example.com` (not `@continuwuity:example.com`!) due to continuwuity's historical legacy. Your first user account would already have been invited to an admin room with this bot."
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-continuwuity.md:72
|
||||
msgid "Find the appservice file you'd like to register. This can be any `registration.yaml` file found in the `/matrix` directory, for example `/matrix/mautrix-signal/bridge/registration.yaml`."
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-continuwuity.md:74
|
||||
msgid "Then, send its content to the existing admin room:"
|
||||
msgstr ""
|
||||
@@ -435,7 +435,7 @@ msgid "We **don't** ask you to [run the `syn2mas` migration advisor command](htt
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-matrix-authentication-service.md:340
|
||||
msgid "You can invoke the `syn2mas` tool via the playbook by running the playbook's `matrix-authentication-service-mas-cli-syn2mas` tag. We recommend first doing a [dry-run](#performing-a-syn2mas-dry-run) and then a [real migration](#performing-a-real-syn2mas-migration)."
|
||||
msgid "You can invoke the `syn2mas` tool via the playbook by running the playbook's `matrix-authentication-service-syn2mas` tag. We recommend first doing a [dry-run](#performing-a-syn2mas-dry-run) and then a [real migration](#performing-a-real-syn2mas-migration)."
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-matrix-authentication-service.md:342
|
||||
@@ -535,7 +535,7 @@ msgid "you've performed a [syn2mas dry-run](#performing-a-syn2mas-dry-run) and d
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-matrix-authentication-service.md:401
|
||||
msgid "To perform a real migration, run the `matrix-authentication-service-mas-cli-syn2mas` tag **without** the `matrix_authentication_service_syn2mas_migrate_dry_run` variable:"
|
||||
msgid "To perform a real migration, run the `matrix-authentication-service-syn2mas` tag **without** the `matrix_authentication_service_syn2mas_dry_run` variable:"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-matrix-authentication-service.md:407
|
||||
|
||||
@@ -434,7 +434,7 @@ msgid "We **don't** ask you to [run the `syn2mas` migration advisor command](htt
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-matrix-authentication-service.md:340
|
||||
msgid "You can invoke the `syn2mas` tool via the playbook by running the playbook's `matrix-authentication-service-mas-cli-syn2mas` tag. We recommend first doing a [dry-run](#performing-a-syn2mas-dry-run) and then a [real migration](#performing-a-real-syn2mas-migration)."
|
||||
msgid "You can invoke the `syn2mas` tool via the playbook by running the playbook's `matrix-authentication-service-syn2mas` tag. We recommend first doing a [dry-run](#performing-a-syn2mas-dry-run) and then a [real migration](#performing-a-real-syn2mas-migration)."
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-matrix-authentication-service.md:342
|
||||
@@ -534,7 +534,7 @@ msgid "you've performed a [syn2mas dry-run](#performing-a-syn2mas-dry-run) and d
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-matrix-authentication-service.md:401
|
||||
msgid "To perform a real migration, run the `matrix-authentication-service-mas-cli-syn2mas` tag **without** the `matrix_authentication_service_syn2mas_migrate_dry_run` variable:"
|
||||
msgid "To perform a real migration, run the `matrix-authentication-service-syn2mas` tag **without** the `matrix_authentication_service_syn2mas_dry_run` variable:"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../docs/configuring-playbook-matrix-authentication-service.md:407
|
||||
|
||||
@@ -1,27 +1,27 @@
|
||||
alabaster==1.0.0
|
||||
babel==2.18.0
|
||||
certifi==2026.2.25
|
||||
charset-normalizer==3.4.4
|
||||
click==8.3.1
|
||||
docutils==0.22.4
|
||||
idna==3.11
|
||||
babel==2.17.0
|
||||
certifi==2025.1.31
|
||||
charset-normalizer==3.4.1
|
||||
click==8.1.8
|
||||
docutils==0.21.2
|
||||
idna==3.10
|
||||
imagesize==1.4.1
|
||||
Jinja2==3.1.6
|
||||
linkify-it-py==2.0.3
|
||||
markdown-it-py==4.0.0
|
||||
MarkupSafe==3.0.3
|
||||
mdit-py-plugins==0.5.0
|
||||
markdown-it-py==3.0.0
|
||||
MarkupSafe==3.0.2
|
||||
mdit-py-plugins==0.4.2
|
||||
mdurl==0.1.2
|
||||
myst-parser==5.0.0
|
||||
packaging==26.0
|
||||
Pygments==2.19.2
|
||||
PyYAML==6.0.3
|
||||
requests==2.32.5
|
||||
setuptools==82.0.0
|
||||
snowballstemmer==3.0.1
|
||||
Sphinx==9.1.0
|
||||
sphinx-intl==2.3.2
|
||||
sphinx-markdown-builder==0.6.9
|
||||
myst-parser==4.0.1
|
||||
packaging==24.2
|
||||
Pygments==2.19.1
|
||||
PyYAML==6.0.2
|
||||
requests==2.32.3
|
||||
setuptools==78.1.0
|
||||
snowballstemmer==2.2.0
|
||||
Sphinx==8.2.3
|
||||
sphinx-intl==2.3.1
|
||||
sphinx-markdown-builder==0.6.8
|
||||
sphinxcontrib-applehelp==2.0.0
|
||||
sphinxcontrib-devhelp==2.0.0
|
||||
sphinxcontrib-htmlhelp==2.1.0
|
||||
@@ -30,4 +30,4 @@ sphinxcontrib-qthelp==2.0.0
|
||||
sphinxcontrib-serializinghtml==2.0.0
|
||||
tabulate==0.9.0
|
||||
uc-micro-py==1.0.3
|
||||
urllib3==2.6.3
|
||||
urllib3==2.3.0
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,5 +1,5 @@
|
||||
# SOME DESCRIPTIVE TITLE.
|
||||
# Copyright (C) 2018-2026, Slavi Pantaleev, Aine Etke, MDAD community members
|
||||
# Copyright (C) 2018-2025, Slavi Pantaleev, Aine Etke, MDAD community members
|
||||
# This file is distributed under the same license as the matrix-docker-ansible-deploy package.
|
||||
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
|
||||
#
|
||||
@@ -8,7 +8,7 @@ msgid ""
|
||||
msgstr ""
|
||||
"Project-Id-Version: matrix-docker-ansible-deploy \n"
|
||||
"Report-Msgid-Bugs-To: \n"
|
||||
"POT-Creation-Date: 2026-02-13 10:32+0000\n"
|
||||
"POT-Creation-Date: 2025-01-27 09:54+0200\n"
|
||||
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
|
||||
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
|
||||
"Language-Team: LANGUAGE <LL@li.org>\n"
|
||||
@@ -17,7 +17,7 @@ msgstr ""
|
||||
"Content-Transfer-Encoding: 8bit\n"
|
||||
|
||||
#: ../../../README.md:1
|
||||
msgid "[](https://matrix.to/#/#matrix-docker-ansible-deploy:devture.com) [](https://liberapay.com/s.pantaleev/donate) [](https://api.reuse.software/info/github.com/spantaleev/matrix-docker-ansible-deploy)"
|
||||
msgid "[](https://matrix.to/#/#matrix-docker-ansible-deploy:devture.com) [](https://liberapay.com/s.pantaleev/donate)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:1
|
||||
@@ -28,10 +28,6 @@ msgstr ""
|
||||
msgid "donate"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:1
|
||||
msgid "REUSE status"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:3
|
||||
msgid "Matrix (An open network for secure, decentralized communication) server setup using Ansible and Docker"
|
||||
msgstr ""
|
||||
@@ -177,15 +173,15 @@ msgid "[Link](docs/configuring-playbook-conduit.md)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[continuwuity](https://continuwuity.org)"
|
||||
msgid "[conduwuit](https://conduwuit.puppyirl.gay/)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "Storing your data and managing your presence in the [Matrix](http://matrix.org/) network."
|
||||
msgid "Storing your data and managing your presence in the [Matrix](http://matrix.org/) network. conduwuit is a fork of Conduit."
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[Link](docs/configuring-playbook-continuwuity.md)"
|
||||
msgid "[Link](docs/configuring-playbook-conduwuit.md)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
@@ -256,23 +252,11 @@ msgstr ""
|
||||
msgid "[Link](docs/configuring-playbook-client-schildichat-web.md)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[FluffyChat Web](https://fluffychat.im/)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "The cutest messenger in Matrix"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[Link](docs/configuring-playbook-client-fluffychat-web.md)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:70
|
||||
#: ../../../README.md:69
|
||||
msgid "Server Components"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:72
|
||||
#: ../../../README.md:71
|
||||
msgid "Services that run on the server to make the various parts of your installation work."
|
||||
msgstr ""
|
||||
|
||||
@@ -305,7 +289,7 @@ msgid "[Traefik](https://doc.traefik.io/traefik/)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "Web server, listening on ports 80, 443 and 8448 - standing in front of all the other services. [Using your own webserver](docs/configuring-playbook-own-webserver.md) is also possible."
|
||||
msgid "Web server, listening on ports 80, 443 and 8448 - standing in front of all the other services. Using your own webserver [is possible](docs/configuring-playbook-own-webserver.md)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
@@ -336,6 +320,18 @@ msgstr ""
|
||||
msgid "[Link](docs/configuring-playbook-email.md)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[ma1sd](https://github.com/ma1uta/ma1sd)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "Matrix Identity Server"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[Link](docs/configuring-playbook-ma1sd.md)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[ddclient](https://github.com/linuxserver/docker-ddclient)"
|
||||
msgstr ""
|
||||
@@ -348,35 +344,11 @@ msgstr ""
|
||||
msgid "[Link](docs/configuring-playbook-dynamic-dns.md)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[LiveKit Server](https://github.com/livekit/livekit)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "WebRTC server for audio/video calls"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[Link](docs/configuring-playbook-livekit-server.md)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[Livekit JWT Service](https://github.com/livekit/livekit-jwt-service)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "JWT service for integrating [Element Call](./configuring-playbook-element-call.md) with [LiveKit Server](./configuring-playbook-livekit-server.md)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[Link](docs/configuring-playbook-livekit-jwt-service.md)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:85
|
||||
#: ../../../README.md:83
|
||||
msgid "Authentication"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:87
|
||||
#: ../../../README.md:85
|
||||
msgid "Extend and modify how users are authenticated on your homeserver."
|
||||
msgstr ""
|
||||
|
||||
@@ -421,7 +393,7 @@ msgid "[matrix-ldap-registration-proxy](https://gitlab.com/activism.internationa
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "Proxy that handles Matrix registration requests and forwards them to LDAP"
|
||||
msgid "A proxy that handles Matrix registration requests and forwards them to LDAP."
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
@@ -433,7 +405,7 @@ msgid "[matrix-registration](https://github.com/ZerataX/matrix-registration)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "Simple python application to have a token based Matrix registration"
|
||||
msgid "A simple python application to have a token based Matrix registration"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
@@ -441,7 +413,7 @@ msgid "[Link](docs/configuring-playbook-matrix-registration.md)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[Matrix User Verification Service](https://github.com/matrix-org/matrix-user-verification-service)"
|
||||
msgid "[Matrix User Verification Service](https://github.com/matrix-org/matrix-user-verification-service) (UVS)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
@@ -457,18 +429,18 @@ msgid "[synapse-simple-antispam](https://github.com/t2bot/synapse-simple-antispa
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "Spam checker module"
|
||||
msgid "A spam checker module"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[Link](docs/configuring-playbook-synapse-simple-antispam.md)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:99
|
||||
#: ../../../README.md:97
|
||||
msgid "File Storage"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:101
|
||||
#: ../../../README.md:99
|
||||
msgid "Use alternative file storage to the default `media_store` folder."
|
||||
msgstr ""
|
||||
|
||||
@@ -497,18 +469,18 @@ msgid "[matrix-media-repo](https://github.com/turt2live/matrix-media-repo)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "Highly customizable multi-domain media repository for Matrix. Intended for medium to large deployments, this media repo de-duplicates media while being fully compliant with the specification."
|
||||
msgid "matrix-media-repo is a highly customizable multi-domain media repository for Matrix. Intended for medium to large deployments, this media repo de-duplicates media while being fully compliant with the specification."
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[Link](docs/configuring-playbook-matrix-media-repo.md)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:109
|
||||
#: ../../../README.md:107
|
||||
msgid "Bridges"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:111
|
||||
#: ../../../README.md:109
|
||||
msgid "Bridges can be used to connect your Matrix installation with third-party communication networks."
|
||||
msgstr ""
|
||||
|
||||
@@ -584,18 +556,6 @@ msgstr ""
|
||||
msgid "[Link](docs/configuring-playbook-bridge-mautrix-wsproxy.md)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[mautrix-bluesky](https://github.com/mautrix/bluesky)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "Bridge to [Bluesky](https://bsky.social/)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[Link](docs/configuring-playbook-bridge-mautrix-bluesky.md)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[mautrix-twitter](https://github.com/mautrix/twitter)"
|
||||
msgstr ""
|
||||
@@ -724,18 +684,6 @@ msgstr ""
|
||||
msgid "[Link](docs/configuring-playbook-bridge-matrix-bridge-sms.md)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[matrix-steam-bridge](https://github.com/jasonlaguidice/matrix-steam-bridge)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "Bridge to [Steam](https://steampowered.com/)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[Link](docs/configuring-playbook-bridge-steam.md)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[matrix-wechat](https://github.com/duo/matrix-wechat)"
|
||||
msgstr ""
|
||||
@@ -760,6 +708,62 @@ msgstr ""
|
||||
msgid "[Link](docs/configuring-playbook-bridge-heisenbridge.md)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[go-skype-bridge](https://github.com/kelaresg/go-skype-bridge)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "Bridge to [Skype](https://www.skype.com)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[Link](docs/configuring-playbook-bridge-go-skype-bridge.md)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[mx-puppet-slack](https://gitlab.com/mx-puppet/slack/mx-puppet-slack)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "Bridge to [Slack](https://slack.com)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[Link](docs/configuring-playbook-bridge-mx-puppet-slack.md)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[mx-puppet-instagram](https://github.com/Sorunome/mx-puppet-instagram)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "Bridge for Instagram-DMs ([Instagram](https://www.instagram.com/))"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[Link](docs/configuring-playbook-bridge-mx-puppet-instagram.md)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[mx-puppet-twitter](https://github.com/Sorunome/mx-puppet-twitter)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "Bridge for Twitter-DMs ([Twitter](https://twitter.com/))"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[Link](docs/configuring-playbook-bridge-mx-puppet-twitter.md)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[mx-puppet-discord](https://gitlab.com/mx-puppet/discord/mx-puppet-discord)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[Link](docs/configuring-playbook-bridge-mx-puppet-discord.md)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[mx-puppet-groupme](https://gitlab.com/xangelix-pub/matrix/mx-puppet-groupme)"
|
||||
msgstr ""
|
||||
@@ -773,7 +777,7 @@ msgid "[Link](docs/configuring-playbook-bridge-mx-puppet-groupme.md)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[mx-puppet-steam](https://codeberg.org/icewind/mx-puppet-steam)"
|
||||
msgid "[mx-puppet-steam](https://github.com/icewind1991/mx-puppet-steam)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
@@ -796,11 +800,11 @@ msgstr ""
|
||||
msgid "[Link](docs/configuring-playbook-bridge-postmoogle.md)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:140
|
||||
#: ../../../README.md:141
|
||||
msgid "Bots"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:142
|
||||
#: ../../../README.md:143
|
||||
msgid "Bots provide various additional functionality to your installation."
|
||||
msgstr ""
|
||||
|
||||
@@ -809,7 +813,7 @@ msgid "[baibot](https://github.com/etkecc/baibot)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "Bot that exposes the power of [AI](https://en.wikipedia.org/wiki/Artificial_intelligence) / [Large Language Models](https://en.wikipedia.org/wiki/Large_language_model) to you"
|
||||
msgid "A bot that exposes the power of [AI](https://en.wikipedia.org/wiki/Artificial_intelligence) / [Large Language Models](https://en.wikipedia.org/wiki/Large_language_model) to you"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
@@ -845,7 +849,7 @@ msgid "[maubot](https://github.com/maubot/maubot)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "Plugin-based Matrix bot system"
|
||||
msgid "A plugin-based Matrix bot system"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
@@ -857,7 +861,7 @@ msgid "[Honoroit](https://github.com/etkecc/honoroit)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "Helpdesk bot"
|
||||
msgid "A helpdesk bot"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
@@ -869,7 +873,7 @@ msgid "[Mjolnir](https://github.com/matrix-org/mjolnir)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "Moderation tool for Matrix"
|
||||
msgid "A moderation tool for Matrix"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
@@ -881,7 +885,7 @@ msgid "[Draupnir](https://github.com/the-draupnir-project/Draupnir)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "Moderation tool for Matrix (Fork of Mjolnir)"
|
||||
msgid "A moderation tool for Matrix (Fork of Mjolnir)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
@@ -900,11 +904,11 @@ msgstr ""
|
||||
msgid "[Link](docs/configuring-playbook-bot-buscarron.md)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:155
|
||||
#: ../../../README.md:156
|
||||
msgid "Administration"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:157
|
||||
#: ../../../README.md:158
|
||||
msgid "Services that help you in administrating and monitoring your Matrix installation."
|
||||
msgstr ""
|
||||
|
||||
@@ -937,7 +941,7 @@ msgid "[synapse-admin](https://github.com/etkecc/synapse-admin)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "Web UI tool for administrating users and rooms on your Matrix server"
|
||||
msgid "A web UI tool for administrating users and rooms on your Matrix server"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
@@ -953,7 +957,7 @@ msgid "Consists of the [Prometheus](https://prometheus.io) time-series database
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[Link](docs/configuring-playbook-prometheus-grafana.md) (for [prometheus-nginxlog-exporter](docs/configuring-playbook-prometheus-grafana.md#enable-metrics-and-graphs-for-nginx-logs-optional))"
|
||||
msgid "[Link](docs/configuring-playbook-prometheus-grafana.md) (for [prometheus-nginxlog-exporter](docs/configuring-playbook-prometheus-nginxlog.md))"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
@@ -992,20 +996,32 @@ msgstr ""
|
||||
msgid "[Link](docs/configuring-playbook-synapse-usage-exporter.md)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:169
|
||||
#: ../../../README.md:170
|
||||
msgid "Misc"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:171
|
||||
#: ../../../README.md:172
|
||||
msgid "Various services that don't fit any other categories."
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[sliding-sync](https://github.com/matrix-org/sliding-sync)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "(Superseded by Simplified Sliding Sync integrated into Synapse > `1.114` and Conduit > `0.6.0`) Sliding Sync support for clients which require it (e.g. old Element X versions before Simplified Sliding Sync was developed)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[Link](docs/configuring-playbook-sliding-sync-proxy.md)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[synapse_auto_accept_invite](https://github.com/matrix-org/synapse-auto-accept-invite)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "Synapse module to automatically accept invites"
|
||||
msgid "A Synapse module to automatically accept invites."
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
@@ -1017,7 +1033,7 @@ msgid "[synapse_auto_compressor](https://github.com/matrix-org/rust-synapse-comp
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "Cli tool that automatically compresses `state_groups` database table in background"
|
||||
msgid "A cli tool that automatically compresses `state_groups` database table in background."
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
@@ -1036,24 +1052,12 @@ msgstr ""
|
||||
msgid "[Link](docs/configuring-playbook-matrix-corporal.md)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[Matrix.to](https://github.com/matrix-org/matrix.to)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "Simple URL redirection service for the Matrix ecosystem"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[Link](docs/configuring-playbook-matrixto.md)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[Etherpad](https://etherpad.org)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "Open source collaborative text editor"
|
||||
msgid "An open source collaborative text editor"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
@@ -1065,7 +1069,7 @@ msgid "[Jitsi](https://jitsi.org/)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "Open source video-conferencing platform"
|
||||
msgid "An open source video-conferencing platform"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
@@ -1077,7 +1081,7 @@ msgid "[Cactus Comments](https://cactus.chat)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "Federated comment system built on Matrix"
|
||||
msgid "A federated comment system built on Matrix"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
@@ -1089,7 +1093,7 @@ msgid "[Pantalaimon](https://github.com/matrix-org/pantalaimon)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "E2EE aware proxy daemon"
|
||||
msgid "An E2EE aware proxy daemon"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
@@ -1120,18 +1124,6 @@ msgstr ""
|
||||
msgid "[Link](docs/configuring-playbook-ntfy.md)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[Element Call](https://github.com/element-hq/element-call)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "A native Matrix video conferencing application"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:0
|
||||
msgid "[Link](docs/configuring-playbook-element-call.md)"
|
||||
msgstr ""
|
||||
|
||||
#: ../../../README.md:187
|
||||
msgid "🆕 Changes"
|
||||
msgstr ""
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user